How to check if Consent Mode is working: a step-by-step checklist

You check whether Consent Mode is working in the browser, not in the cookie banner's settings screen. The banner showing a tidy "accept" and "reject" button tells you nothing about what your tags actually do. To verify Consent Mode v2 is real, you open Chrome DevTools and Google Tag Assistant, watch what fires before and after consent, and confirm all four consent signals update correctly. This checklist walks those checks one by one, with what a passing result looks like at each step.

The reason this matters: a banner that looks perfect is the single most common compliance gap I find. It pops up, it logs a choice, the legal team is satisfied, and underneath GA4 has been firing on page load before anyone clicked a thing. The banner is theatre; the tags are what the regulator and your data both care about.

This assumes you've already set up Consent Mode v2 and just want to confirm it works. If you're earlier than that, start with the Consent Mode v2 implementation guide and come back to verify once it's in place.

Why a banner that "looks fine" often isn't

Consent Mode has two failure modes, and both hide behind a banner that looks completely normal.

The first is tags that fire too early. The banner appears, but GA4, the Meta pixel, or Google Ads already sent a hit before the user touched it. That's a straight compliance breach: you collected data before consent. It usually happens when the tags aren't actually gated by the consent state, just sitting on a page-load trigger as if the banner weren't there.

The second is signals that never update. The default state is set, but when the user clicks accept or reject, nothing changes. Consent Mode is sending the same denied (or granted) signal no matter what the visitor chose, so either you're losing data you're allowed to collect or collecting data you're not. Both look identical from the front end. You can only see the difference in the browser.

What you need before you test

Three free tools cover everything in this checklist. Get them open before you start.

• Chrome DevTools (Network tab). Built into Chrome. This is where you watch what actually leaves the browser and read the gcs parameter.
• Google Tag Assistant. Connects to your site and shows each tag, its consent state, and whether it fired or was blocked.
• GA4 DebugView. Confirms GA4's side: that events arrive with the right consent state. My guide to GA4 debug mode and DebugView covers setup if it's new to you.

Open your site in an incognito window so you start from a clean, no-consent state, and keep DevTools on the Network tab filtered to your analytics domains.

The Consent Mode checklist: 7 things to verify

Work through these in order. Each one has a clear pass condition, so you know exactly what you're looking for.

#	Check	Tool	Pass looks like
1	Tags silent before consent	DevTools / Tag Assistant	No GA4 or Ads hits before a click
2	Default state is denied	Tag Assistant consent tab	All four signals "denied" on load (EU)
3	Signals update on choice	DevTools / dataLayer	Values change on accept and reject
4	All four v2 signals present	Tag Assistant	ad_storage, ad_user_data, ad_personalization, analytics_storage
5	Cookieless pings on denial	DevTools Network	Pings still fire with gcs=G100
6	GA4 confirms consent state	GA4 DebugView	Events show the correct consent state
7	Ads sees Consent Mode	Google Ads diagnostics	Consent Mode detected, modeling eligible

1. Tags stay silent before consent

In an incognito window, load the page and watch the Network tab before you click anything. You should see no collect requests to GA4 and no conversion hits to Google Ads. If a hit goes out on page load with the banner still sitting there unanswered, that's the breach, and it's the most common one. Fix this before anything else.

2. The default consent state is denied

Open Tag Assistant and read the consent state on page load. In the EU, all four signals should read "denied" by default, because you're not allowed to assume consent. If anything shows "granted" before the user chose, your default is wrong and you're collecting on an assumption you can't make.

3. Signals update when the user chooses

Click accept, then watch the dataLayer or Tag Assistant. You should see a consent "update" event flip the relevant signals to "granted." Reload, click reject, and confirm they stay denied. If the signals don't move when you click, Consent Mode is decorative: it's sending one fixed answer regardless of choice.

4. All four v2 signals are present

Consent Mode v2 added two signals to the original two. Confirm you're sending all four: ad_storage, ad_user_data, ad_personalization, and analytics_storage. If you only see ad_storage and analytics_storage, you're on the old v1 setup, which Google no longer accepts for EEA ad features. This is a quiet way to lose remarketing and conversion data.

5. Cookieless pings fire on denial (Advanced mode)

If you run Advanced Consent Mode, rejection shouldn't mean silence. GA4 and Ads still send cookieless pings so Google can model the conversions you lost to the rejection. In the Network tab after clicking reject, you should still see hits going out, just with the consent signals denied. No pings at all on rejection usually means you're on Basic mode, which recovers nothing.

6. GA4 confirms the consent state

