Glossary/Failure modes
Unattributed installs
Definition
An install is unattributed when no signal linking it to a prior ad click or link tap survived the journey through the app store, which can mean the install was organic or that the signal existed and was lost.
Those two cases look identical in a dashboard and have completely different implications, so the useful work is separating them. Some of the gap is fixable by you today. Some of it is a platform limit that no measurement vendor can close, whatever their marketing says — and a vendor reporting a suspiciously small unattributed bucket is usually guessing rather than measuring.
What can actually be known
Attribution is not one mechanism. It is a set of signals with very different guarantees, and which ones exist depends on the platform and how the user reached the store.
| Signal | Platform | Tells you |
|---|---|---|
| Play Install Referrer | Android, Play installs only | The exact campaign string and click time — deterministic, per install |
| Meta Install Referrer | Android, Meta ads | Deterministic campaign data for Meta traffic specifically |
| SKAdNetwork postbacks | iOS | That an install happened, attributed to a campaign — aggregated, delayed, no user identity |
| IDFA with ATT consent | iOS, consented users only | Deterministic matching, for the share of users who opted in |
| A token carried across the store trip | Both | Deterministic, when the token survives |
| Self-attributing network reports | Both | The network's own claim, on its own terms |
The asymmetry is the whole story
Android has a first-party, deterministic channel from the store to the app. iOS has nothing equivalent — SKAdNetwork reports installs in aggregate and deliberately carries no per-user identity. Any product claiming per-install iOS attribution comparable to Android's is either using consented IDFA, which covers a minority of users, or inferring it.
Gaps you can close
Roughly in order of how much volume they typically account for, and all of them are your side of the line.
- The link was never tagged. The most common fixable cause by a distance. A store link posted in a newsletter, a bio, a QR code, or a partner page with no campaign parameters produces an install that is genuinely indistinguishable from organic. It was a campaign, it just did not say so.
- The store URL lost its parameters. A redirect, a shortener, or a hand-edited link that dropped
referrer. Worse, an unencoded&inside the referrer value truncates it, producing partial data that looks like a successful read. - The referrer was requested once and given up on.
SERVICE_UNAVAILABLEfrom the Play referrer client is transient, and the value stays available for 90 days. Integrations that treat the first failure as "no referrer" discard recoverable installs permanently. - The SDK initialised after the first screen. The payload arrives, the app has already decided what to show, the association is dropped. Attribution data exists and is thrown away.
- Attribution runs only on cold launch. An install that first opens via a push notification or a warm resume can miss the code path entirely.
- The match window is too short for the actual journey. A user who taps an ad, gets interrupted, and installs the next evening is real behaviour, not an edge case.
# Android — the referrer must be ONE url-encoded parameter.
# Decoded: utm_source=newsletter&utm_medium=email&utm_campaign=spring
https://play.google.com/store/apps/details?id=com.example.shop&referrer=utm_source%3Dnewsletter%26utm_medium%3Demail%26utm_campaign%3Dspring
# The failure that looks like success: an unencoded & ends the parameter,
# so everything after utm_source is silently dropped.
...&referrer=utm_source=newsletter&utm_medium=email # BROKEN
# iOS — App Store links accept campaign parameters, but they feed
# App Store Connect analytics, not your app. Nothing is handed to the
# binary on first launch. There is no iOS install referrer.
https://apps.apple.com/app/id123456789?pt=12345&ct=spring&mt=8Gaps nobody can close
These are platform and policy limits. They are worth stating plainly because the alternative is treating them as a vendor selection problem and switching tools to solve something no tool solves.
| Limit | Effect | What you get instead |
|---|---|---|
| No iOS install referrer | No first-party deterministic path from App Store to app | SKAdNetwork, aggregated and delayed |
| ATT declined | No IDFA, so no deterministic cross-app match | SKAdNetwork only |
| Crowd anonymity thresholds | Low-volume campaigns return coarse or null conversion values | The install count, without the detail |
| SKAN postback timers | Data arrives 24–48h+ after the install, sometimes days | Correct numbers, late |
| Installs from outside Google Play | No referrer exists at all | Nothing |
| TestFlight installs | Carry no attribution signal | Nothing — expected, not a bug |
| Cross-device journeys | Desktop ad, mobile install — no shared identifier | Nothing deterministic |
We do not close the iOS gap with fingerprinting
The technique that makes an iOS unattributed bucket look small is probabilistic matching on device characteristics — IP address, screen size, OS version, timing. Apple's policy prohibits it, it produces confident-looking numbers with no per-install ground truth, and it degrades silently. We report the install as unattributed instead. A larger honest bucket beats a smaller invented one, and it is worth checking whether a vendor's better-looking numbers are measurement or inference.
Telling organic from lost
Since both land in the same bucket, use signals around the install rather than the install record itself.
- Compare the platform split. If Android's unattributed share is much lower than iOS's, the difference is roughly the platform limit — that part is structural. If Android's is *also* high, that part is fixable and is probably untagged links.
- Watch unattributed volume against spend. Genuinely organic installs do not track ad spend. A bucket that rises and falls with campaigns is measurement loss wearing an organic label.
- Check store listing traffic sources. Play Console and App Store Connect report browse versus search versus referral independently of your SDK. High referral traffic alongside high unattributed installs means links are arriving untagged.
- Look at the timing distribution. Organic installs spread across the day. A cluster minutes after a campaign send is not organic.
- Audit one campaign end to end. Take a live link, tap it on a clean device, install, and watch what your integration receives. One pass finds untagged links and truncated referrers faster than any dashboard analysis.
A stable unattributed share that does not respond to spend, with Android meaningfully lower than iOS, is close to the floor for honest measurement. Chasing it below that means buying inference and calling it data.
UTM builder
The largest fixable cause of unattributed installs is links that never carried campaign parameters. This builds correctly-encoded store and web links with a live preview, which also avoids the unencoded-ampersand mistake that silently truncates an Android install referrer.
Open the utm builder →Frequently asked questions
- Why are so many of my installs unattributed?
- Either they were genuinely organic, or a signal existed and was lost. The most common fixable cause is links that were never tagged with campaign parameters, so a real campaign install is indistinguishable from an organic one. The most common unfixable cause is iOS, which has no install referrer — SKAdNetwork reports installs in aggregate with no per-user identity, so a meaningful unattributed share on iOS is structural rather than a bug.
- Why is iOS attribution worse than Android?
- Google Play provides the Play Install Referrer, a first-party deterministic channel that carries a campaign string from the store link through to the app's first launch. Apple ships no equivalent. On iOS you have SKAdNetwork, which is aggregated, delayed, and carries no user identity, plus deterministic matching for the minority of users who grant ATT consent. The difference is a platform design decision, not an integration quality difference.
- Can a measurement vendor fix unattributed iOS installs?
- Not without inference. The technique that shrinks the iOS unattributed bucket is probabilistic fingerprinting — matching on IP address, screen size, OS version, and timing. Apple's policy prohibits it, it has no per-install ground truth, and it degrades silently as conditions change. A vendor showing a much smaller unattributed bucket than the platform allows is estimating, and it is fair to ask them which.
- How do I tell organic installs from lost attribution?
- Check whether the unattributed bucket moves with ad spend — genuinely organic installs do not. Compare the platform split, since a much higher iOS share than Android reflects the structural platform limit while a high Android share points at fixable problems like untagged links. Store console traffic-source reports also show referral volume independently of your SDK.
- Does the Play Install Referrer work for every Android install?
- Only for installs that came through Google Play from a URL carrying a referrer parameter. Sideloaded APKs, pre-installed builds, Firebase App Distribution, App Center, and most alternative app stores carry no referrer at all. A user who searched for your app inside the Play app rather than following your link also produces no referrer, because nothing but the store URL can set it.
- What is a normal unattributed install rate?
- There is no single figure, because it depends on your platform mix, how much traffic is genuinely organic, and how completely your links are tagged. A more useful test than a benchmark: if the bucket is stable, does not move with ad spend, and is meaningfully lower on Android than iOS, it is behaving the way honest measurement behaves given the platform constraints.
Related terms
- Deferred deep link not working — A deferred deep link fails when the signal meant to carry the pre-install destination across the app store — an install referrer, a stored token, or a server-side match — is absent, expired, or never read on first launch.
- Migrating off Firebase Dynamic Links — Migrating off Firebase Dynamic Links means replacing the link generation, the hosting domain, and the SDK integration of a service that was shut down on 25 August 2025, after which page.link URLs stopped resolving.