Consent Mode v2 rollout - a step-by-step guide for WordPress and WooCommerce

A client calls because GA4 shows fewer purchases than the store shows orders, and Google Ads has stopped counting conversions. They then search for a Consent Mode v2 rollout guide and land on ten articles, each starting with a different plugin, none of which explains how to confirm the thing actually worked. So I am going to run this the other way around: what breaks without consent signals, how to set it up, and the test that answers “working” or “not working” in five minutes.

Consent Mode is the mechanism by which your site tells Google’s scripts what the visitor agreed to, before those scripts store anything. Version two added two new signals about advertising data. Without them, some of Google’s advertising features stop behaving the way you expect for traffic from the European Economic Area - and that is usually the moment someone picks up the phone.

One thing up front: I am writing as a developer who implements and tests measurement, not as a lawyer. The duty to ask for cookie consent comes from data protection and electronic communications law, not from Google’s rules. How to word the consent notice and the privacy policy is a question for a lawyer. My job is to make sure that, in the code, the answer the visitor gives is actually respected.

What Consent Mode v2 is, and what breaks without it

Technically, Consent Mode is a set of states passed to Google tags before they run. Version one knew two: ad_storage (advertising cookies) and analytics_storage (analytics cookies). Version two added ad_user_data (may user data be sent to Google for advertising purposes) and ad_personalization (may ads be personalised, which covers remarketing). Four switches, each either granted or denied.

What happens without it? The first scenario, and the more common one in the sites I inherit: the consent banner is there, it looks fine, and it is connected to nothing. Cookies are written no matter what the visitor clicks, because the banner only hides itself. Measurement is complete, but consent is fiction - and that is a real exposure, not a theoretical one.

The second scenario: the banner does block scripts, but Google never learns anything about consent state. Visitors who declined leave no trace at all - no cookie, and no cookieless signal either. As far as Google is concerned that slice of traffic never happened, so campaigns optimise on truncated data and your reports show fewer sales than you actually made. In both cases you are making budget decisions on numbers that do not describe reality, which is the same trap I pull apart in my comparison of SEO and Google Ads on pure economics.

What a rollout costs - market ranges

The cost splits into three parts, and they are worth separating because each behaves differently.

• The consent banner (CMP). WordPress plugins typically offer a free tier for low traffic and a paid subscription above it, running from tens to a few hundred zloty a year depending on pageviews and whether you need several languages. Google maintains a list of certified consent platforms and expects one of them for some of its advertising products, so check that list before you buy.
• Configuration and wiring it to the tags. This is labour, not a licence: setting default states, connecting the banner to GTM or gtag, verifying load order. On the market, the rollout itself on a typical site or store usually runs from a few hundred zloty to around 2500 zloty net depending on scope - and I want to be clear that this is a rough market reality, not my price list.
• Testing and a comparison against real orders. The part most often skipped, and the cheapest to do straight away, because without it you have no idea whether the first two items achieved anything.

What pushes a quote to the top of the range: a store with many tag sources (Google Ads, Meta, Hotjar, affiliate scripts), a custom theme with scripts hardcoded into header.php, multiple languages, and aggressive caching. What keeps it low: a clean WordPress install, a single GTM container, and consent handled alongside other work.

What helps: before paying for anything, open your browser’s developer tools and count how many cookies the site writes before you click a single thing in the banner. If analytics and advertising cookies are already there, you know where to start - and you have an argument against buying the most expensive plan just in case.

Rolling it out on WordPress and WooCommerce

Order of operations matters more here than the choice of plugin. Consent Mode has to set the default state before any Google tag fires. A second too late and the first request still goes out with no consent information attached.

In practice I work through this list:

1. Pick one consent plugin and disable the rest. Two banners at once is the single most common reason a rollout appears not to work. Often one lives in a plugin and the other was left in the theme by a previous developer.
2. Turn on its Consent Mode v2 mode and confirm it handles all four signals, not just the two from the older version. Good plugins state this plainly in their settings.
3. Set the default state to denied for European Economic Area traffic, and raise it to granted only after the visitor accepts.
4. Wire it to the tags. If the site already runs Google Tag Manager, I inject consent state once, in GTM, and set required consent per tag there - running Consent Mode v2 in GTM is simply more comfortable, because you never touch theme code again. If measurement goes through plain gtag, the plugin has to call gtag('consent', 'default', ...) before GA4 loads.
5. In WooCommerce, check the purchase event. The purchase event fires on the thank-you page, and that page must never be cached and must not lose the consent script. This is exactly the caching trap I describe in the piece on why WooCommerce carts get abandoned for technical reasons.
6. Clear the cache and test in a private window, because your own browser remembers the consent you gave earlier and shows you a state a new visitor will never see.

If the theme has scripts pasted straight into the header, plugin settings alone will not cover them; they have to be brought under consent control. That is usually where I come in: I speed up and repair existing sites and stores, so I clean up those stray scripts as part of the measurement work instead of wrapping them in yet another plugin.

Basic or advanced - how to choose

This is the one decision in the whole rollout that deserves actual thought rather than a tick in a box.

