A redirect can make one perfectly ordinary customer journey look like several unrelated visits. Google gives a blunt example: without cross-domain measurement, one person moving between two root domains can be recorded as two users and two sessions. The identifier designed to prevent that split expires after just two minutes, according to Google’s Tag Platform documentation.
This matters because source data guides real decisions. If a paid campaign, partner link or email drives a sale but a redirect hides the origin, the successful channel may look unproductive while Direct or Referral traffic takes the credit. You can then cut the campaign that worked, reward the intermediary that did not, or mistake a tracking fault for growing brand demand.
The good news is that redirects do not automatically destroy attribution. Problems usually appear when a chain changes security level, applies a restrictive referrer policy, drops query parameters, or moves a visitor between separately measured domains. Once you test the full route rather than the link you originally published, these faults become manageable.
How Redirect Chains Erase Referrer Data
A redirect chain works rather like a series of connecting trains. The passenger can reach the right station while their luggage, in this case the source data, goes missing at an interchange. Each extra hop adds another policy, server, and opportunity for the journey to be altered.
When someone follows a web link, the browser may send a Referer HTTP header to the destination. Despite the misspelling in the technical name, this header is simply information about the page or origin that led to the request. An analytics tool can use it to classify a visit as referral traffic when no more specific campaign information is available.
A redirect does not always replace or erase that header. The result depends on the original link, the type of redirect, browser behaviour, security changes and the Referrer-Policy applied along the route. The MDN Referrer-Policy reference explains that the modern default, strict-origin-when-cross-origin, sends the full URL for same-origin requests, sends only the origin on a same-security cross-origin request, and sends no referrer when navigation moves from HTTPS to HTTP.
That last case is especially important. If a secure campaign link passes through an old HTTP tracking domain, the browser may suppress the referrer to protect information from leaking to a less secure connection. A link marked rel=”noreferrer” or a response using a no-referrer policy can also remove the header deliberately. Privacy is the correct priority, so the answer is not to force browsers to reveal more than users or referring sites permit.
Instead, simplify the path you control. Replace legacy HTTP redirectors with HTTPS, remove duplicate hops and point campaign links at the final canonical landing page whenever possible. A vanity URL may still be useful for print, podcasts or offline events, but it should normally perform one clean redirect rather than pass through several historical domains.
Test with the browser’s developer tools rather than relying on the address bar alone. Open the Network panel, enable Preserve log, load the campaign URL and inspect every document request in order. Record each status code, destination, security change and Referer request header so the marketing and development teams can see exactly where information changes.
Repeat that test on mobile as well as desktop if the campaign opens inside an app. An in-app browser, link shortener or partner tracking platform can behave differently from a normal browser tab. The human-first goal is simple: let people reach the correct page quickly, while collecting only the source information needed for honest measurement.
How Redirects Remove Tracking Parameters
Referrer data is useful, but manual campaign parameters give you more control. Google Analytics can read UTM values in a destination URL to identify a source, medium and campaign. Its URL builder guidance recommends using utm_source, utm_medium and utm_campaign together, with consistent capitalisation because the values are case-sensitive.
These parameters sit in the query string, the part of a URL after the question mark. A redirect rule can carry that query string to the destination, replace it with a new one or discard it completely. The redirect status code alone does not guarantee preservation, so changing a 302 to a 301 is not a tracking strategy.
Cloudflare Bulk Redirects provides a useful concrete example. Its documented preserve_query_string option is explicit and defaults to false. With preservation enabled, an incoming value such as ?utm_campaign=spring can reach the new page; without it, the campaign data disappears before the analytics tag loads.
This problem often surfaces during a migration. A team carefully maps old pages to relevant new pages, checks that visitors do not hit a 404 and confirms that search engines reach the right content. Yet a rule that sends /old-offer?utm_campaign=partner_launch to /new-offer may quietly omit everything after the question mark, leaving the visit without its manual campaign identity.
Build a repeatable test before launching any redirect campaign. Create a unique tag such as utm_source=qa, utm_medium=redirect_test and utm_campaign=redirect_audit_2026, then open the published entry URL in a clean browser session. Check that all three values remain on the final landing URL, confirm that the page loads normally and verify the source in GA4 Realtime or DebugView.
The same discipline applies when evaluating a new acquisition source. If you decide to buy bulk website traffic, isolate the test with unique UTM values, confirm that those values survive every redirect and assess engaged sessions and key events rather than celebrating a larger session total. Volume without transparent attribution and useful on-site behaviour tells you very little.
Keep a small campaign taxonomy document so everyone uses the same names. Decide whether the medium is email, paid_social, affiliate or another agreed value, and avoid variants such as Email, e-mail and newsletter for the same channel. Consistency will not repair a broken redirect, but it prevents cleanly delivered parameters from fragmenting into misleading rows.
Be careful when a redirect target already contains its own query string. Some platforms preserve the incoming string by replacing target parameters rather than merging the two, while others require a custom rule. Test the exact live URL with representative parameters instead of assuming a setting labelled preserve will combine everything safely.
How Cross-Domain Redirects Create False Referrals
A journey across several company domains can resemble leaving one shop and entering another, even when the customer sees one continuous experience. A main site, booking engine, member portal and checkout may all belong to you, but separate root domains normally hold separate first-party identifiers. Without a link between them, the measurement system can split one person into multiple users and sessions.
Google’s cross-domain measurement guidance addresses this by decorating links with a parameter named _gl. The parameter carries measurement identifiers to the next configured domain so GA4 can continue the journey as one user and one session. This should be used only for domains that genuinely form part of the same measurement boundary, not as a way to join unrelated websites.
Redirects make the setup fragile when they reject arbitrary query parameters or forward visitors without preserving them. Google specifically advises checking that gl appears on the destination URL and that any redirect keeps it intact. If the first page immediately sends the visitor to a login route, regional domain or canonical hostname and drops gl, cross-domain recognition fails before the destination can use it.
A false referral can then take credit for a conversion. Imagine a visitor arriving from a paid social campaign, browsing your main domain and moving to a separate booking platform. If the hand-off breaks, the booking platform may appear as the immediate referral when the visitor returns, while the paid social campaign loses the commercial outcome that justified its cost.
Map this route from the visitor’s point of view. List the domains, forms, payment processors, login pages and return URLs involved, then click through the complete flow with the Network log preserved. Confirm that _gl is added at the boundary, survives any redirect and is consumed by a correctly installed Google tag on the destination.
Forms deserve a separate check because not every cross-domain implementation decorates them automatically. Google’s Tag Platform documentation notes that form journeys may need explicit form decoration when gtag.js is used. Test submissions, validation errors and post-payment return links, not only ordinary anchor clicks.
GA4 also offers an unwanted-referrals list for domains such as third-party payment processors. That can stop a known intermediary from appearing as a new source, but it does not restore a lost campaign parameter or reconnect two user identities. Google’s unwanted-referrals documentation warns against applying ignore_referrer broadly because valuable source information can be lost.
Fix the journey first, then suppress only genuine intermediaries. Configure cross-domain measurement for domains you control, preserve _gl through every redirect and use referral exclusions narrowly for services that should never receive acquisition credit. This sequence keeps reporting cleaner without hiding evidence of a deeper implementation fault.
How Redirected Visits Become Direct Traffic
Direct traffic is the analytics equivalent of a parcel with no readable return address. Some of those visitors really did type your URL or use a bookmark, but the label does not prove that behaviour. GA4 defines (direct) / (none) as traffic without a clear referral source in its Direct traffic guidance.
Google lists missing UTM parameters, URL shorteners, redirects between sites, HTTPS-to-HTTP journeys, offline documents and ad blockers among the causes. That makes Direct a useful warning signal, not a tidy channel containing only loyal brand visitors. A sudden rise after a migration, domain change, checkout release or email-platform switch deserves investigation.
Do not assume that every lost-source visit will appear neatly in the same Direct row. GA4 contains user, session and event-scoped dimensions, so reports with different scopes can tell different parts of the journey. The practical question is whether identifiable campaign information reached the final page and was collected, not whether one dashboard tile moved by a particular percentage.
Start your diagnosis with a timeline. Compare the date Direct traffic changed with releases that touched redirects, consent settings, domains, payment flows or campaign tools. Then segment the increase by landing page, device, browser, country and new versus returning users to find a pattern narrow enough to test.
Next, reproduce the suspected journeys using unique UTM values. Check the full redirect chain, final query string, Referer header, _gl parameter and GA4 DebugView record. If a tag is missing from the final URL, fix the redirect; if it survives but is absent from GA4, inspect consent, tag loading and data-stream configuration instead.
Treat restored attribution as a data-quality improvement, not a way to make one channel look better. Preserve parameters that users and partners intentionally provide, but respect referrer policies, consent choices and browser privacy controls. Transparent measurement should explain real human behaviour without trying to defeat protections designed for those humans.
Finally, monitor rather than declare the job finished. Keep a small suite of tagged test URLs for your main email, paid, partner, QR and cross-domain routes, and run them after any migration or routing change. Clean source data comes from a maintained system, not a one-off dashboard clean-up.
