Consent mode v2: what actually changes

Google's developer guide is specific: consent mode was updated in November 2023 and now contains two additional parameters, with existing implementations directed to upgrade.

The four consent types appear together in Google's own default example: ad_storage, ad_user_data, ad_personalization and analytics_storage. The first and last govern storage. The two added ones govern whether user data may be sent to Google for advertising, and whether it may be used for personalisation.

That separation is the substance of the change. Before it, consent was largely a question about cookies. After it, sending and personalising are separate answers, which means a visitor can consent to measurement without consenting to personalised advertising, and your tags have to be able to express that.

The requirement is scoped to traffic in the European Economic Area in Google's documentation, which does not make it irrelevant elsewhere. If any meaningful share of your traffic is in scope, the implementation is in scope, and running two different tagging behaviours by geography is harder than running one correct one.

This gets confused in almost every kick-off meeting I have attended. Google states it plainly: consent mode does not provide a consent banner or widget, it interacts with your banner to obtain visitor consent.

So buying a consent management platform is not implementing consent mode. It is buying the part that asks the question. Consent mode is the part that carries the answer to the tags, and the tags are the part that has to act on it.

The practical consequence is that responsibility lands in three places at once: whoever owns the banner, whoever owns the tag manager, and whoever owns the website's page lifecycle. Projects fail at the seams between those three, not inside any of them.

Google's overview lists the tags that carry built-in consent checks, including the Google tag, Google Analytics, Google Ads conversion tracking and remarketing, Floodlight and the Conversion Linker. Anything outside that list, including your own custom tags, needs checks configured deliberately.

Google describes the two directly: basic blocks tags until consent, while advanced loads tags with default settings and adjusts behaviour based on consent, allowing for more detailed conversion modelling.

The same page explains where modelled numbers come from: consent mode uses pings to communicate consent status and key events, and those pings are what enable conversion and behavioural modelling in Google Ads and Analytics.

So advanced buys you estimated coverage for the population that declined. Basic gives you a cleaner, smaller dataset with a hole where those people were.

This is a business decision with a compliance posture attached, not a technical preference. Make it deliberately, write down who made it and why, and revisit it when either the law or your traffic mix changes.

Order first. Google's guide says to set a default value for each consent type you use, and that by default no consent mode values are set at all. The default command has to run before any commands that send measurement data. Get the order wrong and the first hit of every session leaves before consent has been expressed.

Region scoping second. The guide calls it best practice to scope default consent settings to the regions where you surface banners, which preserves measurement where banners are not required and prevents behaviour that does not apply.

Timing third, and this is the one that quietly breaks: consent updates must be tracked on the page where they occur, before any page transition. A banner that accepts consent and immediately navigates has told the tags nothing.

Asynchronous banners fourth. Where the banner may load after the tags, Google's guide documents wait_for_update with a millisecond value to control how long to wait before data is sent. Without it, a slow banner produces a race condition that behaves differently on fast and slow connections, which is why it passes testing on an office network and fails on mobile.

None of those four is visible in a report. All of them are visible in a debug session, which is why this work is verified in the browser rather than in a dashboard.

Expect conversion counts to move, and expect the movement to be uneven across campaigns rather than a uniform percentage. That unevenness is the tell that the change is consent-related rather than performance-related.

Expect audience and remarketing lists to be smaller, because people who declined are not added. Campaigns depending on those lists lose reach before anyone notices the cause.

Expect some figures to be modelled rather than counted. That distinction matters when a finance team asks whether a number was measured, and the honest answer needs to be available before the question is asked, not improvised after it.

And expect enhanced conversions to be affected, because sending user-provided data is exactly the behaviour these signals govern. Enhanced conversions supplement a conversion with hashed first-party data, and whether that data may be sent is a consent question, so the two projects have to be sequenced together.

Open the site in a fresh session with tag debugging on, and watch what fires before you touch the banner. If measurement data leaves before any consent decision, the default is not set or not running early enough.

Then accept, and confirm the update reaches the tags on the same page, before any navigation. Then decline, in another fresh session, and confirm the tags behave differently. A setup that behaves identically in both cases is not implemented, whatever the banner reports.

Then repeat on mobile, on a real network. The race conditions only appear where loading is slow.

Then check the campaign landing pages specifically, not just the home page. Consent implementations are usually applied through a container that is present on the main site and occasionally missing from a standalone landing page, which is the conditional failure pattern that survives launch QA.

This is unglamorous verification work and it is the whole job. Proving each path in a real session, and writing down what was proved, is the actual deliverable of GA4 and Tag Manager implementation, and it is the only way anyone can say the consent setup does what the business believes it does.

In most organisations the banner is owned by legal or a vendor, the tags by marketing, and the page lifecycle by engineering. Nobody owns the seam, which is exactly where every failure lives.

Name one owner for the whole path, even if they cannot do every part themselves. The owner's job is that the three parts agree, and that somebody re-tests after each website release.

Put the re-test into the release checklist rather than the calendar. A quarterly audit finds the problem some time after it shipped, and by then you have a quarter of data you cannot fully trust. A release checklist finds it the same day.

And keep a written record of the configuration decisions: basic or advanced, which regions, which defaults, and the date. When the rules change again, and they will, that document is the difference between a scoped change and a rediscovery project.