Guest data retention must be stated

What it is

A guest bucket cannot impersonate a free account forever. Retention is when or under what conditions that temporary data is wiped (N days idle, uninstall, clearing site data, anonymous server token expiry). Stating it means the person sees the limit when the first guest data is created, and once more as wipe approaches—not a blank workspace on the day it vanishes. This entry is only how long it may live and how that is said. It is not about merge after registration, and not about which features are withheld from guests.

Why it happens

Without an account there is no stable notice channel, so the limit has to live in the current UI and on the device. People treat a guest draft as “already saved in the cloud,” leave for a few days, and return to a policy wipe; trust breaks on the path the product invited them to try first. An unspoken wipe is read as a loss bug. Disclosure must cover local and server: “closing the browser drops it” while an anonymous token stays thirty days on the server, or the reverse, mis-sets expectation. Retention also binds the privacy claim: advertising that guests are not profiled while anonymous behavior logs live a long time pits policy against marketing.

Studying it

Let people create data as guests, return after the limit, and compare advance disclosure and a pre-expiry reminder against none, looking at whether expectation matches reality.

Independent variables: limit visible at first write, countdown or banner near expiry, whether post-wipe empty state says “guest data expired” rather than looking blank. Dependent variables: attribution of loss on return (expiry vs bug), complaints from surprise loss, share who register to keep the data after seeing the limit.

Labs cannot wait N days; use a shortened TTL. “Conversion at expiry” is not the only success—that can be coercion. Success is correct attribution: people can say why it is gone, and whether export or register could still have saved it.

Where it stops holding

Memory-only guest (gone on close) has session length as its limit; say “closing the app will lose this” at first write, do not pretend there are days. When law requires shorter or longer anonymous logs, the user-facing limit must cover the data they can see; logs may follow compliance in a different sentence, but the product must not claim “we keep nothing.” Clearing site data, switching browsers, or refusing cookies ends the limit early; disclosure should mention those user-side acts. Data on an already-registered account does not use guest TTL.

Applying it

• At the guest’s first save or add-to-cart, one visible line states the limit (“guest drafts last N days or until site data is cleared”); the same line is findable in settings.
• Near expiry, an in-app banner; after wipe, the empty state names the reason and honestly says registration cannot resurrect already-wiped data.
• Local storage and the server anonymous token share the same visible limit and wipe together.
• Verify: shrink TTL to an observable window; at first write people should recap the limit; after expiry the empty state must not look like a crash. Switching browsers or clearing site data should end it early, and the UI must not promise the data remains. Spot-check that server anonymous records cannot rebuild the workspace after the stated date.

Related

• Within the group: H6.09.1 Guest mode lets people try core features before registering · H6.09.2 Guest data must merge cleanly after registration · H6.09.4 Some features cannot run in guest mode because they need a durable identity
• Adjacent: H6.01 Registration friction · H6.08 Account deletion
• Search terms: guest retention · anonymous TTL · ephemeral identity