Links in your emails open the browser, not your app: click tracking and Universal Links

Your Universal Links and App Links work: a link to yourapp.com/orders/123 opens the app from Notes, Messages and WhatsApp. Put the same link in a marketing or transactional email, tap it on the same phone, and the browser opens instead.

The link in the email isn't the link you wrote.

What your email provider does to links

To count clicks, SendGrid, Mailgun, SparkPost, Customer.io, Iterable, Braze and almost every other email tool rewrite each link before sending. Your https://yourapp.com/orders/123 becomes something like:

https://email.yourapp.com/ls/click?upn=u001.abc123...

When someone taps it, the request goes to the provider's tracking server, which records the click and redirects to your real URL. The tracking host is often a subdomain of yours (email.yourapp.com, url1234.yourapp.com), but it's served by the provider.

Why that stops the app opening

iOS and Android decide whether to open an app at the moment of the tap, based on the address that was tapped:

• The tapped address is the tracking host, and your app doesn't list it in its Associated Domains (iOS) or verified intent filters (Android). So the phone opens the browser.
• The browser then follows the redirect to yourapp.com/orders/123. A redirect inside the browser is not a tap, and both iOS and Android usually keep the person in the browser at that point.

So the person lands on your website, even with the app installed. If your site has no page for that path, they land on a 404.

Fix 1: turn click tracking off for app links

The simplest fix: tell the provider not to rewrite the links that should open the app.

• SendGrid: add clicktracking="off" to the <a> tag, or turn click tracking off for the message.
• Mailgun: turn click tracking off per message (the o:tracking-clicks option) or for the domain.
• Other providers have a similar per-link or per-message setting.

The link then goes straight to yourapp.com/... and opens the app. The cost: those clicks disappear from your email reports, and anything that relies on them (A/B tests, automations triggered by a click) stops seeing them.

Fix 2: make the tracking domain open your app

The tracking host can become an app link domain like any other, if it serves the verification files and your app claims it. Several providers document a version of this. The pieces:

1. Serve the verification files on the tracking host. https://email.yourapp.com/.well-known/apple-app-site-association and /.well-known/assetlinks.json must answer 200 with JSON and no redirect. The provider's server won't serve your files, so this usually means putting a proxy or CDN in front of the tracking host: it serves the two files itself and passes every other request to the provider.
2. Claim only the click paths. The same host also serves open-tracking pixels, unsubscribe pages and "view in browser" links, which must keep working in a browser. In the Apple file, list just the click path (for SendGrid /ls/click*, Mailgun /c/*, and so on). On Android, use a pathPattern per click path in the intent filter.
3. Add the host to the app. applinks:email.yourapp.com in Associated Domains, and an autoVerify intent filter for the host and paths on Android. Release the update. Until people install it, emails keep opening the browser.
4. Resolve the click in the app. The app now receives the tracking URL, not your destination. Make a request to it from the app, without opening a browser: the provider records the click and answers with a redirect to your real URL. Route on that.

Done this way, the email reports keep counting clicks, the app opens for people who have it, and everyone else gets the normal redirect to your website.

Test it the way people receive it

• Send a real email through your provider to a phone that has the app, and tap the link in the Mail app and in the Gmail and Outlook apps. Some mail apps open links in their own browser, which behaves like an in-app browser.
• Check that open tracking and unsubscribe links still open a browser page.
• Test on a phone that doesn't have the app: the link should still reach your website.
• Our free link checker shows whether a host serves valid apple-app-site-association and assetlinks.json files, which is the first thing to confirm on the tracking domain. The redirect checker shows every hop a tracked link takes.

How DL2App handles it

DL2App does fix 2 for you. In the dashboard you choose your email provider (presets for SendGrid, Mailgun, SparkPost, Customer.io and Iterable, or any other provider) and enter your tracking domain, then point the domain's CNAME at DL2App. DL2App serves the verification files, claims only the click paths, and passes everything else to your provider, so click stats, open pixels and unsubscribe pages keep working. When the app opens, the SDK asks the provider where the click leads, which also counts the click, and hands your code the destination path. People without the app are sent to the provider as before. The email links guide walks through the setup.

Questions people ask

Why do links in my emails open Safari instead of my app? Your email provider rewrote the link to go through its click-tracking domain. The phone decides on the tapped address, which isn't a domain your app claims, so the browser opens and the redirect to your real link happens inside it.

Can I keep click tracking and still open the app? Yes, if the tracking domain serves the Apple and Android verification files, your app claims it for the click paths only, and the app resolves the tracking URL to find the destination. Otherwise, turn click tracking off for app links.

Do I need an app update? Yes. The tracking domain has to be listed in the app's Associated Domains and Android intent filters, so it only works for people who have installed that version.

Does this apply to Android too? Yes. The tapped address is the tracking host, so App Links only fire if that host is verified for your app.