A paid click is a promise about a destination. When someone taps an ad for a specific product, a saved basket, or a renewal offer, the next screen either honours that promise or quietly breaks it. Deep linking is the mechanism that decides which one happens — and for paid acquisition teams it is not a developer detail. It determines whether spend reaches a coherent experience, whether the resulting events mean anything, and whether a campaign read is interpretable at all.
This page is about one decision: whether your paid-ad destinations can be routed reliably today, how to prove it, and what to do when they cannot. It is an operator guide, not an implementation tutorial.
The direct answer
Mobile app deep linking for paid ads is the practice of defining, verifying, and continuously testing the destination contract between an ad click and the exact in-app or web screen that should receive it — across every device state your traffic actually contains.
There are four states worth naming before any budget decision:
App installed, link verified. The click opens the intended in-app screen.
App not installed. The click reaches the web equivalent or the store listing, depending on link type and campaign type.
App installed, association broken. The click silently falls through to the mobile website, often with no visible error.
Deferred. The user installs first, then lands on the intended screen at first open — which is possible only where the platform and your measurement stack both support it.
A deep-link programme is ready when all four states are specified, observable, and tested. It is not ready when only the first one has been checked on the engineer's own phone.
Routing is not attribution
Two distinct systems get conflated constantly, and the confusion produces bad spend decisions.
Routing is where the operating system sends the click. It is governed by link type, domain association, and OS behaviour. Attribution credit is which campaign a later event is assigned to. It is governed by your measurement SDK, attribution partner, or platform reporting. A perfectly routed click can be unattributed. A well-attributed install can land on the wrong screen.
Keep three further distinctions visible when you report:
Conversions are not incrementality. A deep link that improves the post-click experience may improve conversion recording without proving added demand. If incrementality is the question, that is a separate test design — see our note on attribution architecture for paid media.
Installed is not uninstalled. Audience data lags reality. Google states that if someone without your app installed sees an App campaign for engagement ad, it will typically appear as an app install ad with an "Install" button leading to the store (Google Ads Help).
Channel support differs. What one ad platform supports for app destinations is not a general rule. Verify per channel, in that channel's current documentation.
The link primitives, in operator terms
You do not need to write the manifest entries. You do need to know what each primitive can and cannot do, because each one fails differently.
Universal Links (iOS)
Universal links are standard HTTP or HTTPS links. When a user taps one, the system redirects the link directly to the app without routing through the default browser, and one URL serves both website and app. If the person has not installed the app, the system opens the URL in their default web browser instead (Apple Developer).
The association is server-side and verified. When a user installs the app, the system attempts to download the associated domain file and verify the domains in the app's entitlement. Each subdomain needs its own entry in the entitlement and must serve its own apple-app-site-association file (Apple Developer). That subdomain rule is a common source of campaign-level breakage: a landing domain used only by paid media is frequently the one nobody added.
One behaviour surprises marketers: when a user browses the site in Safari and taps a universal link within the same domain, the system keeps them in Safari, respecting the intent to continue in the browser. A link in a different domain opens the app (Apple Developer). Same-domain web journeys therefore behave differently from ad clicks, and a QA test run inside your own site can produce a false negative.
Android App Links
Android App Links are verified HTTPS links, available from Android 6 (API level 23) and later on devices with Google services installed. Android uses Digital Asset Links statements hosted on your website to establish the association, and once verified can route those URLs straight into the app without a disambiguation dialog. Users without the app go to the website instead (Android Developers).
From Android 15 (API level 35), Dynamic App Links allow deep-link behaviour to be refined without shipping a new app version (Android Developers). That matters for campaign operations, because it changes the lead time on a routing fix.
Android verification is directly testable, which makes it the easiest primitive to hold to evidence. On a device you can reset link state with adb shell pm set-app-links --package PACKAGENAME 0 all, invoke verification with adb shell pm verify-app-links --re-verify PACKAGENAME, and read the result with adb shell pm get-app-links PACKAGENAME. Domains that pass show a verification state of verified; anything else did not pass (Android Developers). You do not run these commands yourself — you require the output as evidence before spend increases.
Google's advertising documentation adds a consequence worth memorising: on Android 12 and newer, verification is per intent filter, and if an App Link is not verified correctly the click goes directly to the mobile website with no disambiguation dialog (Google Ads Help). The failure is silent. Nobody complains. The campaign just underperforms its own hypothesis.
Custom schemes
Custom URI schemes such as yourapp://path are easiest to set up and demand less engineering support, but are less secure: without authorisation required, they can be claimed by anyone and used to direct traffic to other apps (Google Ads Help). In Google's engagement campaigns they are allowed, but if the app is not installed a custom scheme leads to an error page with no automatic fallback to a website (Google Ads Help). Google also notes that custom schemes are compatible with App campaigns for engagement only (Google Ads Help).
Redirect-based links
This is where many teams are caught out. Google Ads states that it does not support redirects or third-party deep linking solutions that use redirects, because redirects first send users to an intermediate domain rather than the app landing page (Google Ads Help). Its engagement-campaign guidance lists App Attribution Partner links such as Branch or AppsFlyer OneLink, general redirects, and Firebase Dynamic Links as not supported for this purpose (Google Ads Help).
Do not generalise that rule outward. It describes Google Ads. Other networks maintain their own requirements, and the correct operator behaviour is to check each one rather than adopt a single mental model across the media plan.
The six-state QA matrix
This is the artefact to demand before a routing change is allowed to influence budget. Each row is a real state your traffic contains; each needs an expected destination, an observable signal, and a named owner.
Device / link state Expected destination Observable signal Primary failure mode --------------- 1 App installed, association verified Intended in-app screen In-app screen-view event carrying the campaign parameter Screen opens but parameter is dropped, so the cohort is unreadable 2 App installed, association broken or unverified Mobile web equivalent Web session on the destination path from app-eligible traffic Silent fallback; no error surfaces to anyone 3 App not installed, HTTP-based link Mobile web equivalent or store listing Web landing-page view, or store listing view Page exists but does not match the ad's promise 4 App not installed, custom scheme Error page unless a fallback is configured Absence of any landing event after the click Dead end, invisible in ad reporting 5 Deferred: install first, then open Intended screen at first open, where supported First-open event carrying the deferred destination Window expires; user lands on the generic home screen 6 Invalid, expired, or entitlement-gated URL Graceful in-app state with a recovery path Error state event with reason code Blank screen or forced logout, read as a product problem
Two rows deserve emphasis. Row 2 is the one that quietly destroys interpretability, because the user does arrive somewhere plausible. Row 5 is bounded by platform behaviour: for Google's ad group deferred deep linking, performance stats are associated with the app install rather than the deferred deep link open, and if the user does not open the app within 24 hours of clicking the ad they are taken to the generic home page (Google Ads Help).
What the platforms actually support for paid destinations
Configuration differs by campaign job, and the difference is operationally significant.
For App campaigns for installs, Google's documentation describes specifying the app-specific page in the "App URL" field under advanced options, with users who do not have the app directed to the store listing for that app; on Android, deferred behaviour requires deep links via App Links or a custom scheme plus deferred deep linking enabled in the measurement SDK — either Google Analytics for Firebase or a supported App Attribution Partner (Google Ads Help). Deferred deep linking is therefore not a switch in the ad platform alone; it is a dependency on your measurement stack, and that dependency belongs in the plan before the campaign launches.
Google also warns that if users do not have your app when they click the ad link, they will be sent to Google Play or the App Store — whether the campaign uses custom schemes, App Links, Universal Links, or no deep links at all (Google Ads Help). That is a useful corrective to the belief that deep links rescue uninstalled users on their own.
Do not assume a symmetric iOS post-install handoff. Where the documentation for a given platform and campaign type does not state it, do not plan around it.
One more configuration dependency: the association files must be publicly fetchable. Google advises checking that your robots.txt does not block its crawlers from /.well-known/assetlinks.json or /.well-known/apple-app-site-association (Google Ads Help). This is a marketing-owned file breaking an engineering-owned association — exactly the kind of boundary a route map is meant to catch.
How to test before spend increases
Three layers, in order.
Platform-native validation. Google Ads provides a Deep link validator for identifying and fixing configuration issues on Android and iOS deep links, and a Deep link impact calculator that lists web URLs worth implementing as deep links; Play Console also offers deep link patching for some ad-hoc fixes to Android App Links without a new app release (Google Ads Help). In app engagement ad setup you can select Test App URI to test a deep link on a mobile device by scanning a QR code (Google Ads Help).
Device-state validation. Run the Android pm get-app-links check described above on a clean device, and confirm the iOS association file resolves for every subdomain carrying paid traffic. Test on a device that has never had the app, then on one that has.
Event continuity validation. Click a live ad, arrive on the intended screen, and confirm the event stream shows the arrival, the campaign parameter, and the first meaningful action with the same identifier. If any of the three is missing, the route is unproven even when the screen looks correct.
Who owns what
Deep-link failures persist because ownership is ambiguous. Assign it explicitly.
Growth / UA owns the route map: which campaign, ad group, or creative concept points at which destination, and what promise each makes.
Product owns destination quality: whether the target screen can stand alone for a user arriving cold, with no prior session context.
Engineering owns the association and handling: entitlements, manifest intent filters, hosted association files, and the error states in rows 4 and 6.
Analytics owns continuity and consent: whether the campaign parameter survives the handoff, whether events fire under the consent state the user actually granted, and whether the cohort can be reconstructed later.
The route map is the shared artefact. Without it, each function optimises its own half and no one owns the join.
A hypothetical diagnostic
The numbers below are invented to demonstrate a method. They are not benchmarks, not platform data, and not results from any Sharply Labs engagement. Use your own figures.
An app team runs a re-engagement campaign to a saved-basket screen. In one week the campaign records 40,000 clicks. In-app arrivals on the basket screen tagged with the campaign parameter: 21,000. Web sessions on the equivalent web basket path from the same campaign: 12,000. Store listing views: 4,000. Unaccounted: 3,000.
The naive read is that the campaign "works" because 21,000 people reached the screen. The diagnostic read is different. The campaign targeted users believed to have the app, so 12,000 web sessions suggest either a broken association on some devices (row 2) or a stale audience (row 3). The 4,000 store views point to uninstalled users. The 3,000 unaccounted clicks are the most expensive number on the page, because they might be row 4 dead ends or consent-suppressed events — and those are two completely different fixes.
Before any bid or budget action, the team splits arrivals by OS and by device state, checks Android verification status on a sample of affected devices, and confirms whether the missing 3,000 correlate with a particular OS version, domain, or creative. Only then does a spend decision make sense. Adjusting bids first would be optimising against a measurement artefact.
When not to deploy deep links
Deep linking is not free. It adds surface area, and there are legitimate reasons to wait.
The destination screen is not viable cold. If the target requires prior context, a session, or an entitlement the arriving user does not have, routing there creates a worse experience than the home screen.
Association cannot be verified on the domains you actually advertise on. Paid media often runs on a subdomain or a separate landing domain. If that domain is not associated, the link is decorative.
No one owns the error states. Rows 4 and 6 need a designed recovery path, not a blank screen.
The campaign type does not support the link type. Custom schemes for install campaigns are a known mismatch in Google Ads, per its documentation cited above.
Instrumentation cannot distinguish the six states. If you cannot tell a silent web fallback from an intended web destination, you cannot learn from the change, and you should fix telemetry first.
Concurrent changes are in flight. A simultaneous onboarding change, pricing test, and routing change make the resulting read uninterpretable. Post-install experience belongs to a separate discipline — see onboarding optimisation for paid UA.
The stop, repair, or scale gate
Use a single rule before any meaningful budget increase on a deep-linked campaign.
Scale when all six states have an expected destination, the verification evidence is current for every advertised domain, arrivals reconcile against clicks within a tolerance the team agreed in advance, and the intended screen produces the downstream event you will actually judge the campaign on.
Repair when routing is correct but continuity is not — the screen opens and the parameter is lost, or the event fires but the cohort cannot be reconstructed. Hold spend flat, fix instrumentation, re-read.
Stop when arrivals cannot be reconciled at all, or when a material share of clicks lands in an undefined state. Spending into an unknown destination buys data you cannot use.
This gate deliberately says nothing about cost per install or return. Routing quality is a prerequisite for a trustworthy read, not a performance guarantee. Where the underlying question is which campaign job deserves the money, that decision belongs to install versus re-engagement allocation; where it is whether to route paid demand through web or straight to the store, see web-to-app versus direct app install. Both assume the destination contract described here already holds.
Limitations and tradeoffs
Platform documentation changes, and several behaviours cited here are explicitly version-dependent — Android 12 verification scope, Android 15 dynamic links, and Google's 24-hour deferred window are all current statements that should be re-verified before a launch. Consent state limits what you can observe, which means some fraction of arrivals will remain unattributable by design rather than by fault. Verified associations reduce interception risk but add release and hosting dependencies. And a deep link improves the match between promise and destination; it does not create demand that was not there.
Teams sometimes ask whether deep linking is worth the engineering cost when installs are flowing. The honest answer is that the cost is not the link; it is the ongoing QA discipline around six states across two operating systems and every domain the media plan touches. Budget for that or do not start.
Work with Sharply Labs
If your team is about to scale user acquisition or re-engagement and cannot currently prove where paid clicks land, we can review the system with you. A focused engagement examines the route map, OS association and domain verification, store fallback behaviour, consent-safe instrumentation, event continuity from click to first meaningful action, and cohort quality by device state. You receive a prioritised QA and test plan naming what to fix, in what order, and what evidence should exist before spend increases.
We do not promise lower cost per install, lower cost per action, higher return on ad spend, or store ranking gains. What we offer is a destination contract you can defend, and campaign reads you can act on. See how we work with mobile app teams and what a growth engagement covers, or bring your current route map to the conversation.