Practical UTM checklist for testing persistence across redirects and app links
Practical UTM checklist for testing persistence across redirects and app links
Ever noticed campaign traffic turning up as ‘direct’ or ‘unknown’ even though it came from a tagged link? Redirects and app links can strip, rewrite or fail to pass UTM parameters, so attribution becomes unreliable.
This checklist explains how to verify UTM capture on servers and in analytics, trace redirect and app link flows, design tests and choose tools to keep UTM parameters persistent, and analyse results to implement fixes. Use it to spot where parameters are lost, quantify the effect on attribution and apply targeted fixes that restore reliable campaign measurement.
What should I verify first when campaign traffic is attributed as direct or unknown?
Begin by verifying UTM capture on servers and in analytics: create distinct test UTM sets, record each test URL, and search server access and application logs for the initial GET, redirect response, and follow-up GET to confirm whether the query string was preserved. Then export raw analytics payloads for the same tokens and compare counts, timestamps, and campaign fields to locate gaps in ingestion or collection.
How can I trace where UTM parameters are lost through redirects and app links?
Map the end to end click flow and capture every HTTP request and response in the redirect chain, recording Location headers, referrer fields, status codes, and request lines so you can pinpoint the hop where parameters change or vanish. Use browser developer tools, a proxy, or packet capture, and instrument redirect endpoints or app launch handlers to persist and echo incoming parameters tied to unique test tokens.
What tests and tools should I use to verify UTM persistence across environments?
Build a test matrix covering redirect types, intermediate domains, link shorteners, and app install fallbacks, assigning unique UTM tokens to each scenario and instrumenting verification points at the first server touch, final page, storage writes, and app entry. Use a network proxy or inspector, devices or emulators that exercise app installs, and a logging endpoint for assertions, then automate reproducible tests that capture redirect traces and artefacts, include retries, and check edge cases like encoding and fragment handling.
How should I handle app install or deep-link flows that do not forward UTMs?
Test both cold-install and warm-launch flows, capture the install referrer handoff and the app's first network calls, and if direct parameter passing fails implement a short-lived server-side token exchange that maps the UTM on click and resolves it on first open. Alternatively, persist incoming UTMs in a first-party cookie or server session for reliable handoff into the app.
What fixes and verification steps restore reliable attribution after finding UTM loss?
Apply targeted fixes such as updating redirect rules to forward query strings, enforcing consistent URL encoding and case handling, persisting UTMs in cookies or server sessions, or using server-to-server campaign mapping where query parameters cannot be carried. Validate changes with automated end-to-end regression tests, compare pre- and post-change attribution counts, and create alerts for increases in unknown or direct attribution.

Check UTM capture on server and in analytics
Create distinct UTM sets and use them only for tracing clicks. Record each exact test URL so you can search your logs for the same token. Execute clicks from different devices and channels to produce repeatable traces. Then check server access and application logs for the initial GET, the redirect response and the subsequent GET to confirm whether the query string was preserved. Capture full request lines, headers and response codes across the redirect chain, and treat any missing UTM parameter in the later request as evidence that a redirect, proxy or client-side navigation has rewritten or dropped the parameters.
Export raw server-side click records and the analytics ingestion payloads for the same test UTM parameters, then compare counts, timestamps and campaign fields to spot any gaps. If the server logs include the UTM but the analytics platform does not, have a look at the analytics collection layer, attribution rules and any client or server sanitisation that might normalise or drop query parameters.
For app-link and deep-link flows, test both cold-install and warm-launch scenarios. Capture the initial intent or open URL, the install referrer handoff and the app’s first network calls. If direct parameter passing fails, use a short-lived token exchange: map the UTM on the server when the click happens and resolve that token on first open to restore the original UTM information.

