Attribution lost in transit
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.
| Channel, as GA4 files it | Sessions | Conv. |
|---|---|---|
| (direct) / (none) | 4,812 | 286 |
| organic search | 2,310 | 61 |
| payments.████.com (referral) | 1,940 | 173 |
| 540 | 12 | |
| google / cpc | 212 | 4 |
How to catch it
- 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).
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- 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.
- 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).
- 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.
Sources on file
Cited in these case files
F-204 turns up as evidence across the archive. It is cited in:
- FIELD NOTE Consent Mode v2 didn't lose your conversions. Your tags did The mirror case on the consent side: modelling recovers most of what Consent Mode v2 mis-gates from the cookieless denial pings plus consented-user behaviour and volume. F-204 is a separate, deterministic loss of the click id, not something that starves that modelling.
- VERDICT You don't need server-side tracking Where the verdict lands on "it depends". Server-side becomes the F-204 backstop precisely when a redirect cannot be made to preserve the client-side gclid.
- RECONCILIATION Reconciliation No. 01 — what moved this period Safari's 24-hour cookie cap returns visitors without a GA4 cookie; they count as new sessions with no prior source, drifting conversions toward (direct). Same loss, different cause.
- SYMPTOM Direct traffic jumped after the redesign A redesign broke cross-domain linking; referrer data vanished mid-redirect and GA4 relabelled paid traffic as (direct). The textbook trigger for F-204.
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.