identify to connect that install to your own account ID, and setUserAttributes to attach anything you know that FlowPilot cannot see.
Everything here shows up on the Users page.
identify
configure(...), as soon as you know who the person is — typically right after sign-in or when you restore a session at launch.
From that point on, events are attributed to your ID instead of the anonymous one. The anonymous ID is kept as an alias, so the person’s history from before they signed up stays attached to them rather than appearing as a second, unrelated user.
A flow already on screen keeps the ID it started with, so a session’s funnel is never split across two identities.
reset
setUserAttributes
plan leaves campaign alone. Pass null as a value to clear a key:
Attributes are limited to 100 keys, with each value capped at 512 characters. Nested objects are stored as JSON text. Your key names are sent exactly as you write them.
What the SDK reports about the device
Once per app session, the SDK sends a device report. It is sent separately from analytics events rather than attached to them, so a person’s event count is not inflated by a description of their phone.Optional dependencies
Onlyreact-native is required. These packages each add detail to the report if your app already has them, and are skipped silently if it does not:
Without any of them, the report still carries platform, OS version, time zone, and locale — most of what the Users list displays.
What it never collects
- No advertising identifier. The SDK does not read the IDFA or the Android advertising ID, and never triggers an App Tracking Transparency prompt. Adding FlowPilot cannot cause your app to ask for tracking permission.
- No location.
- Nothing personal. No contacts, no email, no name. If FlowPilot knows who someone is, it is because you called
identify.
Absent, not guessed
Anything the SDK cannot read is left out of the report entirely. It is never sent as an empty string or"unknown", and an absent value never overwrites a value the server already had — so a report from a build without expo-device cannot blank the model recorded by a build that had it.
When reports are sent
Every report is fire-and-forget. A failed one is dropped silently and retried on the next launch; it never surfaces an error, blocks a flow, or affects analytics ingestion.