The value of analytics data depends on its accuracy, consistency, and effective governance. Cross-domain tracking can enhance continuity when users navigate between separate websites as part of a single journey. However, it does not substitute for robust measurement design, consent management, or comprehensive quality assurance.

In enterprise contexts, a customer journey may start on a corporate website, continue to a product-specific domain, proceed to an application platform, transition through a third-party payment provider, and subsequently return to the original site. If these domains are not configured appropriately, the journey can be fragmented into multiple sessions, self-referrals may be recorded in reports, and conversion attribution may become unreliable.

Google Tag Manager can facilitate cross-domain tracking, but it does not address architectural, legal, or platform-level constraints independently. A robust implementation requires consistent tagging, correctly configured domains, preservation of linker parameters, appropriate consent handling, and thorough testing across the entire journey.

1. What cross-domain tracking is designed to solve

Standard analytics cookies are generally set in the context of a particular domain. A cookie created on www.example.co.uk is not automatically available to checkout.example-payments.com or example-account.com.

Without cross-domain configuration, a user moving between separate domains may be treated as:

1. A new user on the second domain.

2. The start of a new session.

3. A referral from the first domain.

4. A new source of traffic when returning to the original site.

This can affect:

• Conversion rates.

• Channel attribution.

• User and session counts.

• Funnel reporting.

• Marketing performance analysis.

• The relationship between landing-page activity and transactions.

Cross-domain tracking transfers relevant Google measurement information between participating domains. The objective is to enable the destination domain to maintain the existing measurement context, provided that the implementation, browser behaviour, and consent state allow it.

It is important to specify the limitations of this approach. Cross-domain tracking does not address poor event design, inconsistent implementation across properties, missing consent, duplicate tags, or incorrect transaction logic. While it may reduce unnecessary session fragmentation, it does not ensure complete continuity in all scenarios.

• Recommended action: confirm that the reporting problem is genuinely caused by domain transitions rather than broader data-quality issues.

2. Start with the domain architecture

Before configuring Google Tag Manager, document how the domains relate to one another.

A useful architecture document should include:

• The primary website.

• Product or brand websites.

• Regional domains.

• Account or application platforms.

• Checkout and confirmation domains.

• Subdomains.

• Payment providers and other external services.

• Redirects between any of the above.

• The Google Analytics property and web stream used by each domain.

This distinction is significant because not every domain should be included within a single reporting journey.

For example, a group may operate:

• brand-one.co.uk

• brand-two.co.uk

• account.example.com

• checkout.example-platform.com

The first two domains may represent distinct brands and require separate reporting. The account and checkout platforms may need to be incorporated into the same customer journey as one or both brands. This decision should be made prior to implementation, rather than inferred from existing tag deployment.

Cross-domain tracking should be regarded as a measurement design decision, not merely a configuration setting within Google Tag Manager.

• Recommended action: produce an explicit domain map before configuration begins, including redirects, external hand-offs and reporting ownership.

3. Use a consistent measurement structure

For GA4 cross-domain tracking, participating domains normally need to use the same GA4 web data stream and Measurement ID if they are expected to contribute to the same user and session journey.

The Google tag or GA4 configuration deployed through GTM must also be available on each domain where tracking is required. This can be achieved through:

• One shared GTM web container.

• Multiple containers using controlled, consistent configurations.

• A central template or deployment process.

• A combination of GTM and direct Google tag implementation.

The specific deployment method is less critical than the outcome. The essential requirements are that tags use the correct Measurement ID, events adhere to a consistent measurement specification, and relevant consent rules are applied uniformly.

If a domain uses a different property, Measurement ID, or event model, linking it to another domain will not automatically produce a unified or comparable dataset.

• Recommended action: validate Measurement IDs, event specifications, consent behaviour and deployment ownership before enabling cross-domain behaviour.

4. Configure the domains and linker behaviour

GA4 uses a linker parameter called _gl to pass measurement information between domains. When configured correctly, the Google tag can add this parameter to links leading to participating domains. The destination tag can then read it and use the information to continue the journey.

Google’s official documentation provides the underlying configuration details in its guide to cross-domain measurement.

The implementation should be aligned in both relevant locations:

GA4 administration

Within the relevant web data stream, configure the domains that should be treated as part of the same journey.

