App tracking overview

X3 measures native apps the same way it measures websites, with the things only apps have on top: the store, the install, Apple's and Google's attribution interfaces and native screens. There is no parallel world: an app session is an X3 session, a screen is a pageview, a login is an identify call, an inquiry is X3.lead(), a purchase is a purchase conversion confirmed by a server, and a recording plays in the same player as your web recordings. Web and app share one project, so one person's journey can start with an ad on your website and continue in your app.

The examples on these pages use Nordlicht, a fictitious coaching app with the landing page nordlicht.app, Meta and Google campaigns, a subscription sold in the app and a "Request a personal consultation" button.

What X3 measures in apps

AreaWhat you get
Install sourceWhere every install came from, as exact as the platform allows: X3 links with the Play Install Referrer, Apple Ads, Universal Links and logins exact per install; AdAttributionKit and SKAdNetwork postbacks per campaign. Every number carries its accuracy tier (install attribution).
UsageSessions, screens, events, engaged time, taps, app opens, installs and updates, app versions, devices by class, countries. Screens work in page reports, goals, funnels, relevance and journeys.
PeopleSignup and login call identify with a hashed user id and e-mail. X3 attaches the app usage to the existing lead from your website form, quiz, Meta Instant Form or CRM and shows re-logins, active days and devices (identity).
ConversionsThe same conversion definitions as on the web. Store purchases are confirmed on the server (App Store, Google Play, RevenueCat or your own server) and reported with leads to Meta, Google Ads, TikTok and LinkedIn (purchases, conversions).
RecordingsOptional wireframe recordings of the screen layout, inputs always masked, played in the X3 player with a phone frame (recordings).
ConsentYou choose the consent mode per app: always on, opt-in or opt-out, with separate purposes and ready-made consent screens (consent).

Architecture