Basic means Google tags do not run at all until the visitor accepts. Nothing is sent, not a single request. It is simpler and the most conservative option, but you learn nothing whatsoever about visitors who decline.

Advanced loads the tags immediately with every consent signal set to denied. The tag then sends a cookieless ping - no identifier, nothing stored on the device - and Google uses those pings to model the missing conversions. You get richer reports, but traffic reaches Google before anyone clicks accept, which needs to be described in your privacy policy and, in my view, checked with a lawyer.

What I choose for clients: advanced for stores genuinely spending money on Google Ads, because the modelling clearly helps campaign optimisation there. Basic for brochure sites and anywhere the owner wants maximum caution and runs no paid campaigns. Switching modes later is one setting, so it is not a decision you are stuck with.

How to check that Consent Mode v2 works

This is where the guides stop and the real work starts. I do not trust a plugin telling me Consent Mode is active - I look at network traffic. Plenty of people go hunting for a dedicated consent mode checker at this point, but everything you need is already in the browser.

1. Open the site in a private window and filter the network tab for requests to Google.
2. Before clicking anything in the banner, look at the gcs parameter on the request. G100 means both states denied, G111 means both granted. No gcs parameter at all is a bad sign: Consent Mode either did not load or loaded too late.
3. Check the gcd parameter next to it - this is the step missing from most guides. gcs only encodes the two older states, advertising and analytics, which is version one. The signals added in version two, ad_user_data and ad_personalization, travel in gcd. If gcs is there but gcd is not, the site is still sending plain Consent Mode v1, and that is exactly the case where the plugin shows a green badge while the v2 rollout does not actually exist. Tag Assistant also spells out all four states in its consent tab, in plain words.
4. Accept consent and reload. The gcs code should flip to G111, and only now should analytics and advertising cookies appear in the application tab.
5. Decline in a fresh private window and confirm no cookies are written. This is the test that exposes a decorative banner: if cookies land despite a refusal, consent is not being respected.
6. Open DebugView in GA4 - events should carry a visible consent state, and the conversion diagnostics in Google Ads should stop reporting missing consent signals.

One warning so nobody is disappointed: after a correct rollout, GA4 will report fewer purchases than WooCommerce, not the same number. Every refusal is genuinely lost measurement, and no rollout reverses that.

What I do differently - comparing against real orders

A standard rollout ends when the plugin shows a green badge. I end mine with numbers from two sources.

Afterwards I take the order count from the WooCommerce dashboard for a given period and the count of purchase events in GA4. The gap between them is not an error, it is a map: it shows what share of customers decline and how much measurement you are really losing. Only with that number in hand is it worth discussing whether to switch to advanced mode or redesign the banner itself - because a banner that scares people off is a conversion problem, not only a measurement one. The exercise tends to surface issues that have nothing to do with consent, which I collect in one place in the usual causes of low conversion on a company website.

The second test I always run: I walk the entire purchase path in a private window having declined consent, and check whether the store still works. I have seen setups where declining consent broke the cart script, because someone had grouped it with analytics. The store measured nothing and sold nothing, and nobody noticed, because the owner clicked accept out of habit every time.

Summary

Consent Mode v2 means passing four consent states to Google tags before they store anything. On WordPress and WooCommerce the rollout comes down to one banner, a default state of denied, wiring it into GTM or gtag ahead of the Google tags, and keeping the thank-you page out of the cache. Then you pick basic or advanced, and finally you check the gcs and gcd parameters in the browser and compare GA4 against store orders.

The worst possible outcome is a banner that looks correct and does nothing: you carry the consent exposure and a hole in your measurement at the same time. Five minutes in developer tools settles it for good.

Frequently asked questions

Is Consent Mode v2 mandatory? The obligation to ask for cookie consent comes from legislation, not from Google’s terms. Consent Mode is the technical way of passing that answer to Google’s tools, and a condition for some of their advertising features working on European Economic Area traffic. In short: you have to collect consent either way, and Consent Mode decides whether your measurement and campaigns get anything out of it. Confirm the legal scope with a lawyer.

Is a consent banner plugin enough on its own? Only if it supports Consent Mode v2 and genuinely controls every script on the page. If the theme or an old plugin pastes Google code straight into the header, the banner will not block it and the rollout is cosmetic. That is why I always check cookies in the browser after installation rather than trusting the dashboard.

Why do I have fewer conversions in GA4 after the rollout? Because that is how it is supposed to work. Visitors who declined leave no complete trace, so reports come in below the WooCommerce order count. Advanced mode fills part of that gap with modelling, but it never returns you to the days when cookies were written for everyone without asking.

Google Tag Manager or gtag? If GTM is already on the site, I stay with it: required consent is configured per tag and you never touch theme code again. If the site only has a gtag snippet, staying with that is simpler and cheaper, as long as the consent plugin sets the default state before GA4 loads. The bad option is running both, because two tag sources then compete over the same measurement.

Sitting on this yourself and unsure where to start? I speed up and repair existing sites and stores - Core Web Vitals, outages, the features that are missing. Let’s talk about your project.