ShieldLabs
Back to blog

Persistent carts and preferences: keeping state for logged-out returning visitors

Persistent carts and preferences: a returning device is recognized and its saved cart and settings are restored, without a login or a durable cookie

Last updated on August 16, 2026 · 8 min read

A shopper fills a cart, gets distracted, and comes back three days later to an empty cart and a store that has forgotten every preference they set. They were not logged in, and the cookie that held their state expired or was cleared, so the site treats them as brand new. That reset is expensive: Baymard Institute puts the average online cart-abandonment rate at about 70 percent, and a returning visitor arriving to a blank slate is one of the quiet reasons why. Keeping a cart and preferences persistent for a logged-out visitor comes down to one capability: recognizing that the same device is back, so you can restore what they left without asking them to sign in.

Key takeaways

  • A persistent cart keeps a returning visitor's items and settings across sessions, so a logged-out shopper does not come back to an empty cart.
  • The usual store, a client-side cookie, is short-lived now, so a visitor who returns after a few days finds their cart and preferences gone.
  • Recognizing the returning device is what restores the state. The same device coming back is the key you use to bring the saved cart and preferences forward.
  • It works without a login. A durable device identifier recognizes the returning device even in incognito and after cleared cookies, because it is derived from the device rather than stored in a cookie.
  • Recognition is a signal your store consumes: you get a durable device identifier, and your app stores the cart against it and restores it on return.

What is a persistent cart?

A persistent cart is a shopping cart whose contents survive across sessions and devices-visits, so a returning shopper finds their items still waiting instead of starting over. For a logged-in customer this is easy, the cart is saved against the account. The hard case, and the common one, is the shopper who is not signed in. Most carts are built by anonymous visitors, and if their cart only lives in a cookie, it disappears the moment that cookie expires or is cleared. The same is true of the preferences a shopper sets along the way, currency, language, size, shipping region, or a filtered view, all of which reset to defaults on the next visit.

Persistence for an anonymous shopper therefore depends on recognizing the returning visit. If you can tell that the same device is back, you can look up the cart and preferences you saved for it and bring them forward. If you cannot, every return is a cold start, and the cart you spent acquisition budget to fill is gone.

Why carts and preferences reset

The state resets because the two things a store leans on to remember an anonymous shopper, a cookie and a login, are both weak on the visits that matter.

  • Cookies are short-lived by design now. Browser privacy protections cap how long a script-set cookie survives. Safari's Intelligent Tracking Prevention limits them to seven days, and as little as 24 hours in some cases. A shopper who returns a week later has already lost the cookie that held their cart.
  • Shoppers browse logged out. The comparison, the wishlist-building, the second and third visit before buying, mostly happen without an account. Asking a shopper to sign in just to keep a cart adds the exact friction that loses the sale.
  • Storage gets cleared. Incognito windows, cleared browsing data, and privacy extensions wipe the local store a cart depends on.

The cookie is fragile even when a shopper does nothing at all. A 2025 study presented at the Internet Measurement Conference measured 20,000 sites and found third-party scripts overwriting or deleting first-party cookies on 32 percent of them, so the small file holding a cart can be clobbered by another script on the page before the shopper ever returns.

So the shopper who is most worth remembering, a returning one who already built a cart, is precisely the one a cookie-based store forgets. Recovering that cart is not a storage problem, it is a recognition problem.

Recognizing the returning device to restore state

What persists when the cookie does not is the device. A derived, durable device identifier recognizes the same device on its next visit even after the cookie is cleared and the IP has changed, which is exactly the moment a cookie-based cart is lost. That recognition is the key you save the cart against and look it up by on return. The mechanism behind it, recognizing a device without cookies, is the same cookieless device identification that powers the broader personalization for anonymous visitors case, applied here to the specific job of bringing a cart and preferences back.

The flow is simple. On each visit, the device is recognized and you get a stable device_id. You store the cart, the wishlist, and the preferences against that device_id in your own system. When the device returns, you look them up and restore them, no login, no long-lived cookie. Because device_id is derived from the device rather than a cookie, it holds in incognito and after cleared cookies, and it recognizes the same device across months rather than the days a cookie now lasts, which is exactly what a returning shopper needs.

When we tested this in practice, the split held up: a returning device was recognized after its cookies were cleared, its connection had switched, and even inside an incognito window, because the identifier is derived from the device rather than stored where a browser can erase it. That is the exact failure a cookie hits after Safari began capping script-set cookies to as little as a day in 2020, so the returning shopper a cookie forgets is the one a derived device signal still brings back to a full cart.

