Deferred Deep Links

Deferred deep links solve the "click before install" problem. When a user clicks a link but doesn't have the app installed, deferred deep linking preserves the link context through the install flow so the user lands on the right content after installing.

The Problem

Without deferred deep links:

1. User clicks a product share link
2. App isn't installed — user goes to the App Store
3. User installs and opens the app
4. User lands on the home screen with no context

The link context is lost during the install step.

The Solution

With WarpLink deferred deep links:

1. Click — User taps a WarpLink URL
2. Signal capture — WarpLink's redirect page collects browser signals (IP, User-Agent, Accept-Language, screen size, timezone) via a brief JavaScript interstitial
3. Store redirect — User goes to the App Store or Play Store
4. Install — User installs the app
5. First launch detection — The SDK detects first launch (UserDefaults on iOS, SharedPreferences on Android)
6. Signal collection — The SDK collects device signals (screen size, timezone, languages, platform-specific IDs)
7. Attribution request — The SDK sends signals to the WarpLink attribution API
8. Match — The server matches install-time signals against click-time signals and returns the original link data

The user now opens the app and lands directly on the shared product.

How Matching Works

WarpLink uses a two-tier matching system:

Tier 1: Deterministic

Exact-match signals that guarantee accuracy:

• iOS (IDFV) — Identifier for Vendor, used for re-engagement when the app was previously installed
• Android (Play Install Referrer) — The Play Store passes the click referrer through the install process

Deterministic matches always have confidence 1.0.

Tier 2: Probabilistic (Enriched Fingerprint)

When deterministic signals aren't available (first install on iOS, sideloaded Android apps), the server compares browser-side and device-side signals to compute a fingerprint match:

Confidence decreases over time because IP addresses and network conditions change.

Match Window

The match window controls how far back the server looks for matching clicks. Default is 72 hours, configurable per-SDK:

• Shorter windows (24-48h) reduce false positives
• Longer windows (72h+) catch users who take time to install

KV Storage

When a click is identified as a potential deferred deep link (user redirected to app store), the Worker stores a deferred payload in Cloudflare KV:

• Key: deferred:{fingerprint}
• Value: Link data + click signals
• TTL: Match window duration

The attribution API reads this payload when the SDK requests a match.

Caching

The SDK performs the attribution check exactly once per install:

• First launch: collects signals, sends attribution request, caches result
• Subsequent launches: returns cached result (no network request)
• The check is idempotent — even if called multiple times, only one network request is made