Cart contents must persist across sessions

What it is

Cross-session persistence means SKUs, quantities, checkmarks, and notes in the cart are still there after a tab close, a process kill, a next-day return, or a login on another device. The cart is external memory for “not buying yet.” It is not a wishlist (which does not enter checkout) and not a checkout draft (which already carries address and tender). People add items to postpone a decision; an empty cart turns postpone into search-again.

Why it happens

Add-to-cart is a low-commitment move: compare later, wait for someone else, wait for payday, lift a candidate set out of search. Working memory cannot hold a dozen variants; the cart is external memory. Wiping it when the session ends tells people that “park it” is unsafe, so they screenshot, star, or leave. Guest carts live on-device; signed-in carts live on the account. Those two stores must merge, not overwrite—overwrite reads as theft. Silent resolution of conflicts (different quantities, one side expired) breaks trust the same way.

Studying it

Use real returns, not a lab checkout on the same sitting. Have people add items, force a session end (clear cookies, kill the app, wait overnight), then measure whether the cart is intact.

Independent variables: signed-in vs guest, cross-device or not, merge policy (overwrite / add / let the person pick), guest retention window. Dependent variables: item retention on return, leave-because-empty, quantity errors after merge, unsolicited “it’s gone” reports.

Incentivized participants memorize products and will not show dependence on external memory. Do not count “added again” as success—that is forced rebuild. Same-day lab tasks almost never reveal cross-session loss; use next-day or diary methods.

Where it stops holding

Privacy rules that cap guest retention require a stated expiry, not a silent wipe. Shared devices should not sync a local cart onto whoever just signed in. For tickets and flash sales, keeping the line-item is not a stock lock; people can return to a cart that no longer buys. B2B requisition is a purchase request, not this cart.

Applying it

• Persist signed-in carts on the account; persist guest carts on-device; merge by SKU at login and show both sides when quantities conflict.
• Silent delete only for true unavailability; price or stock changes keep the line and signal separately.
• Cross-device follows the account; do not write device A’s guest cart onto account B without confirmation.
• Verify on three paths: same account next day, a second device still signed out, then merge after login. Screenshot SKUs and quantities; any empty or overwritten cart fails.

Related

• Within the group: H7.01.2 Stock and price changes in the cart must be called out · H7.01.3 Adding to cart needs immediate feedback
• Adjacent: H7.02 Checkout flow · H8.05 Save for later · H7.13 Payment failure and unknown state
• Search terms: persistent shopping cart · cart persistence · guest cart merge