Check whether your cookie consent and Consent Mode v2 work

Consent Mode is the layer where your site tells Google about the user's consent. It sets a default state before the decision and updates it after the click in the banner. Google tags — Google Ads, GA4, Floodlight — read this signal and adjust their behavior to it.

Version 2, required in the European Economic Area since March 2024, adds two new parameters to the familiar ad_storage and analytics_storage: ad_user_data and ad_personalization. Without them, from that date Google limits remarketing and audience lists for EEA and UK traffic.

ad_user_data is consent to send user data to Google for advertising purposes. ad_personalization is consent to ad personalization and remarketing. Together with ad_storage (advertising cookies) and analytics_storage (GA4 measurement) they form four independent signals — each either granted or denied.

You can see these values in the network traffic: in Google requests as the gcs parameter (for example G100 on refusal, G111 after consent) and gcd, which encodes the state of all signals. These are exactly what we look at when checking whether consent actually flips from denied to granted after acceptance.

Consent Mode runs in two modes. In Basic mode Google tags don't load until the user consents — after refusal they send nothing. It's simpler to implement, but on refusal you're left with no data and no modeling.

In Advanced mode tags load right away, but before consent they send cookieless, anonymized pings. From these Google models the conversions and behavior of users who didn't consent — measurement is fuller, but the setup needs more care.

Which one? Advanced gives more data and better modeling at higher traffic volumes; Basic can be more convenient for simple setups and a cautious approach to privacy. In both modes the same thing matters: a correct default state and respecting refusal.

Consent Mode v2 is a response to two regulations. The Digital Markets Act (DMA) requires Google — as a gatekeeper — to obtain consent before using data for ad personalization. GDPR and the European Data Protection Board's guidance call for genuine, freely given consent, in which refusal is as easy as acceptance.

That's why v2 isn't a Google setting you can skip — it's a precondition that determines whether your EEA campaigns get a full set of data at all.

A faulty setup doesn't block the site — it quietly trims the data your campaigns learn from:

• Remarketing and audience lists stop being fed by EEA traffic.
• Conversion modeling is off — some real conversions never reach the reports, and Smart Bidding loses its optimization signal.
• Ad personalization is limited, so the same budgets land less effectively.

The loss is gradual and hard to spot without measurement — which is why it's worth verifying, instead of assuming that if the banner is there, everything works.

In e-commerce the stakes are highest, because there's the most to capture: product views, add-to-carts, checkouts and purchases with real values. These feed dynamic remarketing, Enhanced Conversions and revenue-based optimization — and all of them pass through the consent layer.

Popular platforms — Shopify, WooCommerce, PrestaShop or Shoper — have Consent Mode v2 integrations, but the default configuration is rarely complete. What's usually missing is a correct default state, consistent passing of transaction values, or consent for non-Google pixels. The result: the store collects less data than it thinks, and campaigns optimize on an incomplete picture.

In short, implementation comes down to five steps:

• Connect a Google-certified consent management platform (CMP) — it collects the user's decision.
• Set the default state to denied for all four signals before the user clicks.
• Update the signals after the decision — granted or denied according to the choice.
• Wire it all through Google Tag Manager and mind the order: the CMP loads before the tags.
• Consider server-side GTM for durable measurement and control over your data, plus a clean GA4 configuration.

And most importantly: installing a CMP doesn't mean the setup works. Configurations drift, tags end up wired outside the consent mechanism, and leaks like to hide until the second page view.

Setups tend to break in a few recurring places:

• The default state isn't set to denied — tags start with full consent before the user clicks anything.
• The CMP loads after the tags, so the first requests go out before consent even takes effect.
• The Meta pixel or other trackers are wired outside the consent mechanism — Consent Mode covers Google tags, the rest has to be handled separately.
• Consent is respected on the first page view, but the leak only appears on the second visit.
• After refusal the signal doesn't flip to denied, or the tag sends data anyway.

Most of these look correct in the code and only surface in real traffic — which is why looking at the configuration alone isn't enough.

Manually: open your browser's developer tools, the Network tab, and filter by “collect” or “google”. Before clicking the banner, check that Google starts from gcs=G100 and that advertising trackers (for example Meta /tr) aren't firing yet. After acceptance the signal should flip to gcs=G111. After refusal no tag should send data — including on the next page view.

It works, but it's tedious and easy to miss a request that only fires on the second visit. That's why we built this test: enter your site's address at the top and we'll visit as a real user, click “accept” and “reject” across three scenarios, and show a report with evidence from the network traffic — no email required.