Pay Per Click
17 minute read

How to Fix Cross Domain Tracking Not Working Properly: A Step-by-Step Troubleshooting Guide

Written by

Matt Pattoli

Founder at Cometly

Follow On YouTube

Published on
March 29, 2026

Your checkout page shows 500 conversions this month. Your analytics dashboard shows 500 new sessions from direct traffic on that same checkout domain. Something doesn't add up. Those aren't new visitors landing directly on your checkout page. They're customers who started their journey on your main website, clicked through to complete their purchase, and got counted as entirely separate sessions because your cross domain tracking isn't working.

This data fragmentation creates a cascade of problems. Your conversion rates appear artificially low because sessions get split across domains. Your attribution reports credit "direct traffic" instead of the actual marketing channels that drove those purchases. Your remarketing audiences miss qualified users. And worst of all, you're making budget decisions based on incomplete data that doesn't reflect reality.

The frustrating part? Most cross domain tracking failures stem from a handful of fixable configuration issues. A missing domain in your settings. A parameter getting stripped during redirects. A tag that fires on your main site but not your subdomain. Browser privacy features blocking cookies. These problems are systematic, which means you can diagnose and fix them systematically.

This guide walks you through a proven troubleshooting process that identifies exactly where your tracking breaks down. You'll verify configurations, test parameter passing, audit your tag setup, address privacy restrictions, validate your data, and implement targeted fixes. Whether you're working with Google Analytics 4, Google Tag Manager, or third-party solutions, these steps restore accurate, unified user journeys across all your domains.

Step 1: Verify Your Current Cross Domain Configuration Settings

Start at the source. Your Google Analytics 4 property contains a specific list of domains where cross domain tracking should work. If this list is incomplete or incorrect, everything downstream fails.

Log into your Google Analytics account and navigate to Admin in the bottom left corner. Under the Property column, click Data Streams, then select your web data stream. Scroll down to Configure tag settings, then click Configure your domains under Additional Settings.

This is where Google Analytics determines which domains should share user sessions. You should see a list of all domains and subdomains where your site operates. Common configurations include your main domain (example.com), your www subdomain (www.example.com), and any checkout or application subdomains (checkout.example.com, app.example.com).

Check for these common configuration errors:

Missing domain variations: If you list example.com but not www.example.com, users moving between these variations will appear as separate sessions. Add both versions even if one redirects to the other.

Forgotten subdomains: Every subdomain where users can navigate needs to be listed explicitly. If your checkout happens on shop.example.com but that subdomain isn't configured, those sessions will break.

Typos and formatting issues: A single character mistake (exmaple.com instead of example.com) causes complete tracking failure for that domain. Double-check spelling carefully.

Incorrect regex patterns: Some implementations use regex patterns to match multiple subdomains. If your pattern is too restrictive or contains syntax errors, domains won't match correctly.

Document your current configuration in a spreadsheet. List every domain that should be tracked, then note whether it appears in your GA4 settings. This creates a clear record of what needs fixing.

Next, verify your measurement ID consistency. Open your main website in a browser and view the page source. Search for your GA4 measurement ID (it looks like G-XXXXXXXXXX). Then do the same on each subdomain or secondary domain. The measurement ID should be identical across all properties. If you see different IDs, you're sending data to separate GA4 properties, which means cross domain tracking can't work because the data never reaches the same destination. For a comprehensive walkthrough, check out our cross platform tracking setup guide.

Step 2: Test Link Decoration and Parameter Passing Between Domains

Configuration settings mean nothing if the actual mechanism for passing user identity between domains fails. Google Analytics uses a parameter called _gl that gets appended to URLs when users click from one configured domain to another. This parameter contains encrypted session information that allows GA4 to recognize the same user across domains.

Open your main website in Chrome. Right-click anywhere on the page and select Inspect to open Developer Tools. Click the Network tab at the top of the developer panel. This shows you every request your browser makes, including navigation to other pages.

Now click a link that takes you from your main domain to your secondary domain or subdomain. Watch the URL in your browser's address bar carefully. You should see a _gl parameter appear briefly, looking something like: checkout.example.com/?_gl=1*abc123*_ga*encoded_data

If you don't see this parameter, your link decoration isn't working. This could mean your cross domain configuration isn't active, your Google Tag Manager setup is incorrect, or JavaScript errors are preventing the decoration code from executing.

