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 | Omitted by default (browser SDK stores nothing while anonymous); server derives a gfh_ hash at ingest instead | One day (the hash salt rotates daily); persisted and long-lived only with cookieless: false |
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. By default the browser SDK does not generate or persist an
anonymous_id. It omitsanonymous_idfrom events entirely, and the server derives a daily-rotatinggfh_hash id at ingest. - 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.