Consent Mode v2 and Marketing Measurement: How to Set It Up and Test It

digital-marketing
Consent panel controlling analytics and advertising states in Consent Mode v2

A visible cookie banner does not prove that Consent Mode v2 is working. The test is the state received by tags before the user chooses, the subsequent update and the actual behaviour of each tag when consent is granted, denied or changed.

Quick answer: Consent Mode v2 tells Google tags whether they may use storage, user data and ad personalisation. It does not replace a consent platform or grant permission. A correct implementation sets default states, updates the user’s choice and tests the complete journey with Tag Assistant, cookies and network requests.

What Consent Mode v2 is and what it does

The term “v2” is used for the expansion of consent mode with two advertising signals, ad_user_data and ad_personalization, in addition to ad_storage and analytics_storage. It is not a different banner or a screen that activates itself in Google Tag Manager.

The CMP presents the choices and retains the user’s preference. Google Tag Manager, when used, organises tag execution. Consent Mode communicates the states and enables compatible tags to adapt their behaviour. It can also be implemented with the Google tag without GTM.

In a digital analytics implementation, the three components must be reviewed as a chain. A banner that stores a choice but does not communicate it leaves the integration incomplete. A tag that receives the correct state after it has fired may have sent data under a previous state.

The four main consent signals

Signal What it controls Common mistake
analytics_storage Storage related to analytics, such as measurement cookies. Confusing it with permission for every analytics tool or third-party tag.
ad_storage Storage related to advertising. Assuming it also decides by itself whether user data may be sent or ads personalised.
ad_user_data Consent to send user data to Google for advertising purposes. Failing to map it because the banner only distinguishes necessary and statistics cookies.
ad_personalization Consent for personalised advertising. Granting it automatically when measurement is accepted even though the banner separates the choices.

Each signal accepts granted or denied. The mapping must reflect the purposes actually shown by the CMP. Grouping all signals for technical convenience may contradict the choices offered to the user.

Basic and advanced mode: an architectural decision

The distinction is not a scale of quality. These are two ways of deciding what tags do before consent is received. The choice must be coordinated with the privacy policy, the applicable legal position and the measurement architecture.

Criterion Basic mode Advanced mode
Before consent Google tags remain blocked until the relevant consent is granted. Tags may load with denied states and send cookieless signals.
If consent is denied The same measurement flow as a consented visit does not occur. Compatible tags adapt their behaviour and may send cookieless pings.
Modelling Fewer site-specific signals are available to models. Cookieless signals may contribute to modelling when requirements are met.
Practical implication Tag blocking and release must be controlled correctly. You must understand which requests are sent even when states are denied.

“Cookieless” does not mean “no data communication”. Nor does it mean that an advanced implementation is suitable for every website. Consent Mode does not determine whether consent is legally valid, whether the information provided is sufficient or whether a third-party tag respects the selection.

Do not choose advanced mode simply to try to increase conversion numbers. Modelling does not recover an individual record of users who denied consent, is subject to requirements and does not guarantee that every missing conversion will be reconstructed.

How to configure Consent Mode v2 in the correct order

1. Inventory tags, domains and entry points

Review the GTM container, plugins, theme code and directly embedded scripts. Include campaign pages, subdomains, iframes and external forms in the journey. A GA4 tag in the theme and another in GTM can duplicate events even if one of them respects consent.

Document which CMP collects the preference, which categories it presents and how they map to the four signals. Installing a second CMP over an existing one does not resolve a source conflict: first locate who displays the banner, who retains the choice and who loads each tag.

2. Set default states before measurement

The default state must be set before commands that send data. In GTM, the tag or template that establishes consent should use the Consent Initialization mechanism. Tags that do not manage consent should not use that trigger merely to run early.

If the implementation uses gtag.js, the default command must run before measurement configuration. When the CMP loads asynchronously, wait_for_update can allow time for the update, but it does not by itself repair an incorrect loading order.

3. Update and retain the choice

Consent Mode does not store the user’s decision itself. The CMP or custom solution must retain it and send the update as soon as the person confirms their preferences. The choice must be restored on later pages without being overwritten by generic values.

The update must also work when previously granted consent is withdrawn. Waiting until the next visit may leave events on the current page under an earlier state. Google’s technical Consent Mode instructions describe default commands and updates; they must be adapted to the actual CMP and container.

4. Review built-in and additional checks

Compatible Google tags include built-in consent checks. In GTM, “additional checks” serve another purpose: they can require extra states before a tag fires. Adding them without understanding the built-in behaviour can block a tag unnecessarily or create a false sense of protection.

Third-party tags do not automatically inherit Google’s behaviour. Each provider needs an explicit rule and its own test. A Tag Management architecture helps identify owners, triggers and dependencies, but it does not replace the assessment of purpose.

How to test the implementation from start to finish

Test with a clean session and record the URL, action, expected state and observed state. Tag Assistant shows default and updated consent states, but validation must also cover cookies, browser storage and network requests. Seeing denied on a screen does not by itself prove that every tag respects it.

  1. No interaction: check the default state and the requests made under the chosen mode.
  2. Reject all: confirm that no signal is granted by mistake and that each tag responds according to its purpose.
  3. Accept all: review the update and complete a test conversion to detect omissions or duplicates.
  4. Choose by category: compare each signal with the selection; do not assume that all of them change together.
  5. Change preferences: grant, withdraw and grant again to check updates on the same page.
  6. Navigate and return: validate persistence across relevant pages, templates and subdomains.

Repeat the journey on mobile, campaign pages and forms. If regional rules exist, test from the relevant effective location: changing only the browser language does not demonstrate that a different geographic configuration was applied. Use test data and avoid personal information in screenshots or technical logs.

A missing default state points to loading order. A choice that does not update points to the CMP-to-tag connection. A duplicated event usually requires a review of installations and triggers. These are diagnostic clues, not confirmed causes until the implementation is inspected.

How to interpret measurement and maintain it

A decline after correcting Consent Mode may reveal that events were previously collected without respecting the choice. It may also result from a tag being blocked incorrectly or an update failing to arrive. Compare the change date with traffic, consent rate, diagnostics and conversions before attributing the difference to commercial performance.

Modelled data is not individual observation and does not need to match the CRM. Google Analytics and Google Ads use different requirements, windows and rules. Separate observed events, modelled results and sales recorded by the business when assessing measurement quality.

Key points for completing the implementation

  • Tag map: source, owner, purpose and trigger.
  • Consent map: CMP categories and their associated signals.
  • Documented decision: basic or advanced mode and regional scope.
  • Test evidence: no choice, reject, accept, customise, withdraw and return.
  • Maintenance plan: review after changes to the CMP, forms, templates or container.

Consent Mode v2 is valuable when the consent decision, technical execution and data interpretation remain aligned. A one-off configuration is not enough: any change to the banner or tags can alter the journey.

Frequently asked questions

Does Consent Mode v2 replace a CMP?

No. Consent Mode communicates states to compatible tags, but it does not present choices or retain the decision itself. You need a CMP or a correctly integrated custom solution to collect and store preferences.

Does Consent Mode v2 guarantee legal compliance?

No. It can be used to check the technical behaviour of tags, but it does not determine whether the wording, purposes, legal basis or method of obtaining consent meet the applicable obligations. That assessment requires appropriate legal advice.

Does advanced mode measure every rejected conversion?

No. It may send cookieless signals that contribute to modelling when requirements are met, but it does not create individual profiles of users who denied consent or guarantee recovery of every conversion.