Deferred Deep Linking
How Lander brings someone to the right screen after they install your app from a link, per platform, and what it will not do.
A deferred deep link is a link someone taps before your app is installed. They go to the store, install, open the app, and should land on the screen the link was for, not on the home screen.
Lander does this wherever it can be done honestly, and tells you how sure it is every time. Each deferred link carries a confidence (deterministic or probabilistic) and a method saying which flow found it.
tap (app not installed) --> edge --> store, with a token where possible
|
install
|
first launch --> SDK: POST /v1/sdk/init --> Lander ties the install to the tap?
|
yes: deferred link on onDeepLink (isDeferred: true)
no: nothing delivered, install recorded as unattributedAt a glance
| Platform | Flow | Confidence | What you do |
|---|---|---|---|
| Android | Play Install Referrer | deterministic | Nothing. Works out of the box. |
| iOS | Continue in app page | deterministic | Turn it on. Add a custom URL scheme (recommended). |
| iOS and Android | Authenticated handoff | deterministic | Call one API from your server and one SDK method after sign in. |
| iOS | Probabilistic matching | probabilistic | Opt in, and treat the result as a hint. Add IP matching for a much higher match rate. |
| Anything else | unattributed | Nothing. The install is still counted. |
Android: automatic and exact
When someone without your app taps a Lander link on Android, the edge sends them to your Play Store listing with a short, single use token in the Play Store's install referrer. Google Play hands that referrer to your app after install. On first launch the SDK reads it once and sends it to Lander, which turns it back into the link.
- The link arrives with
isDeferred: true,confidence: deterministicandmethod: install_referrer. - Nothing is read from the device except the referrer Google Play provides for this purpose.
- A token works once and expires after 7 days.
It does not work when the install does not come from the Play Store (another store, a sideloaded APK, an emulator without Play), or when the link has an Android fallback URL: that URL wins, and Lander cannot add a token to a page it does not control.
iOS: why it is harder
Apple gives apps no install referrer, and the App Store drops anything a link tries to pass through it. The usual industry workarounds are device fingerprinting, silent pasteboard reads and advertising identifiers. Lander uses none of them. Instead it offers three honest options that work together.
Continue in app page (deterministic)
Instead of sending iPhone users straight to the App Store, the edge shows a small, fast page with your app's name and two choices: a button to get your app on the App Store (for example Get Acme Shop on the App Store), and I already have the app, open it.
After installing, the person comes back to the page (it stays open in Safari) and taps the second button. The app opens on the link's screen with method: landing_page, and isDeferred: true because the app was installed after the tap. Safari's Smart App Banner at the top of the page offers the same Open button.
The page has no scripts and relies on the user's explicit tap, so nothing is guessed. The cost is one extra screen for people without the app, which is why it is off by default.
- Turn on
iosLandingPage(see Settings below). Your iOS app needs an App Store ID under Platforms. - Add a custom URL scheme to your iOS app and to your iOS platform settings in Lander. iOS keeps a Universal Link tapped on a page of the same domain inside Safari, so without a scheme the open button may reload the page instead of opening your app. With a scheme, the button always opens the app.
- Links with an iOS fallback URL skip the page and go to that URL.
Authenticated handoff (deterministic, iOS and Android)
If people sign in to your app, your own account system is the most reliable bridge. Typical case: someone taps an invite on their laptop, signs up on your website, then installs the app on their phone.
- Your server tells Lander which link belongs to which user, with a secret key (
POST /v1/handoffs). - The app claims it right after that user signs in:
final link = await Lander.claimHandoff(user.id);
if (link != null) router.go(link.route, extra: link);The link comes back with method: authenticated_handoff. It is delivered once, returned directly instead of on onDeepLink, and expires after 7 days unless you set a shorter time. Use a user ID nobody can guess, such as your auth system's UUID, never an email address or a counter. Lander stores only a salted hash of it.
Probabilistic matching (opt in, off by default)
With probabilisticMatching on, Lander keeps a few coarse facts about recent iPhone taps: the iOS major version, the country and the time. On an iOS first launch it looks at taps from the last 2 hours (adjustable from 15 minutes to 6 hours). If every tap with the same iOS version and country points at the same link, the app gets that link with confidence: probabilistic and method: probabilistic_match. If they point at different links, Lander returns nothing rather than guess.
On its own this is weak, so it mostly works for links with little traffic. Turn on probabilisticIpMatching as well and Lander first looks for taps from the same network, using a keyed hash of the IP address (never the address itself), deleted once matched and after 7 hours at most. That finds far more installs, as long as the network does not change between the tap and the first launch.
Treat probabilistic links as a hint
A probabilistic match can be wrong. Use it for convenience, like landing on a product page. Never sign someone in, apply a referral credit or reveal anything private because of it. Check that your privacy policy and App Store privacy details cover it before you turn it on, especially IP matching.
Not available yet
App Clips could carry a link into the full app deterministically. Lander does not support them yet.
What unattributed means
Every first launch that no flow could tie to a tap is recorded as an unattributed install. Nothing is delivered, and the app starts normally. This is not an error: on iOS without the opt in features it is the honest answer for most store installs. If a deterministic link turns up later for that install (the person taps "open it" on the Continue in app page, or signs in and claims a handoff), the install is upgraded to it.
In your app
Deferred links arrive exactly like every other link, through Lander.onDeepLink or Lander.getInitialLink(), once. Handoffs are the exception: Lander.claimHandoff returns the link to you directly.
Lander.onDeepLink.listen((link) {
if (link.isDeferred && link.confidence == LanderConfidence.probabilistic) {
// A good guess: show the screen, but do not act on it silently.
}
router.go(link.route, extra: link);
});More code and edge cases in Deferred links in the SDK.
Settings
Per project, shared by the test and live environments. Change them with PATCH /v1/deferred/settings and a secret key; there is no dashboard switch for them yet. Changes apply to the next tap.
| Setting | Default | Effect |
|---|---|---|
iosLandingPage | off | iPhone taps get the Continue in app page instead of an immediate App Store redirect |
webFallbackTokens | off | Redirects to your web fallback carry lander_token, which your server can pass to POST /v1/handoffs |
probabilisticMatching | off | Opt in iOS probabilistic matching |
probabilisticIpMatching | off | With probabilistic matching on, also match by network (a keyed hash of the IP, kept at most 7 hours) |
probabilisticWindowMinutes | 120 | How far back probabilistic matching looks, 15 to 360 |
curl -X PATCH https://api.golander.link/v1/deferred/settings \
-H "Authorization: Bearer sk_live_..." -H 'Content-Type: application/json' \
-d '{"iosLandingPage":true}'Privacy summary
- Android uses the Play Install Referrer, which exists for this purpose.
- iOS deterministic flows depend on a tap by the user or on your own sign in.
- Probabilistic matching is off unless you turn it on, and compares only OS major version, country and tap time.
- IP matching is a second opt in. It compares a keyed hash of the network, deleted once matched and within 7 hours at most.
- Lander never stores IP addresses, never builds device profiles, never reads the pasteboard and never uses advertising identifiers.
- Tokens are random, single use and expire after 7 days. Handoffs store a hash of your user ID, not the ID.