For organisations operating several websites, regional domains, customer portals or hosted services, consent management is not limited to displaying a banner. The consent state must be collected, stored, resolved and communicated consistently wherever the same user journey continues.

This becomes more complex when the environment includes separate registrable domains, such as example.co.uk, example.de and example.com, rather than only subdomains such as www.example.com and shop.example.com. A consent choice recorded on one domain is not automatically available to another domain, and Google Consent Mode does not provide a general-purpose cross-domain consent synchronisation mechanism.

A reliable implementation therefore requires a clear separation between the Consent Management Platform (CMP), the domain architecture and the tagging or analytics layer.

1. The distinction between subdomains and separate domains

The first technical distinction is the scope of the domain structure.

A first-party cookie can generally be configured for a shared parent domain. For example, a cookie scoped to .example.com may be available to:

• www.example.com
• shop.example.com
• account.example.com

This approach may support consent continuity across subdomains, provided that the CMP, cookie attributes, security settings and site architecture are configured consistently.

Separate registrable domains are different. A cookie set on example.co.uk cannot be read by example.de, even if both domains are controlled by the same organisation. Browser security boundaries prevent a first-party cookie from being shared in this way.

Consequently, a multi-domain consent architecture may require:

• A CMP configuration covering all relevant domains.
• A documented mechanism for resolving consent on each domain.
• A consistent consent taxonomy across properties.
• A controlled method for transferring or retrieving consent preferences.
• Independent validation of the consent state before tags execute.

The technical solution will depend on the CMP and the legal basis for processing. Do not assume that a common corporate identity is sufficient to permit unrestricted consent sharing.

Recommended action: Create a complete inventory of domains, subdomains, applications, consent categories, regions and tagging containers before designing the implementation. The inventory should distinguish between domains that can share first-party storage and domains that require an alternative consent resolution method.

2. Consent Mode is not a cross-domain consent store

Google Consent Mode controls how supported Google tags and SDKs behave according to the consent state supplied to them. Google’s Consent Mode overview identifies consent types including:

• analytics_storage
• ad_storage
• ad_user_data
• ad_personalization
• functionality_storage
• personalization_storage
• security_storage

Consent Mode can adjust tag behaviour, restrict storage and enable cookieless measurement signals where applicable. Google’s documentation also states that consent state pings are sent from each page on which Consent Mode is implemented.

This does not mean that Consent Mode stores a user’s CMP preference and makes it available across unrelated domains. Google’s implementation guidance states that Consent Mode does not save consent choices. The implementation is responsible for persisting the choice and updating the consent state on subsequent page loads.

Consent Mode should therefore be treated as a downstream communication layer:

1. The CMP obtains or resolves the user’s consent choice.
2. The site or application persists or retrieves the relevant state.
3. The CMP communicates the state to the tagging layer.
4. Google tags adjust their behaviour according to the supplied values.

This distinction is important because a technically correct Consent Mode configuration on one domain does not, by itself, establish a correct consent state on another domain.

Recommended action: Document the boundary between the CMP and Consent Mode. The CMP should be identified as the source of the consent decision, while Consent Mode should be documented as the mechanism that communicates that decision to supported Google tags.

3. Mapping consent categories across domains

Different domains may use different CMP configurations, tag managers or analytics properties. Without a common taxonomy, the same user choice may be interpreted differently across the estate.

For example, one domain may classify an analytics cookie under “analytics”, while another maps it to “performance”. A marketing category may also be split between advertising cookies, remarketing, enhanced conversions and personalisation.

A central consent model should define how each category maps to the relevant technical signal:

The mapping should be consistent across domains unless a documented business, technical or regulatory reason requires a difference.

A consent state of “granted” must not be interpreted as consent to every purpose. Consent is granular, and each signal must reflect the applicable purpose and jurisdictional requirements.

The Google Analytics consent mode reference provides further detail on how the individual consent types affect tag behaviour, data storage and advertising functionality.

Recommended action: Maintain a version-controlled consent mapping document. It should record the CMP category, the corresponding Consent Mode signal, the tags affected, the default state, the geographic scope and the evidence used for validation.

4. Choosing a cross-domain consent pattern

No single pattern suits every multi-domain environment. The appropriate design depends on whether the domains are related, whether the user journey crosses them directly and whether the CMP supports cross-domain consent sharing.

Common approaches include the following.

Shared first-party storage for subdomains

When all properties sit beneath the same registrable domain, a root-domain cookie may provide a practical way to maintain a common state. The cookie configuration must be reviewed carefully, including:

• Domain scope.
• Secure and SameSite attributes.
• Expiry and renewal.
• Consent withdrawal behaviour.
• Compatibility with application and server-side components.

The CMP must still initialise correctly on every subdomain and communicate the resolved state to the tagging system.

CMP-supported cross-domain synchronisation

Some CMPs provide documented functionality for synchronising consent preferences across separate domains. This may use a consent service, an API, a controlled redirect or another mechanism defined by the provider.

