10 Deep Linking Mistakes That Break Install Attribution

TL;DR: These are the ten setup mistakes we see break install attribution. Check three first: the Android destination is not the Play Store URL, the app uses an API key instead of an SDK key, or the attribution check runs late. Of 309 matched installs in our October 2026 test, 303 went to the correct link (98.1 percent); see Attribution Accuracy.

How Install Attribution Fits Together

A tap and an install happen on two different screens, minutes or hours apart. WarpLink tries four matching methods in order and stops at the first match: the Play Install Referrer on Android, a device ID repeat check on iOS, then a probabilistic match on the request IP, language, and timezone, and raw device signals. A referrer match is deterministic and scores 1.0. The rest carry a confidence score you can route on. The full cascade is in Install Attribution.

Every mistake below breaks one link in that chain. Each one follows the same pattern: the symptom, the check, and the fix. If the problem is that the link does not open the app at all, that is a different list: see 15 Reasons Universal Links Are Not Opening and 12 Reasons Android App Links autoVerify Fails.

1. Android Visitors Do Not Land on the Play Store URL

Symptom: Android installs show as unmatched or match with a lower score than they should.

Check: The Play Install Referrer is attached only when WarpLink sends the visitor to the Play Store. Open the link on a device without the app and watch where it goes. The dashboard also flags this on the link.

Fix: Make the https://play.google.com URL the destination for visitors without your app, and set it as your Android store URL on the app. That keeps Android attribution deterministic.

2. A Custom Scheme Is the Only Destination

Symptom: Visitors without the app land nowhere useful, and no install follows.

Check: A URL such as myapp://promo is an in-app route, not a web address. A market://details?id=... address counts as a custom scheme too.

Fix: Set a fallback URL and your app's store URL. WarpLink sends visitors without the app to the fallback URL, then to the store URL, on both platforms, and routes a market:// address to your fallback or your Android store URL rather than to the scheme itself.

3. You Expect Universal Links to Carry Context Through an Install

Symptom: The link opens the app when it is installed and the user lands on a generic home screen after a fresh install.

Check: Universal Links and App Links open an app that is already on the device. The App Store passes nothing through an install.

Fix: Add the deferred deep link check at first open, and route on the result. Platform guides: iOS, Android, React Native, Flutter. The SDKs run the check for you after configure().

4. The SDK Is Configured With an API Key

Symptom: Links open the app, the dashboard shows clicks, and installs never appear.

Check: An API key and an SDK key share the same wl_live_ shape, so a swapped key does not fail loudly: SDK validation still succeeds and links still open, but the attribution call is rejected every time. Install attribution is never one of an API key's scopes.

Fix: Create a dedicated SDK key under Keys > SDK keys in the dashboard and use it only for mobile builds.

5. The Attribution Check Runs Late or Never

Symptom: Installs match in some sessions and not in others, mostly after a long onboarding.

Check: Confirm WarpLink.configure() runs at launch, in Application.onCreate() on Android or at app start on iOS, and that automatic deferred checks are not switched off without a manual call.

Fix: Configure at launch so the check fires on first open, before sign-in or onboarding moves the user on. If you turn the automatic check off, call checkDeferredDeepLink yourself at the same point.

6. Attribution Waits on a Tracking Prompt

Symptom: Attribution only runs after the user taps through a permission prompt.

Check: Look for an App Tracking Transparency request wrapped around the attribution call.

Fix: Remove the dependency. WarpLink matching uses no IDFA and no GAID, and the IDFV used for the repeat check is exempt from the prompt. Probabilistic keys are stored as one-way hashes. Details are on the Install Attribution page.

7. The Test Reuses an Old Tap or Switches Networks

Symptom: A clean test install returns no match, or a different link than you tapped.

Check: On iOS, the scored match uses the request IP, so a tap on one network and an install on another gives it less to work with. Several old taps from the same office network can also share a match bucket.

Fix: Tap a fresh link before each test install, keep the tap and the install on the same network, and open the app right away. Our own test used the same method, and 30 of 30 same-network iOS installs matched. The method and device checklist are on Attribution Accuracy.

8. The App Ignores the Match Result