Native cores for iOS (Swift) and Android (Kotlin) do the work; thin wrappers bring them to React Native, Expo and Flutter. Data travels as gzip JSON batches over HTTPS, recommended through the first-party proxy on your own domain (https://nordlicht.app/n3), which is also your link domain and the endpoint for Apple's postback copies.

Architecture of the X3 app SDKsThin wrappers for React Native, Expo and Flutter sit on native cores: X3Kit for iOS 15+ and io.x3growth:sdk for Android API 24+, each with core, UI or Compose helpers and a replay module. They use system APIs such as AdServices, AdAttributionKit and the Play Install Referrer, never the IDFA, the GAID or fingerprinting, and send gzip JSON batches through your first-party proxy on nordlicht.app/n3 to the X3 API, which reports conversions to Meta, Google Ads, TikTok and LinkedIn. Store notifications from Apple, Google and RevenueCat go to the API directly.WRAPPERS@x3growth/react-nativeExpo Module, hooks, componentsExpo config pluginInfo.plist, manifest, linksx3growth (Flutter)Pigeon, navigator observerNATIVE CORESX3Kit · Swift PackageiOS 15+X3KitUIReplayqueue · consent · batches · install idsame conformance fixtures on bothio.x3growth:sdk · KotlinAndroid API 24+sdkcomposereplayqueue · consent · batches · install idsame conformance fixtures on bothSYSTEM APISiOSAdServices · AdAttributionKitStoreKit 2 token · ATT statusAndroidPlay Install Referrer 2.2Play Billing account idneverIDFA · GAID · fingerprintingJSON batches, gzip, HTTPSYour domain nordlicht.app/n3 (first-party proxy)/v1/m/* · /go/<code> · /.well-known/appattribution · /.well-known/skadnetworkApple, Google, RevenueCatstore notificationsdirect, signedX3 APIIngest · journeys · leads · goals · relevance · purchases · recordings · dashboard · MCPapp_installs · app_postbacks · app_store_eventsMeta CAPI (app)Google AdsTikTok Events APILinkedIn CAPI
Architecture of the X3 app SDKs

The SDKs never read the IDFA or the GAID, never fingerprint devices and never match IP addresses between app and web. Nothing leaves the device before the purpose "usage analytics" is granted in the consent mode you chose (X3.lead() excepted, because an inquiry is an explicit action).

Accuracy at a glance

The most important limit first: on iOS there is no way to tie an install from the App Store to an ad click exactly, unless the click ran on Apple Ads or the person later identifies themselves. Whoever promises more uses fingerprinting (IP address plus device traits). Apple forbids that and X3 never does it, on the web neither.

SituationiOSAndroid
Click on an X3 link or your landing page's app button, then store, install, first openexact at signup or login, when the web journey carries an identity; otherwise aggregatedexact: the Play Install Referrer carries the UTM parameters and the X3 click token
Apple Ads campaign (App Store search)exact: AdServices token, campaign down to keyword, no ATT neededdoes not apply
Meta app campaignaggregated (AdAttributionKit / SKAdNetwork postbacks)exact: Meta Install Referrer (encrypted in the Play referrer)
Google app campaignaggregated (postbacks); campaign optimization needs Firebaseexact: gclid in the Play referrer; campaign optimization needs Firebase
Organic (store search, word of mouth)unknown, plus aggregated store campaign links in App Store Connectorganic: the referrer says utm_medium=organic
Link a signup or login to an existing leadexactexact
In-app conversions to Meta, TikTok, Google with user dataonly with ATT permission; without ATT app events without user datawith the ad measurement purpose granted
Session recordingsyes, with the recordings purposeyes, with the recordings purpose

What to tell your team: on Android you see every install with its campaign. On iOS you see Apple Ads exactly, all other campaigns as totals per campaign, and at the latest at login the whole journey of the person, if you knew them before. The strongest lever on iOS is therefore a web first funnel: landing page, e-mail or account in the browser, then the app through a magic link. The identity exists before the store, and the login closes the gap deterministically.

Accuracy tiers of install attribution by platformEight tiers: referrer is exact on Android through the Play Install Referrer, apple_ads is exact on iOS through the AdServices token, link is exact on both when an X3 link or Universal Link opens the app, identity applies on both after a login joins an earlier web journey, aggregated covers AdAttributionKit and SKAdNetwork postbacks on iOS and platform reports, organic is reported by Google Play, unknown means no source and pending means the Apple Ads lookup is still running.TieriOSAndroidLevelreferrerExact (Play referrer)–exactper installapple_adsExact (Apple Ads)exact–per installlinkVia linkexactexactinstall or re-engagementidentityVia loginafter loginafter loginper install, retroactiveaggregatedAggregatedpostbacksplatform reportsper campaign onlyorganicOrganic–Play: organicper installunknownUnknownno sourceno sourceper installpendingResolvingApple Ads wait–transient
Accuracy tiers of install attribution by platform

How app data reaches the dashboard

  • Platform filter. Projects with a registered app get the filter Plattform (Platform) with Alle · Website · Apps · iOS-App · Android-App; the session list also shows the columns Plattform and App-Version. The page map (heatmaps) always uses website sessions in such projects; scroll and section figures exist only for website sessions, so filter by Website when you compare them.
  • Einstellungen › Apps (Settings › Apps): register an app with App verbinden (Connect app), copy its key, check the first data in the wizard step Prüfen (Check), follow the setup checklist on the tab Einrichtung (Setup), set up X3 links, store notifications, ad platforms and the generated store privacy tables.
  • Quellen › Installationen (Sources › Installs): installs by source, campaign, accuracy tier, platform, app and day; the funnel link clicks → first opens → accounts → active → purchasers; Apple postbacks per campaign; cost per install where ad costs are connected.
  • Visits. App sessions show the platform icon, the app version and an App card (OS, device class, ATT status, consent mode, install source). Recordings play in a phone frame.
  • Lead profile. The card App lists the person's installs with their accuracy tier, the last login, logins in the last 7 and 30 days, active days, devices and purchases.

Retention

Retention cohorts show how many installs come back: the share of installs with a session on day 1, day 7 and day 30 after the first open, grouped like the installs report (source, campaign, accuracy tier, platform, app or day). The REST route is GET /v1/projects/{project}/app-installs/retention (scope analytics:read), with the same filters as the installs report.

Ask Claude about your app

The X3 MCP server answers questions about app traffic with the same analytics tools as for websites: pass the platform filter (ios, android or app for both) and ask, for example, "Which campaigns brought Android installs that bought within 7 days?" or "How many iOS installs came through Apple Ads last month?". Installs, accuracy tiers and app purchases are part of the answers; contact data needs the opt-in scope leads:read as on the web.

Where to go next

  1. App tracking quickstart: install the SDK for your stack and see the first screen in a few minutes.
  2. Consent in apps: choose a mode, wire the consent screen, read your obligations.
  3. Platform guides: iOS, Android, React Native and Expo, Flutter.
  4. Attribution and people: install attribution, users, logins and leads.
  5. Money: purchases and subscriptions, in-app conversions and ad platforms.
  6. Session recordings in apps, privacy details for the stores, the app SDK reference and troubleshooting.
  7. Wire format of the app endpoints: app ingest API. All SDKs side by side: SDK overview.

Not included yet

Screen heatmaps for apps, Apple Ads cost import, Google's server-to-server app conversion API and on-device measurement, App Clips, clipboard-based deferred deep links (apps that obtain a link token themselves pass it with applyLinkToken), automatic StoreKit and Play Billing observation, adapters for mobile consent platforms (call X3.consent from your CMP's callback instead), Windows, macOS, tvOS and watchOS apps, and video recording.