Concepts
Deferred deep linking
How a link survives an app install on Android and iOS, how each install is matched, and the limits you should plan for.
Someone without your app taps a link, installs the app from the store, and opens it. Deferred deep linking is what makes that first launch land on the invite, product or article they tapped, instead of the home screen. It is included on every plan.
How it works
- The tap reaches DL2App, which sends the visitor to the store and keeps a short-lived note of the tap.
- On first launch, the SDK asks DL2App whether this install came from a tap.
- If there is a confident match, the SDK delivers the link to your code with
source: "deferred", exactly once.
How an install is matched
| Method | Platform | How | Certainty |
|---|---|---|---|
install_referrer | Android | Google Play passes a tap ID through the install. The SDK reads it on first launch. | Exact |
clipboard | iOS, opt-in | The store page copies a token, and the user taps a paste button in your app on first launch. | Exact |
fingerprint | iOS (and Android without Play) | The first launch is compared with recent taps from the same network: operating-system version, screen size, language, time zone, and how long ago. | A score from 0 to 1 |
Every install record and every delivered link carries the method and, for fingerprint, the confidence. You can see them in the dashboard and in the app.installed webhook.
Precision before recall
Opening someone else’s invite is worse than opening the home screen. So when two recent taps look alike, or the best candidate scores below the threshold, the answer is no match. You will see fewer matches than a service that always guesses, and far fewer wrong ones.
Known limits
We do not quote a match rate. Nobody has measured one independently, and it depends on your audience. Plan for these:
- iOS fingerprint matching degrades when the address changes between the tap and the first launch: VPNs, iCloud Private Relay, a switch between Wi-Fi and mobile data, or a carrier that rotates addresses. On the same network it usually works; across networks it often does not.
- Shared networks are ambiguous. In an office, a campus or a shop, several people can tap the same campaign from one address within minutes. Ambiguous candidates are not matched.
- IPv4 and IPv6 must line up. The browser and the app have to reach us over the same address family. Link hosts and the SDK API need matching IPv4 and IPv6 records for this reason, and a proxy in front of a custom domain that only speaks IPv4 can break matching.
- The window is short: 120 minutes by default, adjustable from 15 minutes to 24 hours per project. Longer catches slow installers and raises the chance of ambiguity. The Android install referrer still matches for up to 7 days.
- Clipboard matching shows iOS’s paste prompt, which is why it is off by default and only ever runs when the user taps the paste button. The SDK never reads the clipboard on its own.
- Delivered once. A deferred link is returned on the first launch of an install and repeated for a few minutes if the app restarts during onboarding. Reinstalling creates a new install.
- Not available when self-hosting from the export bundle.
Apple’s rules
Apple’s policy says an app may not derive data from a device to uniquely identify it. Fingerprint matching here is first-party, used only to deliver a link the person just tapped, kept for hours, and never used for advertising or shared. That is our reading, not an allowance granted by Apple. If you want no probabilistic matching at all, turn off Remember links for first launch in project settings and rely on the clipboard hand-off; Android’s install referrer is unaffected. What to declare in the stores is in Privacy and App Store disclosure.