Deep links in email campaigns that still open the app.
You built the deep link, tested it in Messages, and it worked. Then the campaign went out through your email platform, every href was rewritten, and the app stopped opening for everyone.
Most email platforms rewrite every link in a campaign so they can count clicks. That rewrite replaces your hostname with theirs, and iOS and Android only open your app for a hostname your app has claimed, so the tap loads a browser instead. The fix is to stop the rewrite on that one link, because a redirect from the tracker into your domain does not reliably reopen the app. Ferry gives you a hostname you own, serves the association files for it, routes app, store, and desktop from the same URL, and counts the open itself so you do not lose the measurement.
The tracking rewrite is the whole problem.
Nothing about email is hostile to deep links. Click tracking is. Once you know exactly what your platform does to an href, the fix is short.
- Find out what your platform does to links
Click tracking rewrites href to the platform domain and redirects through it. Your app never sees a hostname it claimed, so it never opens. Check a real send rather than the preview pane, because previews often do not apply the rewrite.
- Turn the rewrite off for the app link
Most platforms support a per-link opt-out, usually an attribute or class on the anchor. Use it on the Ferry link. Ferry counts that open on its own side, so switching the platform tracking off for one link does not leave you blind.
- A branded tracking domain only helps if you can serve files on it
Adding the tracking hostname to Associated Domains achieves nothing unless that same hostname also serves a valid apple-app-site-association and assetlinks.json listing your app. Many platforms do not allow it. Confirm before you rely on it.
- Do not expect a redirect to carry the app open
iOS opens the app when the tap targeted a claimed domain. A 302 from a tracker into your universal link generally loads the browser instead, so stacking one more redirect on the chain is not a fix.
- Keep the desktop answer honest
A large share of campaign opens happen where no app can be installed. The same Ferry URL falls back to the project web destination on desktop instead of an app store page nobody can act on.
# One link per campaign, created server side with the sk_ key.
curl -sS -X POST "https://api.ferrylink.io/v1/links" \
-H "Authorization: Bearer $FERRY_SK" \
-H "Content-Type: application/json" \
-d '{
"projectId": "PROJECT_ID",
"domainId": "DOMAIN_ID",
"payload": { "data": { "screen": "cart", "promo": "WELCOME10" } },
"campaign": { "source": "newsletter", "medium": "email", "name": "welcome_series_2" }
}'
# Put the returned URL in the campaign anchor as is, and turn off your email
# platform's click rewrite for that one link. Ferry counts the open itself.The attribute that disables click rewriting differs per email platform, so check your own documentation. The sk_ secret key is server-side only and never belongs in an app or a browser bundle.
Six ways an email link stops opening the app.
Every one of these fails quietly and looks like a broken app rather than a broken link, which is why they usually get reported by a customer rather than by a test.
| What goes wrong | What to do about it |
|---|---|
| Click tracking rewrites the link to the platform domain. | Your app never sees a hostname it claimed, so it cannot open. Turn tracking off for that link, or use a tracking hostname that also serves your association files. There is no third option. |
| A redirect chain is assumed to preserve the universal link. | It usually does not. The decision is made at the tap, based on the URL the tap targeted. After the browser opens, a redirect into your domain is just a navigation and stays where it is. |
| The client opens links in its own in-app browser. | Some mail clients open a webview that never hands the URL to the operating system. You cannot fix that from your side, so keep the web fallback genuinely useful. A share of email traffic will never leave the browser. |
| Turning tracking off is treated as losing the data. | Only the email platform count goes away. Ferry records the link open, the install that follows, and the signup or purchase after that, all attached to the campaign fields on the link. |
| One link is reused across the whole programme. | Every send blends into one row and no send can be compared to another. Create a link per campaign with source, medium, and name set, and read them separately. |
| Security scanners click every link before a human does. | Corporate mail gateways and link previews fetch URLs on their own. Ferry classifies known bots, previews, automated scans, and prefetch requests as excluded traffic at the edge, so they neither consume quota nor show up as real opens. |
Questions developers ask first.
Why do deep links in email not open my app? +
Almost always because the email platform rewrote the link to its own click-tracking domain. iOS and Android only open your app for a hostname your app has claimed and that serves the matching association file, so the tracker domain loads a browser instead.
Can I keep click tracking and still open the app? +
Only if the tracking hostname is one your app claims and that serves a valid apple-app-site-association and assetlinks.json listing your app. Many email platforms will not let you serve files on their tracking domains, so confirm it before you build a campaign around it.
Will a redirect from the tracking domain to my link still open the app? +
Usually not. The platforms decide based on the URL the tap targeted. Once the browser is open, a redirect into your domain is an ordinary navigation and tends to stay in the browser, which is why removing the hop beats adding another one.
Do I lose click data if I disable tracking on a link? +
You lose your email platform count, not the measurement. Ferry records every open on its own links and connects the install, signup, and purchase that follow back to that campaign, which is usually the number you wanted from the click in the first place.
What happens for a recipient who does not have the app? +
They go to the right app store for their device, and Ferry keeps the payload. On the first launch after install the same payload is delivered with isDeferred set to true, so a promo link still lands on the promo rather than the home screen.
What about people reading on desktop? +
The same URL falls back to the project web destination on desktop rather than an app store page that cannot install anything. One link covers all three cases.
Send one that works this week.
Create a campaign link, drop it in the next send with the rewrite off, and compare opens, installs, and revenue in one place.