GA4 self-referrals and rogue referral traffic: the fix

TL;DR

When GA4's Referral channel is full of things that aren't real referrers — your own domain, a payment gateway (Stripe, PayPal), a booking or auth tool (Calendly, Auth0) — your attribution is quietly broken: each hop to one of those domains and back ends the original session and starts a new one credited to the wrong source, so the conversion gets attributed to "Stripe" instead of the Google Ads click that paid for it. The fix is two GA4 settings most setups never touch: configure cross-domain measurement for domains you own, and add third-party hops to the unwanted referrals list so they resolve to Direct instead of stealing credit. Below: how to spot it, and exactly what to change.

---

A client's checkout converts well, but in GA4 a suspicious share of revenue is attributed to a Referral from checkout.stripe.com or even the client's own domain. The optimisation team starts wondering whether they should "invest more in the Stripe channel." They shouldn't — Stripe isn't a channel, it's a leak in the session, and it's siphoning credit away from the paid and organic sources that actually drove the conversion.

Why a payment gateway becomes a "source"

GA4 attributes a session to wherever it began. When a user goes yoursite.com → checkout.stripe.com → yoursite.com/thank-you, that round trip — if GA4 isn't told the domains belong together — looks like three things: the original session, then a new session that started with a referrer of stripe.com, and the conversion fires inside that second session. So GA4 credits Stripe with the purchase. The same thing happens with:

• Your own domains/subdomains (www ↔ app ↔ shop, or a separate booking subdomain) — a self-referral.
• Auth providers (Google/Auth0/Okta login redirects).
• Booking/scheduling (Calendly, Acuity) and third-party carts/checkouts.

Every one of them ends one session and starts another with the wrong source. It's one of the quieter ways traffic also ends up mis-bucketed entirely — a cousin of the Unassigned problem, but here the traffic isn't missing, it's mislabelled, which is worse because it looks like real insight.

How to spot it (2 minutes)

In Reports → Acquisition → Traffic acquisition, set the dimension to Session source / medium and scan the referral rows. Red flags:

• Your own domain (or any subdomain you control) appears as a source.
• A payment, auth, or booking domain (stripe.com, paypal.com, accounts.google.com, calendly.com) appears — especially with conversions attached.
• A spike in Referral conversions that doesn't match any real partnership or backlink.

If you see your own domain in there, you have a cross-domain/self-referral problem, full stop.

Fix 1: cross-domain measurement (for domains you own)

If the journey legitimately spans multiple domains you control (brand.com → shop.brand.com, or a separate app domain), tell GA4 they're one site. In Admin → Data streams → your web stream → Configure tag settings → Configure your domains, list every domain in the journey. GA4 then carries its linker parameter across the hop, so the session — and its original source — survives the domain change instead of restarting. This is the same cross-domain config that, left undone, is a standing item on the GA4 audit.

Subdomains of the same domain (www.brand.com ↔ app.brand.com) share cookies and usually don't need this — but they do commonly need Fix 2 if a redirect makes them look like referrers.

Fix 2: the unwanted referrals list (for third parties you don't own)

For domains you don't own — payment gateways, auth, booking — you can't cross-domain them. Instead, tell GA4 to not treat them as a referral. In the same Configure tag settings, open List unwanted referrals and add the domains (stripe.com, paypal.com, checkout.*, your auth provider, etc.). GA4 then ignores that referrer: the user returns and the session continues attributed to its original source — or, worst case, falls to Direct instead of stealing credit as a fake Referral.

This is the single highest-leverage setting for ecommerce and booking funnels, and almost no inherited GA4 property has it configured.

Fix 3: confirm it worked

Settings like these apply going forward, not retroactively, so verify with fresh traffic:

• Run a test purchase / booking and watch GA4 DebugView — the conversion should now attribute to your test session's real source, not to the gateway.
• A week later, re-check the Referral rows: the payment/auth/own-domain entries should be gone or near-zero.

What about referral spam?

Classic bot referral spam (free-traffic.example, fake referrers) is far rarer in GA4 than it was in Universal Analytics, because GA4 only records events from your actual tag — but it still appears. The unwanted-referrals list handles named offenders; for volume, rely on GA4's bot filtering (on by default) and, if needed, a data filter. Don't confuse spam (junk you want gone) with self-referrals (real traffic that's mis-sourced) — the second is the one quietly costing you attribution.

The pattern, again

Self-referrals are the same failure mode as every other tracking bug we write about: GA4 doesn't error, it just files the data confidently under the wrong label, and a "Stripe channel" looks plausible enough that someone might act on it. The only defence is to look — and to look on a schedule, not when a number finally seems off. It's why the fix belongs in a week-one audit on every client and why trusting the dashboard without verifying is the core mistake.

That's what Phloz is for: every client's GA4 config — cross-domain, referral exclusions, channel rules — modeled and health-checked as part of the tracking-infrastructure map, so "is this client leaking attribution to Stripe?" is a thing you can see, not a thing you discover after a quarter of bad reports. The CRM for SEO agencies and pricing pages cover the workflow; the two settings above cost nothing and fix most of it — go check the Referral rows for your own domain first.