How identity works
This is the map, not the manual. By the end you should be able to answer three questions: which tier you are, whether cross-platform stitching applies to you, and which doc to read next. Crossdeck binds a person to the most durable anchor your setup provides — so where you sit depends on what your app already has.
The anchor rule
Crossdeck binds identity to the most durable anchor your setup provides. The more durable the anchor — anonymous handle, Stripe customer, your own app UID — the more Crossdeck can do with it.
The three tiers
Tier 1 — no backend, no payment
Anonymous visitors, journey analytics only. There's no money and no entitlements, so there is no durable identity to anchor to and nothing to stitch. You read what people did; you don't carry who they are.
Tier 2 — no backend, Stripe present
The Stripe customer is the anchor. Revenue is tracked and reported against that customer. It's a single surface — there's no cross-platform stitch, because there's no app identity to bridge to. This is a complete, valid mode, not a degraded one.
Tier 3 — backend present
Your authenticated app UID is the anchor — the passport. Identity persists across web and iOS, the Stripe subscription attaches to the UID, and entitlements follow the human across platforms. This is the only tier where stitching applies.
Tier 1 or 2? You're done — cross-platform identity doesn't apply to you.
Tier 3 (web and mobile, real accounts)? You must call identify() with the same UID
on both platforms. Read on.
The cross-platform stitch
identify() in the mobile app and your
paying web customer sees free.
You hand Crossdeck the same UID on web and on mobile. That's the entire mechanism — you assert it; Crossdeck does not guess, fingerprint, or match on email.
- Email is never the key. Apple Private Relay alone guarantees the iOS email won't match the web one.
- The device handle is throwaway. The SDK-minted handle is anonymous — it gets attached to the UID; it is not the identity.