TRACKING SPECIALIST — BARIS ASA · LONDON
Synctag
Start the check → TRACKING SPECIALIST — BARIS ASA · LONDON
F-204
F-204 · SIGNAL LOST IN TRANSIT · FILED 2026 · REVISED 15 JUN 2026 · FREQ ▮▮▮▮▯

Attribution lost in transit

Also filed as “(direct) / (none) traffic in GA4”“payment processor showing as a top referral”“paid clicks attributed to direct”“gclid stripped after a redirect”

Attribution lost in transit is the loss of campaign identity (the UTM parameters, the gclid, or session continuity) somewhere between the ad click and the conversion. The visit and the sale are real; only the credit goes missing, so GA4 files paid traffic as (direct) or hands it to a payment domain.

Symptom and cause

Symptom
Traffic that clearly drove sales piling up under "direct / none", or your own payment processor sitting in the top referrals. Real channels get no credit.
Cause
Campaign parameters or the Google click id (gclid) stripped by a redirect; a cross-domain step running without GA4's linker, so the session restarts; or a payment provider's return trip overwriting the original source.
Where it's caught
A suspiciously large "direct" channel, or a checkout/payment domain showing up as a top referral; sessions arriving from ad platforms with no campaign attached.

How the signal gets lost

When a user follows a tracked link, the browser carries the UTMs or gclid and GA4's _gl linker parameter carries the session across a domain boundary. If a redirect along the way (a payment hop, a CDN edge, a marketing platform) drops the query string the _gl parameter rides on, GA4 gets a request with no campaign data and no referrer, and defaults it to (direct) / (none). If instead the round-trip returns with a referrer of its own, GA4 credits that payment or checkout domain rather than the source that earned the visit. Either way the visit is real and the source is lost.

GA4 · Traffic acquisition · sessions · reconstructed · client data anonymised
(direct) / (none) ↑ swells with checkout volume
organic search
payments.████.com (referral) the round-trip, credited as source
email
google / cpc the paid clicks that actually drove it
Channel, as GA4 files itSessionsConv.
(direct) / (none)4,812286
organic search2,31061
payments.████.com (referral)1,940173
email54012
google / cpc2124

How to catch it

  1. In GA4 DebugView, click a real paid ad, enter the checkout or payment flow, and come back. Watch whether the gclid and utm_* parameters vanish mid-journey, or the session restarts (a new session_start).
  2. In Traffic acquisition, look for a (direct) / (none) channel that swells in step with checkout or payment volume. Direct traffic should not scale with paid spend.
  3. Check Admin → Data streams → [select your web stream] → Configure tag settings → Configure your domains, and confirm every domain in the checkout and payment flow is listed for cross-domain measurement.
  4. In DevTools → Network, switch on Preserve log first so entries survive each redirect. Open a product from an ad, then on the request that crosses to the checkout or payment domain, confirm gtag appended a _gl= parameter, and confirm utm_* and gclid are still present on the thank-you URL after the round-trip.
  5. In Admin → Data streams → [select your web stream] → Configure tag settings → Show all → List unwanted referrals, confirm the payment provider domain and any internal redirect domain are excluded.
  6. In Google Ads, confirm auto-tagging is on at the account level (Admin → Account settings → Auto-tagging), then separately confirm the gclid it appends to the landing URL is not dropped by a downstream redirect or checkout system.

What putting it right involves

  1. Preserve the parameters across every redirect: re-append utm_source, utm_medium, utm_campaign and the gclid to each redirect target, or wrap redirects so they carry the original query string through.
  2. Enable and test GA4 cross-domain measurement: add every payment, checkout and marketing redirect domain to the web stream, then confirm the _gl linker parameter is appended at the boundary and read back on return.
  3. Configure the unwanted-referrals list so a return trip from the payment provider, CDN or internal checkout domain is not recorded as the source, and GA4 carries the prior source forward instead. The new session itself is prevented by keeping _gl continuity across the hop (steps 1 and 2), not by this list.
  4. Add a backstop at the conversion layer (browser-side or server-side). For Google Ads: recover the match with Enhanced Conversions (hashed first-party data sent with the conversion, for visitors who allowed ad_user_data), and where you captured the gclid before the strip, an Offline Conversion Import keyed on that gclid. For Meta: send the event via the Conversion API, matched on the fbc/fbclid click id or hashed first-party data (Meta CAPI does not use the gclid). Note the scope: these reattach credit at the Ads or Meta layer (event and user scoped). They do not repair GA4's session-scoped source/medium, so the (direct) / (none) line in Traffic acquisition is only fixed by preserving the referrer and _gl across the redirect (steps 1 and 2).
  5. Verify it end to end in DebugView: trace one journey from ad click to conversion and confirm a single session id survives the whole path with its campaign parameters intact.
How I'd fix this

Sources on file

Cited in these case files

F-204 turns up as evidence across the archive. It is cited in:

Questions on this file

How do I tell F-204 (lost in redirects) apart from F-201 (consent mode)?

Compare regions. F-201 is region-skewed: it hits EU and UK visitors after a consent banner ships and barely touches non-consent regions. F-204 is geographically uniform: it hits all regions equally because the redirect or payment flow is global. The deciding tell: in DebugView, does the gclid or utm_source disappear mid-flow, before any consent decision? If yes, it is F-204. If the hit never fires, or fires stripped of the consent signals Ads needs to match it, it is F-201.

Why does my payment provider show up as a top referral?

The provider returns to your site with its own domain in the Referer header, so GA4 reads it as the source and credits it. Add that domain under Admin → Data streams → [select your web stream] → Configure tag settings → Show all → List unwanted referrals. GA4 then ignores it and carries the prior source forward instead.

Is server-side tracking a fix for F-204?

It is a backstop, not a fix. Enhanced Conversions reattaches the match from hashed first-party data captured at the conversion, independent of the stripped gclid; an Offline Conversion Import instead needs the original gclid, captured before the redirect stripped it. Meta's Conversion API can match on the click id or, like EC, on hashed first-party data. All of them only reattach credit at the Ads or Meta layer, not GA4's own channel report. Fix the redirect first (preserve the parameters, keep the _gl linker) so the browser signal survives. Server-side is insurance on top, not a substitute.

What is the _gl linker, and why does it matter across redirects?

The _gl parameter is a short string GA4 appends to links that cross a domain boundary, to checkout or a payment provider. It carries the GA client id (the _ga / _ga_<ID> cookie values) so the destination keeps the same identity. That destination has to pass _gl back on return so GA4 reads the journey as one session. Without it, GA4 sees a new domain, starts a fresh session, and the original attribution is gone.