How Cross-Domain Tracking Actually Works (And Where It Breaks)
Checkout on a different domain, a partner site, a booking engine hosted elsewhere - the same visit needs to survive the jump. Here's the actual mechanism, and the three places it usually fails.
Cross-domain tracking works by appending a special linker parameter (GA4 calls it _gl) to the URL of any outbound link pointing at the second domain, then reading and consuming that parameter on the destination page to reconnect the visit to the same client identity. Cookies alone cannot do this - a cookie set on one domain is invisible to a different domain by browser design - so the parameter has to physically travel inside the link itself.
What "cross-domain" actually means
Cross-domain tracking is specifically about two or more genuinely separate domains that are part of one logical customer journey - your marketing site and a checkout hosted on a payment processor's domain, a booking engine on its own subdomain-of-a-different-company, or a franchise's national site linking into an independently-hosted local site. It's a different problem from cross-subdomain tracking (www.example.com to shop.example.com), which can be solved by widening a single cookie's scope, because those subdomains still share the same root domain under the hood.
The mechanism: passing identity through the link, not the cookie jar
Since a cookie set on domain A is never sent to domain B, the tracking library instead decorates every outbound link to domain B with a parameter carrying the client ID and a timestamped hash (GA4's _gl parameter works this way; other platforms use an equivalent linker token). When the visitor lands on domain B, that domain's own tracking script reads the parameter out of the URL, verifies the hash hasn't expired, and adopts the same client identity - producing one continuous session across both domains instead of two disconnected ones.
This is entirely a client-side handoff: nothing is sent to the analytics platform's servers to "look up" the session. If the parameter never makes it into the URL, or the destination page never reads it, the two domains simply see two unrelated visitors - not an error, just silence.
Where it breaks - the three real failure points
- Links added after page load never get decorated. Most platforms only auto-decorate links present in the DOM when the tracking script initializes. A "Continue to Checkout" button rendered dynamically by JavaScript, or a link built from a template after an API call resolves, is easy to miss unless the tracking library is explicitly told to watch for it.
- Redirect chains strip the parameter. If the outbound link passes through an intermediate redirect (a URL shortener, an affiliate-tracking redirect, an app-to-browser handoff) before landing on the second domain, and that redirect doesn't forward the full query string, the linker parameter never arrives.
- The linker's timestamp window expires. The hash attached to the parameter is time-bound specifically to prevent it from being replayed as a tracking exploit. A visitor who takes an unusually long time between clicking the link and the destination page finishing its own script initialization (a slow-loading checkout, a long OAuth-style redirect detour) can land after the window has closed, at which point the destination correctly refuses to stitch the session.
The house differentiator: how to verify it, not just configure it
Configuration screens tell you cross-domain tracking is turned on. They don't tell you it's actually working on the specific links your visitors click. Verify it directly: right-click (or inspect) the actual rendered link to the second domain and confirm the linker parameter is present in its href - not just in the platform's settings screen. Then load the destination page with that decorated URL and confirm, in DebugView or an equivalent real-time report, that the visit ID matches the one from the originating domain rather than starting fresh.
Cross-domain tracking - common questions
▸Is cross-domain tracking the same as cross-subdomain tracking?
No. Subdomains of the same root domain (www.example.com and shop.example.com) can share a cookie directly by widening its Domain attribute. Genuinely separate domains (example.com and example-checkout.com, or a hosted checkout on a payment provider’s own domain) cannot share a cookie at all - they need the linker-parameter mechanism described above.
▸Does GA4 handle cross-domain tracking automatically?
GA4 can decorate links automatically once you list the destination domains in your data stream’s "Configure your domains" setting, but automatic decoration only covers links already present when the page loads - links injected by JavaScript after the fact, or clicks handled by custom code that prevents default navigation, often need the linker logic applied manually.
▸Why does cross-domain tracking sometimes work on desktop but not mobile?
The most common cause is a redirect chain that strips query parameters on one platform but not the other - some in-app browsers and mobile checkout flows redirect through an intermediate URL that drops the linker parameter. Test the actual redirect chain per platform rather than assuming desktop behavior generalizes.
Not sure whether your own cross-domain links are actually decorated?
A data audit checks the actual rendered links and the actual session continuity, not just the settings screen.