Cross-domain measurement, and how it silently fails

A visitor clicks a paid ad, lands on your site, and moves to a booking platform on a different domain. Without cross-domain measurement, GA4 sees the second domain as a fresh arrival referred by the first, so it starts a new session with a referral source. Google explains what begins and ends one under about Analytics sessions.

The consequence is not a missing session, it is a misattributed conversion. The booking that happens on the second domain is credited to a referral from your own site rather than to the paid click that paid for it. Every channel report is then wrong in the same direction: paid too low, referral too high.

That is why this failure is expensive out of proportion to its difficulty. Nothing is missing, so nothing alerts, and the report is internally consistent. It just describes a customer journey that did not happen.

It is one of the six recurring failures listed in the GA4 events that break without telling you, and the one most likely to be diagnosed as a bidding problem rather than a measurement one.

GA4 adds an event listener on the document node of the page. When a visitor clicks a link to a configured domain, the click event bubbles up to the document, and a parameter named _gl is appended to the destination URL. The destination page reads that parameter and continues the same session and the same identifiers.

Google documents this directly in setting up cross-domain measurement, including that you configure the domains under the tag settings for a web data stream and can create up to 100 conditions.

That description contains the entire failure surface. If the click does not bubble to the document node, the parameter is never added. If the destination strips the query string, the parameter is added and thrown away. Neither produces an error.

There is a manual path for cases the interface cannot cover. Google shows using the gtag get and set commands to retrieve the client identifier and session identifier on the source domain, carry them in the link, and set them on the destination, and describes the interface approach as the recommended one.

Google names the first three explicitly in its troubleshooting guidance, including that the parameter may end up removed from the URL if the destination page redirects or does not support arbitrary query parameters, and that this usually happens too quickly to observe by eye.

The stopPropagation case is the one that produces the maddening pattern where some links work and some do not. It is a component-level defect, so it tracks with a UI component rather than with a page, and it will reappear the next time that component is reused.

The last row deserves its own mention because it inverts the diagnosis. If the second domain has no Google tag at all, or has a different measurement ID, the linker parameter arrives and there is nothing there to read it. Verify the tag on both sides before debugging the link.

Google's verification procedure is short enough to run by hand and is the right first step. Open a page containing a link to the configured domain, click it, and check that the destination URL contains _gl. The documented form looks like a question mark followed by _gl=1 and a string of characters.

Do this for every crossing rather than one. The whole class of defect is conditional, so a working home page link proves nothing about the button in the pricing table or the form action in the booking widget.

If you cannot see the parameter, Google's first suggestion is the boring one and it is right: check that the domain you configured matches the domain the site actually points to. A configuration for example.com does not cover book.example.net.

For the redirect case, the parameter is present for an instant and then gone, so the browser address bar will not show it. Google points to the network requests view in developer tools, which shows the intermediate request carrying the parameter before the redirect discarded it.

Google also flags a downloads check that is easy to skip: navigate to a page carrying the linker parameter and start a download, then confirm the download still begins. A server that rejects unexpected query parameters can break a file response, which is a real defect introduced by measurement rather than by the site.

These two settings get confused constantly, and using the wrong one produces a report that is quietly wrong instead of obviously wrong.

Cross-domain measurement continues a session across domains you control, preserving the original traffic source. A referral exclusion, which GA4 now presents as unwanted referrals, does something narrower: it tells Analytics not to treat a domain as a traffic source at all.

Use cross-domain measurement for your own booking subdomain or your own second brand. Use unwanted referrals for a third-party payment processor you do not control and cannot tag. The distinction, and the reason the wrong choice still leaves attribution broken, is worked through in payment gateways that break your session data.

Google's own documentation joins them at one point worth knowing: Analytics does not identify traffic as a referral when the navigation is the result of a cross-domain measurement setup and the current page carries the linker parameter. So a working cross-domain setup already suppresses the self-referral, and adding an exclusion on top of it is usually a sign the first one is not working.

This configuration decays, because it depends on things other teams change. A new checkout provider, a marketing site rebuilt in a framework that navigates programmatically, a CDN rule tightened to strip unknown query parameters: any of them turns it off without touching Analytics.

So verification belongs on a schedule rather than in a launch checklist. A weekly assertion that sessions crossing the boundary retain their source is the kind of check described in automated QA for tracking, and it catches this in days rather than quarters.

It is also worth deciding the domain architecture deliberately in the first place, because a booking flow on a subdomain of your own site avoids the problem entirely while a booking flow on a vendor domain guarantees it. That trade-off belongs in property and data stream design.

And when the numbers still disagree after the crossing is fixed, separate the structural gap from the defect before anyone changes a budget. That is the whole argument in why your Google Ads and GA4 conversion numbers do not match, and it is why proving the paths, rather than shipping the container, is the deliverable in GA4 and Tag Manager implementation.