GA410 August 2026·9 min read

GA4 cross-domain tracking: the setup, and how to prove it works

The setting lives in the Google tag, not in GTM. The linker parameter expires after two minutes. And if you still see self-referrals, it isn't working.

DeBy Denis · Perfmetrix

Short answer: configure it in the Google tag, not in a GTM trigger — Admin → Data collection and modification → Data streams → your web stream → Configure tag settings → Configure your domains (Analytics Help, checked 10 August 2026). Then stop trusting the config screen and check your reports for self-referrals. Google's tag decorates outbound links with a _gl parameter at the moment of the click, and "Linker parameters expire after two minutes" (Google for Developers, checked 10 August 2026). If that parameter doesn't survive the hop, the destination domain starts a new session and records your own site as the traffic source. Seeing your domain in your own referral report is the failure signal, whatever the setup screen says.

The setting lives in the Google tag, not in your GTM triggers

People go looking for cross-domain measurement in Tag Manager and find nothing, because it isn't a trigger and it isn't a variable. It's a property of the tag itself.

The path is Admin → Data collection and modification → Data streams → Web → your stream → Configure tag settings → Configure your domains. Google's own settings reference lists "Configure your domains" plainly as the way to "Specify a list of domains for cross-domain measurement" (Analytics Help, checked 10 August 2026). You add match conditions — contains, begins with, exactly matches — against a domain identifier like example.com, and "Conditions are evaluated using OR logic."

One requirement does most of the damage in practice: "The tag on each page must use the same tag ID (i.e., the same 'G-' ID) from the same web data stream." Two brands, two properties, two G- IDs, one checkout flow between them — that setup cannot be stitched by this mechanism at all, and no amount of domain configuration will change it. If your two domains report into different properties, cross-domain measurement is not the feature you need; you need to decide which property is the one that counts.

The linker parameter expires after two minutes, so it only exists at the click

_gl is not written into your HTML. Google's tag listens for clicks on links pointing at domains on your list and appends the parameter at that moment — which is exactly why the expiry is short. "Linker parameters expire after two minutes, so the linker parameter is only added at the time of the click event" (Google for Developers, checked 10 August 2026).

Two things follow, and both catch people out.

You cannot hardcode it. A _gl value pasted into a campaign URL, an email template or a CMS field was dead long before anyone clicked it. The same goes for any URL a crawler cached or a user bookmarked.

You cannot introduce a long pause between decoration and arrival. The parameter is generated for a specific browser at a specific moment, and anything that parks the navigation — an interstitial, a slow consent interaction on the way out, a queued redirect — is spending the budget.

Forms are handled separately. Link decoration is automatic for links; measuring data sent between domains via forms needs decorate_forms enabled (Google for Developers, checked 10 August 2026). A checkout that POSTs to a payment domain is not covered by the same mechanism as an anchor tag.

Redirects and JavaScript navigation are what actually break it

Google documents three failure modes, and each maps onto something common enough that you should check for it by name.

Redirects strip the parameter. "If the destination page redirects or doesn't support arbitrary query parameters, the parameter _gl may end up being removed" (Analytics Help, checked 10 August 2026). Any link-shortener, click-tracking service or marketing redirect sitting between the two domains is a candidate. So is a destination that rewrites unknown query parameters away, which some checkout and booking platforms do deliberately.

JavaScript navigation isn't decorated. The tag fails "when the navigation is triggered by JavaScript as opposed to a direct response to a user action." A styled div with an onclick handler that sets window.location, a framework router pushing a full page change, a "Continue to payment" button that isn't an anchor — none of these are the click event the tag is listening for.

Something else eats the click. It fails "when competing scripts in the page stop the event propagation before it reaches the document node." Chat widgets, consent banners, analytics wrappers and A/B testing tools all attach click handlers, and any of them calling stopPropagation will silently remove the decoration from every outbound link on the page.

The common thread is that the mechanism depends on a real click reaching the document. Everything you install that intercepts clicks is a candidate for breaking it, and none of them will tell you they did.

Denied consent removes the cookie the linker exists to share

Cross-domain measurement works by sharing first-party measurement cookies between domains. If there is no cookie, there is nothing to share.

