Deferred deep links connect a pre-install click to a post-install app open. But how long should that connection last? If a user clicks a link today and installs the app three weeks later, should the deferred link still resolve? What about three months later?
The answer depends on your matching method, your use case, and the tradeoff between catching legitimate late installs and avoiding stale or incorrect matches. This guide covers how to set appropriate expiration windows for deferred deep links. For the matching methods and their accuracy, see deferred linking accuracy. For the technical foundations, see how deferred deep linking works.
Why Expiration Matters
Accuracy Degrades Over Time
The longer the gap between click and install, the less reliable the match:
- Fingerprint matching: IP addresses change within hours on mobile networks. User agents change with OS updates. A fingerprint match after 48 hours is significantly less reliable than one within 1 hour.
- Clipboard matching: The clipboard is overwritten whenever the user copies anything. A token from a click 24 hours ago is almost certainly gone.
- Install Referrer (Android): This is the exception. The referrer persists through the Play Store install regardless of time, so a match after 30 days is just as accurate as one after 30 seconds.
Stale Context Creates Bad UX
A user who clicks a promotional link for a summer sale and installs the app in October should not land on an expired promotion. Stale deferred links lead to:
- Dead product pages (item no longer available)
- Expired offers ("This coupon has expired")
- Irrelevant content (seasonal campaigns, limited-time events)
- Confusion ("Why is this app showing me something about summer?")
Data Retention and Privacy
Keeping click data indefinitely for matching purposes raises privacy concerns. GDPR's data minimization principle (Article 5(1)(c)) requires that personal data be "adequate, relevant and limited to what is necessary." Storing IP addresses and device fingerprints for months to match potential future installs is hard to justify under this principle.
Expiration Windows by Matching Method
Fingerprint-Based Matching
Recommended expiration: 1-24 hours, depending on your tolerance for false positives.
| Window | Match Rate | False Positive Risk |
|---|---|---|
| 1 hour | Lower (catches fewer installs) | Very low |
| 6 hours | Moderate | Low |
| 24 hours | Higher (catches more installs) | Moderate |
| 48+ hours | Marginal improvement | High |
After 24 hours, the probability of a correct fingerprint match drops significantly. The IP address is likely different, and the marginal installs you catch are offset by the increased false positive rate.
For ad campaigns where false attribution wastes ad spend, use shorter windows (1-6 hours). For organic sharing where a false match is just a UX inconvenience, 24 hours is reasonable.
Clipboard-Based Matching
Recommended expiration: 1-4 hours (functional), but the clipboard itself is the real constraint.
The clipboard token survives until the user copies something else. In practice:
- Within 15 minutes: ~80% of tokens still present
- Within 1 hour: ~50% of tokens still present
- Within 4 hours: ~20% of tokens still present
- After 24 hours: effectively 0%
Android 13+ automatically clears the clipboard after approximately one hour. Setting a longer expiration than the clipboard's natural lifetime provides no benefit.
Google Play Install Referrer
Recommended expiration: 7-90 days, depending on use case.
The Install Referrer persists through the Play Store installation process regardless of time. There is no accuracy degradation. The only consideration is whether the deep link destination is still valid.
For evergreen content (product pages, user profiles): 30-90 days is appropriate. For time-sensitive content (promotions, events): match the expiration to the content's validity period.
Combined Methods
When using multiple matching methods with different accuracy profiles, apply different expiration windows to each:
Match priority:
1. Install Referrer (Android): 30-day window
2. Clipboard token: 4-hour window
3. Fingerprint match: 24-hour window
4. No match: default onboarding
The higher-confidence method gets a longer window. The lower-confidence method gets a shorter window to limit false positives.
Expiration by Use Case
Referral Programs
Recommended window: 7-30 days
Referral links are intentionally shared. The sender expects the recipient to install and get credit. Recipients may not install immediately; they might save the link for later. A 7-30 day window accommodates this behavior.
The referral code itself (embedded in the Install Referrer or link URL) is deterministic, so the accuracy concern is about content relevance, not match quality. If your referral program is always active, a longer window is fine.
Ad Campaigns
Recommended window: 1-7 days
Ad-driven installs typically happen quickly. A user who sees an ad and installs 30 days later was probably influenced by something else. Short attribution windows give more accurate campaign performance data.
Most ad networks use standardized windows:
- Google Ads: 30-day click-through, 1-day view-through
- Meta Ads: 7-day click-through, 1-day view-through
- Apple Search Ads: 30-day attribution window
Align your deferred link expiration with your ad network's attribution window for consistent reporting.
Content Sharing
Recommended window: 24-72 hours
Shared content links (articles, products, playlists) are usually acted on within a day or two. After 72 hours, the share context has likely faded from the recipient's memory.
Exception: if the shared content is evergreen (a recipe, a reference article), a longer window (7 days) is reasonable because the content remains relevant.
E-Commerce Promotions
Recommended window: match the promotion's duration
If you send a link for a "48-hour flash sale," set the deferred link expiration to 48 hours. There is no value in routing a user to an expired sale page.
Promotion: Summer Sale (June 1-15)
Deferred link expiration: June 15 23:59:59
After expiration: route to general shop page instead of sale page
Onboarding / Invitation Links
Recommended window: 14-30 days
Invitation links ("Join our team on [App]") may not be acted on immediately. The recipient might wait until they need the app. A 14-30 day window is appropriate, and the invitation context (team name, inviter) remains relevant.
Implementing Expiration
Server-Side Expiration
Store the click timestamp with the deferred link data. When the app requests a match, check the timestamp:
// Server-side match endpoint
function matchDeferredLink(deviceAttributes, matchingMethod) {
const click = findMatchingClick(deviceAttributes, matchingMethod);
if (!click) return null;
const expirationMs = getExpirationForMethod(matchingMethod);
const age = Date.now() - click.timestamp;
if (age > expirationMs) {
// Click is too old; don't match
return null;
}
return click.deferredLinkData;
}
function getExpirationForMethod(method) {
switch (method) {
case 'install_referrer': return 30 * 24 * 60 * 60 * 1000; // 30 days
case 'clipboard': return 4 * 60 * 60 * 1000; // 4 hours
case 'fingerprint': return 24 * 60 * 60 * 1000; // 24 hours
default: return 24 * 60 * 60 * 1000;
}
}
Client-Side Token Expiration
For clipboard tokens, include a timestamp in the token so the app can verify freshness:
// Web: include timestamp in token
const token = JSON.stringify({
path: '/products/123',
campaign: 'summer',
ts: Date.now(),
exp: Date.now() + (4 * 60 * 60 * 1000) // Expires in 4 hours
});
await navigator.clipboard.writeText(token);
// App: check token expiration
fun parseDeferredToken(text: String): DeferredLink? {
val json = JSONObject(text)
val expiration = json.optLong("exp", 0)
if (expiration > 0 && System.currentTimeMillis() > expiration) {
return null // Token expired
}
return DeferredLink(
path = json.getString("path"),
campaign = json.optString("campaign")
)
}
Graceful Fallbacks for Expired Links
When a deferred link has expired, do not show an error. Route the user to a reasonable fallback:
fun handleDeferredLink(result: DeferredLinkResult) {
when (result) {
is DeferredLinkResult.Active -> navigateTo(result.path)
is DeferredLinkResult.Expired -> {
// Route to a related but current page
val fallback = getFallbackForExpiredLink(result.originalPath)
navigateTo(fallback)
}
is DeferredLinkResult.NotFound -> navigateToHome()
}
}
fun getFallbackForExpiredLink(path: String): String {
return when {
path.startsWith("/products/") -> "/shop" // Expired product → shop page
path.startsWith("/promo/") -> "/deals" // Expired promo → current deals
path.startsWith("/invite/") -> "/signup" // Expired invite → sign-up page
else -> "/home"
}
}
Data Cleanup
Expired click data should be purged regularly to comply with data minimization requirements and reduce storage costs:
- Run a daily cleanup job that deletes click records older than your maximum expiration window.
- For fingerprint data (which contains IP addresses and device attributes), purge aggressively (24-48 hours).
- For Install Referrer records (which contain only developer-defined strings), longer retention is acceptable if the data is not personally identifiable.
Tolinku Configuration
Tolinku's deferred deep linking supports configurable expiration windows. Set the attribution window per route or globally in the Tolinku dashboard. Expired links automatically fall back to the route's default destination.
For accuracy across different expiration windows, see deferred linking accuracy. For the full deferred linking setup, see how deferred deep linking works.
Get deep linking tips in your inbox
One email per week. No spam.
