Most explanations of deferred deep linking are written for engineers. They open with SDK initialisation, walk through continueUserActivity handlers, and lose every marketer by paragraph three.
That’s a problem, because deferred deep linking is fundamentally a marketing mechanism. It exists to stop paid and organic traffic from leaking between the click and the first app open. If you own acquisition budgets, referral programs, or lifecycle messaging, you’re the person who benefits from it and increasingly, you’re the person expected to specify it in a brief. So this is the marketer’s version. No code. Just what it does, how it fails, and what to demand from whoever builds it.
The install gap, in plain terms
Let us assume there is a user who scrolls his Instagram feed and reaches the ad about the recipe application providing the specific 20-minute ramen recipe. By clicking on it
the user lands on the app store page because the app is not installed yet and therefore the link cannot open the application directly. Hence, the user installs the application and opens it for the first time.
Where does the user go after clicking the link?
The home screen almost every single time. The ramen recipe is nowhere to be found. A user makes a promise to himself, makes a commitment (meaning installation and hence requires some commitment on behalf of the user) and gets a generic welcome carousel instead.
This is what is known as the point of drop off, or “install gap”. Standard deep links such as Apple’s Universal Links and Android’s App Links cannot bridge these two points. They work perfectly fine while using the application but lack any kind of memory during the installation process. As put by Branch, “Universal Links alone do not carry memory through the install process.”
Deferred deep linking is the technology that bridges the “install gap”.
What deferred deep linking actually does
Deferred Deep Link is a Deep Link with memory. When clicked, it determines whether your application is installed or not:
App installed → regular deep linking kicks in. Your app will be launched into the right screen. Nothing fancy occurs, and it is almost 100% guaranteed to succeed.
App not installed → the link redirects the user to the App Store or Google Play, meanwhile the deep link provider saves the destination and the campaign parameters. After the installation and the launch for the first time, the app asks the provider “did anybody come here waiting for anything? “, and it gets its original data back. The user arrives on the page with ramen recipe.
There are three things that transfer through this process, and it is important to separate them, as vendors confuse all of them:
Destination – where to open the app (the User Experience task)
Context – promotion codes, referrals, product IDs, invitation tokens (the Personalization task)
Attribution data – which campaign, creative, and channel caused the install (the Measurement task)
Usually marketers are concerned with #3, but it is #1 & #2 which will drive the conversion.
How the matching works: deterministic vs probabilistic
To connect a post-install app that’s been opened from a click before installation, there must be some way to confirm that those two actions belonged to the same person. And here, there are two ways, and the distinction is enormous for your reporting.
Deterministic matching is based on a unique identifier which survives installation. In the case of Android, this is done via the Google Play Install Referrer API: you add a referrer parameter to the Play Store URL, and Google Play sends it back to your app after installation. According to AppsFlyer, this is deterministic and 100% accurate matching. When you encounter a suspiciously clean demo for an Android deferred deep link, this is likely the reason.
Probabilistic matching, previously called fingerprinting, and now called device snapshotting by Branch, matches these clicks using a combination of several non-identifying signals collected at the click-time: IP address, device model, OS version, screen size, language, timestamp. For iOS, this is what is mostly available to you, as there is no counterpart for the Play Install Referrer API. This method works fine as long as these signals correspond to each other the user is connected to cellular network and his/her IP address.
What changed, and why older guides mislead you?
Three things have changed underneath a deferred deep linking explainer from before 2025.
App Tracking Transparency introduced by Apple has restricted the deterministic flow on iOS. ATT is limited in terms of cross-app tracking, but deferred deep linking for navigation remains fully allowed without tracking opt-in. Rerouting to the requested content is not a tracking, and that’s the catch – the same link can be deterministic for the sake of user experience and probabilistic for the sake of measurement. The user opts out of tracking, and now deferred deep links have to use probabilistic matching for measurement.
Firebase Dynamic Link service shut down in August 2025. It used to be the default free alternative for many indie developers and small teams. Now the shutdown has forced them to migrate elsewhere. Several vendors, including Kochava, positioned themselves as the way forward. And your team can still be one of them if it has never reassessed FDL yet.
Clipboard-based handoff appeared as an alternative. Clipboard sharing is a more consistent option compared to fingerprinting, but it needs a user action and has its consent issues. Clipboard passing is a patch, not a solution. The overall consequence for marketers: deferred deep linking works:
Leave a Reply