Most analytics setups run two identity spaces: the analytics SDK mints one anonymous ID, RevenueCat mints another, and every revenue question becomes a mapping exercise. FolioKit never has two. The SDK generates the ID and hands the same value to RevenueCat — so behavior and money share one identity by construction, not by sync.
Fresh install, step by step
app_user_id. From this moment, every trial, renewal, refund,
and expiration RevenueCat ever reports carries FolioKit's ID.
Existing apps with live subscribers
If your app already has RevenueCat users, rotating their IDs would be reckless — so FolioKit does the opposite. RevenueCat stays configured exactly as it is, and the SDK adopts RevenueCat's existing ID as its own on each device:
- RevenueCat is configured first, untouched. Entitlements, purchase history, and subscriber state are never affected.
- The SDK starts with RevenueCat's current
app_user_idinstead of generating one. - The behavior-to-revenue join works from that day forward, for existing and new users alike. New installs get one shared ID from the start.
What happens on reinstall
The ID lives in the app's local storage, so deleting the app deletes the ID. On reinstall, honestly stated:
- Analytics sees a new user. The reinstalled app generates a fresh ID; the old behavior history stays on the old ID. FolioKit accepts this seam rather than papering over it — the techniques that would "recognize" the person again (fingerprinting, device graphs) are exactly the tracking FolioKit refuses to do.
- The subscriber keeps their purchase. Restoring purchases goes through Apple's receipt, and RevenueCat re-attaches the entitlement to the new ID (its standard transfer behavior). Access keeps working, and revenue events from then on join to the new ID.
- Paying status stays correct. Because the paying flag is reconciled daily against RevenueCat's entitlements — not inferred from past events — a transferred subscription is counted once, on the identity that currently holds it.
What this ID is not
- Not the IDFA, and not derived from the device — it's a random value.
- Not shared between your apps: each app mints its own. There is no cross-app graph of your users, by design.
- Not linked to a person: no name, email, or account is ever attached unless you deliberately put one in your own event properties (the integration rules say don't).
The deeper background — why two identity spaces drift, why connectors can't fully repair them — is in Why your PostHog and RevenueCat numbers never match. And the full data policy is on the data & privacy page.