Pay special attention to what happens during redirects. Many sites implement security redirects or URL canonicalization that processes the URL before the page loads. If your redirect strips query parameters, the _gl parameter disappears before GA4 can read it. This is similar to issues where UTM parameters not tracking properly due to redirect stripping.

Test different link types across your site:

Standard HTML links: Click regular navigation links that cross domains. These should decorate automatically if your configuration is correct.

JavaScript-triggered navigation: Some sites use JavaScript to handle clicks instead of standard links. These require special handling in your GTM configuration to ensure decoration happens before navigation.

Form submissions: If users submit a form on domain A that posts to domain B, the form action URL needs decoration. This often requires custom GTM configuration.

Redirects and intermediary pages: If clicking a link on domain A redirects through domain B before landing on domain C, each hop needs to preserve the _gl parameter.

Use incognito mode for your testing. Regular browsing sessions have cached cookies that can mask tracking problems. Incognito mode simulates a new user without existing GA cookies, which is when cross domain tracking matters most.

Document which link types work and which fail. This tells you exactly where to focus your fixes. If standard links work but form submissions don't, you know the core configuration is fine but forms need specific attention.

Step 3: Audit Your Google Tag Manager Container Configuration

If you manage tracking through Google Tag Manager, your container configuration determines whether cross domain tracking actually functions. Even with perfect GA4 property settings, incorrect GTM setup prevents those settings from taking effect.

Log into Google Tag Manager and open the container that manages your website tracking. Navigate to Tags in the left sidebar and find your GA4 Configuration tag. This is the foundational tag that sets up Google Analytics 4 tracking across your site.

Click the tag to open its configuration. Look for a setting called "Configure your domains" or "Cross domain tracking." This should be enabled, with a list of domains identical to what you configured in GA4 itself. If this setting is disabled or the domain list is incomplete, cross domain tracking won't work regardless of your GA4 property settings.

Check the tag's triggering conditions. The GA4 Configuration tag needs to fire on every page across every domain. Look at the Triggering section at the bottom of the tag configuration. It should show "All Pages" or a custom trigger that fires on all pages across all your domains.

Here's where many implementations fail: the GA4 Configuration tag fires on the main website but not on subdomains. This happens when someone sets up GTM on the primary domain, tests it there, and forgets to implement the GTM container on secondary domains. Every domain needs the exact same GTM container code in its header. When tracking pixels not firing correctly, this is often the root cause.

View the page source on each of your domains. Search for "googletagmanager.com/gtm.js?id=" and verify you see your GTM container ID (GTM-XXXXXX). If a domain is missing the GTM code entirely, no tags will fire there, making cross domain tracking impossible.

Look for duplicate or conflicting GA4 implementations. Some sites have both a direct GA4 implementation (hardcoded in the page template) and a GTM-managed implementation. These can override each other, causing unpredictable behavior. Search your page source for your measurement ID (G-XXXXXXXXXX). It should appear only in the context of your GTM container, not as a standalone script.

Review your tag firing sequence. Tags fire in a specific order, and if your GA4 Configuration tag fires after a user navigates away, it won't have time to process cross domain parameters. Check your tag's priority settings and ensure it fires early in the page load sequence.

Use GTM's Preview mode to test in real time. Click Preview in the top right of your GTM interface, then enter your website URL. This opens your site with a debugging panel that shows exactly which tags fire, when they fire, and what data they send. Navigate from your main domain to your secondary domain while Preview mode is active. You should see the GA4 Configuration tag fire on both domains, with cross domain settings active.

Step 4: Diagnose Cookie and Browser Privacy Interference

Even with perfect configuration, browser privacy features can block the cookies that make cross domain tracking possible. Safari's Intelligent Tracking Prevention and Firefox's Enhanced Tracking Protection specifically target cross-site tracking mechanisms, which unfortunately includes legitimate analytics.

Test your cross domain tracking in Safari. Open Safari, navigate to your main website, then click through to your secondary domain. Open Safari's Web Inspector (Develop > Show Web Inspector, or enable the Develop menu in Safari Preferences first). Go to the Storage tab and look for cookies from your domains.

