What is deferred deep linking?

Definition

Deferred deep linking is the practice of preserving a link's destination through an app store install, so that a user who did not have the app lands on the intended screen the first time they open it.

An ordinary deep link only works when the app is already installed. If it is not, the tap goes to the store, the destination is discarded, and a user who clicked a specific product opens the app on a generic home screen. Deferred deep linking is the mechanism that carries that destination across the gap — and the two platforms give you completely different amounts of help with it.

What happens across the install

Five steps, and only one of them is under the platform's control. The rest is your link service and your app.

1. The user taps a link. The app is not installed, so nothing intercepts it and a web request reaches your link service.
2. The service records the click — destination, campaign fields, a click identifier — and redirects to the correct store, attaching whatever context that store will carry.
3. The user installs and opens the app for the first time.
4. On first launch the app asks the service what this install came from, presenting whatever signal survived the trip.
5. The service returns the original destination and campaign fields, or nothing at all if no signal survived. The app routes accordingly.

Android: the install referrer carries it

Google Play passes a string from the store URL through to the installed app. It is exact, deterministic, and available to any app that asks — which makes Android the easy platform for this.

# What your link service redirects an uninstalled Android user to.
# Everything after referrer= is an opaque string you define.
https://play.google.com/store/apps/details\
?id=com.example.shop\
&referrer=utm_source%3Demail%26utm_campaign%3Dspring%26click_id%3Dclk_4b7d2e%26deep_link_value%3D%2Fproducts%2F42

# What the Install Referrer API returns on first launch, decoded:
utm_source=email&utm_campaign=spring&click_id=clk_4b7d2e&deep_link_value=/products/42

val client = InstallReferrerClient.newBuilder(context).build()

client.startConnection(object : InstallReferrerStateListener {
    override fun onInstallReferrerSetupFinished(responseCode: Int) {
        if (responseCode != InstallReferrerClient.InstallReferrerResponse.OK) return

        val details = client.installReferrer
        val referrer = details.installReferrer          // the string above
        val clickTime = details.referrerClickTimestampSeconds
        val installTime = details.installBeginTimestampSeconds

        // clickTime -> installTime is the click-to-install time, which is
        // also the primary signal for detecting click injection.
        Router.resolveDeferred(referrer, clickTime, installTime)
        client.endConnection()
    }

    override fun onInstallReferrerServiceDisconnected() {}
})

iOS: what actually survives

There is no iOS install referrer. The App Store passes nothing from the click to the installed app, which is why every iOS deferred implementation is a matter of what other signal can be made to survive.

The last row is a policy decision, not a capability gap. Fingerprinting assembles an identity from screen size, boot time, free disk space and IP address — the same signals Apple designated as required-reason APIs precisely because of this use. When no deterministic signal survives, we return no attribution rather than a guess dressed up as a match.

The payload your app resolves

Whatever the platform, first launch ends with one call and one response. Designing that response to be explicit about *how* it was matched is what keeps downstream reporting honest.

{
  "matched": true,
  "match_type": "deterministic",
  "match_signal": "play_install_referrer",
  "click_id": "clk_4b7d2e",
  "clicked_at": "2026-08-17T09:14:02Z",
  "installed_at": "2026-08-17T09:19:58Z",
  "deep_link": "https://example.com/products/42",
  "deep_link_value": "/products/42",
  "campaign": { "source": "email", "medium": "newsletter", "name": "spring" }
}

// And the honest negative case, which iOS produces regularly:
{
  "matched": false,
  "match_type": null,
  "match_signal": null,
  "deep_link": null
}

Both are needed: direct links for users you already have, deferred for the ones you are acquiring. When the deferred half returns nothing and you expected an answer, the ordered checklist is in deferred-deep-link-not-working.