UTM Parameters Lost After a Redirect? Find the First Broken Hop

You tag a campaign link, click it, and reach the right page. Then you notice that the final address has lost its campaign parameters. Find the first redirect that changes those values before changing your analytics setup.

A working destination and a working measurement path are separate checks. A short link, an old product URL, a domain redirect, or a landing-page script can deliver the page while dropping information you intended to measure. This guide helps you locate that break and give the person maintaining the route a precise repair request.

Start with one controlled link

Choose one external campaign you can test. Record the destination and expected values before shortening, wrapping, or distributing the link. Use a clearly named test campaign so the check is recognizable in your own reporting.

For example, a fictional launch email might point to:

https://example.com/launch?utm_source=newsletter&utm_medium=email&utm_campaign=launch_demo

Google's campaign URL guidance explains how manual campaign parameters become acquisition dimensions. Keep a consistent naming convention; values with different capitalization can appear separately. The three values above are a small diagnostic example, not a complete campaign taxonomy.

Use public campaign labels. An email address, customer ID, access token, or confidential project name does not belong in this test URL. Addresses can appear in browser history and logs.

Keep the exact link people receive, too. Testing the destination directly skips any short-link service or email wrapper that might change the route. If an ad platform also uses auto-tagging, test its real path without removing its click identifiers to make the experiment simpler.

Compare the route, not just the final screen

Click the distributed link in a test browser and copy the final address. Compare each expected parameter's value, not only whether the address contains the letters utm.

If a value is missing or different, open the browser's Network panel before trying again. Preserve the log across navigation and inspect the document requests. For each HTTP redirect, record the status and the response's Location destination. MDN's explanation of HTTP redirects describes how that header tells the browser where to go next.

Suppose the route has three stages: the link in an email, a short URL, and a canonical landing page. If the short URL still produces a destination containing all the expected values, but the canonical redirect removes them, the second redirect is the useful repair target. “Campaign attribution is broken” is much less actionable than naming that route and showing its output.

The Network panel also helps distinguish an HTTP redirect from a page that first loads and then navigates through JavaScript. A header-only command will not reproduce every client-side action.

For a public link containing only safe sample labels, someone comfortable with a terminal can inspect HTTP response headers with:

curl -sS -L -D - -o /dev/null 'https://example.com/your-test-link'

Replace the placeholder with your controlled test link. This uses a GET request and follows redirects; it does not run page scripts or validate an analytics event. Avoid sharing the raw output from authenticated pages, where headers or URLs may contain private information.

A small experiment: two identical status codes, different outcomes

We ran a local HTTP demonstration on September 30, 2026, using a temporary loopback server and synthetic campaign labels. One route returned a fixed landing URL. The other copied three validated campaign values into that destination. Both returned 302, and both landing pages returned 200.

The fixed destination ended with /landing?plan=starter; the campaign parameters disappeared. The copying route added utm_source=newsletter, utm_medium=email, and utm_campaign=launch_demo to the same landing URL. The existing plan=starter value remained in both cases.

Changing the redirect status alone would not add the missing values to the fixed destination. Decide whether a redirect should be temporary or permanent for its actual purpose; inspect its destination separately.

Additional checks preserved a source containing an ampersand and a source containing Chinese characters after URL parsing and serialization. A request with two conflicting utm_source values was rejected rather than choosing one silently. These are observed results from the local demonstration, not a test of a live short-link provider or Google Analytics collection.

Ask for a bounded repair

Send the route owner a short record: the incoming URL, the redirect that loses the value, the destination it currently returns, and the expected destination. Include the time of the check and any wrapper used to reach the route.

The repair should preserve the destination's legitimate existing parameters and handle campaign values deliberately. A redirect that adds a second question mark, double-encodes a value, or overwrites a product option can fix one symptom while breaking another.

For a developer, the following JavaScript demonstrates a narrow policy: copy exactly three nonempty, unambiguous campaign values into an already trusted destination. The URLSearchParams API provides methods for reading, replacing, and encoding these values.

const incoming = new URL(requestUrl);
const target = new URL(trustedDestination);
for (const key of ['utm_source', 'utm_medium', 'utm_campaign']) {
  const values = incoming.searchParams.getAll(key);
  if (values.length !== 1 || !values[0].trim()) {
    throw new Error(`Missing, empty, or repeated ${key}`);
  }
  target.searchParams.set(key, values[0]);
}
// Return target.href using the route's intended redirect status.

This is a demonstration, not a drop-in production redirect handler. The destination must come from trusted configuration, not an arbitrary user-supplied redirect URL. Decide which additional campaign fields or platform identifiers your own route needs, what happens when they are absent, and whether incoming values may replace destination values. Signed URLs need their own verification rules; changing their query strings can invalidate a signature.

Compare decoded parameter values when testing. Spaces may serialize as + or %20 without changing the decoded value. Do not mistake a different ordering or equivalent encoding for missing data.

Check collection after the route passes

Seeing the expected values on the landing URL establishes that they reached that point. It does not establish that a tag read them, an event was accepted, or a reporting dimension will match your expectation.

If the page removes campaign parameters after loading, check when measurement reads the URL. A tidy final address can follow successful collection, or it can erase values before collection. The address bar alone cannot distinguish those situations.

For GA4, use DebugView on your test device to inspect collection, then use the appropriate acquisition report for attribution. DebugView has limited attribution analysis, and privacy or consent settings can prevent events from appearing. Keep the user's actual consent choice intact while testing.

Also check the dimension you are reading. Google's campaign URL documentation notes that GA4 omits UTM parameters from Landing page + query string and Page path + query string. An absence there is not proof that the redirect stripped them. Inspect the captured page location and the relevant campaign dimensions instead.

Keep a repair record someone else can reproduce

Use this compact handoff:

• Distributed link: the exact safe test URL, including any wrapper.
• Expected values: source, medium, campaign, and any other fields in scope.
• First changed hop: incoming address, status, and destination.
• Repair owner: short-link configuration, server rule, or page script.
• Retest: parameter values preserved, existing destination options intact, correct page loaded.
• Collection check: tool, test time, relevant event or report, and remaining uncertainty.

Retest the link from the original distribution point after a change. If the route crosses domains or passes through an app, include that same path in the check. Keep routing evidence separate from acquisition evidence so a passed redirect test does not become an unsupported claim about reporting.

For the wider sequence from tagged link to useful action, continue with how to measure one campaign end to end. When a campaign goes missing, find the first observable break, repair that part, and verify collection as its own step.