Roughly 30 percent of GA4 properties spanning two domains in 2026 silently split a single buyer journey into two sessions — losing the original Google or paid source on the hop — yet most teams notice only when their own domain shows up as a top referral. A journey that crosses domains is not broken traffic; it is unstitched traffic, and the fix is never to re-tag everything by reflex. It is to find the one place the link between domains breaks.
This guide follows a visitor forward across two domains through seven checkpoints — source loss, the _gl linker, Admin configuration, subdomains versus separate domains, third-party carts, referral exclusions and verification — so you fix the cause, not the symptom. To check your own setup against the most common cross-domain leaks automatically, run our free 5-axis tracking audit.
Updated 2026-05-17 with current cross-domain measurement, _gl linker and unwanted-referrals behavior observed across US, UK and European accounts.
- A domain hop resets the session unless cross-domain measurement links the two domains — 1 buyer becomes 2 users. 2. The _gl linker carries the client ID between domains and must survive in the destination URL. 3. Configure your domains in Admin under the web data stream, and put the tag on every domain. 4. Subdomains need nothing — only true separate domains need config. 5. Third-party carts strip the linker — list them and add referral exclusions to keep the source.
Why does one journey become two sessions?
Source loss is the first thing to understand because it explains every symptom below it. GA4 identifies a visitor by a client ID stored in a first-party cookie scoped to one domain. The moment a visitor crosses to a second domain, that cookie is unreadable, so the second domain mints a new client ID and starts counting from zero.
New client ID — Because the destination domain cannot read the origin domain's cookie, GA4 treats the arrival as a brand-new user. One person who clicked a Google ad, browsed your marketing site, and hopped to checkout is now logged as two users in two sessions.
Lost source — Worse than the double count, the second session records the first domain as its referrer. The original paid or organic source that earned the click is overwritten, so revenue on the checkout domain looks like it came from your own site.
Self-referral — That overwrite is exactly the self-referral pattern: your own domain climbing the traffic-acquisition report. It is the loudest signal that a domain hop is unstitched. For the dedicated playbook on clearing it, see our GA4 self-referral exclusion guide.
The goal is simple: one journey should remain one session with its original source intact, no matter how many domains it touches.
What is the _gl linker and how must it pass?
Once you accept that the cookie cannot follow the visitor, the mechanism that does is the linker. The _gl parameter is how GA4 hands the client ID from one domain to the next without relying on a shared cookie.
The linker parameter — When cross-domain measurement is configured, the Google tag appends _gl to every outbound link and form that points to a listed domain. It encodes the client ID and session context as a short-lived string in the URL.
Surviving the hop — The destination domain reads _gl on arrival and adopts the same client ID instead of minting a new one. You can confirm it visually: click through and the address bar shows a long ?_gl=1*... string for a moment. No _gl on the destination means no stitch.
What breaks it — Anything that rewrites the destination URL before GA4 reads it — a redirect that drops query parameters, a cart that sanitizes the URL, or a manual link that bypasses the tag — kills the linker. Never block or strip _gl in a firewall rule or CDN.
The linker is the entire load-bearing mechanism here, so most cross-domain debugging is really linker debugging. If you are moving to a server-side setup, our server-side GTM guide explains how the handoff changes.
How do you configure cross-domain measurement in Admin?
With the mechanism understood, the configuration is short — and it is where most fixes actually land. Cross-domain measurement is set per data stream, not per property, so you configure it on the web stream that serves both domains.
The exact path — Open Admin, pick the property, choose Data streams, click your web data stream, then Configure tag settings and Configure your domains. This is the single screen that controls the whole behavior.
Adding domains — List every domain in the journey with a match type: contains, equals, or begins with. Both example.com and examplecart.com must appear. A missing domain is the most common reason a correctly installed tag still splits sessions.
The tag requirement — Configuration is necessary but not sufficient: the Google tag must be live on every listed domain. If the destination domain has no tag, there is nothing to read the _gl parameter on arrival, so the stitch fails silently.
Save, then republish or wait for the tag to refresh before testing. If your funnel ends in a Google Ads conversion, align this with our GA4 conversion import setup so the stitched session reports correctly downstream.
Subdomains vs separate domains: which needs config?
A large share of wasted effort comes from configuring the wrong thing. The deciding question is whether the hop crosses the registrable domain or merely a subdomain of it.
Subdomains stitch free — shop.example.com and www.example.com share the same root, the same first-party cookie scope, and therefore the same client ID. GA4 keeps them in one session automatically with zero configuration. Adding them to the domain list is harmless but pointless.
Separate domains need config — The session only breaks when the registrable domain changes, for example example.com to examplecart.com, or a booking host on its own domain. That is the hop that needs cross-domain measurement and the _gl linker.
Diagnose before you configure — Read the two URLs in the journey and compare the root domain. If the root is identical, the split is not a cross-domain problem and you should look at filters, consent, or tag duplication instead.
Getting this distinction right saves hours: you stop adding subdomains that never needed it and start listing the genuinely separate domain that is actually breaking the session.
Why do third-party carts drop the linker?
Even with perfect Admin configuration, a hosted cart or checkout can still break the chain because you do not fully control how it handles the incoming URL. This is the single most common real-world failure point.
Parameter stripping — Many hosted carts, booking engines and payment pages sanitize or rewrite the inbound URL for security, dropping the _gl parameter before GA4 on that page can read it. The linker arrives but is discarded, so a new session starts.
The self-referral it creates — Because the source is lost, the checkout domain logs your own site as the referrer. The original paid click vanishes and revenue is misattributed to internal traffic.
The two-part fix — First, list the cart domain under cross-domain measurement so the linker is expected on both ends. Second, add the cart or payment host to the unwanted-referrals list so GA4 refuses to credit it as a source even if a stray hop slips through.
If the platform hard-strips parameters and offers no native GA4 setting, a server-side handoff or the platform's own connector is usually required — there is no client-side workaround when the URL is rewritten server-side. For revenue reconciliation across this gap, see our GA4 and Google Ads discrepancy guide.
How do referral exclusions interact with this?
Cross-domain measurement and referral exclusions solve two different halves of the same problem, and clean multi-domain tracking usually needs both working together.
What stitching does — Configuring your domains links the sessions and, as a side effect, treats those listed domains as internal so they are excluded from the referral source. This is GA4's automated replacement for the old manual referral-exclusion list.
What unwanted referrals do — For domains you do not control — a payment gateway, an SSO host, a redirect service — you add them to the list of internal and unwanted referrals under the data stream. This stops a known intermediary from overwriting the original source even though it is not part of your stitched journey.
Why you need both — Stitching keeps the session whole; unwanted referrals keep the credit on the true source. Configure the domains you own for stitching, and exclude the third-party hosts that should never be credited.
Get the two roles straight and the source survives end to end. The companion self-referral exclusion walkthrough covers the exact list entries for common gateways.
The cross-domain diagnostic table
Work this table top to bottom — it is ordered by how fast each cause is to confirm and how often it is the real reason a journey splits across domains.
When sessions split, the reflex is to rip out and reinstall the Google tag on both domains. That rarely helps and often introduces duplicate tags that double-count. In 9 cases out of 10 the tag is fine and the real gap is a missing domain in configuration or a _gl parameter stripped on the hop. Confirm the linker first, fix configuration second, and only touch the tag if it genuinely is not firing on a domain.
How to verify and prioritize the fix
You will usually find more than one gap. The mistake is changing several things at once so you cannot tell what worked. Verify in a fixed order and fix by impact times ease.
Check the linker first — Click through the funnel and read the destination address bar. A _gl=1*... string means the linker fired; its absence is the fastest, cheapest confirmation that the hop is unstitched. This single check resolves most cases.
Then watch real-time — Open real-time and confirm one user crosses both domains without the user count incrementing. Two users for one journey means the client ID is not passing and you should return to the linker.
Then confirm in reports — After 24 to 48 hours, check traffic acquisition still credits Google or your paid source, not your own domain. This is the only check that proves attribution, not just stitching.
Mind the limits. Real-time confirms stitching instantly, but final attribution and self-referral cleanup only settle in processed reports a day or two later, so do not declare victory on real-time alone. Build clean source tags before you scale with our UTM builder, and to surface every cross-domain leak automatically, run the SteerAds free 5-axis audit.
Sources
Official sources consulted for this guide:
-
support.google.com — cross-domain measurement
-
support.google.com — unwanted referrals
-
support.google.com — default channel group
-
support.google.com — about Analytics
FAQ
Why is my GA4 traffic splitting into two sessions across domains?
When a visitor moves from one domain to another, GA4 treats the second domain as a fresh visit unless cross-domain measurement links them. Without the link, the second domain starts a new session, assigns its own client ID, and records the first domain as the referral source. So a single buyer becomes two users and the original Google or paid source is lost. The cause is almost always one of three things: the two domains are not both listed under cross-domain configuration, the _gl linker parameter is not surviving the hop, or a third-party cart strips query parameters. Around 30 percent of multi-domain accounts in 2026 leak source this way. Fix the configuration first, then verify the linker.
What does the _gl parameter in my URL do?
The _gl parameter is the GA4 linker. When cross-domain measurement is configured, the Google tag appends _gl to outbound links and forms that point to your other listed domain. It carries the client ID and session context so the destination domain can stitch the visit to the same user instead of starting fresh. You will see it as a long string like ?_gl=1*abcd... in the address bar the instant you click through. If _gl is absent on the destination URL, the linker did not fire, the hop is not stitched, and you will get a self-referral. Never strip or block this parameter; it is the mechanism that keeps one session whole.
Do subdomains need cross-domain configuration in GA4?
No, and this is the most common over-configuration mistake. Subdomains of the same root domain — shop.example.com and www.example.com both under example.com — already share cookies and the same client ID, so GA4 keeps them in one session automatically with no setup. You only need cross-domain measurement when the registrable domain itself changes, for example from example.com to examplecart.com or a separate booking host. List a true separate domain under your data stream configuration; leave same-root subdomains alone. Adding subdomains to the domain list does no harm but solves nothing, and it distracts from the real separate-domain gap that is causing the split.
Why does my third-party checkout cause self-referrals?
Hosted carts, booking engines and payment pages often live on a separate domain and frequently strip or rewrite incoming query parameters, which drops the _gl linker before GA4 can read it. The result is a new session that records your own site as the referrer — a self-referral — and the original paid source disappears. Two fixes apply. First, list the checkout domain under cross-domain measurement so the linker is expected on both ends. Second, add the checkout domain to referral exclusions or the unwanted-referrals list so GA4 ignores it as a source. If the platform hard-strips parameters, a server-side handoff or the platform's native GA4 connector may be required.
How do I add a domain to cross-domain measurement?
Open GA4 Admin, select the property, then choose Data streams and click your web data stream. Under Configure tag settings, open Configure your domains. Add each domain that belongs to the same journey using a match type — contains, equals, begins with — so both example.com and examplecart.com are listed. Save, then republish or wait for the tag to refresh. The Google tag must be installed on every listed domain for the linker to pass. Configuration alone does nothing if the destination domain has no tag. After saving, click through the funnel and confirm the _gl parameter appears on the destination URL.
What are referral exclusions and do they still exist in GA4?
In GA4 the old Universal Analytics referral-exclusion list is largely automated: when you configure cross-domain measurement, the listed domains are treated as internal and excluded from referral source. For payment providers and other domains you do not control, GA4 uses an unwanted-referrals list under the data stream's list of internal and unwanted referrals. Add domains like your gateway or a redirect host there so they do not overwrite the original source. The distinction matters: cross-domain measurement stitches the session, while unwanted referrals stop a known intermediary from being credited as the source. You usually need both for a clean multi-domain funnel.
How do I verify cross-domain tracking is working?
Use three checks in order. First, click a link from one domain to the other and look at the destination address bar — a _gl parameter means the linker fired. Second, open GA4 real-time reports and confirm a single user moves across both domains without the user count incrementing. Third, after 24 to 48 hours, check that traffic acquisition still credits Google or your paid source rather than your own domain as a referral. If real-time shows two users for one journey, the linker is not passing. Remember the limit: real-time confirms stitching but final attribution and self-referral cleanup only settle in processed reports a day or two later.