A UTM-tagged link cannot attribute an app install. The click happens in a mobile browser, the install happens in the App Store or Google Play, and the utm_source / utm_campaign string is lost crossing that boundary — the store never receives your query parameters, and the freshly installed app launches with no shared cookie or identifier tying it back to the click. UTMs still work fine for the web landing page that hosts them; they simply stop at the storefront. Attributing the install itself needs a deep-linking and measurement layer built for mobile, and on both platforms that layer is what an MMP like AppsFlyer OneLink provides.
Why UTM parameters break at the store boundary
UTM tracking is a web convention. A tagged URL like ?utm_source=instagram&utm_campaign=launch is read by a page's analytics script (GA4, for example) once the browser loads the page. That model assumes the click and the conversion happen in the same browser session, sharing the same cookies.
A mobile install breaks every part of that assumption:
- No shared identifier. The browser that registered the click and the app process that runs after install are sandboxed from each other. There is no cookie, no
localStorage, no session that survives the handoff. - The store strips the query string. When a user taps through to the App Store or Google Play, your
utm_*parameters do not travel into the store listing in any form a web analytics tool can read. The install is recorded by the store, not your page. - First open has no referrer. When the app launches for the first time, it knows nothing about which ad, post, or link brought the user there.
So the UTM correctly attributes the landing-page visit and can still measure "how many people reached the page," but it goes dark the moment the user crosses into the store. That gap is exactly what mobile attribution exists to close.
How AppsFlyer OneLink closes the gap
OneLink is AppsFlyer's single smart link that does device detection, redirection, and attribution in one URL (AppsFlyer deep linking). One link handles every case: it sends a new user without the app to the correct store for their device and OS, and it deep-links an existing user straight into the app (AppsFlyer dev docs). The attribution data that a UTM would have carried is preserved by the AppsFlyer SDK and surfaced on the app's first open, rather than being thrown away at the storefront.
Three mechanics make this work:
- Attribution. OneLink records the click and matches it to the install the SDK reports, so AppsFlyer can answer "which campaign drove this install" without relying on a web cookie.
- Redirection. The same link routes by device — App Store for iOS, Google Play for Android, or a fallback web URL — instead of you maintaining separate links per platform.
- Deferred deep linking. If a new user installs and opens later, OneLink remembers the original link intent and routes them to the right in-app screen on first launch (AppsFlyer deep-linking setup).
For users who already have the app, OneLink opens it directly using iOS Universal Links (Apple Developer) and Android App Links (Android Developers), so the tap never bounces through the browser. Dynamic deep-link parameters on the link then route to specific in-app content — a product, a referral, a promo — carried as values the SDK reads at open time.
The platform-specific plumbing underneath
OneLink abstracts two very different attribution models on the two stores.
On Android, campaign data survives the store via the Google Play Install Referrer API. Play passes a referrer string from the click through to the app after install, and AppsFlyer reads it to attribute the source (Android Developers). This is the closest mobile gets to a UTM surviving the storefront — but it is a dedicated API, not your web query string.
On iOS, deterministic matching depends on user consent. Under App Tracking Transparency (ATT), an app must ask permission before tracking the user across other companies' apps, and most users decline (Apple Developer). Without consent there is no shared device identifier, so install attribution falls back to SKAdNetwork, Apple's privacy-preserving, aggregated and deliberately delayed model (Apple Developer). Apple's newer AdAttributionKit builds on the same privacy model and interoperates with SKAdNetwork (Apple Developer). The practical effect is covered in depth in SKAdNetwork explained: iOS install numbers are coarse, late, and sometimes withheld below an anonymity threshold.
If campaigns are generated programmatically, note that AppsFlyer released OneLink API v2.0 in December 2025, adding faster short links, QR generation, and configurable link expiry (AppsFlyer product news). Version 1.0 is deprecated and unmaintained after June 2026, so new integrations should build on v2.0.
Keep one event taxonomy across tools
OneLink and SKAdNetwork answer the campaign-attribution question. They do not replace first-party product analytics — and conflating the two is how teams end up with numbers that never reconcile. The durable setup keeps your own owned events as the source of truth for product behavior, and treats the MMP as the attribution layer on top.
That means mapping one canonical event taxonomy to AppsFlyer's in-app events, exactly once. VibeTraker documents this mapping in Connect AppsFlyer:
signup_completed→af_complete_registrationtrial_started→af_start_trialpurchase_completed→af_purchase(withvalueandcurrency)
VibeTraker's role is the install and contract setup, not a dashboard mirror. It generates the integration contract — the react-native-appsflyer SDK plus the APPSFLYER_DEV_KEY and APPSFLYER_APP_ID env vars to inject (AppsFlyer React Native plugin) — and enforces that the same canonical events feed both Firebase and AppsFlyer. It does not pull AppsFlyer's dashboards through a Data API; the owned-event spine stays the system of record for product behavior, and AppsFlyer answers the attribution question on top.
For the decision of which MMP and analytics stack to pair, see Firebase vs AppsFlyer; for turning attributed installs into spend efficiency, how to measure mobile ROAS; and if you previously relied on Firebase Dynamic Links for routing, the shutdown alternatives cover the migration to OneLink-style links.
The short version: a UTM measures a web visit, and an MMP link measures an install. They are different layers solving different problems, and a mobile growth stack needs both — the UTM to read the landing page, and OneLink to carry attribution across the boundary the UTM cannot cross.