The value of consented analytics and advertising data is contingent upon the accuracy, consistency and governance of the signals used to control collection and activation. A Consent Management Platform (CMP) should not be treated merely as a banner implementation.
In most enterprise environments, consent decisions may need to be translated across analytics platforms, advertising tags, tag management systems, customer data platforms and server-side forwarding layers. A visitor may accept analytics cookies while rejecting advertising cookies. A returning visitor may already have a stored preference. A visitor in the UK may require a different consent experience from a visitor in another jurisdiction. These states should be reflected in platform behaviour at the correct point in the collection workflow.
A robust CMP integration should therefore include a defined architecture, clear purpose mapping, correct load order and testing across relevant consent states. It is also necessary to recognise its limits. A CMP can improve implementation consistency, but it is not a replacement for governance, legal review, downstream enforcement or technical control over systems outside the agreed implementation scope.
1. What a CMP integration should control
A CMP integration should usually perform four connected functions:
- Present and record the consent choice
- Translate the choice into platform-specific signals.
- Control whether tags and data collection methods are activated.
- Carry the consent state into downstream systems.
If one of these functions is incomplete, the banner may appear to operate correctly while the underlying implementation remains inconsistent.
For example, a visitor may select “reject marketing”, but a Meta Pixel may still be injected by a separate script outside the tag management system. Alternatively, Google Analytics may correctly receive a denied analytics_storage signal in the browser, while a server-side container continues to forward events without evaluating the consent state.
The principal limitation of CMP-led consent management is that it does not, by itself, resolve hardcoded scripts, undocumented third-party technologies, inconsistent regional logic or weak downstream controls. These issues should be addressed explicitly in the implementation design.
Recommended action: the CMP should be treated as one component in a wider consent architecture, not as a standalone compliance solution.
2. Define consent categories before configuring tags
The first step should be to define the purposes presented to visitors. The labels used in the CMP should be understandable, but they must also support precise technical mapping.
Common categories include:
- Strictly necessary – functionality required for the website or service to operate.
- Functional – preferences or features that are not essential but improve the user experience.
- Analytics or statistics – measurement of visits, interactions, performance and user behaviour.
- Advertising or marketing – advertising cookies, remarketing, conversion tracking and audience activation.
- Personalisation – processing used to tailor content, offers or recommendations.
The exact categories will depend on your privacy notices, legal advice and technology stack. They should not be added simply because a CMP provides them as default options.
Each category should have:
- A clear description
- A defined purpose
- A list of associated vendors
- A documented legal basis or consent requirement
- A technical signal or rule controlling the relevant processing
- An owner responsible for reviewing changes
A robust taxonomy should create a consistent relationship between the user-facing choice and the technical implementation, provided that the categories are maintained as the technology stack changes.
Recommended action: establish ownership for category maintenance and require review whenever a new vendor, tag or processing purpose is introduced.
3. Map consent choices to vendor signals
Platforms rarely use the same terminology as a CMP. The integration should therefore translate broad consent categories into the signals understood by each vendor.
Google Analytics and Google Ads
For Google’s measurement and advertising products, the most commonly used Consent Mode signals include:
- analytics_storage
- ad_storage
- ad_user_data
- ad_personalization
A typical mapping might be:
The mapping should reflect the wording and scope of the consent collected. If analytics consent is granted but advertising consent is denied, the implementation should not set both analytics_storage and ad_storage to granted.
Google’s Consent Mode documentation explains how Google tags adjust their behaviour based on the signals received. Depending on the configuration, tags may send limited cookieless measurement requests when storage is denied. This may support reporting continuity in some scenarios, but it is not a replacement for legal review or a documented privacy assessment. Suitability should be determined by region and use case.
Google also requires the CMP integration to update consent when the visitor makes or changes a choice. An initial default command without a corresponding update command should not be treated as a complete implementation.
- Recommended action: document the exact mapping between CMP purposes and Google consent signals, then validate the implementation through network inspection and Tag Assistant.
Microsoft Clarity
Microsoft Clarity uses two consent permissions:
- analytics_Storage
- ad_Storage
These should be mapped independently to your analytics and advertising purposes. Microsoft’s Clarity CMP integration guidance specifically warns against granting both permissions when the visitor has only accepted one category.
The current Consent API uses a command such as:
The exact capitalisation of these keys matters. The integration should also send the stored state for returning visitors and issue a new call when preferences are updated. As with any vendor-specific API, the implementation should be validated against current documentation rather than inherited assumptions from prior builds.
- Recommended action: verify the Clarity consent call in a controlled test session for first-time visitors, returning visitors and preference updates.
Adobe Experience Platform Web SDK
Adobe implementations require their own consent configuration. The Adobe Platform Web SDK extension can use a default state such as:
- in
- out
- pending
It can then receive an explicit consent update through the Web SDK setConsent action.
Adobe’s CMP consent implementation tutorial describes how consent can be captured using Adobe’s consent standards or IAB TCF data. The key design decision is not merely which option is selected in the extension. It is necessary to determine how the CMP state becomes available at the correct point in the page lifecycle and how subsequent events behave before and after consent is known.
If the default is pending, events may be queued until consent is provided. If the default is out, events before consent are dropped. These behaviours have different data and privacy implications and should be selected deliberately. Neither approach removes the need to document the treatment of pre-consent events, reconcile any reporting impact and confirm alignment with the stated consent model.
- Recommended action: define the expected handling of pre-consent Adobe events in the solution design before implementation begins.
4. Set the correct default state
Consent defaults should be established before consent-dependent tags or SDKs begin processing.
For UK and EEA traffic where consent is required before non-essential storage or tracking, analytics and advertising signals should generally begin in a denied state. The exact regional configuration should be confirmed against your legal requirements and documented privacy position.
A default state should not be set only after the banner has loaded. By then, another tag may already have created cookies or transmitted data.
With Google Tag Manager, the CMP should normally be loaded using the Consent Initialisation trigger. Google’s GTM setup guidance also recommends ensuring that the CMP code runs before Google tags and that the CMP is present across all relevant pages.
This is particularly important where a site uses:
- Multiple GTM containers
- A hardcoded Google tag alongside GTM
- Separate containers for different brands or regions
- Plugins that inject advertising or analytics scripts
- Third-party components such as video players, chat tools or payment widgets
The default state should be tested on a clean browser session before any interaction with the banner. This can help identify early-firing technologies, but it will not by itself confirm that all downstream forwarding and vendor-specific behaviour is correctly aligned.
- Recommended action: test default behaviour with no stored consent state, then repeat with region simulation, multiple containers and hardcoded vendor scripts where applicable.
5. Implement update commands when consent changes
A consent choice is not complete when it is stored in the CMP database. It should be communicated to every relevant platform.
A practical sequence is:
- The CMP loads and applies the regional default.
- Analytics and advertising signals are set to the appropriate initial values.
- The visitor selects a preference.
- The CMP stores the decision and issues update commands.
- Tag management rules and vendor APIs respond to the new state.
- The new state is retained and reapplied on subsequent visits.
The update should occur when the visitor finalises the choice, rather than on every interaction with the banner controls. This reduces unnecessary state changes and the risk of inconsistent platform behaviour.
The same process should apply when consent is withdrawn. Withdrawal should not only update the CMP interface. It may also require cookies to be removed, identifiers to be disabled and future events to be blocked or restricted, depending on the vendor. Historical data already processed by third parties may not be retrospectively removed by a simple consent change, so the operational effect of withdrawal should be documented clearly.
- Recommended action: define a withdrawal workflow covering interface update, storage handling, vendor update calls and downstream enforcement behaviour.
6. Use tag blocking as an enforcement layer
Consent signals and tag blocking are related, but they are not interchangeable.
Some platforms can operate in a consent-aware mode when storage is denied. Other vendors should not load at all without the relevant consent. The implementation should distinguish between these behaviours. A CMP integration can support that distinction, but only where the relevant technologies are governed by the same control framework.
In GTM, each tag should have appropriate consent requirements. For example:
- GA4 tags should require the analytics consent signal.
- Google Ads conversion and remarketing tags should require the relevant advertising signals.
- Advertising pixels should be blocked unless marketing consent is granted.
- Functional tags should be linked to the functional category rather than being treated as essential by default.
- Custom HTML tags should be reviewed individually rather than assumed to be compliant.
Tags installed outside GTM also need to be assessed. A CMP cannot reliably block a script that is hardcoded into the page unless the script has been integrated with the CMP or otherwise controlled.
This is a common source of implementation gaps. A site may have a well-configured GTM container while a consent-independent plugin continues to load a marketing script. Good CMP configuration is not a replacement for a proper inventory of deployed technologies.
- Recommended action: maintain a controlled vendor and script inventory and reconcile it periodically against live-page behaviour.
7. Carry consent through server-side forwarding
Moving collection server-side does not remove the need for consent enforcement. It changes where enforcement takes place.
A suitable architecture passes consent information from the CMP to the client-side tag management layer, and then into the server-side request. The server-side container should use that information before forwarding data to analytics or advertising endpoints.
A typical flow is:
- The CMP establishes the consent state in the browser.
- Client-side tags decide whether an event should be collected.
- If an event is sent to a server-side endpoint, the consent state travels with the request.
- The server-side container validates the state.
- The request is either forwarded, restricted, or dropped.
- Parameters that are not permitted under the consent state are removed before forwarding.
The server-side layer should not trust the browser signal without validation. Consent values should be checked for expected formats, and the system should have a defined response for missing or contradictory values.
For example, if an event contains an advertising identifier but the forwarded consent state indicates that advertising consent is denied, the request should be investigated and handled according to the documented policy.
Server-side forwarding can provide additional control over enforcement and transformation, but it does not solve poor consent mapping in the browser, unclear legal categorisation or inconsistent vendor configuration. It should be treated as an additional enforcement point, not a substitute for client-side governance.
- Recommended action: validate consent state on arrival at the server-side endpoint and apply explicit forwarding rules for denied, missing and contradictory values.
8. When regional consent logic is likely to be appropriate
A multi-country website may require different banner presentation, defaults and vendor behaviour by region. A well-designed solution should support those differences without creating an unmaintainable collection of separate implementations.
Regional rules can determine:
- Whether consent is opt-in or opt-out
- Which purposes are displayed
- The default value of each signal
- Whether a privacy signal such as Global Privacy Control affects the state
- Which vendors are available in a particular market
- Whether a consent banner is shown
These rules must be tested with location simulation and clean browser profiles. It is not sufficient to test only from the organisation’s office location.
The implementation should also record which regional rule was applied. This can help explain why two otherwise identical visits received different defaults and may provide useful evidence during troubleshooting or compliance reviews.
- Recommended action: log the applied regional rule and test it using location simulation and clean browser profiles.
9. A practical approach
A CMP integration should be tested as a set of scenarios, not merely as a banner.
At minimum, test:
- New visitor with no stored preference
- Accept all
- Reject all
- Analytics accepted, and advertising rejected
- Advertising accepted, and analytics rejected
- Returning visitor with a stored preference
- Visitor changing preferences
- Visitor withdrawing consent
- Different regional locations
- JavaScript disabled or delayed.
- Multiple subdomains
- Multiple containers
- Server-side requests with missing consent values
Use browser developer tools, GTM Preview, Tag Assistant, vendor debugging tools and network request inspection. Confirm both what fires and what does not fire.
The test should also check cookies, local storage, request parameters, data layer events and server-side forwarding. A consent state visible in the CMP interface is not evidence that every vendor has received and applied it.
A practical delivery approach often includes:
- Defining consent purposes and vendor mapping against current legal and privacy requirements
- Documenting which technologies are controlled through the CMP, tag manager, application code and server-side layer
- Setting regional defaults and load order rules before deployment
- Implementing vendor-specific consent updates using current official documentation
- Testing acceptance, rejection, withdrawal and returning-visitor scenarios across regions
- Revalidating the setup whenever new tags, plugins, markets or collection paths are introduced
This approach can reduce ambiguity and support maintainability, but it remains dependent on disciplined change control. If tags are added outside the agreed framework, consent behaviour may drift over time.
- Recommended action: maintain a repeatable test plan covering browser behaviour, vendor calls, cookies, storage, data layer events and server-side forwarding.
10. Conclusion
CMP integration can improve the consistency with which consent decisions are translated and enforced across analytics and advertising platforms, particularly where multiple vendors, regions and collection methods are involved. Its value is contingent upon accurate purpose definition, correct vendor mapping, appropriate default behaviour and reliable downstream enforcement.
Its limits should also be recognised clearly. A CMP does not, by itself, resolve hardcoded scripts, replace privacy assessment, guarantee vendor compliance or ensure that server-side forwarding is correctly governed.
A robust implementation should therefore combine CMP configuration with tag governance, vendor-specific validation, regional testing and ongoing review against official documentation.
If the current implementation produces unexplained data discrepancies or fails to demonstrate how consent is propagated through the stack, a structured analytics and tagging audit can identify where signals are being lost.
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