Such functionality should be assessed for:

• The domains and regions supported.
• The data transmitted between domains.
• The security model.
• The timing of consent resolution.
• The handling of consent withdrawal.
• The audit record created for each decision.

The implementation should rely on the CMP’s documented method rather than attempting to transfer internal cookies or undocumented parameters.

Consent resolution on every domain

In some environments, each domain may collect consent independently. This can be appropriate where the privacy notices, purposes, controllers or processing activities differ. It may result in separate consent records and different tag behaviour across the estate.

This approach is not inherently incorrect, but it must be reflected in the privacy documentation and user experience. A central corporate preference centre should not imply a scope of consent that the underlying implementation cannot support.

5. Loading order and default states

Consent timing is a material part of the implementation. Google’s technical guidance requires the default consent state to be set before measurement commands or tags send data.

A typical sequence is:

1. Initialise the data layer or tagging environment.
2. Set the default consent state.
3. Load or initialise the CMP.
4. Resolve any stored or transferred consent preference.
5. Update the consent state.
6. Allow consent-aware tags to operate according to the resulting state.

For an asynchronous CMP, you may need a waiting mechanism to let the consent update complete before relevant tags fire. The specific implementation depends on the tagging platform and CMP integration.

The default state must not be treated as a substitute for a resolved preference. A default  denied may be appropriate while consent is unresolved, but it must be followed by an update when a valid consent record is available. Similarly, a regional default must be implemented consistently on every domain where that regional rule applies.

The Google Consent Mode documentation distinguishes between basic and advanced implementations. The choice affects whether tags are blocked before interaction or whether restricted, cookieless signals may be sent while consent is denied.

6. What this approach does not solve

A cross-domain consent architecture does not solve every privacy or measurement problem.

It does not:

• Establish the legal basis for processing.
• Determine whether consent is required in a particular jurisdiction.
• Make separate controllers or processors one legal entity.
• Transfer consent to domains that the CMP does not support.
• Guarantee that non-Google or custom tags respect the consent state.
• Repair data already collected unlawfully or inaccurately.
• Preserve user identity across domains without separate identity and attribution considerations.
• Eliminate reporting differences caused by consent loss, browser restrictions or attribution models.
• Replace a Data Protection Impact Assessment when required.

Consent Mode also does not automatically govern every vendor deployed through a tag management system. Google tags have built-in consent checks, but other vendors may require additional configuration, custom consent checks or explicit blocking rules.

Recommended action: Treat consent implementation, privacy governance and measurement architecture as related but separate workstreams. Each should have its own acceptance criteria, owners and validation evidence.

7. A practical implementation and QA approach

A controlled implementation can be structured into the following stages.

Stage 1: Document the estate

Record every domain, subdomain, application, environment, CMP instance, tag manager container, analytics property and advertising account. Include redirects, payment providers, support platforms and authentication portals.

Stage 2: Define the consent contract

Specify the consent categories, Consent Mode signals, default states, regional rules and tag requirements. This creates a measurable contract between the CMP and the tagging layer.

Stage 3: Configure the CMP

Implement the CMP according to the approved domain model. Where cross-domain synchronisation is required, use a documented provider capability and record how consent is transferred, retrieved and withdrawn.

TagDataTrust’s CMP integration services support the technical integration of consent management with tagging and analytics environments.

Stage 4: Configure tagging behaviour

Set default Consent Mode values before measurement activity. Map the CMP events or APIs to the relevant updates, and configure non-Google tags with appropriate consent checks.

Stage 5: Test each transition

Test at least the following journeys:

• First visit with no stored preference.
• Acceptance of all categories.
• Rejection of all optional categories.
• Partial category selection.
• Navigation between subdomains.
• Navigation between separate registrable domains.
• Consent withdrawal.
• Consent renewal after expiry.
• Regional variations.
• Redirects and authentication flows.
• Mobile and desktop environments.

Validation should include CMP state, browser storage, data layer events, tag firing, network requests and analytics results. Google’s consent debugging guidance can be used to inspect the state received by Google tags.

The existing multi-domain conversion linker case study shows why domain inventories and hostname controls also matter for measurement accuracy. Consent continuity and cross-domain attribution are separate concerns, but both require precise control over the domains involved.

Conclusion

Tracking consent states across multiple domains requires more than deploying the same CMP script across every property. The domain structure, consent taxonomy, storage boundaries, regional rules and tag behaviour must be designed as one controlled system.

Consent Mode communicates the resolved state to supported Google tags. It does not replace the CMP, create a shared cross-domain consent store or determine the legal basis for processing. Reliable implementation depends on clear ownership of each layer, documented mappings and testing across every relevant domain transition.

For organisations with a complex digital estate, a structured audit provides a practical basis for reducing consent discrepancies while protecting the reliability of analytics and advertising data. The most effective implementations are those that define the consent model clearly, apply it consistently across domains and validate it against documented technical and governance requirements.

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