Deep linking

Deep linking is the practice of using a single URL to send a user directly to a specific screen, product, or piece of content inside a mobile app rather than to the app’s home screen or a mobile web page. A deep link carries a destination and, usually, a payload such as a product ID, a promo code, a referral token, or an attribution ID, which the app reads on open and uses to render the right experience.

Everything else on this page is a variation on that one idea. Deep linking gets complicated because a link has to survive three separate environments on its way to your app: the web page or ad that hosts it, the platform the user tapped it in, and the operating system that decides which app opens. Each layer can quietly break the link, and each does so differently.

TL;DR

• A deep link is a URL that opens a specific in-app destination and passes data to the app on open.
• There are 3 layers to get right: web deep links (the URL and its association files), platform deep links (how Instagram, Meta, Reddit, TikTok, email, and SMS handle your link), and app deep links (the OS mechanism: Universal Links on iOS, App Links on Android, URI schemes as a legacy fallback).
• Deferred deep linking covers users who don’t have the app yet: click, install, then land on the right screen. It requires an attribution SDK. No operating system provides it natively.
• In-app browsers on social platforms are the single most common reason a correctly configured deep link still doesn’t open the app.
• Ad platforms split into 2 groups, and the group decides where you configure deep links at all.
• Singular is one of 5 App Attribution Partners Google supports for deferred deep linking on Google Ads, and one of only 2 that need no additional configuration to enable it.
• Deep links are only worth building if you can measure them. Singular tracking links are built to support deep links and deferred deep links once your app is configured.

Before implementation, it helps to know which layer you’re debugging. Most “the deep link is broken” tickets are a problem in one specific layer.

Layer 1: Web deep links

A web deep link is an ordinary HTTPS URL, for example https://example.com/product/123, that has been claimed by your app. When the OS sees it, it checks whether your app owns that domain. If yes, it opens the app. If no, it loads the web page.

Both iOS and Android require you to publish a machine-readable association file proving the app and the domain belong to the same owner.

On iOS, that file is apple-app-site-association, served with no file extension over HTTPS from either the root of your domain or /.well-known/, with /.well-known/ preferred, paired with an Associated Domains entitlement in the app using the applinks: prefix. Apple periodically re-crawls the file, so changes aren’t instant. See Apple’s documentation on associated domains for the current spec.

On Android, the equivalent is assetlinks.json at /.well-known/assetlinks.json, listing your package name and signing certificate fingerprint, paired with android:autoVerify=”true” on the relevant intent filter. Google’s guide to verify App Links covers the hosting rules, which are stricter than most teams expect.

Hosting rules that trip teams up

These apply to both platforms and account for a large share of failed verifications:

• HTTPS only. Neither OS will fetch the file over plain HTTP.
• No redirects. If /.well-known/assetlinks.json 301s anywhere, even to another HTTPS URL on the same domain, Android won’t follow it.
• Correct Content-Type. application/json for assetlinks.json. The Apple file must be served as JSON without a .json extension in the filename.
• No authentication. The file must be publicly readable with no cookies, tokens, or headers.
• Don’t block the crawlers. If your robots.txt blocks AdsBot-Google or AdsBot-Google-Mobile from either /.well-known/assetlinks.json or /.well-known/apple-app-site-association, Google Ads can’t validate your association files, which fails deep link validation for ad campaigns.

Deep linking, SEO, and the app-to-web content match

Deep linking doesn’t change how your web pages are indexed. Search engines index web content, not app content. But there’s a UX rule that matters for both quality score and user trust: the app screen a link opens should match the web page it replaced. If a search snippet promises a product page and the app opens on a home feed, you’ve created a mismatch users notice.

For teams running mobile web and app in parallel, this connects directly to web attribution, where you need one view of a journey that starts in a browser and finishes in an app.

Layer 2: Platform deep links

This is where most real-world deep linking fails, and it’s the layer marketers control most directly.

The problem is the in-app browser. Most large social platforms open links tapped inside their app in an embedded webview rather than handing the URL to the operating system. Universal Links and App Links depend on that OS-level handoff. Inside an embedded webview the handoff is often suppressed, so a user who has your app installed still lands on your mobile site.