With analytics_storage set to denied, the tag will "not read or write first-party analytics cookies", and "cookieless pings will be sent to Google Analytics for future measurement" instead (Analytics Help, checked 10 August 2026). A visitor who has refused analytics storage has no persistent client ID on domain A for the linker to hand to domain B. The journey is not stitched, and that is the documented behaviour rather than a bug in your setup.

There's a second effect that Google's cross-domain page doesn't cover, because it isn't Google's to fix. Consent state is itself first-party storage. Domain B cannot read the cookie or the localStorage entry where domain A recorded the visitor's answer, so unless your CMP does its own cross-domain sync, the same person is asked twice — once on each domain — and can answer differently each time. Check what your CMP actually does here before assuming consent carries across the hop. It is a question about your consent tool, not about GA4.

Self-referrals are the test; the unwanted-referrals list is not the fix

This is the part worth writing down, because the tempting fix makes the problem invisible instead of solving it.

Google's referral logic is explicit: "Analytics will not identify traffic as referral when the referring website is a result of a cross-domain measurement setup, such as when a user navigates across domains you have configured in your domains list and the current page contains the linker parameter _gl" (Analytics Help, checked 10 August 2026). Read that backwards. If your own domain is showing up as a referral source, the _gl parameter was not on the page when it loaded. That is a direct, reliable signal, and it is more trustworthy than the configuration screen.

Now the trap. GA4 offers a setting called List unwanted referrals, in the same Configure tag settings panel, and adding your own domain to it does make the self-referral disappear. What it actually does is append ignore_referrer with a value of true to every matching event (Analytics Help, checked 10 August 2026) — the referrer stops being displayed as a traffic source. It does not join the two sessions. It does not recover the original campaign. The visitor still counts twice, the conversion still lands on a session with no acquisition source, and you have removed the only indicator that told you so.

Use the unwanted-referrals list for third parties you genuinely pass through and control — a hosted payment provider, an external booking engine — where you accept that the stitch is lost and just want the referral noise out of your channel report. Don't use it on a domain you were trying to measure across.

To verify properly: click a real link from domain A to domain B in a real browser, and look at the address bar on arrival. If _gl is in the URL, the decoration worked. If it isn't, the fault is upstream — in the click, in a redirect, or in a script that swallowed the event — and it is not something the destination can fix.

Cross-domain measurement is a first-party cookie problem before it is a configuration problem: the linker exists to carry a cookie value that has to be set, readable and unblocked at both ends. The cookie scanner loads your site in a real browser and records which cookies are actually written and when — including whether the analytics cookie exists at all before consent is answered, which is what decides if there is anything for the linker to pass.

How we test this, and what we can't tell you

We built our scanner because arguing about whether something fires is a waste of everyone's afternoon — it loads the site in a real browser and records what actually happens. One detail from that build applies directly here: every domain gets a fresh browser context, because cross-contamination between runs is a real measurement trap. It's the reason two people checking the same site in devtools come back with different answers, and it's the same discipline a cross-domain check needs. Test the hop in a clean session, not in the tab you've had open all morning with a _ga cookie already on both domains.

What we can't give you is a number. We have no measured data on how often cross-domain setups are broken in the wild — our scanner records consent and tag behaviour on a single domain, and it doesn't currently follow a journey across two. Producing an honest figure would mean scripting a real click-through between paired domains, checking for _gl on arrival, and confirming the session actually joined rather than trusting the parameter's presence. We haven't run that, so everything above is Google's documentation and the failure modes it names.

What to check this week

Open the Google tag settings and read the domain list out loud against your actual estate — including the payment, booking and support subdomains nobody remembers. Confirm both sites carry the same G- ID. Then click through the real journey and look for _gl in the address bar, because that single check settles it faster than any amount of screen-reading.

Finally, look at your referral report for your own domains before you switch anything on, and again a week after. If they're still there, the configuration didn't take, and the answer is somewhere in a redirect or a click handler rather than in GA4. Getting the click, the consent signal and the conversion to survive the whole trip is the work we do.

Sources

1.Analytics Help — [GA4] Set up cross-domain measurement · Checked 2026-08-10
2.Google for Developers — Cross-domain measurement (the two-minute linker expiry) · Checked 2026-08-10
3.Analytics Help — [GA4] Identify unwanted referrals · Checked 2026-08-10
4.Analytics Help — Configure your Google tag settings · Checked 2026-08-10
5.Analytics Help — Consent mode behaviour when analytics_storage is denied · Checked 2026-08-10