Mobile Apps and Deep Links

A short link that leads to a mobile app has three audiences at once: people who already have the app, people who do not, and people whose browser lives inside another app. This page covers all three, plus the two pieces of setup that make the difference — the association files on your domain, and the deferred click context your app can read on first launch.

What the mobile section does

Open a link, go to the Mobile tab and turn on mobile destinations. For each platform you can set three addresses:

• App link — the address inside your app: your own scheme with a path (myapp://product/42), an Android intent, or a universal https link.
• Store address — the App Store or Google Play page, used when the app does not open.
• Web fallback — a page for visitors you would rather not send to the store at all.

Everything is optional. A link with only a store address is a plain store redirect. A link with an app link and a store address gets the full behaviour: the page tries the app first and moves on to the store when nothing happens.

Two more settings decide what happens outside a plain phone browser:

• Tablets — treat them as phones (the default) or as desktops.
• In-app browsers — what to do when the link opens inside Instagram, TikTok, Facebook or a similar app.

Desktop visitors follow the Desktop destination if you set one, and the link's main destination otherwise. Nothing about the mobile section changes what desktop visitors see unless you ask for it.

Why in-app browsers need their own rule

Most link clicks in a social feed never reach Safari or Chrome. They open in a web view inside the app itself, and several of those web views keep every navigation to themselves: a universal link stays in the web view, and a custom scheme quietly does nothing. That is not a bug you can fix from the link — it is a decision made by the app that owns the web view.

So the setting gives you three honest options:

| Choice | What the visitor gets | | --- | --- | | Try to open the app | The interstitial page tries the app link; when the web view is known to block it, the page skips the wait and shows how to reopen the link in the phone browser. | | Go straight to the store | No app attempt at all — useful for install campaigns where the store page is the goal. | | Go to the web fallback | The visitor stays on the web, which is often the best answer for content links. |

Association files: the setup that makes links open the app silently

For a link to open your app without a browser stop, the operating system has to know that your domain and your app belong together. Both platforms check that with a file served from the domain itself:

https://go.brand.com/.well-known/apple-app-site-association
https://go.brand.com/.well-known/assetlinks.json

You do not write those files. In Domains, open the domain and add your apps under Mobile apps:

• for iOS: the App ID in the form TEAMID.com.company.app, and the paths the app should handle (* covers every short link);
• for Android: the package name and the SHA-256 signing fingerprints from Play Console.

The platform builds and serves both files from your domain with the exact response both platforms require: status 200, no redirects, application/json, no transport compression. That last one matters more than it sounds — a proxy that gzips the file in transit is one of the most common reasons app links silently stop working.

Checking the setup

The Check the files button fetches both files from your live domain and reports what a platform would see. The findings map to specific fixes:

| Finding | What to do | | --- | --- | | The domain did not answer | The domain is not serving traffic yet, or DNS is still propagating. | | The file is missing | No apps are configured for this domain, or the request never reaches the platform. | | The domain redirects this address | Something in front of the domain rewrites /.well-known/. Platforms do not follow redirects here. | | Served as the wrong type | The response is HTML, usually a 404 page from another service. | | The response arrives compressed | A proxy compresses the file. Both platform checks can fail on that. | | No app is declared | The file is valid but empty for that platform — add the app in the dashboard. |

After the files are in place, both platforms cache them on their own CDN, so a fresh app install can take a while to pick up a change. Reinstalling the app is the reliable way to force a re-read during testing.

Deferred click context after install

A visitor without your app clicks a link, lands in the store, installs the app and opens it. At that moment the app knows nothing about where the person came from — the browser session and the app are two unrelated worlds.

Turn on Deliver the click context after install and the platform keeps a short device fingerprint for a couple of hours: platform, major OS version, language, country, screen size, time zone and network operator. There is no IP address in it, no advertising identifier, and nothing that could be traced back to a person.

On first launch your app asks the platform whether a click happened:

curl -X POST https://go.brand.com/__dl/claim \
  -H 'content-type: application/json' \
  -d '{
    "platform": "ios",
    "os_version": "17.4",
    "language": "de",
    "timezone_offset": 120,
    "screen_width": 1170,
    "screen_height": 2532,
    "pixel_ratio": 3
  }'

A match answers with the original link and its campaign tags:

{
  "matched": true,
  "confidence": "high",
  "score": 100,
  "matched_on": ["screen", "timezone_offset", "language", "os_version"],
  "url": "myapp://product/42",
  "domain": "go.brand.com",
  "slug": "promo",
  "link_id": "lnk_...",
  "utm": { "utm_source": "newsletter" },
  "click_id": "...",
  "clicked_at": "2026-08-14T10:00:00.000Z"
}

No match answers with {"matched": false} — and so does a second request for the same click, because the record is handed over exactly once.

The limits, stated plainly

• Matching is probabilistic. Two devices of the same model, on the same network, in the same time zone and language look identical to this method. That is why every answer carries a confidence and the list of attributes it was decided on: high means screen size and time zone both matched on a fresh click, low means treat it as a hint, not a fact.
• The window is hours, not days. The fingerprint expires two hours after the click, and confidence drops after the first fifteen minutes.
• Send the request once, on first launch. The record is consumed by the first successful match; a second call returns nothing.
• A store redirect without the interstitial page collects less. Screen size and time zone are only known to the page that runs in the browser, so a link that goes straight to the store matches on language and OS version alone — and says so, with a lower confidence.

Testing checklist

1. Open the link on a phone with the app installed: it should land inside the app.
2. Open it without the app: the page appears briefly and the store opens.
3. Open it from a social feed: check that your in-app browser choice matches what you expect.
4. Open it on a desktop browser: the desktop destination or the main destination.
5. Run Check the files on the domain and confirm both files come back clean.