Platforms do this for reasons that have nothing to do with you: keeping the user one swipe from the feed, and retaining the ability to observe behavior on the destination page.

Documented link behavior by channel

Behavior varies by channel and by operating system, and it isn’t symmetrical. The table below reflects Singular’s documented redirect behavior for links in owned and organic channels.

Three things worth pulling out.

Email and native messaging are the safe zone

Gmail, Apple Mail, iMessage, and WhatsApp handle both deep links and store fallbacks on both platforms. If you want predictable behavior, start there.

Social feeds need an intermediary

Facebook, YouTube, Slack, and X all render links inside in-app browsers that suppress the OS handoff. A landing page in the middle that re-triggers the link as a user action is the fix.

Instagram and Reddit need planning, not fixing

Instagram won’t deep link on Android, and won’t fall back to the App Store on iOS. Reddit does neither on either platform. If either is a meaningful channel for you, design the landing experience deliberately rather than assuming the link resolves.

Controlling how your link previews

Separately from routing, the preview card a link renders when shared is controlled by Open Graph tags. Singular supports optional OG Title, OG Description, and OG image URL on Custom Source links, set in Manage Links or overridden dynamically at click time. Preview customization is supported across Facebook, Instagram, Google, Gmail, LinkedIn, X, Reddit, Discord, Pinterest, Slack, Telegram, WhatsApp, Snap, TikTok, Viber, LINE, KakaoTalk, Tumblr, Quora, QQ, WeChat, and iMessage.

In-app browser workarounds

None of these are elegant. All are better than losing the session.

1. An interstitial “open in app” page. An intermediary page that re-triggers the link as a user action. Singular creates this automatically as the Social Landing Page, with no page to build. You enable it per link by toggling Enable Landing Page under Social Link Settings in Manage Links. It’s available for Custom Source links, Mobile Web-to-App links, and Partner links for specific partners where deep linking is blocked. The default flow is a CTA button the user taps. Where the link has an app scheme and a deep link destination configured and the force redirect flag is set for that platform, the page can open the app on load with no tap. Android has force redirect enabled by default; on iOS you enable it by appending _force_redirect=true. Users may briefly see a white screen before the app opens.

Two conditions worth knowing. Don’t enable it on a link with no deep link destination, since there’s nothing for the page to route to. And if the app is already installed, iOS will try to open it directly, skipping the landing page and any fallback URL. That behavior can’t be overridden.

1. A client-hosted landing page. If you want full design control, host your own and either track the click into the page or embed the tracking link inside it. Decide which touchpoint you want the install attributed to before you build.
2. QR handoff for desktop and out-of-home. Camera-app scanning bypasses the problem entirely. Singular generates a QR code automatically for every custom source link, in PNG and SVG.
3. Smart banners on your mobile web page. Lower tap rates, but no engineering risk.

The measurement consequence matters as much as the UX one. If a user is stranded in a webview, that session gets attributed to mobile web rather than to your app. Your channel ROAS will look worse than it is and your app engagement numbers will look thinner than reality.

Ad platforms: the self-attributing split

Ad platforms fall into 2 groups, and the group determines where you configure deep links.

• Self-attributing networks run their own attribution and don’t accept MMP tracking links for app campaigns. Meta, Google Ads, Snapchat, TikTok, and X Ads all work this way. You configure deep links in the partner’s own dashboard, and deferred behavior comes through the MMP integration rather than through a link. With Singular, deferred deep linking is enabled automatically for Google Ads, Snapchat, and TikTok Ads once Partner Configuration is activated. For Meta, it’s enabled through your Singular customer success manager, and the equivalent function must be turned off in the Facebook SDK to avoid two systems competing to serve the same destination.

Google publishes a list of App Attribution Partners it supports for deferred deep linking on Google Ads. Singular is on that list, and is one of only 2 partners that require no additional settings to enable deferred deep link postbacks. The others need integration toggles, a support ticket, or a setting check.

• Web campaigns on those same platforms are different. Meta web campaigns using Sales or Traffic objectives, and TikTok web campaigns, do route through Singular tracking links, which is exactly where the Social Landing Page matters. Facebook’s in-app browser supports neither iOS Universal Links nor Android App Links, and TikTok’s suppresses iOS Universal Links, so a web-to-app campaign on either platform will silently drop users on your app’s home screen without an intermediary page.

