How to track users across multiple domains and subdomains without losing attribution

When a single user moves from your corporate site to a login portal to a product app on different domains, most analytics setups quietly split that one person into three separate visitors — and the original campaign that brought them in loses the conversion. Cross-domain tracking is the practice of keeping one user as one continuous journey across those boundaries, using first-party cookies, referral exclusions, and a linker that carries identity between domains. The practical conclusion: it is achievable, but only if you configure all three mechanisms deliberately and verify them continuously, because a setup that looks correct on day one can silently break with the next site change.

Why sessions and attribution break at domain boundaries

Larger organizations rarely live on a single domain. A typical journey might start on the corporate marketing site, move to a separate login portal, continue into a product web app on its own domain, and occasionally pass through a campaign microsite bought for a specific launch. Each of these is often a distinct registrable domain, sometimes owned by different internal teams or vendors.

The problem is structural, not a bug in any one tool. Analytics identity is stored in a browser cookie, and cookies are scoped to the domain that set them. A cookie written on corporate.com cannot be read on product-app.com — the browser treats them as unrelated origins. So when the user crosses that boundary, the analytics library on the new domain finds no existing identifier, mints a fresh one, and starts a new session.

Two things break at that moment. First, session continuity: one person becomes two visitors, inflating your user count and halving average engagement per user. Second, and more damaging, attribution. The new domain sees the referrer as your previous domain, so the visit is credited to that internal referral instead of the paid campaign, organic search, or email that originally brought the user in. The conversion that happens on the product app is attributed to your own website rather than to the channel that earned it.

Cookies, referral exclusions, and linkers: how they actually behave

Reliable cross-domain tracking rests on three mechanisms. Understanding what each one actually does — and what it does not do — is what separates a setup that holds from one that appears to work and quietly leaks.

First-party cookies and their domain scope

A first-party cookie is one set by the domain the user is currently visiting, as opposed to a third-party cookie set by an external domain embedded in the page. First-party cookies are the durable foundation for analytics because browsers increasingly restrict third-party cookies and shorten script-set cookie lifetimes; Safari's Intelligent Tracking Prevention and Chrome's evolving cookie policies are the relevant constraints here. The important limitation for our purposes is scope: a first-party cookie belongs to exactly one registrable domain and cannot be shared with another domain, no matter who owns both.

• What this means in practice: the identifier is available everywhere on one domain and its subdomains, but stops dead at the edge of that domain.
• Why it matters: you cannot simply set one cookie and expect it to follow the user across domains — the value has to be actively carried over.

The referral exclusion list

A referral exclusion list tells your analytics not to treat traffic arriving from certain domains as a new source. Without it, when a user lands on product-app.com from corporate.com, the tool records corporate.com as the referrer and typically starts a new session attributed to that referral. Adding all of your own domains to the referral exclusion list prevents that: internal transitions no longer reset the campaign source, and the original acquisition channel is preserved. In Google Analytics this is configured under the property data settings; see the reference on managing cross-domain measurement and referral exclusions in the analytics documentation.

The linker parameter

The linker is the mechanism that physically moves identity across the boundary. When a user clicks a link from one of your domains to another, the linker appends the current identifier (and session information) to the destination URL as a parameter. The receiving domain reads that parameter and adopts the identifier instead of minting a new one, so the same user is recognized as one continuous journey. This is why you sometimes see a long parameter such as a linker value appended to URLs when moving between an organization's sites — that string is the identity being handed over.

Linkers have real failure points worth naming: they only work on links the analytics library can decorate, so hard-coded links, server-side redirects, and links generated after the page loads can strip the parameter. A redirect that drops query strings will silently sever the handover even when everything is configured correctly.

Subdomain tracking vs cross-domain tracking

These two problems are frequently conflated, but they are genuinely different in difficulty, and treating them the same is a common source of wasted effort.

• Subdomain tracking covers movement within one registrable domain — for example from www.example.com to shop.example.com to app.example.com. Because these share the same parent domain, a cookie scoped to .example.com is readable across all of them. In most modern setups this works without a linker; the identity simply persists. The main thing to get right is that the cookie is set at the parent-domain level rather than at a single host.
• Cross-domain tracking covers movement between separate registrable domains — example.com to example-app.com to example-login.io. These never share cookies under any configuration, so you must combine a referral exclusion list with an active linker. This is the harder case and the one where attribution most often leaks.

A useful test: if two hostnames share the same registrable domain (the part you actually registered, plus its public suffix), it is a subdomain case. If they do not, it is a cross-domain case and needs the full mechanism. Login portals, checkout providers, and product apps on their own domains are almost always cross-domain, even when they look like part of the same brand.

A setup-and-verification checklist

The setup itself is a finite list of steps. The discipline is in verifying each transition on a real journey and re-checking after any change to your sites.