The list should include the domains that users genuinely move between, rather than every domain owned by the organisation. Include the required hostnames and check that production, regional and application environments have been considered.

Google Tag Manager

Within the Google tag or GA4 configuration used in GTM, configure the cross-domain settings so that links to the relevant domains can be decorated.

Depending on the implementation, this may include:

• The domains permitted for auto-linking.

• Acceptance of incoming linker parameters.

• The URL position used for the linker parameter.

• Conversion Linker configuration where Google Ads conversion measurement requires it.

A Google Tag Manager implementation should document these settings explicitly, rather than relying on individual administrators’ knowledge of the container.

5. A practical approach

A practical implementation should be structured and not considered complete solely because the relevant Google Tag Manager settings have been enabled.

In most cases, the following sequence is appropriate:

1. Define the intended reporting journey. Determine which domains should and should not belong to one measurement journey.

2. Map the real navigation paths. Document direct links, redirects, payment steps, authentication flows and return journeys.

3. Align the measurement setup Confirm the intended GA4 property, web stream, Measurement ID, event model and consent behaviour across all participating domains.

4. Configure linker behaviour deliberately. Apply cross-domain settings in GA4 and GTM using the documented domain list.

5. Test full journeys rather than isolated pages. Validate that parameters persist through the full path from entry to conversion.

6. Record known limitations. If a provider, redirect or consent rule prevents continuity, that limitation should be documented explicitly in implementation and reporting materials.

A robust implementation should acknowledge that some journeys may remain only partially measurable, depending on the technical and legal constraints present.

• Recommended action: implementation documentation should record both the intended behaviour and any accepted limitations.

6. Understand the role of the _gl parameter

When a user clicks a qualifying link, the Google tag may append _gl to the destination URL. The destination site can then read the parameter and, where conditions allow, continue the measurement context.

For example:

The parameter must be present when the destination page loads. Several technical processes may remove it before that happens:

• Redirects that discard query parameters.

• URL-cleaning scripts.

• Consent or security middleware.

• Single-page application routing.

• Link shorteners.

• Personalisation tools.

• Server-side redirects.

• Payment or authentication hand-offs.

Google linker parameters also have a limited validity period. A user who opens a decorated URL and completes the journey much later may not retain the same linking context. The implementation should therefore be tested against realistic customer behaviour, not only an immediate click from one page to another.

The parameter should not be manually recreated or renamed without a specific, documented justification. Custom identifier passing can introduce additional privacy, security, and data quality considerations.

It is also necessary to state what the linker parameter does not solve. If _gl is stripped before page load, if the destination domain does not load the relevant tag, or if consent prevents identifier use, cross-domain configuration will not restore continuity by itself.

• Recommended action: validate that _gl persists through all redirect chains and arrival states before release.

7. Subdomains are not the same as separate domains

Subdomains often cause unnecessary complexity.

For example:

• www.example.com

• shop.example.com

• account.example.com

These are subdomains of the same root domain. In many GA4 implementations, the Google tag can maintain measurement across them without the same cross-domain linker configuration required for separate root domains.

However, this does not mean that subdomain tracking can be ignored. You still need to confirm:

• Cookie domain behaviour.

• Consent state availability.

• Consistent Measurement IDs.

• Tag loading on every subdomain.

• Referral and hostname reporting.

• Any redirects between www and non-www versions.

A subdomain may be operated by a separate platform with different cookie, consent, or tagging restrictions. In such cases, its technical relationship with the root domain should be evaluated explicitly rather than assumed.

8. Payment providers require a separate approach

Payment journeys are one of the most common causes of attribution problems.

If customers are redirected to a payment provider and then returned to the confirmation page, there are two different scenarios.

The payment provider supports measurement

If the provider permits the Google tag to run and allows the required parameters and consent signals to pass through, it may be possible to include the provider-hosted step in the broader cross-domain design.

This is dependent on the provider’s platform, implementation options and contractual arrangements. It should not be assumed without validation.

The payment provider does not support measurement

If no tag can run on the provider’s domain, there cannot be full measurement continuity across that part of the journey. It may still be possible to reduce attribution distortion when the customer returns, but that is not equivalent to complete cross-domain measurement.