Google Ads has its own requirement for web campaigns that route into an installed app, including Search and Performance Max. The final URL has to be a native App Link or Universal Link, because Google Ads policy requires the click destination to point directly at the final landing page. Custom URI schemes and redirect-based links aren’t accepted there. This is a requirement on the final URL only, so you can keep your existing linking setup on other channels and add native links for Google Ads alongside it.

Everything else either accepts tracking link redirects or integrates server to server. For partners that accept redirects, your tracking link delivers the deep link experience directly. For asynchronous partners, the click notification arrives after the fact and the deep link is configured in the partner’s campaign dashboard.

The recurring problem with non-self-attributing partners is link wrapping. When a partner wraps your tracking link in their own redirect, Universal Links stop firing, because Apple requires direct user intent behind the routing. That’s what the force redirect fallback exists for. Deferred deep linking is unaffected by wrapping, because it runs through the SDK rather than the redirect chain.

Layer 3: App deep links

Once a link reaches the operating system, one of 3 mechanisms handles it.

URI schemes (legacy)

A custom scheme like myapp://product/123. The app registers the scheme at install time and the OS routes anything starting with myapp:// to it.

• Works: when the app is installed, in most contexts including many webviews.
• Fails: when the app isn’t installed. The user gets an error or nothing at all.
• Deferred: not on its own. Singular can still carry a deferred destination on a scheme-based link through the SDK using the _ddl parameter.
• Security: any app can register the same scheme, so schemes can be hijacked. Google Ads doesn’t accept them as a final URL for this reason.
• Still useful as: a fallback inside in-app browsers, and as the deep link on an App Store custom product page.

iOS Universal Links (iOS 9+)

An HTTPS URL claimed by your app via the Associated Domains entitlement and the apple-app-site-association file.

• App installed, the app opens at the right screen.
• App not installed, your web page loads, which can route to the App Store. Landing the user on the right screen after that install is deferred deep linking, which the SDK handles rather than the link type.
• No error state, no scheme hijacking, works from Safari, Mail, Messages, and most non-webview contexts.

Android App Links (Android 6.0+)

An HTTPS URL verified through assetlinks.json and android:autoVerify.

• Verified: opens the app directly, no chooser dialog, and no other app can claim the URL.
• Not verified: on Android 12 and later, verification is per intent filter, effectively per host, and an unverified link goes silently to the browser with no disambiguation dialog. There’s no user-visible error, which makes broken verification easy to miss.
• Android 15+ adds Dynamic App Links. You declare a broad intent filter in the manifest, then define specific routing rules in assetlinks.json on your server, including path exclusions and rules based on query parameters or URL fragments. Devices with Google Play services re-fetch the file roughly once a week, so you can change routing without shipping a new app version.

Two constraints on Dynamic App Links are easy to miss. Server-side rules can only narrow the scope declared in your manifest, never expand it. And devices on Android 14 or earlier ignore the dynamic rules entirely and fall back to the manifest, which keeps the change backward compatible but means you can’t rely on it for your whole install base.

Google also offers deep link patching in Play Console, which lets Android teams make ad hoc fixes to App Link configurations on the current app version without a new release.

Deferred deep linking handles the user who doesn’t have your app yet. They click a link, land in the store, install, open, and the app still knows where they were headed.

No operating system provides this. Apple and Google offer no deferred mechanism. It works because an attribution SDK sits on both sides of the install: the provider records the pre-install click and its context, the SDK retrieves that context on first open, and your app reads the destination and renders the intended screen. That’s why deferred deep linking is an MMP capability rather than a platform feature.

The 2026 reality on match rates

With App Tracking Transparency limiting IDFA availability, deterministic matching on iOS is unavailable for most users, and deferred deep linking falls back to probabilistic matching on signals like IP, user agent, screen dimensions, locale, and timezone. Accuracy varies widely and degrades on shared networks, carrier-grade NAT, and when iCloud Private Relay is active. Two practical rules follow:

• The shorter the click-to-install window, the higher the match rate. Optimize store page load and install flow, not just the link.
• Design for the miss. Your app’s first-run experience should degrade gracefully to a sensible default screen rather than a blank state, because a meaningful share of deferred links won’t resolve.

On Android, GAID remains available subject to user opt-out, so deterministic deferred matching is still viable. Google’s Android Privacy Sandbox was deprecated on 17 October 2025, with the Attribution Reporting API among the technologies retired on both Chrome and Android. The practical consequence for Android measurement planning is that GAID is the operating model rather than a transitional one.

App Store custom product pages can carry a deep link

On iOS 18 and iPadOS 18 or later, you can attach an app deep link to an App Store custom product page. When a user who already has the app taps Open on that page, they land on the specified in-app destination rather than the home screen. The deep link can be a Universal Link or a custom URL scheme, and it must be submitted for review with the custom product page.

Apple recommends Universal Links here and advises against URL shorteners or services that add redirects. Test both on a device running iOS 18 or later before committing, since the apple-app-site-association file is fetched asynchronously and may not have resolved immediately after install.

Deep link types compared

Note on the deferred column. No link type provides deferred deep linking on its own. In every row above, the deferred behavior comes from an attribution SDK holding the destination across the install.

Google shut down Firebase Dynamic Links on 25 August 2025. The console had gone read-only in May 2024, and existing links on both custom domains and page.link subdomains now return 404 errors. Google didn’t ship a direct replacement and pointed teams toward third-party providers.

The lasting lesson is operational rather than technical. Many teams discovered they had no inventory of where their links lived: onboarding flows, referral programs, password reset emails, printed QR codes, partner placements. Breakage showed up as unexplained drops in activation rather than as an error anyone could trace. Keep an inventory of live links, the channels they run on, which are short links you can repoint, and who owns each surface.

That last one deserves emphasis. If your app requires authentication, the login flow must preserve the deep link destination and forward the user there after sign-in. Dropping a user on the home screen after they log in is a silent conversion killer and one of the most common gaps between a deep link that technically works and one that converts.

• Re-engagement and retargeting. A user viewed a product and didn’t buy. A deep-linked retargeting ad returns them to that exact product, or to their cart with a coupon applied, rather than a home feed where they have to find it again.
• Web-to-app. App users typically convert at a higher rate than mobile web users, helped by saved payment credentials, push permission, and personalization. Deep linking is the mechanism that makes the handoff worth doing.
• Owned channels. Email, SMS, push, and in-app messaging all benefit, and email in particular performs well because mail clients usually hand off cleanly to the OS.
• Referrals and sharing. A shared link that carries the referrer’s ID through install and into first open is entirely a deferred deep linking problem.
• Onboarding continuity. A user who signed up on your website shouldn’t restart onboarding in the app.
• Non-digital. Short links and QR codes in out-of-home, print, packaging, and events.

The through-line is retention. Every extra tap between intent and destination is a chance to abandon.

Measurement: the part that makes deep links a marketing asset

A deep link that isn’t measured is a UX improvement. A deep link that is measured is an attribution surface.

There’s a subtle failure worth understanding here. When a user taps a tracking-enabled Universal Link and the app is already installed, the device may open the app without making an HTTP request, so some trackers never register a click. The routing works and the measurement silently doesn’t.

When a deep link carries attribution parameters, you can answer questions that are otherwise unanswerable: which creative drove the app open, whether a web-to-app journey converted better than mobile web, what the incremental value of re-engagement spend was, and how much of your “organic” app traffic is really owned-channel traffic that lost its attribution in a webview.

This is why deep linking belongs with your mobile attribution stack rather than beside it. In Singular, tracking links are built to support deep links and deferred deep links once your app is configured, across Apple Universal Links, Android App Links, and Android intents, including journeys that begin on the web and finish in the app, where cross-device attribution becomes relevant.

Web layer

☐  apple-app-site-association served from /.well-known/, HTTPS, JSON content type, no extension, no redirect

☐  assetlinks.json served from /.well-known/, HTTPS, application/json, no redirect, no auth

☐  Package name and SHA-256 signing fingerprints correct for every build variant, including release keys

☐  robots.txt doesn’t block AdsBot-Google or AdsBot-Google-Mobile

