UTM for app deep links
When a campaign link opens a native app instead of a web page, the UTM values have to survive a web-to-app handoff that does not always preserve query strings. This page covers passing campaign data into deep links and the caveats that can drop it along the way.
Passing UTM into a deep link
A web-to-app deep link is still a URL, so you can attach utm_* values to it and have the app read them when it opens. For an already-installed app, the OS or your deep-link router can hand the query string to the app, which parses the campaign data on launch.
Keep the same utm_source / utm_medium / utm_campaign you would use on the web so the app-side attribution maps to the same campaign rows, and keep every value generic.
- A deep link is a URL that can carry utm_* parameters
- Reuse the same campaign labels as the web journey
- The app parses the query string on launch
Where parameters get dropped
The handoff is the fragile part. If the app is not installed, the journey detours through an app store, and the original query string usually does not survive an install on its own — preserving it needs an install-referrer or deferred-deep-link mechanism specific to the platform. Even for an installed app, an intermediate redirect or in-app browser hop can strip parameters.
Treat app-side attribution as dependent on your specific deep-link tooling, not as automatic. Verify end to end that the utm_* values actually reach the app, and if they cannot, attribute on the web leg you can observe rather than guessing at the in-app source.
How it appears in analytics and logs
A deep link can carry utm_* into the app, but the handoff — through the OS, an app-store install, or an in-app router — does not guarantee the query string survives. If it is dropped, the in-app session has no campaign source.
Diagnostic use case
Carry campaign attribution into a native app when a link is meant to open the app, while understanding where the parameters can be lost.
What WebmasterID can help detect
WebmasterID reads utm_* on the web side of the journey. For the in-app leg, attribution depends on whether your deep-link setup preserves the parameters; WebmasterID does not invent app-side data it cannot observe.
Common mistakes
- Assuming utm_* automatically survives an app-store install.
- Letting an in-app browser or redirect strip the parameters silently.
- Passing a user identifier through the deep link instead of generic labels.
Privacy and accuracy notes
Pass only generic utm_* labels into a deep link. The web-to-app handoff is not a private channel, and an install referrer or clipboard hop can expose whatever you put in the link. Never pass a user identifier or secret.
Related pages
- Push notification campaign tracking
Push notifications drive re-engagement, but their clicks blur into direct or app traffic unless tagged. This page shows how utm_medium=push keeps notification-driven visits as a distinct channel, with a worked example and the rule against personal data in the link.
- Cross-domain UTM tracking
When a visitor moves from one domain you own to another mid-journey, the original campaign source can be lost unless the UTM values carry across. This page explains how to preserve them and the session caveat that, without care, splits one campaign visit into two attribution records.
- Campaign links (docs)
Carry campaign labels into web-to-app deep links.
Sources and verification notes
- MDN — URL search paramsA deep link is a URL whose utm_* parameters may or may not survive handoff.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.