Skip to main content
Deferred mobile attribution is in Public Beta. The exact Android path requires a Google Play installation, and the exact iOS path requires a real App Store or TestFlight flow with a user-initiated paste.
A deferred deep link preserves the original link context when the app is not installed at click time. Biqli uses an opaque, expiring handoff instead of putting the route, referral code, or safe metadata into a store URL.

​
Android exact deferred flow

  1. An Android visitor opens a mobile-enabled Biqli short link without the app installed.
  2. Biqli records the click and creates an opaque handoff snapshot.
  3. Biqli redirects to the configured Google Play URL with the opaque token nested in the Play Install Referrer value.
  4. Google Play installs the app and exposes the referrer to the installed package.
  5. On first launch, the Android SDK reads the referrer once, extracts only biqli_token, closes the connection, and calls the resolver.
  6. A valid handoff returns exact_install_referrer with exact confidence.
The SDK never persists or sends the complete Google Play referrer string. It may temporarily persist the extracted opaque token in Android Keystore-backed encrypted storage until the resolver accepts it or reaches a terminal result. An emulator or sideloaded package cannot prove this path because only Google Play supplies a real Install Referrer. Use an internal test track for the release test.

​
iOS exact deferred flow

iOS does not provide a general App Store Install Referrer API. Biqli therefore uses a visible, user-initiated handoff:
  1. An iOS visitor opens a mobile-enabled link without the app installed.
  2. If Deep View is enabled on the domain and the link, Biqli records the click, creates an opaque handoff snapshot, and displays the Deep View.
  3. The visitor selects Continue. The page attempts to copy an opaque HTTPS handoff URL and then opens the App Store or TestFlight.
  4. After installation, the app displays the Biqli paste control.
  5. The visitor explicitly selects Paste. The iOS SDK validates the supplied URL and resolves the handoff.
  6. A valid handoff returns exact_handoff with exact confidence.
The iOS SDK never polls or silently reads UIPasteboard. On iOS 16 and later, use BiqliPasteButton or BiqliPasteControl, which is based on Apple’s user-operated UIPasteControl. On iOS 15, provide a clearly labeled user action and pass the resulting URL to Biqli.resolvePastedURL(_:). If either Deep View switch is disabled, Biqli redirects to the iOS fallback without creating this exact user-paste path.

​
Optional iOS probabilistic matching

Probabilistic matching is off by default and never replaces an exact match. It runs only when all of these conditions hold:
  • the request is an iOS first open;
  • the Mobile App permits probabilistic fallback;
  • the SDK configuration enables it;
  • the application passes consentGranted: true;
  • the request names a verified, HTTPS-enabled domain attached to the app; and
  • exactly one eligible recent, unused click candidate exists within the configured window, which cannot exceed 60 minutes.
An ambiguous or missing candidate returns none. A probabilistic result is labeled matchedBy: probabilistic and confidence: probabilistic; never represent it as exact evidence.

​
Handoff lifecycle

  • The handoff expires according to the Mobile App’s exact handoff lifetime.
  • A successful exact handoff is bound to the resolving app installation.
  • A replay by the same installation returns the same accepted result without creating another attribution.
  • A different installation cannot claim an already accepted handoff.
  • Disabling a link or Mobile App prevents new eligible resolutions. Deleting the Mobile App revokes its keys and removes its generated association entries.
  • Rotating the mobile publishable key activates a new key while the previous key remains usable only for the configured overlap period. Update shipped builds before the overlap ends.

​
Snapshot behavior

The click captures the route, referral code, safe metadata, and allowed dynamic values at click time. Editing the link later does not rewrite an already-created handoff. A new click receives the new configuration. An installed app opening the short URL directly resolves the current mobile payload for that visit. This difference is intentional: a deferred handoff preserves what the person clicked, while a new direct visit uses the link as it exists then. Read Attribution and lifecycle for first-open immutability, retries, cached results, and reinstall behavior.