☐  Verified via Google’s Digital Asset Links API endpoint and the Google Ads Deep Link Validator

App layer

☐  Associated Domains entitlement with applinks: for every domain, including short-link domains

☐  android:autoVerify=”true” on every relevant intent filter

☐  Route handlers for every deep-linked path, with a sensible default for unrecognized paths

☐  Deferred deep link payload resolved before the first screen renders

☐  Login flow preserves and forwards the deep link destination

☐  URI scheme registered as a webview fallback

Platform layer

☐  In-app browser handling in place, whether Singular’s Social Landing Page or your own

☐  Deep links configured in the partner dashboard for self-attributing networks, not in your link builder

☐  No duplicate deferred deep link setting enabled in a partner SDK alongside your MMP

☐  Short-link domain registered for Universal Links and App Links

☐  Each channel tested individually. Don’t assume an Instagram bio behaves like an Instagram ad

Measurement layer

☐  Attribution parameters on every link

☐  Deferred deep link match rate monitored as a KPI, not assumed

☐  Web-to-app journeys reconciled against mobile web sessions

☐  Override domains restricted on any link exposed publicly

Singular Links routes users across iOS, Android, and web, with attribution built into every click.

Book a demo  ·  Get a free trial

What is the difference between a deep link and a deferred deep link?

A deep link opens a specific screen in an app the user already has installed. A deferred deep link works when the app isn’t installed: the destination is held while the user goes to the app store, installs, and opens the app for the first time, at which point they’re routed to the original destination. Deferred deep linking requires an attribution SDK. No operating system provides it natively.

Do deep links work if the user doesn’t have the app?

Universal Links and App Links do. They fall back to your mobile web page, which can route the user to the app store. Custom URI schemes don’t; they dead-end. That’s the main reason schemes are no longer recommended as a primary mechanism.

Why does my deep link open the browser instead of the app?

Most often because the tap happened inside a social platform’s in-app browser, which suppresses the OS-level handoff that Universal Links and App Links rely on. The second most common cause is failed domain verification, and on Android 12 and later that failure is silent, with no disambiguation dialog to signal it.

Are Universal Links and App Links the same thing?

They’re equivalents, not the same thing. Universal Links are Apple’s mechanism, verified through apple-app-site-association. Android App Links are Google’s, verified through assetlinks.json. Both use standard HTTPS URLs and both require a domain-to-app association file, but they’re configured separately and can fail independently.

Do I still need URI schemes in 2026?

As a primary mechanism, no. As a fallback inside in-app browsers, and as the deep link on an App Store custom product page, yes.

How do deep links work with Google Ads and Meta?

For app campaigns, both are self-attributing networks that don’t accept MMP tracking links, so deep links are configured in each platform’s own dashboard. Deferred deep linking runs through your attribution partner: Singular is one of 5 App Attribution Partners Google supports for this, and needs no additional settings to enable it. For web campaigns that route into an installed app, Google Ads requires a native App Link or Universal Link as the final URL, which you can implement alongside your existing linking setup on other channels.

How accurate is deferred deep linking on iOS?

It depends on the matching method available. Where ATT consent grants IDFA access, matching is deterministic. Where it doesn’t, matching is probabilistic and accuracy varies with network conditions. Shared IPs, carrier NAT, and iCloud Private Relay all reduce it. Treat it as a measured range, monitor it, and design your first-run experience to degrade gracefully.

Does deep linking affect SEO?

Not directly. Search engines index your web content, not your app content, and implementing deep links doesn’t change rankings. Matching your app destination to the corresponding web page is a UX best practice that affects post-click quality.

What replaced Firebase Dynamic Links?

Firebase Dynamic Links shut down on 25 August 2025 and Google didn’t ship a direct replacement, instead pointing teams toward third-party providers. Existing FDL URLs now return 404 errors. Teams migrating typically move to a provider that handles routing and attribution together.

What’s changed on Android recently?

Two things. Android 15 introduced Dynamic App Links, which let you update deep link routing rules server-side without a new app release. And Google’s Android Privacy Sandbox was deprecated on 17 October 2025, including the Attribution Reporting API, meaning GAID-based measurement subject to user opt-out remains the operating model.