Cross-Domain Tracking: How to Fix Broken User Sessions

If your business spans multiple domains — a main site on one domain, a shop on another, a booking system on a third — you’ve probably noticed broken analytics data. Visitors appear to “arrive” from your own site. Sessions split in half. Conversion attribution falls apart. Cross-domain tracking fixes this by maintaining a single user session across multiple domains.

In this guide, I’ll explain why cross-domain sessions break, how to fix them, and how to verify your setup actually works. This pairs with my conversion tracking guide — if tracking basics are new to you, start there.

Why Sessions Break Across Domains

Analytics tools identify visitors using cookies. Cookies are domain-specific — a cookie set on yoursite.com isn’t visible to shop.yoursite.com (subdomain) or yourshop.com (different domain).

When a visitor moves from your main site to your shop on a different domain, the analytics tool sees two separate visitors. The referral source for the shop visit becomes “yoursite.com” instead of the original Google search or ad click that brought the visitor in the first place.

The consequences are real:

• Inflated visitor counts — one person counted as two or three visitors
• Self-referrals — your own domains appearing as top traffic sources
• Broken attribution — the original campaign, keyword, or ad that drove the visit is lost at the domain boundary
• Inaccurate funnels — funnel analysis can’t span across domains without proper linking

When You Need Cross-Domain Tracking

Not every multi-domain setup needs cross-domain tracking. Here’s when you do and don’t need it:

You need it when:

• Your checkout is on a different domain (e.g., Shopify hosted checkout)
• You use a third-party booking system on its own domain
• Your marketing site and app are on different domains
• You operate region-specific domains (yoursite.com, yoursite.de, yoursite.fr)

You don’t need it when:

• Everything is on subdomains of the same root domain (most analytics tools handle this automatically)
• The external domain is a third-party service you don’t control
• You’re using cookieless analytics that doesn’t rely on cross-session identification

How Cross-Domain Tracking Works

The solution is conceptually simple: when a visitor clicks a link from Domain A to Domain B, pass the session identifier in the URL. Domain B reads the identifier from the URL and continues the same session instead of creating a new one.

Most analytics tools automate this. You configure which domains should share sessions, and the tool appends a parameter (like _gl for Google tools) to cross-domain links automatically. The receiving domain reads that parameter and links the sessions together.

Implementation Steps

1. List all domains that should share a single analytics session
2. Configure cross-domain linking in your analytics tool or tag manager
3. Add referral exclusions for your own domains so they don’t appear as traffic sources
4. Test the full journey — navigate from Domain A to Domain B and verify the session continues

Referral Exclusion List

This is the step most implementations miss. Even with cross-domain linking configured, your analytics tool may still count the domain transition as a new session with a referral source. Adding your domains to the referral exclusion list prevents this — telling the tool “traffic from these domains is not a new session.”

Testing Your Setup

A misconfigured cross-domain setup is worse than no setup at all. Here’s my verification checklist:

1. Check URL decoration — click a link from Domain A to Domain B. Does the URL contain a linker parameter? If not, cross-domain linking isn’t active
2. Check real-time reports — with your session active on Domain B, check if the real-time view shows you as the same user (not a new session)
3. Check self-referrals — in your traffic sources report, your own domains should not appear. If they do, your referral exclusion list is incomplete
4. Check conversions — complete a test conversion that spans both domains. Verify the original traffic source is preserved in the conversion report

Cross-Domain Tracking and Privacy

Passing session identifiers in URLs raises privacy questions. The linker parameter contains a client ID that, combined with analytics data, could identify an individual. Under GDPR, this means:

• Cross-domain tracking requires the same consent level as single-domain cookie tracking
• The linker parameter should be considered personal data
• Both domains must be covered by the same privacy policy and DPA

For businesses using privacy-first analytics, cross-domain tracking is less of an issue. Cookieless tools don’t track individuals across sessions, so the domain boundary doesn’t create the same data problems.

Common Mistakes

Forgetting iframes. If Domain B loads inside an iframe on Domain A (common with embedded booking widgets), standard cross-domain linking doesn’t work. You need iframe-specific configuration or server-side tracking to bridge the gap.

Missing referral exclusions. The single most common issue. Even experienced teams forget to update the exclusion list when adding new domains.

Not testing after CMP changes. Consent management platforms can interfere with cross-domain linking. If your CMP blocks the analytics script before consent, the linker parameter won’t be appended. Always re-test after CMP updates.

What’s Next

Cross-domain tracking is a configuration problem, not a conceptual one. List your domains, enable linking, exclude self-referrals, and test thoroughly. For most setups, it takes an hour to implement and saves months of bad attribution data.

In upcoming guides, I’ll cover attribution models for making sense of multi-touch conversion paths, and form tracking for capturing lead data across domains.