Most B2B marketing funnels touch more than one domain. A marketing site sends visitors to an app, a checkout page, or a demo booking tool on a separate domain, and each of those boundaries is a tracking gap. Without cross-domain configuration, GA4 resets the session at every domain handoff — the client ID does not carry over, and the original acquisition source is lost. The conversion lands in Direct, regardless of whether organic search, email, or a paid campaign drove the original visit. The result is a Direct channel that converts unusually well and organic or paid channels that underperform relative to what the sales team reports. Fixing cross-domain tracking requires no code changes, only a tag configuration update, and it removes one of the most common systematic attribution errors in B2B marketing analytics.
When you need cross-domain tracking
Cross-domain tracking is necessary any time a conversion in your funnel happens on a different root domain from where the user first arrived. The most common B2B scenarios: a marketing site at yourcompany.com with demo bookings handled on a Calendly or Chili Piper subdomain, a SaaS trial signup hosted at a separate root domain from the marketing site, a checkout page hosted by a payment processor on their own domain, or a partner landing page where paid campaigns send traffic. You do not need cross-domain tracking for standard subdomains under your own root domain — blog.yourcompany.com and app.yourcompany.com share the GA4 session by default without any special linker setup, provided your GA4 tag is installed on both. Applying cross-domain configuration to subdomain relationships that do not require it introduces duplicate sessions and inflates session counts rather than fixing attribution.
How GA4 loses the session at a domain boundary
When a visitor clicks a link from your marketing domain to an external domain, the browser does not transmit the GA4 client ID to the destination. The destination page starts an entirely new session with no record of how the visitor arrived. GA4 files that session as Direct — not because the user typed the destination URL, but because no recognized referrer or client ID was received. Any conversion on the destination domain is attributed to Direct instead of the acquisition channel that initiated the journey. For B2B teams where demo requests, trial signups, or contact form submissions happen on a separate domain from the marketing site, this is a systematic undercount of every channel that drives awareness and pipeline. The broader pattern of how GA4 misattributes sessions across tracking gaps is covered in /blog/why-your-ga4-data-lies.
Setting up cross-domain tracking in GA4
GA4 resolves cross-domain attribution using a URL Linker. When a user clicks a link from your configured source domain, GA4 appends a _gl parameter to the destination URL. The destination domain's GA4 tag reads that parameter, extracts the client ID, and continues the existing session instead of starting a new one. To configure this in Google Tag Manager, open your GA4 Configuration tag, navigate to Fields to Set, and add the field linker_domains with a value listing each destination domain separated by commas — for example, app.companydomain.com,booking.thirddomain.com. Set a second field, cross_domain_measurement, to true. Publish the container update and allow a few minutes for the change to propagate to all visitors. If you deploy GA4 using the gtag.js snippet rather than GTM, add an accepts_incoming: true property to your gtag config call and include a domains array listing each destination domain. Once live, every outbound link from your marketing site to a listed destination domain will automatically carry the client ID through the URL parameter.
Verifying the configuration works
Testing cross-domain configuration requires a browser that will not interfere with the linker parameter. Open an incognito window with extensions disabled — ad blockers frequently strip the _gl parameter before the destination tag can read it, giving a false negative on a correctly configured setup. Click a link from your source domain to a destination domain and inspect the destination URL in the address bar. It should show a _gl parameter for a brief moment before the tag processes and removes it. Simultaneously, open GA4 DebugView in your property. The destination session should show the same client ID as the source session rather than appearing as a new Direct visit. If DebugView shows a new session starting on the destination side, the most common causes are a domain in the configuration that does not exactly match the actual destination URL including www handling, a redirect that fires before the _gl parameter is read, or a missing GA4 tag on the destination domain. ClimbPast's tracking health feature at /features/tracking-health automates this verification, confirming that sessions arrive correctly across each domain boundary without requiring manual DebugView monitoring after every tag update.
Common mistakes that break attribution
The most frequent error is an incomplete domain list. A team configures cross-domain tracking for their app subdomain but omits the Calendly or Chili Piper booking domain where actual conversions happen — so demo requests continue landing as Direct. Before publishing any cross-domain configuration, map every URL in the conversion flow and confirm each distinct root domain appears in the linker settings. The second common mistake is testing in a browser with ad blockers active, which strips the _gl parameter and makes a working configuration appear broken. The third is applying cross-domain settings to subdomain relationships that share a root domain and do not require them, which creates duplicate sessions instead of resolving an attribution problem. If a GA4 property has accumulated configuration layers over time and cross-domain issues are difficult to isolate, ClimbPast connects directly to GA4 and surfaces tracking gaps across the full conversion flow without requiring a manual DebugView session for each affected page. For a per-URL audit of tag behavior and session integrity after a cross-domain change, /features/tracking-health is the starting point. Teams evaluating whether cross-domain complexity is a reason to rethink their analytics approach entirely can see how ClimbPast handles attribution monitoring at /google-analytics-alternative.