Deeplinkly

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.

Signals available per platform, and what each one can tell you.
SignalPlatformTells you
Play Install ReferrerAndroid, Play installs onlyThe exact campaign string and click time — deterministic, per install
Meta Install ReferrerAndroid, Meta adsDeterministic campaign data for Meta traffic specifically
SKAdNetwork postbacksiOSThat an install happened, attributed to a campaign — aggregated, delayed, no user identity
IDFA with ATT consentiOS, consented users onlyDeterministic matching, for the share of users who opted in
A token carried across the store tripBothDeterministic, when the token survives
Self-attributing network reportsBothThe 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.

  1. 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.
  2. 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.
  3. The referrer was requested once and given up on. SERVICE_UNAVAILABLE from 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.
  4. 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.
  5. 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.
  6. 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.
A store link that carries what it needs
# 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=8

Gaps 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.

Structural limits, and what is actually available instead.
LimitEffectWhat you get instead
No iOS install referrerNo first-party deterministic path from App Store to appSKAdNetwork, aggregated and delayed
ATT declinedNo IDFA, so no deterministic cross-app matchSKAdNetwork only
Crowd anonymity thresholdsLow-volume campaigns return coarse or null conversion valuesThe install count, without the detail
SKAN postback timersData arrives 24–48h+ after the install, sometimes daysCorrect numbers, late
Installs from outside Google PlayNo referrer exists at allNothing
TestFlight installsCarry no attribution signalNothing — expected, not a bug
Cross-device journeysDesktop ad, mobile install — no shared identifierNothing 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 workingA 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 LinksMigrating 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.