Mobile SDKs overview

Five packages, one behaviour. The Flutter plugin, the React Native bridge and the Unity package all reimplement or wrap the same contract as the two native SDKs, so an app measured through any of them produces the same rows.

The SDK integration tab in the panel prints the current version of each, with your key and host filled in. Copy the dependency line from there rather than from these pages, so a version bump never depends on a doc being edited.

• The install, with how it happened: the Play Install Referrer (which carries the click id from a tracking link) or Apple Search Ads attribution, the device model and OS, the app version and the SDK version.
• Opens and sessions. Thirty idle minutes end a session, and it rolls at the visitor's local midnight -- the same model the web SDK uses, so an app and a site on one dashboard are measured the same way. State is persisted, because mobile OSes kill backgrounded apps routinely and an in-memory session would restart every time.
• Funnel events you send with track(): begin_checkout, sign_up, level_complete and the rest. Behaviour, never revenue.
• Identity you send with identify(). Email and phone are SHA-256 hashed on the device; the raw values never leave it.
• Device signals for install quality: the advertising id when the user allows it, the App Set ID on Android, and raw integrity signals (emulator, root, jailbreak) as evidence rather than a verdict.

Never collected: names, raw contact details, precise location, or any purchase amount from the app itself.

A browser sends an Origin header we can check against your domains. An app sends nothing of the kind, so mobile beacons are HMAC-signed with the app secret instead. The SDK signs at the moment of sending, not when the event was queued, so an install recorded offline is still valid when it finally goes out; handset clocks drift, so the tolerance is fifteen minutes and the SDK corrects itself from our clock after one rejection.

It is a deliberately modest guarantee. It raises forging an install from a curl command to reverse-engineering your binary; it is not claimed to be unforgeable. See Keys & credentials for what a leaked secret does and does not buy.

Two campaigns can post identical day-one revenue while one buys customers and the other buys uninstalls. Sessions are what tell them apart.

• Retention counts a return as a session on a later calendar day. Three opens in the hour after installing is still the install.
• Emulators and rooted devices are flagged, never dropped -- most emulator installs in real data are your own QA. The SDK sends the raw signal names, so the rule can be retuned on our side without waiting for an app-store review.
• Repeated installs from one device are disclosed as the device-farm tell. Disclosed, not excluded: a shared shop tablet and a farm look identical from install counts alone.

If you are the marketer: Quick start: mobile app is the five-stage map, and stages 4 and 5 are yours.

If you are the developer: your framework's page, then Testing a mobile integration before you hand the build over.