How to Check Whether Redirects Strip Campaign Parameters

A campaign link can contain the parameters a team expects at the start of a journey, yet a later address can lack them or contain different values. A redirect, a client-side navigation, a tracking template or an incorrectly constructed link may be involved. The first task is to find what actually changed and where; a reporting discrepancy by itself cannot identify the cause.

This guide is for marketers, analytics owners and web developers checking a landing-page or tracking change. It uses synthetic examples and a small local comparison. The sources were checked on 5 November 2026. It does not measure lost sessions, prove a traffic source, or claim that every redirect removes parameters.

Start with five checks

• Agree the route, release, browser and selected names before the test; use synthetic values.
• Observe server redirects and browser-side navigation separately, and mark unobserved stages.
• Inspect the URL available when the relevant tag executes, not just the final address bar.
• Keep missing, changed and ambiguous values separate; record the expected denominator.
• Assign a next owner and retest; do not turn one parameter comparison into an estimate of traffic or revenue.

A measurement symptom is not a diagnosis

Google's direct-traffic guidance says that redirects can strip UTM parameters. It also lists legitimate direct access and tracking interference among other reasons traffic can appear as direct. Therefore, an increase in direct traffic can justify investigation, but it cannot prove that a specific redirect is at fault. Compare the affected reporting scope and change history before deciding what to test.

Similarly, Google's clicks and sessions guide explains that a click and an analytics session are different measurements. A person can click more than once in one session, leave before a tag loads, or use a browser that limits collection. Rewrites, redirect behaviour and configuration can also matter. Do not expect the two numbers to match exactly, or multiply their difference by an average order value to estimate loss.

Ask a narrow operational question instead: “For this release, does the selected test journey retain these expected parameters until the tag needs them?” A yes is evidence about that tested journey. A no is a reason to inspect the first differing stage, not proof of a business impact.

Freeze a small, safe test contract

Write down the landing route, environment, deployment or tag-container version, browser, device, test time and selected parameter names. Identify the team that owns the link, the web route and the analytics tag. Agree which values should be present at which stage. Include a mobile journey if the live experience or tracking template differs by device, and a relevant locale if a regional redirect changes the path.

Use an approved staging environment or a specifically authorised synthetic production test. Build a made-up URL under a domain reserved for examples when demonstrating the comparison. Never click a real paid ad to perform a test: use an approved preview or a synthetic URL, according to the platform's own rules. Avoid real customer links, click IDs, personal information, session cookies, credentials and sensitive query values. Browser histories, screenshots, tickets and network traces can all retain URLs. Store only the minimum evidence in an approved location and redact it before sharing.

The parameter review worksheet gives each test a synthetic ID, a place to record unknown stages, and a named next owner. An unknown observation is not a pass.

Observe the journey one stage at a time

1. Establish the start. Save the synthetic URL that is actually supplied to the permitted test. A URL written in a campaign brief, a platform's configured final URL and the URL that opens in a browser can differ. Record which one you observed. Keep parameter names and values separate, and do not assume that URL fragments after the hash sign are query parameters.

2. Inspect server responses. For an approved test, a developer can inspect the sequence of HTTP responses and their Location headers, recording each hop. A single HEAD request, such as a basic header-only check, may not follow the same path or return the same result as a browser GET. If a command follows redirects automatically, retain enough evidence to identify each intermediate response; the final status alone hides where a parameter disappeared. Avoid logging real query strings to a shared terminal or ticket.

3. Inspect browser navigation. A page may change location through JavaScript after the server response, and a single-page application may update the address as its router starts. A command-line HTTP trace will not execute those scripts. Use a clean, authorised test profile and browser developer tools to observe the journey. Record redirects and client-side changes separately, including a route or environment in which the behaviour could not be reproduced.

4. Check tag timing. The address visible after the page settles may not be the address available when a tag executed. Use the relevant tag's approved debugging tools and implementation documentation to inspect its actual execution and inputs without overriding consent settings. The required observation depends on the tag: some implementations may capture data earlier or pass it through another configuration. A browser address and a tag's input are related evidence, not interchangeable proof.

5. Find the first observed difference. Compare the start with the first redirect, then the next response, browser navigation and tag-time observation where available. If the start and final URL differ but the middle was not observed, the location of the change remains unknown. A developer should inspect the relevant route and tracking configuration before proposing a fix. Re-run the same synthetic case after the change and keep both versions of the evidence.

Include the platform configuration