Open DebugView and trigger an event. GA4 should show the event arriving with the consent state that matches what you chose. This is the analytics-side confirmation that the signal you sent in the browser actually reached GA4 intact, not just that it left your page.

7. Google Ads sees Consent Mode

In Google Ads, check the conversion diagnostics. A correctly wired setup shows Consent Mode detected and your conversions eligible for modeling. If Ads reports no Consent Mode signal, the Ads tags aren't reading the consent state even if GA4 is, and your modeled conversions won't materialize.

The gcs parameter: a 30-second check

If you only have time for one check, read the gcs parameter. Every GA4 and Ads hit in the Network tab carries a gcs value that encodes the consent state at the moment it fired.

gcs=G100 means consent was denied. gcs=G111 means analytics and ad storage were granted. So the quick test is: load the page, find a collect request, and read its gcs. Before consent it should be G100 (or no hit at all). After accepting, the next hits should show G111. If you accept and the gcs stays G100, the grant never propagated, and that single string just told you the setup is broken. Google's Consent Mode documentation lists the full parameter format.

When Ania, who runs an ecommerce store, swore her banner was "definitely working" in 2025, the gcs check settled it in under a minute. Every hit read G100, even after accepting everything. The banner updated its own cookie but never called the consent update, so Google thought every single visitor had denied. She'd been running on modeled data for months without knowing her real consent signal never fired.

What to do when a check fails

A failed check almost always traces back to one of two causes, and both are fixable.

If tags fire before consent (check 1) or the signals never update (check 3), the problem is timing: your tags aren't gated by the consent state, or the banner updates its cookie without telling Google. This is exactly the race condition my Universal Consent Adapter was built to solve, a GTM template that reads the consent cookie and fires the update reliably. If you're missing two of the four signals (check 4), revisit the Consent Mode v2 setup and add the new parameters.

And if you go through all this and decide the cleaner answer is analytics that doesn't lean on consent gymnastics at all, that's one of the reasons EU-hosted tools come up, which I compared in Piwik PRO vs GA4.

Conclusion

Consent Mode either works or it doesn't, and the only place that question gets answered is the browser. Run the seven checks: tags silent before consent, default denied, signals updating on choice, all four v2 signals present, cookieless pings on denial, GA4 confirming the state, and Ads seeing it. The gcs parameter gives you a 30-second gut check any time you're unsure.

If that's more browser debugging than you want to do, or you'd rather have someone confirm it independently, a free GTM audit checks your consent setup along with the rest of your tags, and ongoing GTM monitoring catches it the next time a site update quietly breaks the wiring. A banner that looked fine last quarter is exactly the kind of thing that drifts.

FAQ

How do I know if Consent Mode is working?

Check it in the browser, not the banner UI. Open Chrome DevTools on the Network tab and confirm no GA4 or Ads hits fire before you click the banner, then accept and confirm the gcs parameter on outgoing hits changes from G100 (denied) to G111 (granted). If tags fire before consent or the gcs never updates, Consent Mode is not working.

What is the gcs parameter in Consent Mode?

The gcs parameter is a value on every GA4 and Google Ads hit that encodes the consent state when the hit fired. gcs=G100 means consent was denied, and gcs=G111 means analytics and ad storage were granted. Reading it in the DevTools Network tab is the fastest single check of whether Consent Mode is reflecting the user's choice.

What are the four signals in Consent Mode v2?

Consent Mode v2 sends four signals: ad_storage, ad_user_data, ad_personalization, and analytics_storage. The first version only used ad_storage and analytics_storage. If your setup is only sending those two, you're on the outdated version, which Google no longer accepts for EEA advertising features.

Why is GA4 collecting data before I accept cookies?

Because the GA4 tag isn't actually gated by the consent state. It's firing on a normal page-load trigger as if the banner weren't there, which is a compliance breach. The fix is to ensure tags read the default denied consent state and only fire fully once the consent update grants analytics_storage. This is the most common Consent Mode failure.

Does Consent Mode still collect data when a user rejects?

In Advanced mode, yes, in a limited, privacy-safe way. GA4 and Ads send cookieless pings carrying the denied consent signals so Google can model the conversions lost to rejection. In Basic mode, rejection blocks the tags entirely and nothing is sent, so no modeling happens. Which one you run is a deliberate choice with a real data trade-off.

Can I test Consent Mode without any tools?

Not reliably. The banner gives you no insight into what tags do, so you need at least the Chrome DevTools Network tab to see outgoing hits and read the gcs parameter. Google Tag Assistant and GA4 DebugView add confirmation. All three are free, and without them you're guessing whether your consent setup is compliant.