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.
Why the source is lost at a domain boundary
Suppose a campaign lands a visitor on your marketing site, and they then move to your app on a different domain. The app domain sees the marketing domain as the referrer — a self-referral — and, by default, may treat that as a new session sourced from your own site, discarding the original campaign that brought the visitor in.
Referrer trimming compounds this: the cross-site navigation may send only the origin, and an https-to-http step can drop the referrer entirely. Either way, the inbound source rarely survives a naive domain hop, so conversions on the second domain get mis-credited to internal traffic.
- The second domain sees the first as a self-referral
- Default behaviour can overwrite the original inbound source
- Referrer trimming and https-to-http loss make it worse
Preserving attribution across domains
Two mechanisms work together. First, add every domain you own to the analytics referral-exclusion list so a hop between them continues the session rather than starting a new self-referred one. Second, persist the original UTM parameters across the boundary — carry utm_source, utm_medium, and utm_campaign onto the link or capture them at first load and re-attach them — so the inbound source travels with the visitor.
Do not rely on the referrer to bridge your domains; trimming and downgrades make it unreliable. The query string is the dependable carrier, and the exclusion list stops the boundary from resetting the source.
How it appears in analytics and logs
If a second domain you own reports the first as a top referrer, the original inbound source is being lost at the domain boundary. The hop creates a self-referral that replaces the real campaign unless you carry the source across explicitly.
Diagnostic use case
Stop the original source from being overwritten when visitors move between your own domains, so the marketing site or campaign that drove the visit keeps credit through to conversion.
What WebmasterID can help detect
WebmasterID reads UTM parameters that you persist across your domains and classifies your own hostnames as internal, so a multi-domain journey keeps its original source instead of degrading into a self-referral.
Common mistakes
- Leaving your own domains off the exclusion list, creating self-referrals.
- Not persisting UTM parameters across the domain boundary.
- Relying on the referrer to bridge domains despite trimming and downgrades.
Privacy and accuracy notes
Cross-domain handling uses domain names and your own URL parameters, not visitor identity. WebmasterID treats the source as a coarse signal and never fingerprints visitors to stitch domains together.
Related pages
- 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.
- 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.
- Referrer trimming by browsers
Modern browsers trim the referrer for privacy: the default policy sends only the origin (scheme + host) when navigating cross-site, not the full path and query. So you often see example.com rather than the specific page that linked to you. This page explains the default referrer policy, why it exists, and why UTM parameters are unaffected.
- Attribution analytics
Keep the original source across multi-domain journeys.
Sources and verification notes
- MDN — Referer headerHow cross-site navigation sets a referrer that can become a self-referral.
- MDN — Referrer-PolicyTrimming and downgrade behaviour that erodes cross-domain referrers.
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.