Deep linking and deferred deep linking

What is a deep link?

A deep link is a URL that opens a specific screen or piece of content inside a mobile app, rather than the app's home screen or a web page. A link to a product, a referral offer or a particular article is a deep link if tapping it lands the person on that exact place in the app.

There are three kinds you will meet:

• Custom scheme links, such as myapp://product/42. Simple, but any app can claim the same scheme and there is no web fallback.
• Universal links on iOS, which are ordinary https links verified against your website.
• App Links on Android, also verified https links.

Google's Android guidance prefers verified https links, because custom schemes can be claimed by other apps.

Universal links on iOS

Universal links work when the app declares the domain in its Associated Domains entitlement, such as applinks:example.com, and the website serves a matching apple-app-site-association file.

• The file lives at https://<domain>/.well-known/apple-app-site-association, with no file extension.
• It must be served over https with a valid certificate and no redirects.
• Each subdomain needs its own entry and its own file.
• Since iOS 14, devices fetch the file from an Apple-managed CDN, which requests it from your server within 24 hours. Devices check for updates about once a week.

Universal links have some behaviours that look like bugs but are by design. A link typed into Safari's address bar never opens the app, and tapping a link to the same domain you are already browsing stays in Safari. Inside third-party in-app browsers, Apple says support is up to those browsers.

App Links on Android

App Links work when the app's intent filter includes android:autoVerify="true" and the website serves a matching Digital Asset Links file.

• The file lives at https://<domain>/.well-known/assetlinks.json, served as application/json with no redirects.
• It lists the package name and the SHA-256 fingerprint of the app's signing certificate.
• With Play App Signing, the fingerprint must be the app signing key from the Play Console, not the local upload key.
• On Android 12 and later, an unverified domain opens in the browser instead of the app.

Why don't normal deep links survive an install?

Because both universal links and App Links only route to an app that is already installed; if it is not, the operating system opens the URL in the browser and the original destination is lost.

Apple's documentation says that if the person has not installed the app, the system opens the URL in their default web browser. No Apple document in our sources offers a first-party way to carry the original URL through an App Store install. Android App Links behave the same way for apps that are not installed.

That is a problem for paid acquisition. Someone taps an ad for a specific product, installs the app and lands on the home screen. The context from the ad is gone.

What is deferred deep linking?

Deferred deep linking routes a new user to specific in-app content on their first open, after they have installed the app from a link. It is called deferred because the routing is postponed until after the install.

Neither Apple nor Google defines the term in their documentation; it is the industry's name for the technique. It works like this:

1. The person taps a link. The link service records where it should lead.
2. The app is not installed, so the person goes to the store and installs.
3. On first open, the SDK asks the link service whether this install came from a link.
4. If there is a match, the service returns the destination, and the app routes there.

On Android, step 3 can use the Google Play Install Referrer, which carries the referrer URL through Google Play. On iOS, there is no equivalent referrer, so solutions rely on other matching techniques.

Why attribution and deep linking belong together

Step 3 above is the same question attribution asks: which link or ad led to this install? Deferred deep linking and install attribution use the same click record, the same matching and the same first-open event.

Running them as separate tools means two SDKs answering one question, and sometimes answering it differently. A unified setup gives:

• One match per install: the screen the person lands on and the campaign that gets credit come from the same decision.
• One link per campaign: the same tracking link handles routing and measurement.
• Consistent re-engagement: deep links to existing users can also be credited as re-engagement.

In an MMP such as Linkrunner, for example, every link is dynamic and deferred by default, so the same link routes the user and records the attribution.

A worked example

A travel app runs an Instagram ad for a weekend deal to Goa, linking to the deal screen.

• Existing user: Aditi has the app. On Android, the verified App Link opens the deal screen directly. The tap is recorded as a re-engagement click.
• New user: Imran does not have the app. The link sends him to the store. He installs and opens the app, the SDK matches the install to his click, and the app opens on the Goa deal rather than the home screen. The same match credits the Instagram campaign with the install.

One caveat from Meta: deferred deep linking is not available for new iOS 14 and later campaigns that use SKAdNetwork for attribution.

Testing checklist

• Fetch the apple-app-site-association and assetlinks.json files directly and confirm a 200 response with no redirect.
• On Android, run adb shell pm get-app-links <package> and look for verified.
• On iOS, paste the link into Notes and long-press it to check that the app is offered.
• Test deferred links on a clean device with the app uninstalled.
• Confirm the attribution and the destination both come from the same click.

For the mechanics of matching, see how an install gets attributed and Android attribution and the install referrer. The glossary defines every link type.