Deferred Deep Linking Without an SDK: How It Actually Works Under the Hood
You can carry link intent across an app install without embedding an attribution SDK. Here is what actually survives the store boundary on Android and iOS, what breaks, and what each workaround costs in privacy.
The context dies at the store boundary
Someone taps a link to /product/42. The app is not installed, so your redirect sends them to the store. They install, they open the app, and they land on a generic home screen. The HTTP request that carried their intent ended at the store listing. The freshly installed app starts with no URL, no cookie, no referrer header. Nothing from the click survived.
Carrying that context across the install is deferred deep linking, and the standard answer is "embed an MMP SDK". A lot of teams do not want that answer. The question shows up wherever developers gather — Apple Developer Forums thread 772811 is one of many asking how to do it without a third-party SDK — and the audience got wider in August 2026, when AppsFlyer moved deferred deep linking out of its free plan. So: can you build it yourself? On Android, yes, cleanly and officially. On iOS, sort of, through workarounds with real costs.
One scope note before the mechanics. We cover what deferred deep linking is and when it pays off in a separate article. This post is only about the plumbing: which transport can smuggle a token across an install, and how much you can trust each one.
What survives the install, and what does not
Android: the Install Referrer API is the honest good news
Google Play solves this natively. A Play store URL accepts a referrer query parameter, Play stores that string alongside the install, and the app can read it back verbatim after first launch through the Install Referrer API. That is the entire mechanism. No fingerprinting, no clipboard, no guessing.
It is not quite "zero code", to be precise. Reading the value requires the com.android.installreferrer library — a small artifact that talks locally to the Play Store app on the device. It makes no network calls to anyone, it is not an analytics SDK phoning home, and it adds nothing to your privacy disclosures beyond what you choose to do with the string.
What goes in the parameter is up to you: a link ID, a campaign name, an encoded deep-link target. Keep it short and URL-encoded — the referrer on play.google.com/store/apps/details?id=com.example&referrer=tok_8f2 comes back exactly as sent.
The full loop, end to end
- 1On link tap, your redirect appends referrer=<token> to the Play URL, where the token points at click context stored on your server.
- 2On first launch, the app connects an InstallReferrerClient and reads the installReferrer string.
- 3The app exchanges the token at your API for the stored context — deep-link path, campaign — and routes the user.
- 4Your server marks the token consumed. The referrer string persists on the device, so single-use enforcement has to live server-side.
The limits are narrow and predictable: the API only covers installs that actually went through Google Play. Sideloads, Huawei AppGallery, and other stores do not carry a Play referrer, and the value should be read once shortly after first launch, not treated as a permanent store.
iOS: no official equivalent, three workarounds ranked
Apple ships nothing like the Install Referrer. An App Store product page does not carry arbitrary parameters through an install, and everything below is a workaround built on that absence. Ranked from least bad to most niche:
Clipboard pass-through
01 · medium reliability, permission-gatedYour link-tap page writes a short token to the clipboard — behind a button tap, since Safari requires a user gesture for programmatic copy — then forwards to the App Store. On first open, the app reads the pasteboard, finds the token, and exchanges it with your server.
The catch arrived with iOS 16: reading the pasteboard triggers the system paste prompt. The user sees "Allow this app to paste from Safari?", on the very first screen of an app they installed thirty seconds ago, and many decline. A decline is silent loss — you cannot distinguish it from "no token existed". UIPasteboard.detectPatterns can check for a matching pattern without prompting, but it cannot read the value. The clipboard can also be overwritten between tap and first open. It works, measurably often, but it is a coin with a visible second face.
Probabilistic matching
02 · low–medium reliability, privacy-hostileAt click time the server records IP address, device model and OS version from the user agent, and a timestamp. On first open the app calls your endpoint, which looks for a click with matching signals inside a short window, usually under half an hour. No token travels at all; the match is a guess.
We describe this because vendors sell it, not because you should build it. The signals are degrading: iCloud Private Relay masks IPs, carrier-grade NAT puts thousands of users behind one address, and device models are coarse buckets. Apple explicitly discourages fingerprinting, and in the privacy-manifest era, collecting these signals for matching is something App Review can ask you to justify. Accuracy falls every year and the false matches route real users to the wrong screen.
App Clips and other niche paths
03 · reliable but narrowAn App Clip invoked from your link receives the full URL and can hand the context to the full app through a shared container after install. Inside its niche this is the most reliable iOS path — but it requires building and maintaining an App Clip, and it only fits flows where a lightweight instant experience makes sense. Shared web credentials and associated domains solve the adjacent problem of auth continuity, not general link context. Worth knowing, rarely the answer.
The design pattern that holds regardless of mechanism
Whichever transport carries the token — referrer string, clipboard, even a probabilistic match ID — the server-side architecture is the same, and getting it right matters more than the transport. Do not stuff the whole deep link into the channel. Store the click context on your server and move only a short-lived key.
Store context keyed by a random token
On click, write {deep_link, campaign, timestamp} under a short random token, and put only the token into the transport. This keeps payloads small, keeps campaign data out of clipboards and referrer logs, and lets you change what "context" means without touching the client.
Expire aggressively
A TTL of 30 to 60 minutes covers the real tap-to-install journey. A deferred route resolved a week after the click is wrong more often than it is right — the person who opens the app then is not on the errand they were on when they tapped.
Enforce single use
Consume the token on first exchange. Referrer strings persist on-device and clipboards can be read twice; without single-use, a reinstall or a second device can replay someone else’s context and misattribute the install.
Fail to the default, not to a guess
No token, expired token, declined paste prompt — land the user on the normal home screen. A generic first open is mildly disappointing; being routed into another user’s cart is a support ticket.
Reliability, honestly stated
Rough figures from teams running these in production. Your mix of traffic sources, install delay, and audience iOS version moves every number.
| Mechanism | Platform | Reliability | Notes |
|---|---|---|---|
| Play Install Referrer | Android | High | Official API, survives delayed installs, no user prompt. Play installs only. |
| Clipboard token | iOS | Medium | Gated by the iOS 16+ paste prompt; declines are silent; clipboard is volatile. |
| Probabilistic matching | iOS | Low–medium | IP + model + timing window. Degrading under Private Relay and CGNAT; discouraged by Apple. |
| App Clip hand-off | iOS | High, narrow | Deterministic, but only for flows that justify building an App Clip. |
What this means for your stack
If your deferred routing need is Android-only, you need very little: a link that appends the referrer parameter, the small referrer library, and one endpoint that exchanges tokens. That is an afternoon of work, and it is genuinely SDK-free in the sense that matters — no third-party code observing your users.
iOS is where managed solutions earn their keep, because the workarounds are the product: maintaining match infrastructure, designing around the paste prompt, and tracking each OS release that moves the ground. That is also why it is priced like infrastructure — Appy offers deferred deep linking at the Enterprise tier, where that maintenance is the vendor’s problem instead of yours.
Be honest about which problem you have, though. If what you actually need is "users who already have the app should land on the right screen", that is standard deep linking — no install boundary to cross. Appy’s deep link shim covers that case on the Pro plan at $9.99/month, store fallback included, still without an SDK. Measure how much of your funnel is genuinely fresh-install-with-context before buying the harder machinery.
Frequently asked questions
Does the Install Referrer work from a QR scan?
Yes, provided the QR resolves through a link that appends the referrer parameter to the Play URL. The mechanism does not care how the click started — scan, tap, or NFC — only that the store URL carried the referrer when Play opened. A QR pointing straight at a bare Play URL carries nothing.
Why did my clipboard token approach suddenly break?
Almost certainly the iOS paste prompt. Since iOS 16, the first pasteboard read from your app triggers a system permission dialog, and a meaningful share of users decline it. Your code did not regress; your read now has a human in the loop. Check whether your token-found rate dropped rather than went to zero — that is the signature.
Is fingerprint matching actually allowed on iOS?
It is a gray zone, and the ground is moving against it. Apple’s guidelines prohibit fingerprinting for tracking, privacy manifests require you to declare the signals you collect and why, and App Review has rejected apps over it. Some vendors still ship it. If you build it yourself, you own that risk, and you should assume accuracy keeps falling either way.
Do I need deferred deep linking at all?
Only if the post-install landing screen materially changes your funnel. If most installs come from generic campaigns with no specific destination, a good onboarding beats a deferred route. Measure first: count clicks where a real deep-link target existed and the app was not installed. If that number is small, spend the effort elsewhere.
Continue exploring
Deferred Deep Linking: How It Works and When to Use It
Understand how deferred deep linking carries the original link intent across install so new users land on the right in-app screen, not a generic home tab.
Complete Guide to Universal Links for iOS and Android
Everything you need to know about universal links, deep links, and app links. Learn how to implement them and boost your mobile marketing.
iOS 26 Link Tracking Protection: Which URL Parameters Survive?
Safari now strips click identifiers like gclid and fbclid from campaign links while UTMs pass through. What that means for app install measurement, and how first-party links keep attribution working.
Looking for something else? Browse all topics on the blog.
Route the installs you already earned
Standard deep links with store fallback on Pro, deferred deep linking on Enterprise — both without putting an SDK in your app.
Start with Appy