"My main site and my separate sign-up or checkout domain pass users back and forth, but the GA4 numbers just don't add up." This is a very common stumbling point for services that span multiple domains. Even when per-page tracking looks fine, if the user's identity is severed the moment they cross domains, your reports and your bid optimization quietly go wrong.
Does any of this sound familiar?
- Your own domain shows up as a traffic source in the referral report (a self-referral)
- It's one user, yet the session splits into two the moment they cross domains
- User and session counts come out inflated — higher than they feel
- Sign-up or checkout conversions don't attach to the campaign that brought the visitor in
This guide organizes how GA4 cross-domain tracking breaks, how to verify it using the _gl linker parameter and DebugView, the blind spots that get missed, and how to think about verifying it in production.
What cross-domain tracking actually is
GA4 tells users apart with an identifier called the client_id, normally stored in that domain's cookie. Here's the trap: cookies aren't shared across domains. So when a user moves from site.com to checkout.othersite.com, the destination re-counts the same person as a brand-new user.
Cross-domain tracking prevents this. When you configure your domains, GA4 automatically appends a linker parameter — _gl= — to the URL on link navigation, carrying the client_id across. Without that configuration, the hand-off never happens.
| State | What happens | Typical symptom |
|---|---|---|
| Configured (healthy) | _gl= is appended to the URL; client_id carries over |
Continues as the same user, same session |
| Not configured (broken) | client_id doesn't carry; reassigned on the destination | Session fragmentation, self-referral, inflated counts |
| No referral exclusion | Payment gateways etc. get logged as a traffic source | Self-referral breaks attribution |
The key point: "the tag fires on each domain" and "the same person is recognized across domains" are two different things. Most checks stop at the former. Confirming the GA4 tag itself fires is covered in how to verify your GA4 tag is working, but this article is about what comes next — whether the hand-off happens.
Subdomains vs. cross-domain: a common source of confusion
Before diving into causes, it's worth clearing up a point that trips up many teams: subdomains and cross-domain are not the same thing, and GA4 handles them differently.
If your user journey stays within subdomains of the same parent domain — for example, www.yoursite.com to blog.yoursite.com to shop.yoursite.com — GA4 handles this automatically. The _ga cookie is set on the parent domain (.yoursite.com), so it's accessible to all subdomains without any extra configuration.
Cross-domain tracking is only needed when users move between entirely different domains — for example, yoursite.com to checkout.otherdomain.com. These are separate cookie jars, and that's where the _gl linker parameter comes in.
| Scenario | Configuration needed? |
|---|---|
www.yoursite.com → blog.yoursite.com |
No — GA4 handles subdomains automatically |
yoursite.com → checkout.otherdomain.com |
Yes — cross-domain tracking must be configured |
yoursite.com → payment.stripe.com (third-party) |
Referral exclusion only (you can't install your tag on a domain you don't own) |
Common pitfall: setting up cross-domain tracking between your own subdomains when it isn't needed. This can actually introduce unnecessary
_glparameters and even cause issues. If both pages share the same parent domain, just make sure the same GA4 tag is installed on both — no domain configuration is required.
Cause 1: "Configure your domains" is not set
The most common cause. In the GA4 admin, under "Data Streams → Configure tag settings → Configure your domains," you must register every domain users move between. If the destination domain isn't listed, GA4 won't append the linker parameter and the client_id won't carry over.
What to check: whether every relevant domain is registered, with no gaps. Watch for subdomain variants (www vs no www, shop., and so on).
Common pitfall: assuming "I put the same measurement ID on both domains, so I'm covered." Installing the tag and configuring your domains are two separate tasks. The tag can be present, but without domain configuration the hand-off still won't happen.
Cause 2: _gl= isn't being appended to the URL
Whether the hand-off is actually working is visible in the URL after navigation. Right after a link takes you from site.com to checkout.othersite.com, if the address bar shows a long string starting with _gl=, the hand-off is functioning. If it's absent, it's breaking somewhere.
What to check: click the cross-domain link for real and see whether _gl= appears on the destination URL. If it doesn't, suspect Cause 1 (a missing domain) or the way the link is implemented (below).
Common pitfall: if you navigate by rewriting
window.locationin JavaScript, or route through a form submission or a redirect,_glcan be dropped instead of appended and preserved. "A plain<a>link carries it, but going through a button doesn't" is a classic pattern.
Cause 3: Referral exclusion (self-referral) isn't set
When you route through a payment processor, cart, or external form, that domain can get logged in GA4 as a traffic source (referral). Then checkout.othersite.com or the payment gateway — rather than your real acquisition campaign — gets treated as "the last source before the conversion," and attribution breaks. This is a self-referral.
Setting up cross-domain tracking correctly resolves most of it, but when you pass through a domain you don't own (like a payment gateway), you additionally need to add that domain to GA4's "unwanted referrals / referral exclusion" list. For how ad-click IDs carry through, see how gclid and click IDs work.
Common pitfall: seeing your own domain or a payment domain listed in the referral report and cheering "we're getting traffic." That may not be new acquisition — it can be a sign that the same user dropping out and being re-counted is inflating the numbers.
Cause 4: Cookie consent (CMP) blocks the destination
Even when the _gl parameter arrives correctly on the destination URL, the hand-off can still fail silently if the user's cookie consent state prevents GA4 from writing a cookie on the destination domain. This is increasingly common with Consent Mode v2 and stricter CMP (Consent Management Platform) enforcement.
Here's how it breaks: a visitor accepts cookies on site.com and navigates to checkout.othersite.com. The _gl parameter carries over, but the consent banner on checkout.othersite.com hasn't been accepted yet — or uses a different CMP that doesn't share consent state. GA4 on the destination sees "no consent" and either fires in cookieless mode or doesn't fire at all. Result: the client_id from _gl is ignored, and the session splits.
What to check: whether your CMP shares consent state across your domains. Many CMPs support cross-domain consent sharing, but it must be explicitly configured. Also verify that Consent Mode's analytics_storage parameter is granted on all domains before assuming the hand-off works.
Common pitfall: testing cross-domain tracking on your own machine where you've already accepted cookies on both domains, then concluding "it works." Real visitors hitting the destination for the first time face the consent banner, and if consent isn't granted or carried over, the hand-off drops — even with a perfectly formed
_glin the URL.
Cause 5: Safari ITP and browser privacy restrictions
Safari's Intelligent Tracking Prevention (ITP) imposes a 7-day expiration cap on first-party cookies set via JavaScript — including GA4's _ga cookie. If a user doesn't return within 7 days, their client_id is gone, and they're counted as a new user on their next visit. For cross-domain tracking, the impact compounds.
Even when _gl successfully carries the client_id to the destination domain, Safari may have already expired the original cookie. And on the destination side, the newly written cookie will also be subject to the same 7-day cap. The result: multi-session journeys that span domains are especially fragile on Safari, which represents 25-35% of web traffic in many markets (and more on mobile).
Other browsers are following suit. Firefox's Enhanced Tracking Protection and Brave's built-in blocking can interfere similarly, though through different mechanisms.
What to check: whether your cross-domain tracking holds up in Safari specifically. Test the full journey in a Safari private window (where ITP is strictest) and compare the client_id behavior to Chrome.
Common pitfall: only testing in Chrome, where cookie restrictions are minimal, and assuming the results apply everywhere. Safari users — often a large share of mobile traffic — may be silently fragmenting your sessions and inflating your user counts without any visible error in your reports.
How to verify: check three things together
Whether cross-domain tracking is alive comes down to these three checks, used together.
_gl=on the destination URL: click the cross-domain link and see whether the linker parameter appears on the destination URL.- client_id in DebugView: in GA4 DebugView, operate both domains in sequence and confirm the same
client_idis used. If it's reassigned, the hand-off failed. - Referral report: check whether your own domain or the payment domain appears as a traffic source in the source/medium report. If it does, a self-referral is happening.
Only when all three line up can you say "the same person is being tracked across domains." To separate this from whether the conversion itself was recorded, also see why a conversion fires but isn't recorded. If the broader problem is zero conversions in Google Ads, see No Conversions in Google Ads? A Step-by-Step Diagnostic Guide for the full diagnostic flow.
What checking on your own machine can't tell you
All three checks above are useful, but verifying once on your own machine has two structural limits.
- Your environment isn't your visitors' environment. Login state, browser extensions, cookie settings, office-IP exclusion and the like mean
_glcan look present on your machine yet the hand-off drops under real visitor conditions (a different browser, tracking protection, consent state). - Paths that involve an ad click are hard to reproduce. To truly confirm "when someone arrives via an ad and crosses domains, does it still attach to the acquisition campaign," you'd need to click a live ad to recreate the path — which carries the risk of an ad-policy violation as a self-click.
Judging "_gl is present, so it's fine" on your own machine tends to miss the problem of the hand-off dropping on the real path your visitors take.
Verification checklist
- Are all domains users move between registered under GA4's "Configure your domains"?
- Any missed subdomain variants (
wwwvs nowww, etc.)? - Does
_gl=appear on the URL after a cross-domain navigation? - Is
_glpreserved even through buttons, forms, and redirects? - In DebugView, is the
client_ididentical across both domains? - Does your own domain or the payment domain show up in the referral report?
- Have you added third-party domains (payment gateways, etc.) to the referral exclusion list?
- Does your CMP share consent state across all domains, so GA4 has permission to write cookies on the destination?
- Have you tested the full journey in Safari (where ITP caps cookies at 7 days)?
- Does the hand-off hold under real production user conditions (not just your one test)?
Frequently asked questions
Q. If I put the same GA4 tag on both domains, is that cross-domain tracking? A. No. On top of installing the tag, you must register the domains under GA4's "Configure your domains." Installation and configuration are separate tasks.
Q. What does the _gl parameter do?
A. It's GA4's linker parameter. It's automatically appended to the URL on cross-domain link navigation and carries identifying information such as the client_id to the destination. Without it, the destination re-counts the visitor as a new user.
Q. What is a self-referral? A. It's when your own other domain, or a payment domain, gets recorded in GA4 as a "traffic source (referral)." Caused by missing cross-domain configuration or a missing referral exclusion, it shifts attribution away from your real acquisition source.
Q. I use an external payment gateway. What should I set? A. Register the domains you own under "Configure your domains," and add the payment-gateway domain you don't own to GA4's referral exclusion list. Do both together.
Q. Do I need cross-domain tracking for subdomains?
A. No. GA4 handles subdomains of the same parent domain (e.g., www.yoursite.com and shop.yoursite.com) automatically, because the cookie is set on the parent domain. Cross-domain configuration is only needed when users move between entirely different domains.
Q. Can cookie consent banners break cross-domain tracking?
A. Yes. If your CMP doesn't share consent state across domains, GA4 on the destination may not have permission to write cookies — even if the _gl parameter arrived correctly. Make sure your consent management is configured for cross-domain consent sharing.
Q. Does Safari affect cross-domain tracking differently?
A. Yes. Safari's ITP caps JavaScript-set cookies (including GA4's _ga cookie) at 7 days of inactivity. This means returning Safari users are often counted as new, and multi-session cross-domain journeys are especially fragile. Server-side cookie setting can mitigate this.
Q. My user count is higher than it feels — is cross-domain the cause?
A. It may be. When the hand-off drops, the same user is reassigned as new on the destination, inflating user and session counts. Check in DebugView whether the client_id carries over.
Conclusion: don't stop at firing — verify the hand-off
Verifying cross-domain tracking takes more than checking that the tag fires on each domain. What matters is what comes next — whether identity carries across domains as the same user, and whether the client_id is preserved on the real path your visitors take in production. For the bigger picture, see the complete guide to GA4 conversion tracking.
ConversionOK runs your live page in an independent, isolated browser and intercepts the events and client_id actually sent, then verifies them — with no need to click your own ad and no interference from your office environment. Start with a free static check to confirm the entry point of your measurement.