What you can persist with a recognized device

Once a returning device is recognizable, the state worth carrying across sessions becomes restorable:

  • The cart and wishlist. Bring back the items a shopper added last time, so a return picks up where the last visit ended instead of at an empty cart.
  • Store preferences. Restore currency, language, shipping region, and size, the settings a shopper should never have to re-enter, so the store feels set up for them on arrival.
  • Browsing context. Reinstate a filtered or sorted view, a recently-viewed row, or the category they were deep in, so the return is continuous.
  • Where they left off in a flow. Resume a multi-step checkout or configuration rather than restarting it.

Each of these is a session your store would otherwise lose to a reset, and none of them asks the shopper to log in. The single requirement is recognizing that the device is back.

The practical limits

Recognition is probabilistic, up to 99 percent rather than a guaranteed unique ID, and a deliberately privacy-hardened session offers less to read, so a return that cannot be recognized confidently should simply start fresh rather than guess. A device shared by two people in a household reads as one returning device, so the cart follows the device.

That also sets a sensible boundary on what to restore. Bringing back a cart and store preferences for a recognized device is low-risk and welcome, while anything sensitive, a payment or a subscription change, stays behind a real login. Kept to that line, device-level persistence recovers the carts a cookie loses, on the visits where a returning shopper is most worth remembering.

Persistent carts and preferences with ShieldLabs

ShieldLabs gives your store the durable device signal that persistence needs. You add one JavaScript snippet, and each visit returns a persistent device_id that is derived from the device, so it survives a cleared cookie, a rotated IP, and incognito, and recognizes the same device across months. You save the cart, wishlist, and preferences against that device_id in your own system, and when the device returns you look them up and restore them, with no sign-in step and no dependence on a long-lived cookie.

ShieldLabs recognizes the returning device and hands you the identifier and its confidence; your store keeps the cart and decides what to restore. You read the signal through the API and webhooks, so the storage and the restoration logic stay in your application where they belong. Recognition is probabilistic, up to 99 percent rather than a guaranteed ID, and a deliberately privacy-hardened session can offer less to read, which is why it is a signal your store weighs rather than a verdict. The same recognition layer powers the wider returning-user experience and ecommerce cases. The free tier covers your first 5,000 identifications.

Sources

  1. Baymard Institute: 44 Cart Abandonment Rate Statistics (average around 70%)
  2. WebKit: Full Third-Party Cookie Blocking and More (Intelligent Tracking Prevention)
  3. Bahrami, Fass, and Shafiq: CookieGuard: Characterizing and Isolating the First-Party Cookie Jar (IMC 2025)
  4. Wikipedia: Device fingerprint

Frequently asked questions

What is a persistent cart?
A persistent cart keeps a shopper's items across sessions, so a returning visitor finds their cart still full instead of starting over. For a logged-in customer the cart is saved against the account. For an anonymous shopper it depends on recognizing the returning visit, because if the cart only lives in a cookie it disappears when that cookie expires or is cleared. Recognizing the returning device is what lets an anonymous cart persist.
How do you keep a cart across sessions without a login?
You recognize the device behind the visit. A derived, durable device identifier recognizes the same device on its return even after the cookie is cleared and the IP has changed, so you can save the cart against that identifier and restore it on the next visit. That works without a sign-in and without a long-lived cookie, as long as you treat the recognition as a confident signal and start fresh when a return cannot be recognized.
Why do carts get emptied for logged-out shoppers?
Because the cart usually lives in a client-side cookie, and browser privacy protections now cap how long those survive, as little as 24 hours to seven days in Safari. A shopper who returns after that finds the cookie, and the cart it held, already gone. Cleared storage, incognito windows, and privacy extensions have the same effect. The state is lost not because it was never saved but because the identifier that would recognize the returning shopper expired.
Does cart persistence work in incognito or after cleared cookies?
Yes. Because the device identifier is derived from the device rather than stored in a cookie, it recognizes the returning device even in incognito and after the browser storage is wiped, which is exactly when a cookie-based cart is lost. A deliberately privacy-hardened session offers less to read and can lower confidence, so a return that cannot be recognized confidently should start fresh rather than restore the wrong cart.
How does ShieldLabs help with cart persistence?
ShieldLabs adds one JavaScript snippet that returns persistent identification surviving cleared cookies and rotated IPs. You save the cart and preferences against that identifier and restore them when the device returns, with no login. ShieldLabs supplies the recognition signal and its confidence; your store keeps the cart and decides what to restore. The free tier covers your first 5,000 identifications.

Related articles