How to trace redirect and app link flows
Start by mapping the end-to-end click journey and capture every HTTP request and response in the redirect chain. Record Location headers, referrer fields, status codes and the original UTM-bearing URL so you can pinpoint the hop where parameters are dropped or rewritten.
Instrument redirect endpoints and app-launch handlers to persist and echo incoming parameters into short-lived sessions, cookies or logs. Correlate these entries with unique test tokens to prove whether values survive via URL forwarding, client-side storage or server-side mapping.
Use browser developer tools, a proxy or device packet capture to compare the recorded values at each hop and produce verifiable evidence of parameter movement.
Vary the redirect mechanics you test. Try different HTTP status codes, client-side JavaScript redirects, meta refresh, HTTP to HTTPS transitions and handoffs to app links. For each method, document whether query strings, fragments or referrers are preserved.
Run the same tests across mobile browsers, in-app browsers, native apps and common client viewers such as email or messaging apps. Capture any differences in referrer behaviour, query string stripping and app launch handling.
Summarise the outcomes in a concise failure matrix that lists issues such as missing parameters, truncated values, duplicated keys or parameters moved into fragments. For each issue, attach clear remediation steps, for example: forwarding query strings, reattaching parameters after app launch, persisting tokens server side or using a fragment-based fallback.
For every fix, include a verification test that proves the UTM parameters persist from the initial click to the final app state. Attach the captured requests, status codes and intent payloads as evidence.

Design tests and choose tools to ensure UTM persistence
Build a test matrix that lists redirect types, intermediate domains, link shorteners and app-install fallback flows, and assign a unique UTM parameter to each scenario so outcomes map to the exact path. Add verification points at the first server request, the final landing page, any writes to cookies, sessionStorage or localStorage, and at app launch to capture the raw incoming URLs, final query strings and deep link parameters. Compare those logs against defined acceptance criteria to reveal persistence, partial loss or overwriting, and to pinpoint where UTMs were altered.
When testing link tracking and redirects, choose tools that let you see the whole flow and capture the events you need to assert against.
Tools to use
– A proxy or network inspector that shows full redirect chains and headers.
– A device or emulator that opens links into apps and can simulate installs and app behaviour.
– A logging endpoint or test hook that collects client and server events for assertions.
How to test
– Automate reproducible tests that script link follows and assert final URLs, stored attribution values, and the parameters the app receives.
– Capture redirect traces and screenshots as artefacts for audits and troubleshooting.
– Include retries and environment resets so results are reliable and easy to debug.
Edge cases to check
– URL encoding and decoding differences.
– Duplicate or conflicting UTM parameters.
– Fragment versus query parameter handling.
– Browser tracking protection modes and their impact on parameters.
– App-not-installed fallbacks and how they change attribution.
Finally, document which environments or redirect patterns systematically alter or remove UTM parameters so engineering teams can prioritise fixes effectively.

Analyse campaign data and fix UTM persistence issues
Collect and compare raw request and analytics data to map the full redirect chain, including the final landing URL, query strings, HTTP status codes and the initial tracking event. This lets you pinpoint the exact hop where utm parameters are lost or altered.
Reproduce the failure across web redirects, app links and deep links on multiple browsers and operating systems, while recording network traces and device logs. Compare client-side and server-side handling to determine whether the issue is consistent or specific to certain environments.
Use a simple acceptance criterion: success means the utm values in the final URL match the utm values in the first tracking event, which gives a clear pass or fail for persistence.
Check common failure modes with concrete tests
Key checks
– Make sure each redirect preserves the query string.
– Check that JavaScript redirects or meta refresh do not overwrite parameters.
– Confirm correct URL encoding and consistent case handling.
– Test whether analytics SDKs or ad networks strip or rewrite UTM fields.
Targeted fixes to preserve attribution
– Update redirect rules to forward query strings and use a consistent encoding strategy.
– Persist incoming UTM parameters in a first-party cookie or a server session so they can be handed off to the app.
– For flows that cannot carry query parameters, implement server-to-server campaign mapping.
Validate and monitor
– Validate changes with automated end-to-end regression tests and by comparing attribution and conversion counts before and after the change.
– Create alerts for increases in unknown or direct attribution so issues are spotted quickly.
– Document clear acceptance criteria and rollback conditions to support rapid iteration and safe deployments.
