Deferred Deep Linking Without Fingerprinting

Device fingerprinting has been the default technique for deferred deep linking for years. It collects device attributes (IP address, user agent, screen resolution, timezone) at click time, then matches those attributes against the device that opens the app. It works, but it is probabilistic, privacy-invasive, and increasingly restricted by platform policies. Apple's App Tracking Transparency and Google's Privacy Sandbox are both designed to limit exactly this kind of cross-context device identification.

The good news: fingerprinting is not the only option. Deterministic methods can achieve higher accuracy with a better privacy profile. This guide covers every fingerprinting-free approach to deferred deep linking and when each one works best. For the full comparison, see fingerprinting vs. deterministic matching. For privacy regulations that affect deferred linking, see deferred linking privacy considerations.

Why Move Away from Fingerprinting?

Three forces are pushing the industry away from fingerprint-based deferred linking:

Regulatory pressure. Under GDPR, device fingerprints constitute personal data (Recital 30). Processing them requires a lawful basis. Under the ePrivacy Directive, accessing device attributes for fingerprinting may require consent. CCPA/CPRA classifies IP addresses and device identifiers as personal information.

Platform restrictions. Apple explicitly discourages fingerprinting in its App Store Review Guidelines and has rejected apps that use it to circumvent ATT. Google's Privacy Sandbox aims to eliminate cross-app tracking signals over time.

Declining accuracy. As browsers and operating systems reduce the information available for fingerprinting (normalized user agents, Private Relay, VPN adoption), match rates drop. A technique that was 70% accurate five years ago may be 50% accurate today.

Method 1: Google Play Install Referrer (Android)

The Play Install Referrer API is the gold standard for Android deferred deep linking. When a user clicks a link that leads to the Play Store, the referrer string is passed through to the installed app.

How It Works

