Deep Links and Web to App Connect in 2026: Where Conversions Leak Between Site and App
Someone taps your Search ad on a phone. They already have your app installed — logged in, card saved, delivery address on file. And they land on the mobile site, where they have to type all of it again. That gap costs conversions every single day, and it is fixed with configuration, not budget: deep links in Google Ads close that gap at the operating-system level.
This is a working guide to deep links in Google Ads and the Web to App Connect mechanics: what engineering has to deliver, which link types are accepted, why third-party redirects are rejected, where measurement quietly breaks, and how to size the opportunity before you spend a sprint on it.
What Web to App Connect is, and why it is worth measuring
Web to App Connect is the set of Google Ads capabilities that routes traffic from web campaigns — Search, Shopping, Display, Performance Max — into an installed app instead of the mobile site. Google cites a benchmark of up to a 2.8× higher conversion rate versus sending that traffic to a mobile web landing page (Google data, April 2025 — treat it as a directional figure, not a promise for your vertical).
The mechanism is obvious even if you distrust the number. In the app the user already has a session, saved payment details and an address; there is no login wall and no captcha. You are not improving the offer — you are deleting three steps from the funnel. So the upside concentrates where app penetration is high and checkout is long: retail, delivery, travel, finance, subscription services.
Deep links do not acquire new users. They stop losing the users you already acquired and are now paying for a second time in the auction.
Which deep links in Google Ads are supported, and which are not
| Platform | Required | Not supported |
|---|---|---|
| Android | App Links — the industry standard, with verified domain-to-app association | Custom schemes such as myapp:// |
| iOS | Universal Links — the industry standard with an association file on your domain | Custom schemes, URL redirects |
| Both | Direct HTTPS links on your own domain | Third-party redirect solutions and intermediary links |
The redirect restriction is not arbitrary: URL redirects are not supported because of security and privacy risks, phishing and malware among them. For teams that have lived on mobile measurement partner redirect links for years, this means rework — the ad has to point at your own domain, and the app opening has to be handled at the OS level.
Size it before you build it
Two tools in Google Ads will save you a week of arguing with engineering.
- Deep Link Impact Calculator. Estimates the potential uplift per URL: which pages receive paid traffic from users who already have the app, and how many conversions are recoverable. That is your sprint justification, expressed in numbers rather than conviction.
- Deep Link Validator. Confirms that a link actually opens the intended app screen. Non-negotiable after implementation: the distance between “engineering says it is done” and “the OS actually opens the app” is wider than anyone expects.
Both live in the App advertising hub under the Google Ads tools menu. The sequence is: size the opportunity → hand engineering a prioritised URL list → validate → switch on.
The engineering requirements
Android
- Intent filters in the app manifest with
android:autoVerify="true". - A Digital Asset Links JSON file hosted on your domain over HTTPS.
- From Android 12 onward, verification is stricter and evaluated per intent filter — one malformed filter breaks only itself, which makes the failure annoyingly hard to spot.
iOS
- The associated domains entitlement in the app.
- An apple-app-site-association file hosted on your domain over HTTPS.
Both platforms
- Association files served over HTTPS, without redirects, with the correct content type.
- robots.txt must not block Google’s crawlers, AdsBot included. This is the same failure class that breaks landing page review — see AdsBot and landing page crawlability.
- Web content and app screen must match: a product URL opens that product, not the catalogue.
The coverage map: where most rollouts fail
The classic failure looks like this: the team deep links to the app home screen and closes the ticket. A user taps an ad for a specific product, lands on the home screen, and leaves. Technically there is a deep link; practically the conversion is gone and you paid for the click.
So the first artefact of the project is a mapping table, not a ticket that says “add deep links.”
| Web page type | App screen | Priority |
|---|---|---|
| Product or service detail page | The same item by identifier | High — this is where paid traffic concentrates |
| Category or collection | The same category with filters applied | High |
| Cart / checkout | Cart with contents preserved | High |
| On-site search results | In-app search with the same query | Medium |
| Promotion landing page | Promo screen or promo category | Medium |
| Articles, help, blog | Usually leave on web | Low |
The rule: a deep link is justified where the app experience is genuinely better than the web one. If the matching screen does not exist in the app, keeping the web page is more honest than dumping the user on the home screen.
Five places the experience breaks
- Login flow. If the app requires authentication, the user must land on the screen they clicked for after signing in, not on the home screen. This is the most common bug and the most expensive one: the user is in the app, just not where they wanted to be.
- Stale inventory. The product exists on the site but not in the app — the user gets an empty state or an error.
- Price and promo mismatch. A promotion runs on the web and not in the app: the user arrives expecting one price and sees another.
- Locale and region. The web page is region-specific; the app opens in the default locale.
- First launch after install. Deferred deep linking has to carry the user to the intended screen after installation, otherwise you lose the journey exactly when it is most expensive.
Measurement: where the conversion lands
The painful part of the rollout is not the link; it is the accounting. Three questions to close before launch.
1. Do in-app conversions credit the web campaign?
If a user leaves a Search campaign for the app and buys there, that purchase has to return to the same account and the same campaign. Otherwise the reporting turns perverse: the Search campaign loses conversions, app share grows, and the team optimises budget in precisely the wrong direction.
2. Is anything double-counted?
The classic: the same event arrives through web tagging and through the app SDK. Reported CPA looks great, the bank balance does not. The verification routine is in duplicate conversions in Google Ads.
3. Have you accounted for lag?
Moving into the app often lengthens the journey: the user opens it, puts the phone down, comes back in the evening. Judging the test a day after launch means judging half the data. How to read the window properly is covered in conversion windows and conversion lag.
And separately: deep links do not repair signal quality. If tracking is broken to begin with, adding another platform to the journey will not improve your reporting — it will make diagnosis harder. Start from the basics in cross-domain tracking in Google Ads and GA4.
A worked sizing example
The numbers below are an illustration, not a benchmark for your category; substitute your own. The point is to show how to size this before the build, not after.
Say a retailer gets 120,000 mobile clicks a month from web campaigns. App penetration among that audience is 18%, so roughly 21,600 clicks are potentially “interceptable.” The mobile site converts that segment at 1.6%, which is about 346 conversions.
If in-app conversion for the same segment runs just 1.8× higher — not the 2.8× top-end figure — you get roughly 622 conversions, an uplift of about 276 conversions a month without buying a single extra click. Multiply by your average order value and margin and you have the number that belongs in sprint planning.
| Input | Example value | Where to find yours |
|---|---|---|
| Mobile clicks from web campaigns | 120,000 / month | Device report in Google Ads |
| Share of audience with the app | 18% | App analytics, or the impact calculator estimate |
| Mobile site conversion rate | 1.6% | Conversion report segmented by device |
| In-app conversion multiplier | 1.8× | Conservative assumption; Google’s top-end figure is 2.8× |
| Incremental conversions | ≈ 276 / month | Result |
The value of this arithmetic is prioritisation, not precision. If the uplift lands in the dozens of conversions, it is not worth an engineering sprint. If it lands in the hundreds, it outranks most of your advertising backlog.
What it looks like in reporting
After launch you need three cuts to separate real uplift from reshuffled credit.
- Device segment. Deep link effects only appear on mobile. If everything improved, you are looking at seasonality or another change.
- Page-type comparison. Compare conversion rates for URLs that already have deep links against those that do not — the closest available substitute for a proper experiment.
- Share of conversions completed in-app. It should rise while total spend holds. If app share grows but total conversions do not move, you have simply moved credit from one pocket to another.
With decent reporting infrastructure all three already exist and need no new tooling — how to assemble that single screen of truth is covered in media buyer dashboards and reporting.
Launch checklist
- Size the opportunity in the Deep Link Impact Calculator and record the expected uplift in numbers.
- Build the URL-to-screen mapping table and sort it by share of paid traffic.
- Confirm both platforms use the standards: App Links and Universal Links, no custom schemes.
- Remove third-party redirect links from the chain.
- Host association files over HTTPS and verify they resolve without redirects.
- Check robots.txt: Google’s crawlers, AdsBot included, must not be blocked.
- On Android, verify autoVerify per intent filter, not once for the app.
- Test the login path: after authentication the user reaches the target screen.
- Test deferred deep linking — the install-then-first-open journey.
- Run the Deep Link Validator across the priority URL list.
- Reconcile attribution: in-app conversions credit the web campaign, with no duplicates.
- Roll out in stages: highest-traffic URL class first, the rest two weeks later.
How to brief engineering
Most failed rollouts are a briefing problem, not a coding problem. A ticket that says “add deep links” reliably comes back with a deep link to the home screen. A working brief contains:
- The goal in numbers. Monthly mobile clicks on these URLs, share of audience with the app, expected conversion uplift.
- A prioritised URL list. Specific addresses or URL patterns, sorted by share of paid traffic.
- The screen mapping. For each URL pattern, which app screen opens and by which identifier.
- Standards requirement. App Links on Android, Universal Links on iOS; custom schemes and third-party redirects explicitly forbidden.
- Hosting requirement for association files. HTTPS, no redirects, correct content type, reachable by crawlers.
- Acceptance scenarios. User logged in; user logged out; app installed but no session; app installed after the click.
- Definition of done. Deep Link Validator passes across the whole priority list and a manual test passes on both platforms.
Write the maintenance rule into the same ticket: any app release that changes navigation or screen structure triggers a re-check of the mapping table. Without it, half your links will point somewhere wrong within six months, and you will discover it through a quiet rise in CPA rather than an alert.
Who owns what
| Role | Responsibility |
|---|---|
| Media buyer / PPC specialist | Sizing, URL prioritisation, verifying the effect in reporting |
| Mobile engineering | Intent filters, entitlements, deep link handling and login flow |
| Web engineering / DevOps | Association files on the domain, HTTPS, robots.txt |
| Analytics | Attribution, deduplication, reconciling web and app conversions |
When deep links are the wrong project
- Low app penetration. If only a few per cent of your audience has the app, the effect is inside the noise — spend the sprint on landing page conversion for paid traffic instead.
- The app is worse than the site. Narrower catalogue, slower search, missing payment method — a deep link will make results worse, not better.
- One-off purchase journeys. With no repeat visits, the app’s advantage is marginal.
- No maintenance capacity. The mapping table needs updating with every app release; a dead deep link is worse than none.
The mirror case: a strong app with too few installs is a different problem — acquisition, not routing. How that works now that the algorithm owns most of the controls is covered in app campaigns in 2026.
What it is worth in money
Deep linking is one of the rare improvements that does not require more budget. You are not buying more clicks; you are raising the return on clicks you already paid for. On the account it shows up as lower CPA at flat spend, which means the effect appears in unit economics rather than in traffic volume.
There is a speed dividend too. A native app screen normally renders faster than a mobile page, and speed maps directly onto bounce rate — the same mechanics as in landing page speed and Core Web Vitals. Put bluntly, a deep link is the most radical landing page optimisation available: replacing the page with something already installed on the device.
If you are scaling paid traffic across markets and need the infrastructure behind it — stable accounts and the processes around them — see Google Ads agency account rental, with the rest of the stack listed on the PPC Rebels services page.
FAQ
How is a deep link different from a normal app link?
A normal link opens the app store or the home screen. A deep link opens a specific screen — the same product, cart or category the user would have seen on the website.
Why are custom schemes like myapp:// not supported?
They do not prove any association between the app and the domain, which makes them spoofable. Only industry standards are supported: App Links on Android and Universal Links on iOS.
Can I use links from a mobile measurement partner?
Third-party redirect solutions are not supported due to security and privacy risks. The ad must point at your domain, and the OS handles opening the app.
Do I need app campaigns to use deep links?
No. Web to App Connect is specifically for web campaigns — Search, Shopping, Display and Performance Max. App campaigns solve a different problem: driving installs.
What happens if the app is not installed?
The user lands on the normal web page — the URL in your ad. Which is why mobile site quality still matters: it serves everyone without the app.
Do I have to change final URLs in my campaigns?
In the basic setup, no: you point at your own web URLs and the domain association opens the app. That is exactly why redirect chains in the URL are so damaging — they break the association.
How do I confirm a deep link works?
Use the Deep Link Validator in the App advertising hub, then run a manual test on a real device with the app installed and a live session.
What is deferred deep linking?
The journey where the user clicks, does not have the app, installs it, and should then arrive on the intended screen at first launch rather than the home screen. Without it you lose your most expensive click.
Do deep links affect Quality Score?
Not directly. Indirectly yes, because better experience and higher conversion improve campaign economics — but landing page relevance is still assessed against the web page in your ad.
Does anything need changing in robots.txt?
Make sure Google’s crawlers, AdsBot included, are not blocked and that the association files are reachable. Blocked crawlers are a frequent reason domain verification fails.
How long does implementation take?
The app-side work usually fits a single sprint once the mapping table exists. What takes longest is not code but agreeing which app screens correspond to which URLs.
How do I know whether it paid off?
Compare CPA and conversion rate for mobile traffic before and after, adjusted for conversion lag and seasonality. Do not judge the result before a full conversion window for your category has elapsed.