GA4’s unwanted referrals configuration can be considered for known payment or intermediary domains. Google documents this behaviour in its guidance on cross-domain measurement and related GA4 settings. This can prevent the provider from overwriting the intended referral source in certain return journeys, but it does not recreate measurement that was not collected on the provider’s site.

It is necessary to validate:

• Whether the original first-party cookie remains available on return.

• Whether the return occurs within the existing session timeout.

• Whether the payment provider adds or removes URL parameters.

• Whether failed and successful payment attempts are distinguished.

• Whether the confirmation event can occur more than once.

A separate transaction tracking review is often appropriate for complex payment journeys.

• Recommended action: payment-provider journeys should be treated as a distinct measurement workstream rather than assumed to behave like standard cross-domain navigation.

9. Consent can limit session continuity

Cross-domain tracking must operate within the organisation’s consent framework.

If analytics storage is denied on the first domain, the tag may not be able to establish the identifiers required for continuity. If the user then arrives on a second domain and grants consent there, the second domain cannot reliably reconstruct all activity that took place before consent.

This is an expected consequence of respecting the user’s choice. It should not be addressed by passing identifiers through URLs without a clear legal and technical basis.

The implementation should define:

• The default consent state by region.

• Which tags may run before consent.

• Whether linker decoration is permitted before consent.

• How consent updates are passed between domains.

• How a CMP behaves after redirects.

• Whether consent is stored centrally or separately on each domain.

• How denied and granted journeys are represented in reporting.

Google Consent Mode and GTM consent checks should be tested as part of the cross-domain implementation, not as a separate exercise. See TagDataTrust’s guidance on Google Consent Mode v2 for further context.

• Recommended action: include consent-state testing within cross-domain QA rather than treating privacy validation as a separate workstream.

10. Build QA around complete journeys

A successful GTM preview session is not sufficient to confirm that cross-domain tracking works. Testing should follow the customer journey from entry to conversion.

At minimum, the following should be tested:

1. Direct navigation between configured domains: Confirm that the expected linker parameter is added and accepted.

2. Navigation through redirects: Check that _gl survives HTTP-to-HTTPS, hostname, language and platform redirects.

3. Subdomain movement Confirm cookie and hostname behaviour across the relevant subdomains.

4. Payment journeys Test successful, failed, abandoned and repeated payment attempts.

5. Consent variations Test consent granted, denied, changed and unavailable across each domain.

6. Single-page application routing: Confirm that client-side navigation does not remove or overwrite relevant parameters.

7. Session and source reporting: Use GA4 DebugView and browser developer tools to check that events are associated with the expected Measurement ID, user and session.

8. Self-referral monitoring: Review acquisition reports after release. A configured domain appearing as a referral usually indicates a missing, stripped or incorrectly processed linker parameter, although reporting latency and attribution rules should also be considered.

A broader analytics data quality review should include these checks alongside event duplication, missing conversions and dataLayer validation.

• Recommended action: QA should be designed around complete journeys, not isolated tag fires.

11. Common implementation limitations

Cross-domain tracking cannot compensate for:

• Different Measurement IDs where one journey is required.

• A domain that does not load the relevant tag.

• A redirect that removes _gl.

• A payment provider that does not permit measurement.

• Consent being denied before identifiers are created.

• Long delays between decorated-link access and conversion.

• Inconsistent event naming or transaction logic.

• Duplicate tags deployed through multiple systems.

It also does not address broader reporting questions, such as whether domains should be combined in the first place, whether consent choices are handled correctly, or whether conversion logic is trustworthy once the user reaches the final step.

These dependencies should be recorded in the implementation specification. Where continuity is not technically or legally possible, the limitation should be made explicit in reporting rather than concealed through unreliable workarounds.

Conclusion

Cross-domain tracking can be useful when users move between separate domains as part of a single intended journey, and that journey is required within a single reporting context. In the right circumstances, Google Tag Manager can support controlled deployment and governance of that configuration.

At the same time, it is not a standalone solution. It does not replace clear domain architecture, consistent measurement design, consent controls, transaction validation or full-journey QA. Depending on the platforms involved, some parts of the journey may remain only partially measurable.

A measured implementation approach is generally the most reliable: define the reporting requirement first, configure only the domains that genuinely belong together, test realistic journeys end-to-end, and document any limitations clearly.

If you’d like to hear more on this topic and set up a 1:1 call with us, please use the contact form. Contact a Consultant