Skip to main content

Deferred deep linking & the match flow

When someone taps your link without the app installed, the tap still matters. This page follows that tap through the store and back: what OptoLink stores at click time, what the SDK sends on first open, how the two are connected, and what happens when they can't be. The general contrast with direct linking is on Deep linking: direct vs deferred; exact request and response shapes are in the Resolution API.

The flow, end to end​

  1. Click. A browser opens your short URL. The click is recorded, and because the link has deferred delivery enabled, OptoLink stores a match record: the link's destination and parameters plus everything the browser reveals (platform, OS version, language, timezone, device model, IP). The record lives for the link's match window.
  2. Evidence planting. The redirect page gives the device something to carry through the install: it copies a one-time token (opl_…) to the clipboard, and on Android it also embeds the token in the Play Store URL as an install referrer.
  3. Store and install. The visitor installs the app. Depending on platform and permissions, the clipboard token or the referrer token comes along; if neither survives, the device attributes stored in step 1 are the remaining evidence.
  4. First open. The SDK sends one match request with everything it collected: tokens if any, plus its own device attributes.
  5. The match ladder. The backend compares the request against stored records, strongest signal first: clipboard token, install referrer, exact attribute match, weighted attribute scoring, then same-IP as a last resort. The result carries a confidence tier.
  6. Payload delivered. A match returns the link's path and params, and the app navigates as if the link had opened it directly. Whether it matched or not, the attempt is recorded for analytics.

The SDK runs all of this as part of initialization, once per install. Your code reads the result off the SDK's link callback; see your platform's guide (Flutter, iOS, Android).

What the match can and can't trust​

The ladder's order is an order of certainty:

  • Clipboard token and install referrer are deterministic: a one-time value that can only have come from your click. The redirect page prepares the clipboard payload for both platforms; a denied clipboard prompt or a stripped referrer removes that leg.
  • Fingerprint matching compares device attributes observed in the browser with what the native app reports. Exact agreement on all attributes counts as high; partial agreement goes through weighted scoring, where every attribute contributes points and the total decides whether a match happens at all.
  • Same-IP matching attributes a first open to the most recent click from the same network address. It's the thinnest evidence and is graded low.

Two protections are built in. A matched record is consumed, so the same click can't match twice. And when many recent clicks from one IP all score high but point at different links (an office or campus network), OptoLink declines to guess: those opens come back unmatched rather than mis-attributed.

What the tiers mean in your reports: Attribution & match confidence. The SDK-side view, including the per-platform prompts the clipboard leg triggers: Flutter: deferred deep linking.

Match windows​

The match window is how long a click stays matchable. It's a per-link setting, inherited from the template when the link doesn't set its own, measured in hours:

  • Default: 24 hours
  • Allowed range: 1 to 720 hours (30 days)

Within the window, the stored record answers match requests; after it expires, the record is gone and the same first open comes back unmatched. Set a longer window for campaigns with a long consideration gap between tap and install, and a shorter one where clicks should expire quickly (flash promotions, per-day content).

Changing the match window on a template applies to every link inheriting it on the next click: see Link anatomy.

When no match is found​

An unmatched first open is not an error: the app opens normally, and the request returns matched: false. Typical causes:

  • The link had deferred delivery turned off.
  • The match window expired before the first open.
  • Every token leg failed (clipboard denied, referrer stripped) and the device attributes didn't agree strongly enough, or the network was too shared to judge.

The attempt is still recorded, so the funnel in analytics shows where installs lost their link context. Drop-offs are attributed to your organization when the SDK sends its key with the match request, which is why the SDKs do by default.

Testing the flow​

You can exercise the whole chain on a device: click a link, install, and watch the match land. The Flutter SDK's testing guide walks through it, including the expected paste permission prompts: Test your integration.