Self-referrals & session fragmentation

Symptom and cause

Symptom

Your own site or your payment gateway sits in your referral report (shop.example.com "referring" www, or paypal.com / referral), and one journey is counted as two sessions at the hop.

Cause

A new session starts mid-journey: a second root domain without cross-domain measurement, a subdomain whose cookie is set on its own hostname, or a payment step that outlasts the session timeout. The new session takes the hop as its source unless that domain is on the unwanted-referrals list.

Where it's caught

Referral reports listing your own domains or a payment gateway, often converting far above the site average; landing pages that are mid-journey URLs; users and sessions both inflated on multi-domain journeys.

How one journey becomes two sessions

It is rarely the gateway's fault. The gateway is just the step where GA4 reads the return. GA4 credits a source at two levels, and the gateway can land in either.

Session reports (Traffic acquisition, Session source / medium) take a session's source once, from whatever arrives on session_start, the first hit of a visit: a referrer, UTM tags or the gclid (the Google Ads click id). A new source mid-visit does not start a new session. Inactivity does: 30 minutes by default.

Attribution reports work differently. They credit key events (GA4's name for conversions). In Google's example a tagged link arrives mid-session: the session source stays the same, and the new source is still credited as a touchpoint for the key event. A gateway return that carries its own referrer can take purchase credit the same way, without any new session.

In the session reports, the gateway or your own domain only appears when something forced a fresh session at a step in the journey. Three things do it.

A payment step longer than the timeout. The shopper leaves for PayPal, a 3-D Secure check or a banking app, stays away more than 30 minutes, and lands back on the confirmation page in a new session whose referrer is the gateway. The purchase fires in that session, so the gateway takes the sale in both kinds of report.

A second root domain without the linker. The shop runs on one domain and the checkout or booking step on another. Without cross-domain measurement the second domain never receives _gl, the URL parameter that carries the visitor's identity across, so it issues a new _ga cookie (the cookie GA4 uses to recognise a visitor). GA4 files a new user and a new session whose source is your own first domain.

A subdomain with its own cookie. Google tags write their cookies on the highest-level domain by default, so www and shop share one _ga cookie. A cookie_domain setting hard-coded to one hostname gives each subdomain its own cookie. Google names exactly this, subdomains on different cookie domains, as a cause of self-referrals.

The unwanted-referrals list covers all of these. GA4 adds ignore_referrer=true to matching events, so the gateway is not read as a source and the return counts as direct. In session reports a direct session inherits the shopper's earlier non-direct source, if there is one within the lookback window (the period GA4 looks back over for an earlier source). In attribution reports direct visits get no credit unless the whole path is direct, so the credit goes back to the earlier non-direct touches. With no earlier source, it stays (direct).

Time	Event · page	Session	Session source / medium
14:02	session_start · /product	1	google / cpc
14:03	begin_checkout · /checkout	1	google / cpc
14:04	leaves for paypal.com
14:41	session_start · /order-confirmed	2	paypal.com / referral
14:41	purchase · /order-confirmed	2	paypal.com / referral

37 minutes at the gateway, new session

How to catch it

1. The two-minute check, no developer needed. Open Reports → Acquisition → Traffic acquisition, set the primary dimension to Session source / medium and search for "referral". Set the Key events column to purchase (the dropdown on the column header) and read Session key event rate. A payment domain or one of your own domains where most sessions convert points to F-205: those sessions exist only to finish a purchase that started somewhere else. Total revenue on that row is roughly what sits under the wrong source. If the row is a payment domain, go to fix step 1. If it is your own domain, steps 4 and 5 below need whoever manages your tags.
2. Read which domains they are. Common gateway rows are paypal.com, checkout.stripe.com and klarna.com, plus the 3-D Secure page of the shopper's bank, whose hostname varies by bank. Any gateway that sends the shopper to a payment page on its own domain and back behaves the same way. Use the hostname your own report shows.
3. Open Reports → Engagement → Landing page. A confirmation page, an order-status URL or a mid-checkout step listed as a landing page means sessions are starting halfway through the journey.
4. Steps 4 and 5 need whoever manages your tags. Walk one journey with Tag Assistant connected and Admin → Data display → DebugView open: land from a tagged link, add to basket, pay with the gateway, return. One journey should produce one session_start. A second session_start on the return, or on the hop to another domain, is the split. Then, in Chrome DevTools → Application → Cookies, compare the _ga value on each domain and subdomain. A different value means the identity broke (cross-domain or cookie domain). The same value with a new session_start after a long payment step means the session timed out at the gateway.
5. Check the setting the break points to. For a second root domain: the Configure your domains screen in the same tag settings, then follow a link across and confirm _gl is on the destination URL. For subdomains: a hard-coded cookie_domain in the Google tag settings in GTM or in the gtag snippet. For gateways: the unwanted-referrals list (path in the fix, step 1).

What putting it right involves

1. In GA4 Admin, no developer needed: list the payment and verification domains as unwanted referrals under Admin → Data collection and modification → Data streams → Web → [your stream] → Configure tag settings → Show all → List unwanted referrals. In practice, a "contains" match on paypal.com covers its regional hostnames in one entry. Do the same for the stripe.com or klarna.com rows your report shows. For 3-D Secure bank pages, copy the hostname from the report. Up to 50 entries per stream. Afterwards the return reads as the shopper's earlier source, or (direct) if there was none, including on a timed-out return. If your own domain still shows as a referral after this, the break is in your tag setup (steps 2 and 3), not in GA4 settings. One limit: a timed-out return is still a second session. Only its source changes, so session counts stay split unless the payment step stays inside the timeout.
2. If checkout spans two root domains (needs whoever manages your tags): join them with cross-domain measurement (Configure your domains), then check that _gl survives every redirect on the way. Google warns that a destination that redirects or rejects unknown query parameters can drop it, and the session splits anyway.
3. If checkout spans subdomains (needs whoever manages your tags): leave the cookie domain on automatic so every subdomain shares one _ga cookie, remove any cookie_domain set to a single hostname, and tag every page with the same G- ID from the same web data stream. Google recommends cross-domain setup for subdomains too. Where self-referrals persist, its advice is to check the cookie domain settings and exclude the subdomains. In GA4 that exclusion is the unwanted-referrals list.
4. Do not set ignore_referrer on every page. Google warns against it: it suppresses source data you want. The unwanted-referrals list applies it only where the referrer matches.
5. Verify and date it. Walk the journey again: one _ga value, one session_start, the original source still on the purchase. It is not retroactive. Sessions already recorded keep the gateway as source, so annotate the date before anyone compares months.
6. Optional, and a checkout change rather than a GA4 setting: a payment step embedded on your own site removes the hop altogether. Worth weighing only if the gateway keeps taking credit after the steps above.