Deep linking: direct vs deferred
A deep link is a short URL that opens your app on specific content instead of a web page. OptoLink handles two modes, and the difference is whether the app is already installed when the link is tapped:
- Direct deep linking — app installed: the link opens the app straight to the link's destination.
- Deferred deep linking — app missing: the link routes through the app store, and the destination survives the install to land on the first open.
The click-by-click routing decisions are in Routing & fallbacks; the deferred flow in detail is Deferred deep linking & the match flow.
Direct deep linking
When the app is installed, the ideal path never touches a web page. The mobile OS verifies that your app is allowed to open your link domain, using platform-verified association files that OptoLink publishes for you:
- iOS Universal Links: Apple's CDN fetches
/.well-known/apple-app-site-associationfrom your link domain and matches your app's team ID and bundle ID against it. - Android App Links: Google's verification does the same with
/.well-known/assetlinks.jsonand your app's signing certificate fingerprints.
With verification in place, a tap opens the app at the OS level, instantly. The SDK then fetches the link's data (path and parameters) for that URL and your app navigates. Because the OS does the routing, the browser never loads a page and there is nothing to fall back from.
Verification depends on configuration being complete on both sides: your app must declare the associated domain and be signed with the fingerprints on file. Where it isn't, the tap lands on the redirect page instead, which runs its own routing ladder (URI scheme, then store, then web). See Routing & fallbacks.
Deferred deep linking
When the app isn't installed, the story changes. A tap on the link routes to the app store, the person installs, and the first launch of the app must somehow recover where the journey started.
The web's usual tools are gone at that point: the store install happens in a different app, a different browser context, often minutes or hours later. No cookie, no session, no referrer survives. The only thing that works is evidence: whatever the click could plant on the device, and whatever the device can honestly report about itself on first open.
That recovery step is the match: connecting one first app open to one earlier click. OptoLink records each click's evidence for a configurable window (24 hours by default) and the SDK sends one match request on first launch. What comes back is the original link's path and parameters, so the user lands on the content they originally tapped.
Deferred delivery can be turned off per link (or per template); the default is off. See Link anatomy for the fields that control it.
Why the match is the hard part
Deterministic signals are the easy case. The redirect page can copy a one-time token to the device clipboard, and Android can attach a token to the Play Store referrer. When either arrives intact, the match is certain: one token means one click.
But each deterministic channel has holes. Users can deny clipboard access; some Android vendors and builds strip the referrer. So OptoLink also matches probabilistically: the click stores device attributes observed in the browser (platform, OS version, language, timezone, model, IP), and the first open reports the same attributes from inside the native app. Agreement across those signals produces a graded confidence rather than a certainty, and the grades are visible in your analytics: Attribution & match confidence.
The design trade-off is coverage versus certainty. Deterministic-only matching is precise but loses every install where the token didn't survive; the probabilistic legs recover much of that traffic at the cost of an occasional wrong guess. How to treat low-confidence matches in your app is covered in the Flutter SDK's deferred page.
Where the SDKs fit
You don't implement any of this by hand. Each SDK runs the flow as part of initialization: direct opens arrive through the platform's link handler, and the deferred match fires once per install automatically.