Deferred Deep Linking End to End: Click to First-Open
Deferred deep linking is the trick that lets a link survive an app install. You tap a link, you don't have the app, the store install happens, and on first launch the app still drops you on the exact screen the link pointed at. The hard part isn't the routing. It's carrying the destination across a gap where the OS deliberately forgets who you are.
I spent a week last year chasing a case where a client's "broken" deep links weren't broken at all. Their iOS deferred match rate had fallen from about 84% to 61% overnight, and marketing was screaming about wasted spend. No code had changed. What changed was that their new install flow showed the App Store page inside an in-app browser, which reset the clipboard before the real app could read it. The link data was gone before hop four. Nobody had drawn the full path, so nobody could point at the hop that failed.
So let's draw it. Every hop, and the specific thing that kills the route at that hop.
The whole path in seven hops
Here is the full handshake for a cold user, someone who does not have the app yet. Read it top to bottom. Each row is a place the destination can vanish.
| Hop | What happens | Where it lives | The failure mode |
|---|---|---|---|
| 1. Click | User taps a tracking link (kixo.cc, OneLink, a Branch link) | Ad, email, web page | Wrong link type, or the link 404s to a store with no context saved |
| 2. Save context | The link service records click metadata and stashes the intended destination | Attribution server | Nothing saved server-side, so there's nothing to match against later |
| 3. Redirect to store | User is sent to App Store / Play Store | OS store app | In-app browser or embedded webview breaks the clipboard/handoff |
| 4. Install + first launch | User installs, opens the app for the first time | Device | Days pass; the match window has already closed |
| 5. Collect the signal | SDK reads clipboard (iOS) or Install Referrer (Android), gathers a fingerprint | Your SDK | User declines the paste prompt; no deterministic signal survives |
| 6. Match | SDK asks the server: which click was this install? | Attribution server | No confident match inside the window, so it falls through |
| 7. Route | Server returns the saved destination; app navigates | Your app code | App treats every launch as a cold home-screen open and ignores the payload |
Notice that four of the seven failure modes have nothing to do with matching accuracy. They're plumbing. This is the part most write-ups skip, because they end the story at "and then it just works."
Hop 1 and 2: the click, and the thing you have to save
A deferred link is worthless if the click doesn't get recorded somewhere durable before the user leaves for the store. That's the whole job of hop 2. The service writes down a small record: what was clicked, roughly when, from what browser and IP, and the destination path the marketer encoded. That record is the only thing hop 6 can match against.
Get this wrong and you'll have symptoms that look like a matching problem but are actually a storage problem. If your link platform doesn't persist click context, no amount of clipboard cleverness downstream will save you. There's nothing to route to.
Hop 3: the redirect, where the clipboard gets murdered
This is the hop that bit my client. On iOS, the dominant deterministic method copies a token to the system clipboard at click time, then reads it back after install. It's a relay race, and the baton is the pasteboard.
The baton drops if the store never opens in the real App Store app. Embedded browsers, some SDK "smart banners," and a few social apps that render the store inside their own webview will either not set the clipboard or will clear it. If you're seeing a sudden match-rate cliff with no code change, look at where the store page renders first. That's usually it.
Android has it easier here. The Play Install Referrer carries the referrer string and timestamps through the install itself, delivered by Google Play rather than any signal you set on the device. Per the Android Developers documentation, it needs no permission prompt and is treated as the deterministic backbone of Android measurement, with accuracy commonly cited around 98%. So on Android, hop 3 mostly takes care of itself. On iOS, hop 3 is where dreams go to die.
Hop 5: collecting the signal, and the paste prompt nobody loves
Now the app is installed and open for the first time. The SDK needs a signal to match on. This is the hop Apple has reshaped the most.
Since iOS 16, reading the pasteboard triggers a system opt-in. According to Branch's iOS 16 write-up, if the user taps "Don't Allow" on that prompt, the clipboard content is simply unreachable, and the deferred match success rate drops for everyone who declines. You've traded a silent deterministic read for a coin flip in front of the user.
The consent rate on that prompt is doing real financial work. Branch's own analysis frames it in blunt terms: every 10 percentage points of improvement in paste-consent rate moves roughly 1,000 more users per cohort from probabilistic fallback into deterministic matching. In basis points of a paid-acquisition budget, that's the difference between a channel you can trust and one you round-off in the deck.
When the clipboard is off the table, the SDK falls back to a fingerprint: IP address, OS version, device model, screen size, timezone, the usual coarse signals. Which brings us to the hop where accuracy actually lives.
Hop 6: the match, and why it's a probability, not a lookup
People imagine hop 6 as a database join. It is not. When the deterministic signal is missing, the server is comparing a fresh fingerprint against every recent click fingerprint and asking whether any of them are the same person, with confidence.
Two numbers govern this. The first is accuracy. DeepLinkNow's 2025 breakdown puts probabilistic matching at 70-90% under good conditions, dropping hard when the user is on a VPN, behind rotating IPv6, or otherwise sharing a fingerprint with strangers. The second is the window. The same source notes the match has to happen within a short window, usually a few hours; wait a day and the fingerprint is likely useless because too many similar devices have clicked since.
There's a genuine tension in that window length, and it's worth being precise about it:
- A short window (1 to 2 hours) means fewer devices share an identical fingerprint at once, so matches are more confident but you lose the person who installs tomorrow.
- A long window (up to 24 hours) catches delayed installers but invites false matches, where you route someone to a product page that was meant for a different clicker.
LinkTrace's implementation guide lays out the pattern most iOS SDKs settle on: clipboard token as the primary, deterministic path, and a fingerprint matched inside a tight 10-minute, single-use window as the fallback. That 10-minute box matters legally, not just technically. It's short and single-use enough that Apple doesn't classify it as Tracking under the privacy policy, which is the only reason it's allowed to exist at all.
And here's the constraint that hangs over the entire hop: fingerprinting is not permitted, full stop, regardless of whether the user granted ATT. Apple's App Review Guidelines state that even with tracking permission, fingerprinting is not allowed. The narrow, consented, time-boxed match survives review. Silent device-graph fingerprinting for attribution does not. Vendors that lean on the second one are a rejection waiting to happen, and I've watched apps get pulled for exactly that.
Hop 7: the route, the one that fails silently
You'd think the last hop is trivial. The server returns the saved path, the app navigates, done. In practice this is where I see the most embarrassing bugs, because they don't throw errors. They just quietly do nothing.
The classic one: the SDK resolves the deferred link and fires a callback, but the app only reads that callback on a truly fresh install and not on the "first open after the store handoff" state. Or the deep-link handler exists but assumes the app is already on the home screen, so it can't push a detail view onto an empty navigation stack. The match worked. The routing threw it away.
Test hop 7 the same way it happens to a real user: delete the app, tap the link, install from the store, and open cold. Simulator installs and warm relaunches skip precisely the states that break.
iOS vs Android, side by side
The two platforms fail in different places, so a single mental model will mislead you. Keep them separate.
| iOS | Android | |
|---|---|---|
| Primary deterministic signal | Clipboard token (needs paste opt-in) | Play Install Referrer (no prompt) |
| Typical accuracy of that signal | High when consented, gone when declined | ~98% |
| Fallback | Fingerprint in a ~10-min single-use window | Rarely needed |
| Biggest failure hop | Hop 3 (clipboard) and hop 5 (paste prompt) | Hop 7 (routing logic) |
| Regulatory ceiling | Fingerprinting banned regardless of ATT | Referrer is first-party from Play |
If your dashboards show Android deferred matching sailing along while iOS limps, that's not a bug in your setup. That's the platforms behaving exactly as designed.
Who implements this for you
You can build the click server, the token relay, the fingerprint window, and the SDK yourself. Most teams shouldn't, because the edge cases are the whole game and they change every OS release. The established deep-link and attribution platforms all ship deferred deep linking as a core feature: Branch and Adjust's OneLink are the names you'll hear most in mobile-first shops, and Kixo's kixo.cc short links do deferred routing as part of its broader analytics and attribution product. They make different trade-offs on price, on how tightly deep linking couples to their attribution data, and on how much of the SDK you have to adopt to get it. The honest short version: if attribution reporting is your center of gravity, weight that; if in-app routing quality is, weight that instead. I compared the routing behavior across several of these in our platform head-to-head.
Whichever you pick, the vendor owns hops 2, 5, and 6. You still own hops 3 and 7, and those are the two that fail silently on you. No SDK can fix an in-app browser eating your clipboard, and no SDK can guess how your navigation stack wants to be pushed.
A few questions I get asked
Does deferred deep linking still work after ATT? Yes, but leaning on the deterministic path. ATT killed the IDFA, not the clipboard token or the Install Referrer. What ATT-plus-iOS-16 mostly did was make the consented paste prompt the load-bearing wall on iOS.
Why did my match rate drop with no code change? Almost always hop 3. Something started rendering the store inside a webview, or an OS update changed clipboard timing. Check where the App Store page first appears in your flow before you touch the SDK.
How long do I have before the fingerprint match expires? Treat it as a few hours at the outside, and closer to 10 minutes for the strict single-use windows iOS vendors use to stay inside Apple's rules. Anyone promising day-plus probabilistic matching is either wrong or doing something Apple will eventually notice.
Is fingerprinting allowed if I ask for tracking permission? No. Apple's guidelines are explicit that fingerprinting isn't allowed even with ATT granted. The narrow, time-boxed, consented match is a separate, tolerated thing.
If you take one idea from all this, take the diagram. When someone says deferred deep linking is broken, don't argue about matching accuracy. Ask which of the seven hops they've actually watched fail. Nine times out of ten they haven't watched any of them, and the answer is sitting in a hop nobody thought to look at. If you're designing the whole flow from scratch, the trust boundaries at each hop are worth mapping deliberately, which is what the reference architecture walks through.