Show returning visitors what they had going, last-viewed products, cart contents, loyalty progress, without making them sign in or start over
A returning visitor has a history the site usually ignores. They viewed three products last week, left two items in a cart, and are halfway to a loyalty tier, and on return they see a homepage that knows none of it. The information exists, scattered across a cookie, a cart table, and a loyalty balance, but it is not assembled and surfaced, so the visitor restarts cold and the site forfeits the easiest personalization there is: showing people what they already had going.
These used to be treated as three separate features (last-viewed recall, cart persistence, loyalty status display), each built once and maintained separately, which is why they tend to be inconsistent: the cart persists but the last-viewed does not, or the loyalty status shows when logged in but vanishes for the recognized-but-anonymous visitor. They are one capability: carry the visitor's relevant state across sessions and surface it, gated on consent, with clean merge behavior and a sensible default when there is nothing to carry.
This recipe treats cross-session state as one surface rather than three disconnected features.
Returning visitors see their carried-over state (recently viewed, pending cart, loyalty progress) without re-authenticating or re-finding it. The metric is returning-visitor engagement: whether recognized returners re-engage with what they had going, which lifts most in considered-purchase categories where people genuinely return to deliberate and where a pending cart or a viewed product is a live consideration rather than a stale impulse. The size depends on how much of the audience returns within the recognition window, which Safari's cookie limits cap for a meaningful share, so the realistic gain is concentrated in the recognizable, returning portion rather than across all traffic.
The second outcome is consistency: the cart, the last-viewed, and the loyalty status all behave the same way for the same visitor, instead of one persisting and another forgetting.
A state store the site can read at request time (CDP, session store, or warehouse-backed profile) plus a personalization layer that surfaces the carried state in the page. Composable stacks suit this because the state lives in one place all surfaces read, which is what makes the cart, last-viewed, and loyalty consistent rather than each maintained in its own silo. The capability that decides whether the experience feels good is request-time rehydration latency: the carried state has to render in the first paint, because state that appears after a flash of the cold page reads as a glitch rather than as the site remembering.
Compare the tools on Martech Stack Builder
Product owns where carried-over state appears, the cart-merge behavior, and the no-state experience, treating the last as a real design rather than an afterthought. Data engineering owns the persistent state store, the request-time rehydration, the consent gate, and the cart-merge logic that reconciles anonymous and authenticated carts. Marketing ops decides which state is worth surfacing where, since surfacing everything is as bad as surfacing nothing. The recipe ships in weeks because the components are standard first-party data; the work is in the cart-merge edge cases and getting the consent gate right, not in anything novel.
Work in this order. Cart, history and loyalty are one capability over one store; a site that half-remembers the visitor is worse than one that consistently does not.
Session history rehydration covers steps 1 to 4, consent-scoped signal collection step 5, visitor state personalization step 6, and fallback content strategy step 7.
The first failure is the cart-merge collision. A visitor with items in an anonymous cart who then logs in, where they also have a saved cart, needs deterministic merge rules, or items duplicate, disappear, or silently overwrite. This is the classic edge case that makes cart persistence feel broken, and it has to be designed rather than left to whichever cart loads last.
The second is inconsistency across the surfaced states. If the cart persists but the last-viewed does not, or loyalty status shows only when authenticated, the visitor experiences a site that half-remembers them, which is worse than one that consistently does not. Treating the three as one capability over one state store is what keeps them consistent.
The third is surfacing without consent or beyond freshness. Carrying state across sessions is recognition, subject to the consent captured at first visit, and a persistent identifier that has aged out (Safari's window) should degrade to the no-state experience rather than surfacing stale carryover. The consent gate and the freshness check are what keep the recognition defensible and current.
The Workshop works out with your team which of these matter for your stack right now, and what to do first: a 90-minute session with the people who own the decision.
The one state store the cart, last-viewed, and loyalty all read from, the cart-merge rules that keep it from breaking, the consent gate that keeps recognition defensible, and the no-state experience as its own design: those are the decisions that turn three inconsistent features into one site that remembers.
Did this recipe match your situation?Anonymous response. Sign up to leave a longer note tied to your account.
Show account-relevant content to known and reverse-IP-identified B2B visitors, with explicit handling of the wrong-match case
Give the AI a memory of each customer that is curated and decaying, not a raw event firehose it cannot use and should not keep
Swap homepage content by visitor location for store availability, regional pricing, and local campaigns, with a clean default when location is unknown