Referral exclusion lists
A referral-exclusion list tells an analytics tool to treat traffic from certain domains — your own site, a payment gateway, an auth provider — not as a new referral but as a continuation of the existing session. Without it, a round-trip through checkout or login can split one visit into several and credit the wrong source. This page explains the mechanism and how to use it.
What a referral-exclusion list does
When a visitor leaves your site for a third-party step — paying through a gateway, authenticating with an identity provider — and then returns, the return navigation carries that third party's domain as the referrer. By default, analytics may read this as a brand-new referral and start a new session, splitting one journey into two and crediting the gateway or auth provider instead of the original source.
A referral-exclusion list names the domains that should not be treated as referrals. Traffic returning from a listed domain continues the existing session, so the original source keeps credit and the journey stays intact.
- Payment gateways and auth providers are the classic entries
- Your own domains/subdomains belong on the list to avoid self-referrals
- Listed referrers continue the session instead of starting a new one
Using exclusions and UTM together
Audit your referral report for domains that are really part of your own flow: checkout processors, SSO/identity hosts, and any of your own hostnames that are not already grouped as internal. Add them to the exclusion list so returns do not fragment sessions.
Exclusion lists fix return-trip splitting; they do not attribute inbound campaigns. Keep using UTM parameters on the links that bring people in, and use exclusions to stop the mid-journey hops from overwriting that source. The two mechanisms are complementary.
How it appears in analytics and logs
If your top referrers include a payment processor, an auth domain, or your own hostnames, sessions are being split on return navigation. A referral-exclusion list reclassifies those returns so the original source keeps the session and the conversion.
Diagnostic use case
Stop a payment gateway, single sign-on provider, or your own subdomains from appearing as referral sources and fragmenting sessions or stealing conversion credit.
What WebmasterID can help detect
WebmasterID classifies self-referrals and known service domains so a round-trip through checkout, login, or your own subdomains does not masquerade as a new referral, keeping attribution attached to the real source.
Common mistakes
- Leaving a payment gateway off the list, so it tops the referral report and steals conversion credit.
- Forgetting your own subdomains, producing self-referrals that split sessions.
- Expecting exclusions to attribute inbound campaigns — that is the job of UTM tags.
Privacy and accuracy notes
Exclusion lists operate on domain names of referrers, not on visitor identity. WebmasterID treats referrers as coarse source signals and never as a way to re-identify a person.
Frequently asked questions
- Why is my payment processor showing as a top referral source?
- Visitors return from the processor's domain after paying, and analytics reads that return as a new referral. Add the processor's domain to your referral-exclusion list so the session continues and the original source keeps the conversion credit.
Related pages
- Self-referral and internal referrers
A self-referral happens when your own domain shows up as the referrer for a visit, which usually means a session broke and restarted mid-journey. Common causes include cross-subdomain navigation, redirect chains, and third-party payment or auth hops that return to your site. The fix is to exclude your own domains so internal navigation is not counted as a new source.
- Cross-domain referrer loss
When a journey crosses between domains you own — a marketing site to an app subdomain, or a multi-domain checkout — the original source can be lost: the second domain sees the first as the referrer (a self-referral) and the inbound campaign is overwritten. This page explains cross-domain referrer loss and how exclusion lists plus persisted UTM parameters prevent it.
- Referrer grouping into channels
Analytics platforms do not report every raw referrer separately — they map hosts into channel groups such as organic search, paid, social, referral, email, and direct. Understanding the default rules explains why a click ends up in one bucket versus another, and why a custom source can be misfiled until you adjust the grouping.
- Attribution analytics
Keep the original source attached across mid-journey domain hops.
Sources and verification notes
- MDN — Referer headerHow return navigations set a referrer that can be mistaken for a new referral.
- MDN — Document.referrer
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.