Deferred deep linking: the destination survives the install.
Deferred deep linking carries a link's destination and payload through an app install. Someone taps a link without having your app, installs it from the App Store or Play Store, and on first launch lands on the exact screen the link pointed to — instead of your home screen with the intent lost.
Three kinds of deep link
Most apps end up using all three. Only the second one needs anything the operating system does not already give you.
| Type | App installed? | What happens |
|---|---|---|
| Direct | Yes | The OS opens your app straight to the path. Universal Links on iOS, App Links on Android. |
| Deferred | No | The user installs first; the path is delivered on first open, once the install is matched to the click. |
| Contextual | Either | The path plus a custom payload — a voucher code, a referrer ID — personalises the first screen. |
How it actually works
Why can't Universal Links and App Links do this on their own?
Because they only work when the app is already installed. Universal Links on iOS and App Links on Android tell the operating system that an https:// URL belongs to your app, and the OS opens it there instead of the browser. If the app is missing, the OS has nothing to open, so it falls back to the web — and the store sits between that web page and the eventual first launch, passing nothing across. The link the user tapped is gone by the time your app runs for the first time.
How does the destination survive the install, then?
By matching the install back to the click on a server that saw both. LinkTrail records the click when the link is resolved, and on first launch the SDK asks whether this install belongs to a recent click. Android has one exact mechanism for this — the Google Play Install Referrer, which the store hands to the installed app — and on iOS the primary signal is a deferred click token the tapped link leaves on the clipboard, read by default only when the user taps a paste control. Where neither is available, matching becomes probabilistic, consent-gated, and scored rather than asserted.
Is deferred deep linking the same thing as attribution?
They share machinery and answer different questions. Deferred deep linking asks where this user should land; attribution asks which campaign earned the install. The same click-to-install match can serve both, which is why the two usually ship together, but plenty of teams only need the first — onboarding, invites, sharing, and email are all deep-linking problems with no budget attached. Our attribution page covers the second question in full.
What happens to routing while you are waiting for consent?
Consent gating is on by default on iOS and Android, and no attribution is recorded until your app grants consent. On Android a fresh install is additionally held until your setConsent decision before the deferred link routes; iOS and re-engagement links route immediately. Granting attributes the install and flushes queued events, denying still routes the link but records nothing — so the consent gate costs you reporting, never the user's destination.
How long after the click can a deferred link still resolve?
Seven days by default, configurable per workspace. That window is a precision control rather than a coverage setting: signals decay at very different rates, so a match ninety seconds after the click and a match six days later are not equally strong claims even at an identical score. The full reasoning, the signal weights, and the confidence floor are published on our methodology page.
What arrives at first open
One onLink handler fires for both a deferred first launch and a re-engagement tap, and it receives the same link shape in every SDK.
| Field | What it is |
|---|---|
| path | The in-app destination to route to. Falls back to / when none is set. |
| customData | String key/value payload configured on the link — voucher codes, referrer IDs, anything. |
| campaign / channel / utm | Campaign metadata, for your own analytics. |
| slug / url | The link's short slug and its canonical URL. |
| iosUrl / androidUrl / fallbackUrl | The routing destinations configured on the link. |
| source | deferred on a first launch after install, reengagement when the app was already there. |
Field casing varies slightly per language. The per-SDK reference is in the deep linking guide.
Adding it to your app
- 1Create a smart link with a deep link path, per-platform fallbacks, and any custom payload the first screen needs.
- 2Point a link domain at LinkTrail; the apple-app-site-association and assetlinks.json files are generated and hosted for you.
- 3Add the iOS, Android, React Native, or Flutter SDK and call configure with your API key at launch.
- 4Register one onLink handler and route on link.path — it fires for both deferred first launches and re-engagement links.
- 5Call setConsent once your consent UI resolves, so attribution can start without ever holding up the user's destination.
- 6Test on a device that has never had the app, because association files cache aggressively and a warm device will not tell you the truth.
The SDKs are open source on GitHub and the Quickstart walks through the dashboard setup and the app code together.
Where to go next
Deferred deep linking answers where a user should land. If you also need to know which campaign earned the install, that is attribution — and if you are replacing Firebase Dynamic Links, the migration path has its own page.
Deferred deep linking — common questions
What is deferred deep linking?
Deferred deep linking is the mechanism that carries a link's destination through an app install. Someone taps a link without having your app, installs it from the App Store or Play Store, and on first launch lands on the exact screen the link pointed to, with any custom payload intact. It is called deferred because the link is delivered later than it was tapped — at first open rather than on the tap.
What is the difference between deep linking and deferred deep linking?
A plain deep link only works if the app is already installed: the OS sees an https:// URL it recognises and opens your app at that path. A deferred deep link covers the case where it is not, by matching the first launch back to the click that preceded it and delivering the same path and payload then. Everyday direct links are handled by Universal Links and App Links; the deferred case needs a service that saw both the click and the install.
Do I need an SDK for deferred deep linking?
Yes. The match has to happen inside the app on first launch, which means code running at launch that can ask whether this install belongs to a recent click. LinkTrail ships native SDKs for iOS and Android plus React Native and Flutter packages that wrap the same native code, so behaviour matches across all four. Integration is three calls: configure at launch, onLink to route, and handleDeepLink to forward OS links.
Does deferred deep linking work on iOS without the IDFA?
Yes. LinkTrail never accesses the Apple IDFA, with or without App Tracking Transparency permission, and never reads the Google Advertising ID. On iOS the primary signal is a deferred click token carried on the clipboard and read by default only when the user taps a paste control; device identifiers are vendor-scoped only. Resetting an advertising identifier has no effect on any of it.
How reliable is deferred deep linking?
It depends on which signal is available, which is why every install records its match type. The Google Play Install Referrer and a deferred click token are exact when present. Where neither is, matching is probabilistic, requires end-user consent, and is scored against a confidence floor of 0.6 — below that the install is reported as organic rather than assigned to the most plausible campaign. We publish no match-rate percentage because we do not yet have a production dataset large enough to support one.
Is deferred deep linking free on LinkTrail?
It is on every plan, including Free. The Free plan covers 5,000 monthly active users, 25,000 clicks a month, and 100 links at no cost and with no card required, which is enough to take a small app from integration to a live campaign. Paid plans start at $19 a month for Starter and $49 for Growth, and exceeding a plan limit throttles the affected feature rather than generating an overage charge.