Identity model
Three IDs and when to use which
Every event GetFluxly accepts carries one or more identifiers. There are three. Picking the right one for a given call site is what makes profiles stitch correctly down the line.
| ID | Purpose | Where it's set | Lifetime |
|---|---|---|---|
anonymous_id | First-touch device identifier | Browser SDK at load, cookie/localStorage | Until the user clears storage |
external_id | Your application's user ID | Your code, once the user signs in | Forever |
user_id | GetFluxly's resolved profile ID | Server response after the first stitch | Forever |
The lifecycle
- Anonymous visit. Browser SDK generates
anonymous_id = anon_a8f3…and persists it. Every event includes only this. - Sign-up / sign-in. Your code learns the application user. Call
identify(externalId, traits), the SDK attaches bothanonymous_idandexternal_idto the identify event. - Stitching. The identity worker resolves the pair into a single
user_id. Subsequent events use either ID; both route to the same profile. - Across devices. A second device starts with its own
anonymous_id. The first identify with the sameexternal_idstitches that device into the existing profile.
Server-side calls
Server SDKs typically know the application user (external_id) already and skip the anonymous_id. That's fine, but it cuts the device-attribution chain, server events come in unattributed to the originating browser session unless your code threads through the anonymous_id from the request.
Where the rules live
The full identity-stitching algorithm and the conflict-resolution rules are in the stitching guide. The contract is locked.