How Deferred Deep Linking Actually Works (Match Tokens, Referrers, and Fallbacks Explained)

The industry’s natural response to the challenge of deferred deep linking is to treat it as a single cohesive mechanism, but in truth it comprises three completely separate functions, each of which addresses a distinct point of failure in the deferred deep linking ecosystem. This is critical to understand if you’re rolling out deferred deep linking yourself, or considering using an SDK that supports it.

The problem deferred deep linking solves

A normal, standard deep link works only when the app is already installed on the device: the user clicks the link which directs the OS to the corresponding application, which in turn reads the URL and directs the user to the right place.

But what about the users who clicked your link but do not have the app yet? Let’s see:

1. The OS has nowhere to send the link, so it falls back to the browser or app store.
2. The user installs the app.
3. The user opens the app for the first time.
4. At this point, the original link is gone. The app has no idea the user came from a specific referral, product page, or campaign.

Deferred deep linking refers to a combination of techniques that directs the user back to step 1, after step 4 — hence, a person who clicked on “check out this pair of shoes” will eventually see this pair of shoes after installing the app rather than being redirected to the app’s homepage.

Mechanism 1: Match tokens

A match token is a unique identifier that associates a click with a specific app install, thus establishing a connection between them at the deepest level, when, from a system point of view, there is no such association (which, by default, there is not, since mobile OSes do not provide a built-in mechanism for passing such information during the installing process).

The general flow:

• When a link is clicked, our platform generates a unique fingerprint for this click, containing information about the IP address, device type, OS, resolution, and more.
• When the application is opened for the first time, the SDK embedded in the application collects the same information from the device where the application is being launched.
• The platform compares these two fingerprints and, if they match, indicates to the application that the installation came from the specified link, providing it with the necessary information (destination screen, referral ID, campaign, and others).

This is probabilistic information — not an exact science, and for good reason. There is always room for error when it comes to fingerprint matching, which is why click-through rates (and not 100% match rates) are your metric of choice. This has to do with the fact that match tokens only work well within a confined timespan, so the earlier you can get a user to click through your link after they’ve opened your campaign, the better.

Mechanism 2: Store referrer data

Android has one genuinely deterministic alternative to link-guessing “fingerprint” matching: the Play Store Install Referrer API. When a user launches an app installed via a Google Play link containing a referrer string, Google Play caches this referrer string for the app and makes it available to the app on first launch via a system-level API, without needing any fingerprinting at all.

Meanwhile, iOS does not have an analogous official mechanism for arbitrary referrer strings (Apple’s App Store campaign tokens are more limited, designed around Apple Search Ads). This is part of why iOS deferred deep linking often leans more heavily on fingerprint-based attribution, or complementary clipboard-based schemes as a fallback.

The upshot is that Android deferred linking can be made arbitrarily more reliable than iOS deferred linking, by virtue of having a first-party data channel which iOS does not. As a result, any attribution SDK which claims comparable levels of accuracy across both platforms is in practice using probabilistic attribution (including possibly clipboard-based “fingerprinting”) for iOS.

Mechanism 3: Fallback routing

Fallbacks are the mechanisms which address everyone the first two mechanisms have failed for — either because something needed to happen before matching could occur, or the user was never going to install the app anyway.

A good fallback chain will typically address the following cases, in order:

1. Is the app already installed and able to deep link to the destination? → Open the app to the destination.
2. Is the app not installed? → Send the user to the appropriate app store (iOS/Android/desktop web, as detected by the user agent), passing along any match token/referrer data necessary to satisfy the equivalent of steps 1 or 2.
3. Is this an unsupported platform or a bot/crawler? → Provide a plain web fallback so the link doesn’t just 404.

The robustness of fallback logic is frequently the difference between a deep linking implementation that works well and one that frequently results in frustrated users — “why did this link just take me to the App Store homepage instead of the product page”?

Where this typically breaks

A few patterns worth knowing if you’re debugging deferred links:

• Long gap between click and install. If someone clicks a link, doesn’t install for three days, then installs, match confidence drops and the deferred payload may not resolve.
• Ad blockers and privacy features stripping fingerprint signals. Some browsers and OS-level privacy settings limit what signals are available, which lowers match accuracy industry-wide, not just for any one vendor.
• Testing on the same device repeatedly. If you reinstall the same app on the same test device to check deferred linking, some platforms will resolve to a previous match token from an earlier test, always a source of confusing bug reports.
• Missing Android referrer permission or misconfigured Play Store listing. If the Install Referrer API isn’t wired up correctly, Android falls back to the same probabilistic matching iOS uses, and loses its accuracy advantage.

How WilderLinks handles this

WilderLinks’ SDKs (Flutter, React Native, native iOS/Android, web, and Unity) implement all three of these mechanisms, not left to the developer to stitch together: match-token based click-to-install linking, Play Store referrer handling on Android, and a configurable smart fallback routing by device, OS, geo, language, time window, and A/B split, such that the fallback chain is not necessarily “installed vs not installed”, but can differentiate by audience segments too. Deferred link resolution and match accuracy are visible right in the analytics dashboard, along with the rest of your campaign’s clicks, installs, opens, and funnel events.

It’s currently in beta and free to use. If you’re debugging deferred linking issues on your current setup or evaluating a switch, start a workspace — happy to walk through your specific match-rate numbers.

New to deep linking terminology? See our Universal Links vs App Links vs Deep Links explainer, or check the docs for SDK-specific setup guides.