Skip to main content

How Deferred Deep Linking Works

Standard deep links only work when the app is already installed. But what happens when a user clicks a link and does not have the app? They are sent to the app store, install the app, open it — and land on the home screen with no context about the link they originally clicked.

Deferred deep linking solves this by preserving the link context across the app installation process.

The Problem​

Without deferred deep linking, the user journey breaks:

  1. User clicks a link to /product/123 in your app
  2. App is not installed, so the user is redirected to the app store
  3. User installs and opens the app
  4. App opens to the home screen — the original destination is lost

The user must now manually search for the product they wanted. Conversion drops, onboarding suffers, and attribution data is lost.

The Flow​

OpenLynk bridges the gap between link click and app install using pending link storage and device matching.

Matching Strategies​

When the SDK calls the restore API, OpenLynk attempts to match the device to a stored pending link using multiple strategies, in order of reliability:

1. Email Match (Most Reliable)​

If the user's email is known at both link-click time and app-install time, OpenLynk matches on email. This is the most accurate method because email addresses are unique identifiers.

When this works: The user was logged into your web experience when they clicked the link, and they log in with the same email after installing the app. Your userEmailProvider in the SDK config returns their email.

2. Device Fingerprint Match​

The SDK generates a device fingerprint based on device characteristics. If the fingerprint at install time matches the fingerprint stored during the link click, the pending link is restored.

When this works: The user clicks the link and installs the app on the same device without significant system changes between the two events.

3. IP + User-Agent Triangulation (Fallback)​

When neither email nor fingerprint produce a match, OpenLynk falls back to matching based on the combination of hashed IP address and user-agent string. This is less precise but catches cases where fingerprinting is not available.

When this works: The user clicks the link and installs the app from the same network and browser within a reasonable time window.

Each pending link goes through a defined lifecycle:

StateDescription
CreatedA user clicked a deep link and was redirected to the app store. The pending link record is created.
PendingThe link is waiting for the user to install the app and for the SDK to call the restore API.
RestoredThe SDK successfully matched and retrieved the pending link. The onRestoredLinks callback fires.
ExpiredThe pending link was not restored within 30 days and is automatically removed.
info

Pending links expire after 30 days. If a user installs the app more than 30 days after clicking the link, the pending link will not be found.

Full Parameter Preservation​

All custom metadata attached to the original link is preserved through the deferred deep linking flow. When onRestoredLinks fires, each RestoredLink contains:

  • The original destination path and full destination URL
  • All custom metadata (campaign, referrer, discount codes, etc.)
  • The original link ID and URL
  • UTM parameters (if set)

No data is lost between the link click and the app install. Your app receives the same metadata it would have received if the user had the app installed when they clicked the link.

Why This Matters​

Deferred deep linking is critical for two scenarios:

Seamless Onboarding​

When a user clicks a shared link and installs your app, they expect to see the content they were interested in. Deferred deep linking delivers them directly to that content on first launch, reducing friction and improving the first-time user experience.

Conversion Attribution​

Marketing teams need to know which campaigns, channels, and referrers drive app installs. Because deferred deep linking preserves UTM parameters and custom metadata through the install flow, you can attribute each install to the exact link and campaign that caused it.

What's Next?​