Setup steps

1. Inventory every domain and subdomain in the journey. List all registrable domains and hosts a user can pass through, including login portals, checkout, help centres, and campaign microsites. You cannot configure what you have not enumerated.
2. Group them into cross-domain vs subdomain relationships. For each pair, decide whether a shared cookie already spans them (subdomain) or a linker is required (cross-domain).
3. Scope first-party cookies at the parent-domain level so subdomain movement is covered automatically.
4. Add every one of your own domains to the referral exclusion list so internal transitions do not reset the traffic source.
5. Enable the linker on all cross-domain transitions and explicitly list the destination domains that should receive the identifier.
6. Audit redirects and outbound links. Confirm that redirects preserve query parameters and that links between domains are ones the analytics library can decorate at click time.
7. Account for consent. If a consent banner blocks the analytics library until acceptance, the linker may not fire on the first click. Decide how this interacts with your consent design and document it.

Verification steps

1. Walk each transition yourself. Move from domain A to domain B as a real user and inspect the destination URL for the linker parameter. If it is missing, the handover failed at that link.
2. Confirm the identifier persists. Check that the user or client identifier on domain B matches the one from domain A rather than being freshly generated.
3. Confirm the session and source do not reset. The original campaign source should still be attached after the jump, and you should not see a spike of internal-referral traffic.
4. Check the reverse and multi-hop paths. Journeys are rarely linear. Test A to B to C and B back to A, since a linker configured in one direction may not be configured in the other.
5. Re-verify after every site change. New microsites, redesigns, redirect changes, and consent updates are the usual causes of regressions. Treat cross-domain tracking as something to monitor, not to set once.

How datataste helps keep one user as one journey

Cross-domain tracking is a configuration problem with a monitoring problem attached. The configuration you can do once; the monitoring is where most teams lose ground, because a linker that stopped firing after a redesign produces no error — just a slow leak of attribution. This is the part datataste is built to address.

• Continuous data-quality monitoring. datataste continuously monitors your tracking data quality and surfaces problems such as broken or missing events, rather than silently reporting wrong numbers. In a multi-domain estate, that means a broken transition or a suddenly missing conversion event can surface as a flagged problem instead of being discovered months later during an attribution review.
• Automatic event detection. datataste automatically detects meaningful website events — clicks, form submits, conversions — using a replay-based event mapper, without requiring manual tag setup for every element. Across several domains and teams, that reduces the number of places where a hand-built tag can be forgotten or misconfigured on a new site.
• Server-side, first-party collection. datataste supports server-side, first-party tracking, with optional forwarding of events to GA4 and Meta from the server. First-party collection aligns with the cookie-scope realities described above, and server-side forwarding gives you a consistent point of collection while you keep sending data to the destinations your teams already use.

To be clear about scope: these capabilities help you detect and diagnose breakage and reduce manual tagging effort across a multi-domain setup. They do not remove the need to design your cross-domain configuration deliberately — the referral exclusions, linker coverage, and cookie scoping still have to be set up correctly for your specific estate. You can read more on the features page and the documentation.

Conclusion

Cross-domain tracking fails quietly by default because cookies stop at domain boundaries and analytics treats each domain as a fresh start. Keeping one user as one journey is not exotic — it is the disciplined combination of parent-scoped first-party cookies, a complete referral exclusion list, and a linker that actually reaches every cross-domain link, verified on real journeys and re-checked whenever the sites change. Multi-domain analytics that you trust comes from treating this as an ongoing quality practice rather than a one-time switch. Because these mechanisms touch cookies, consent, and personal data, involve a privacy professional when you design how identity is carried across your domains.

Frequently asked questions

Do I need a linker for subdomains?

Usually not. If two hosts share the same registrable domain, a first-party cookie scoped to the parent domain is readable across all of them, so identity persists without a linker. A linker is required for separate registrable domains, which never share cookies.

Why is my product app showing my own website as a traffic source?

That is the classic missing referral exclusion symptom. When a user crosses from your marketing site to your app on another domain, the app records your site as the referrer and starts a new attributed session. Adding all of your own domains to the referral exclusion list — together with a working linker to carry the identifier — resolves it.

Does server-side tracking remove the need for cross-domain configuration?

No. Moving collection server-side changes where events are processed, but the browser still stores identity in domain-scoped cookies, and identity still has to be carried across domain boundaries. You continue to need referral exclusions and a linker; server-side collection complements rather than replaces them.

What most often breaks a working cross-domain setup?

Redirects that strip query parameters, links added after configuration that are not decorated by the analytics library, new campaign microsites that were never added to the referral exclusion list, consent banners that delay the analytics library on the first click, and browser changes to cookie handling. This is why continuous verification matters more than the initial setup.