Symptom: Users land on the wrong screen after a low-score match, or on a generic screen after a strong one.

Check: Read matchType, matchConfidence, and matchGuaranteed on the result. A deterministic match is always 1.0. A probabilistic match scores between 0.20 and 0.85, based on time since the tap, the match variant, and whether the IP was shared.

Fix: Route on the score. Go straight to the content near the top of the range, ask for confirmation in the middle, and show generic onboarding at the bottom. Keep sign-in on your own authentication.

9. Campaign Parameters Are Lost on the Way

Symptom: Installs match, and the campaign column in your reports is empty.

Check: Follow the redirect chain from the tap to the store or the app. A wrapper that rewrites the URL can drop utm_ values.

Fix: Set utm_source, utm_medium, and utm_campaign on the link itself. They apply on redirect, and an explicit injected parameter for the same key wins. See Pass UTM Parameters Through Deep Links.

10. The SDK Does Not Say Which App Is Asking

Symptom: In an organization with more than one app, attribution is recorded as ambiguous or refused with a key error.

Check: SDKs before 1.1.0 send no app identity. A key tied to one app acts only as that app, and a request for another app returns 403 KEY_APP_MISMATCH.

Fix: Update to the current SDKs (all four are on 1.1.1), which send the bundle ID or package name, and tie each SDK key to its own app when you want a hard boundary.

How WarpLink Handles the Setup

Register your app and WarpLink generates and serves the apple-app-site-association and assetlinks.json files for it, at the app's own host, {handle}.aplnk.to. Every app host has its own pair, and verified custom domains get one too. Open https://{host}/test to confirm the host is live before you test a tap. On top of that, the iOS, Android, React Native, and Flutter SDKs (MIT, zero third-party dependencies) run the deferred check at first open and return the matched link, the match type, and the confidence score.

Attribution works for installs that follow a tap on a WarpLink link, in any channel: social, ads, creators, email, QR codes, and referrals. The Free plan includes deep links, deferred deep links, install attribution, and analytics, and links on aplnk.to keep redirecting past a plan's click limit. See install attribution, deferred deep linking, and pricing.

Frequently Asked Questions

Why are my app installs not attributed to my deep links? Check the destination and the SDK first. Android needs the Play Store URL as the destination so the Play Install Referrer travels with the visit, the app needs an SDK key rather than an API key, and the attribution check has to run on first open. Check these three first.

Do Universal Links and App Links carry data through an app install? No. They open an app that is already installed. Carrying a link's context through a first install takes a deferred deep link check at first open, which WarpLink runs through the SDK and uses to attribute the install to the link.

Does install attribution need the App Tracking Transparency prompt? Not with WarpLink. Matching uses no IDFA or GAID, and the IDFV used to recognize a repeat check is exempt from App Tracking Transparency, so the prompt does not gate attribution.

How do I test install attribution correctly? Tap a fresh link, install on the same network as the tap, and open the app right away. On Android, send the visitor through the Play Store URL. Repeat for every platform before you ship, and compare the result with the published test method.

What is the best way to avoid attribution mistakes? WarpLink handles the setup in one SDK: the Play Install Referrer on Android, scored matching on iOS, and a match result with a confidence score you can route on. Register the app, configure the SDK with an SDK key, and set the store URLs on the app.

Sources

• WarpLink, Install Attribution: the match cascade, the Play Install Referrer rule, custom scheme routing, confidence scores, and privacy.
• WarpLink, Attribution Accuracy: the October 2026 results and the device test checklist.
• Google, Install Referrer: the Play Install Referrer API that carries the referrer through a Play Store install.
• Apple Developer Documentation, Supporting associated domains: how Universal Links associate an app with a domain.

Related Guides

• Attribution without an MMP: Install Attribution Without an MMP.
• Track installs from a link: Track App Installs From a Link.
• Without IDFA: Install Attribution Without IDFA.
• The options compared: 6 Install Attribution Options for Small Apps.
• When the link will not open the app: 15 Reasons Universal Links Are Not Opening and 12 Reasons Android App Links autoVerify Fails. The file checklist is Apple App Site Association Not Working.
• Platform pages: analytics and SDKs.

Create a free WarpLink account and run the ten checks against your own links.