The _ga cookie contains your Google Analytics client ID, which identifies unique users. If this cookie exists on domain A but doesn't transfer to domain B, sessions will split. Safari's ITP limits cookie lifespan for domains it classifies as trackers, which can include your own domains if they're structured in ways Safari considers tracking-like. This is why many marketers find cookie tracking not working anymore across browsers.

Repeat this test in Firefox with Enhanced Tracking Protection enabled (it's on by default). Navigate between your domains and check if the _ga cookie persists. Firefox blocks many third-party cookies and can interfere with cross domain tracking depending on how your domains are structured.

Check your cookie consent management platform if you use one. Many sites implement cookie banners that block analytics cookies until users consent. If your consent management fires after your GA4 tag attempts to read cross domain parameters, the parameters get processed but the cookie can't be set, causing session splits.

Review your consent implementation order. Your consent management platform should initialize first, then only fire analytics tags after consent is granted. But the cross domain parameter needs to be captured immediately when the page loads, before it potentially gets lost. This creates a timing challenge that requires careful configuration.

Test in incognito mode across browsers. Incognito mode in Chrome behaves differently than private browsing in Safari or Firefox. Each browser implements privacy features differently, and your tracking might work in Chrome but fail in Safari for the same user journey.

Consider the fundamental limitation of cookie-based tracking. Browsers are increasingly aggressive about blocking cross-site cookies, and this trend will continue. Server-side tracking bypasses these browser restrictions entirely by processing tracking data on your server before sending it to analytics platforms.

Server-side implementations use first-party cookies that browsers don't block, and they process cross domain user identification on the server where browser privacy features can't interfere. If you're running into persistent browser-related tracking failures, server-side tracking may be your only reliable solution.

Step 5: Validate Data Flow in Google Analytics Reports

Configuration testing tells you what should work. Report validation tells you what actually works. Your GA4 reports reveal whether user sessions are being unified correctly or splitting across domains.

Open Google Analytics 4 and navigate to Reports > Realtime. This shows activity happening on your site right now. Open your website in another browser window and perform a test journey: start on your main domain, click through to your secondary domain, and complete a conversion if possible.

Watch the Realtime report as you navigate. You should see yourself as a single user moving between pages, with page views appearing under one session. If you see two separate users appear when you cross domains, your tracking is splitting sessions.

Check the event stream in Realtime for your session. Click on your active session to see the sequence of events. You should see page_view events from both domains appearing in chronological order under the same session. If events from domain B start a new session, cross domain tracking failed for that navigation.

Navigate to Reports > Acquisition > User acquisition. This report shows where your users originally came from. Look at the Source/Medium column and check for unusual patterns. If you see your secondary domain appearing as a traffic source (like "checkout.example.com / referral"), those are users whose sessions split when they crossed domains. Understanding attribution tracking not working patterns helps identify these issues faster.

A properly functioning cross domain setup should never show your own domains as traffic sources. Users who start on domain A and move to domain B should maintain their original source attribution (Google / CPC, Facebook / Social, etc.), not get re-attributed to domain B as the source.

Compare your user count to your session count in the Engagement > Overview report. A healthy ratio depends on your site, but if your session count is dramatically higher than your user count (like 10,000 sessions from 3,000 users), you might be splitting sessions. Each domain crossing creates a new session for the same user, inflating your session numbers.

Use the Explore section to create a path exploration. Set your starting point as a page on your main domain, and see if paths correctly show users moving to pages on your secondary domain within the same session. If the paths stop at domain boundaries, sessions are splitting there.

Check your conversion data specifically. Navigate to Reports > Monetization > Conversions (or wherever your key conversions appear). If conversions happen on domain B but users start their journey on domain A, you should see the original source attribution. If most conversions are attributed to "direct / none" or show your own domain as the source, cross domain tracking is failing at the point where conversions happen. Learn more about tracking conversions across multiple channels to improve your attribution accuracy.

Step 6: Implement and Test Your Fixes

You've identified what's broken. Now fix it systematically, testing each change individually rather than implementing everything at once. This approach lets you confirm what actually solves the problem versus what makes no difference.

Start with the simplest fixes first. If Step 1 revealed missing domains in your configuration, add them now. In GA4, go back to Admin > Data Streams > Configure your domains and add any missing entries. Save your changes and wait a few minutes for the configuration to propagate.

If you're using Google Tag Manager, make corresponding changes to your GA4 Configuration tag. Update the domain list to match your GA4 property settings exactly. Save your changes in GTM, but don't publish yet.

Use GTM Preview mode to test your changes before publishing. Click Preview, enter your website URL, and perform your test journey again. The debugging panel shows whether your updated configuration is working correctly. Look for the cross domain parameter appearing in URLs and verify that the GA4 tag fires with the correct settings on both domains.

If Preview mode shows your fixes working, publish your GTM container. Click Submit in the top right, add a version name that describes what you changed (like "Added checkout.example.com to cross domain config"), and publish.

Test again in a real browser without Preview mode active. Clear your cookies completely, open an incognito window, and perform your user journey again. Check the Realtime report in GA4 to confirm you appear as a single session crossing both domains.

Use Google Tag Assistant to validate your implementation. Install the Tag Assistant Chrome extension, navigate to your site, and start recording. Perform your cross domain journey, then stop recording and review the results. Tag Assistant highlights configuration issues, missing tags, and tracking errors. This helps diagnose cross device conversion tracking problems that may compound your cross domain issues.

Enable GA4 DebugView for deeper validation. In your GA4 Configuration tag in GTM, add a parameter called "debug_mode" and set it to "true." This sends detailed event information to the DebugView report in GA4 (Admin > DebugView). Perform your test journey and watch events appear in real time with full parameter details.

Create a documented test case that mimics your most important user journey. For example: "User clicks Google ad, lands on homepage, browses product pages, clicks 'Buy Now' which goes to checkout.example.com, completes purchase." Perform this exact journey and verify that GA4 attributes the conversion to the original Google ad, not to direct traffic or the checkout domain.

Test across multiple browsers. Your fix might work in Chrome but still fail in Safari due to ITP. Test the same journey in Safari, Firefox, and Edge. If browser-specific failures persist after configuration fixes, you're hitting browser privacy restrictions that configuration alone can't solve. For iOS-specific issues, review our guide on ad tracking not working iOS.

Document everything you changed. Create a simple record: what was broken, what you changed, what date you made the change, and how you verified it worked. This documentation becomes invaluable when tracking breaks again in the future or when you need to explain your setup to team members.

Maintaining Accurate Cross Domain Tracking Long-Term

Fixing cross domain tracking once isn't enough. Websites evolve. You launch new subdomains. You migrate to new platforms. You update your tag management setup. Each change creates new opportunities for tracking to break.

Create a monthly audit checklist that takes 15 minutes to complete. First, verify your domain configuration in GA4 still includes all active domains. New subdomains often get added to your infrastructure without anyone thinking about analytics implications. Second, perform a quick test journey from your main domain to your most important secondary domain. Third, spot-check your User Acquisition report for any of your own domains appearing as traffic sources.

This simple routine catches problems before they accumulate weeks of bad data. You'll notice immediately if a new checkout flow breaks tracking or if a platform migration removed your GTM container from a subdomain.

Consider the limitations of browser-based tracking as privacy features become more aggressive. Safari and Firefox already block many tracking mechanisms. Chrome has announced plans to phase out third-party cookies. These trends make cookie-based cross domain tracking increasingly unreliable, especially for users on privacy-focused browsers.

Server-side tracking solutions process user identification and session management on your server, where browser privacy features can't interfere. Instead of relying on JavaScript and cookies that browsers can block, server-side implementations use first-party data collection that browsers treat as legitimate site functionality rather than tracking.

Platforms like Cometly use server-side tracking to capture every touchpoint regardless of browser restrictions, giving you a complete view of the customer journey across all your domains. When cross domain tracking works, you see which campaigns actually drive revenue instead of crediting conversions to direct traffic or the wrong source. Your attribution becomes accurate. Your remarketing audiences capture qualified users. Your optimization decisions are based on complete data rather than fragments.

The difference between fragmented data and unified tracking is the difference between guessing and knowing. When you can see that a user clicked your Facebook ad, visited three blog posts, returned via Google search, and finally converted after clicking an email, you understand what drives results. When tracking breaks and those touchpoints appear as four separate users from four different sources, you're making decisions in the dark.

Ready to elevate your marketing game with precision and confidence? Discover how Cometly's AI-driven recommendations can transform your ad strategy. Get your free demo today and start capturing every touchpoint to maximize your conversions.