Guest data must merge cleanly after registration

What it is

The guest workspace already holds drafts, a cart, progress. If registration yields an empty account, the experience just lived is voided and signup is a punishment. Clean merge means objects in the guest bucket are attached to the new (or existing) account, and on conflict both sides are shown for a choice—not one side silently dropped. This entry is only where data goes at the moment of registration. It is not about which features guest mode offers, and not about whether guest data expires.

Why it happens

The guest primary key is a device or anonymous token; the account key is an email or federated identity. Registration is a key switch. If the switch mints an empty shell and does not move objects, people see “registering threw my work away.” If the target account already has a same-named object (signed in on another device, then tried to merge), silent overwrite destroys the cloud copy; silent discard destroys the guest copy. Merge needs per-object policy: carts can union, conflicting drafts need a pick, progress takes the newer. Cross-device is harder: guest work on a phone, register with the same email on a computer—the phone bucket must still be claimable, not only “current device memory.” On failure, stop at “both copies exist, please choose,” not a half-imported account.

Studying it

Build “guest has content → new signup” and “guest has content → sign in to an existing account,” comparing auto-merge, drop guest, drop cloud, and let the person pick.

Independent variables: merge policy, whether conflicts are visible, whether claiming must finish on the original device. Dependent variables: share of guest objects still present after registration, wrong overwrites, abandonments from loss.

Labs often use empty accounts, so conflict never appears. Use a fixture with same-named drafts on both sides. Registration completion is not merge success—complete with empty content is a fail. If a claim chain can be triggered by someone else on another device against the same email, measure mis-binding separately.

Where it stops holding

Guest content that must not legally merge into an existing account (a minor’s guest into an adult account, enterprise policy forbidding inbound drafts) should refuse with an explanation, not force-merge. When objects are too large to upload in the registration request, continue in the background and show progress in the account; do not freeze the signup page. A refusal to merge should still allow an empty account, with the guest bucket following retention policy, not an undeletable ghost. Federated login with an unverified email must not auto-merge into someone else’s account.

Applying it

• Right after signup or sign-in, queue the current guest bucket to merge; new accounts ingest by default; existing accounts, on conflict, list objects and let the person keep one side or both.
• Across devices, offer “claim guest data on this device,” confirmed in a signed-in state on the original device, so typing an email alone cannot vacuum someone else’s guest bucket.
• On merge failure, keep both sides reachable and offer retry; do not say “sync failed” and drop the bucket.
• Verify: put a unique draft in guest, register a new account, the draft remains and the author is the new account. Second fixture: cloud and guest each have a same-named piece; after sign-in both remain or the person clearly chose. On another device, typing only an email without confirm on the original must not ingest someone else’s guest data.

Related

• Within the group: H6.09.1 Guest mode lets people try core features before registering · H6.09.3 Guest data retention must be stated · H6.09.4 Some features cannot run in guest mode because they need a durable identity
• Adjacent: H6.01 Registration friction · H6.13 Account switching and multiple accounts
• Search terms: guest merge · anonymous to registered · cart merge