Some campaign systems assemble a landing URL from separate pieces. Microsoft Advertising's tracking documentation describes final URLs and tracking templates, including templates at several account levels and lower-level overrides. That is a Microsoft-specific configuration model; do not assume every advertising system has the same precedence. A team should document which template and final URL apply to the particular test before blaming a web redirect.

Google Ads auto-tagging and manual UTM tagging also answer configuration-specific questions. Check the current documentation and the account's actual settings rather than replacing or fabricating a click identifier in an example. This review intentionally handles ordinary selected names only; it does not validate an advertising platform's click ID or infer whether Google Analytics attributed a session correctly.

A worked comparison

Suppose one synthetic start URL carries three selected names: source is newsletter, medium is email and campaign is autumn. A separately observed final URL still has source newsletter and campaign autumn, but medium is Email. Under a case-sensitive comparison, two of the three expected names are preserved and one changed. The preserved share is 2 ÷ 3, or 66.7% rounded to one decimal.

This percentage concerns names in one pair of supplied snapshots. It says nothing about the share of visitors affected. It also does not say whether the tag read the earlier or later value. If an intermediate hop was not recorded, the team cannot identify the first cause from this example. The local comparison calculator performs this comparison without visiting either URL; its report contains names and statuses rather than URL values.

Define awkward cases before counting. In this method, an expected name appears once with a nonblank value at the start. If absent at the end it is missing. A duplicated or blank final value is ambiguous and still belongs in the expected denominator because a valid start value existed. If the start is absent, blank or duplicated, the method excludes that name from the denominator. A name added only at the end is reported as added. If no names are expected, the share is unavailable, not zero.

A small reproducible comparison

The JavaScript below compares a single selected name in two already-observed synthetic URLs. It uses the standard URL and URLSearchParams APIs available in current browsers and Node.js. Values are decoded by the parser; equality remains case-sensitive and whitespace is not removed for equality. Blank or duplicate values are ambiguous. This function does not make a network request, validate a tracking setup or inspect a tag.

function compareName(startUrl, finalUrl, name) {
  const before = new URL(startUrl).searchParams.getAll(name);
  const after = new URL(finalUrl).searchParams.getAll(name);
  if (before.length === 0) return after.length ? 'added' : 'not in start';
  if (before.length !== 1 || !before[0].trim()) return 'ambiguous start';
  if (after.length === 0) return 'missing';
  if (after.length !== 1 || !after[0].trim()) return 'ambiguous final';
  return before[0] === after[0] ? 'preserved' : 'changed';
}

const start = 'https://example.test/?utm_medium=email';
const end = 'https://example.test/?utm_medium=Email';
compareName(start, end, 'utm_medium'); // changed

Try an absent final name, a duplicate name and a value encoded as both %20 and a plus sign. URLSearchParams decodes both forms of a space in a query before comparing; a fragment is not included. The example is deliberately limited to a single name. A production tool must also validate inputs, avoid exposing sensitive values and explain its denominator. Our calculator limits the number and form of names, rejects URLs containing credentials, and outputs statuses only.

Where reviews go wrong

Comparing the wrong moments. A final browser URL can look correct after a tag already ran. Conversely, a later cleanup of the address does not by itself prove the tag missed a parameter. Record the observation point and the tag's actual timing.

Treating an ambiguous value as preserved. A query can contain the same name more than once. Different systems may choose the first value, the last value or another interpretation. This method flags duplicates for investigation rather than assuming they are equivalent. It also treats blank values as ambiguous rather than silently counting them as correct.

Ignoring the rest of the measurement system. A valid URL cannot guarantee consent, tag execution, successful network delivery, correct channel classification or a complete analytics report. Test those separate questions against the appropriate specification and privacy controls. Do not use the comparison to circumvent a visitor's choice.

Leaking test evidence. Even a screenshot can expose an account identifier or sensitive value in the address bar. Synthetic test IDs and redacted status-only notes make the handoff safer. The optional AI handoff prompt accepts names and statuses, never raw URLs; a person must verify its output. Without AI, use the worksheet to write the same facts and next action.

Close the loop

Give the web owner the first observed differing stage, the scoped synthetic case, what was not observed and the expected behaviour. Give the analytics owner a separate action to inspect the tag-time input and relevant configuration. Agree who decides on a release hold and when to retest. After a change, repeat the same route and scope; add other routes only when the owner has reason to check them. This article is AI-assisted editorial work using synthetic examples and does not claim a client implementation or personal review.