1. Your web link includes a referrer parameter in the Play Store URL:

   https://play.google.com/store/apps/details?id=com.example.app&referrer=path%3D%2Fproducts%2F123%26campaign%3Dsummer
   

   Implementation

   // Add dependency
   // implementation 'com.android.installreferrer:installreferrer:2.2'
   
   class DeferredLinkHandler(private val context: Context) {
   
       fun checkInstallReferrer(callback: (String?) -> Unit) {
           val client = InstallReferrerClient.newBuilder(context).build()
   
           client.startConnection(object : InstallReferrerStateListener {
               override fun onInstallReferrerSetupFinished(responseCode: Int) {
                   if (responseCode == InstallReferrerClient.InstallReferrerResponse.OK) {
                       val response = client.installReferrer
                       val referrer = response.installReferrer
                       // Parse the referrer string
                       val params = Uri.parse("?$referrer")
                       val path = params.getQueryParameter("path")
                       callback(path)
                   } else {
                       callback(null)
                   }
                   client.endConnection()
               }
   
               override fun onInstallReferrerServiceDisconnected() {
                   callback(null)
               }
           })
       }
   }
   

   Accuracy and Limitations

   • Match rate: ~99%. Fails only for sideloaded installs or enterprise distribution.
   • Privacy: No personal data collected. The referrer string is controlled by the developer.
   • Limitation: Android only. No iOS equivalent.
   • Limitation: Requires the install to go through the Play Store. Direct APK installs, alternative stores (Samsung Galaxy Store, Amazon Appstore), or managed distribution do not pass referrers.

   Method 2: Clipboard-Based Matching

   Copy a token to the clipboard when the user clicks the link. Read it back when the app opens. See clipboard-based deferred linking for the full implementation.

   Quick Summary

   // Web side: copy token on click
   document.getElementById('install-btn').addEventListener('click', async () => {
     await navigator.clipboard.writeText('dl_products_123_campaign_summer');
     window.location.href = storeUrl;
   });
   

   // Android side: read clipboard on first open
   val clipboard = getSystemService(CLIPBOARD_SERVICE) as ClipboardManager
   val text = clipboard.primaryClip?.getItemAt(0)?.text?.toString()
   if (text?.startsWith("dl_") == true) {
       routeToContent(text)
       clipboard.clearPrimaryClip()
   }
   

   // iOS side: read clipboard (triggers paste permission on iOS 16+)
   if let text = UIPasteboard.general.string, text.hasPrefix("dl_") {
       routeToContent(text)
       UIPasteboard.general.string = ""
   }
   

   Accuracy and Limitations

   • Match rate: 60-80%. Drops when users copy something else before installing.
   • Privacy: No device attributes collected. The token is developer-controlled.
   • Limitation: iOS 16+ requires paste permission. See iOS paste permission and deferred links.
   • Limitation: Clipboard can be overwritten between click and install.

   Method 3: App Clip to Full App Handoff (iOS)

   App Clips are lightweight versions of iOS apps that launch instantly from links, QR codes, or NFC tags. When a user transitions from an App Clip to the full app, context can be passed deterministically via the shared app group container.

   How It Works

   1. User taps a link or scans a QR code.
   2. App Clip launches with the full URL context.
   3. App Clip saves the deep link context to a shared container.
   4. User installs the full app from the App Clip card.
   5. Full app reads the context from the shared container.

   // In the App Clip: save context
   let defaults = UserDefaults(suiteName: "group.com.example.app")
   defaults?.set("/products/123", forKey: "deferredDeepLink")
   
   // In the full app: read context
   let defaults = UserDefaults(suiteName: "group.com.example.app")
   if let path = defaults?.string(forKey: "deferredDeepLink") {
       routeToContent(path)
       defaults?.removeObject(forKey: "deferredDeepLink")
   }
   

   Accuracy and Limitations

   • Match rate: ~100% when the App Clip-to-app flow is used.
   • Privacy: No fingerprinting. Context passes through Apple's shared container.
   • Limitation: Requires building and maintaining an App Clip.
   • Limitation: Only works when the user's entry point is the App Clip (not a direct link to the App Store).

   Method 4: UTM Parameters in Store URLs

   Pass campaign-level context (not user-level) through the app store URL. This does not achieve per-user deferred deep linking, but it preserves attribution context.

   Android

   https://play.google.com/store/apps/details?id=com.example.app
     &referrer=utm_source%3Demail%26utm_campaign%3Dsummer_sale
   

   The Install Referrer API returns this string. Parse the UTM parameters to determine which campaign drove the install.

   iOS

   Apple's ad attribution APIs provide campaign-level data, but not deep link context. For iOS, UTM parameters in the store URL are not passed through to the app.

   Alternative: use custom product pages on the App Store. Create different product pages for different campaigns, each with a unique URL. Track which product page drove the install via App Analytics.

   Method 5: QR Code / NFC with Embedded Context

   For physical-to-digital flows (print media, retail, events), embed the deep link context directly in the QR code or NFC payload:

   QR code encodes: https://yourapp.com/products/123?ref=flyer_summer
     → User scans QR code
     → Browser opens the URL
     → If app is installed: App Link opens the app with the full URL
     → If not installed: Landing page copies token to clipboard + redirects to store
   

   The QR code itself carries the context. No fingerprinting is needed for the QR-to-app flow. Deferred linking (post-install) still needs clipboard or Install Referrer, but the initial context capture is deterministic.

   Method 6: Server-Side Session Matching (First-Party Only)

   If you control both the website and the app, you can use first-party session data:

   1. User visits your website. Your server creates a session and stores the deep link context.
   2. User installs your app.
   3. On first app open, the app sends a first-party identifier (e.g., a device token generated by your SDK) to your server.
   4. If the user logs into the same account on both web and app, the server matches the sessions.

   This is not fingerprinting because it relies on authenticated identity (login), not device attributes. It only works when the user has an account and logs in on both platforms.

   Web: user logged in as [email protected], clicked /products/123
     → Server stores: { email: "[email protected]", deferredPath: "/products/123" }
   
   App: user logs in as [email protected] on first open
     → Server returns: { deferredPath: "/products/123" }
     → App routes to product page
   

   Accuracy and Limitations

   • Match rate: 100% for users who log in on both platforms.
   • Privacy: Uses authenticated identity, not device fingerprinting.
   • Limitation: Only works for users with accounts who log in before the deferred link is needed.

   Combining Methods

   The most robust fingerprinting-free approach combines multiple methods:

   Android:
     1. Check Play Install Referrer → near-100% accuracy
     2. Check clipboard → fallback for non-Play-Store installs
     3. Check authenticated session → fallback for logged-in users
   
   iOS:
     1. Check App Clip shared container → if App Clip was used
     2. Check clipboard (with paste permission) → primary method
     3. Check authenticated session → fallback for logged-in users
     4. No match → proceed to default onboarding
   

   The key insight: Android is largely solved by the Install Referrer API. iOS is the platform where fingerprinting-free deferred linking remains challenging, and clipboard matching (with its paste permission hurdle) is currently the best deterministic option.

   Tolinku's Approach

   Tolinku's deferred deep linking prioritizes deterministic methods. The SDK uses the Play Install Referrer on Android and clipboard matching on iOS as primary strategies, with configurable fallback behavior. No device fingerprinting is required for basic deferred link resolution.

   Configure your deferred deep linking in the Tolinku dashboard. For accuracy expectations across methods, see deferred linking accuracy. For the complete deferred linking overview, see how deferred deep linking works.