Consent Mode in the Denied State: Auditing Tags When the Answer Is No
Stores test the accepted path and ship the denied path unexamined. What Consent Mode v2 should be doing when consent is denied, and how to audit tag behaviour in that state.
Every consent audit we see tests the happy path: click accept, watch the tags fire, close the ticket. The state that carries the legal weight is the other one. When a visitor denies consent, or never answers at all, your tags are supposed to behave differently, and in a remarkable number of stores they behave exactly the same, because nobody ever audited the no.
Google's Consent Mode v2 is the mechanism most of these stores rely on, with its four storage parameters, ad_storage, analytics_storage, ad_user_data, and ad_personalization, gating what tags may store and send. This post explains what denied should look like in the data layer and network panel, and the audit sequence that verifies it.
What denied actually instructs
Consent Mode does not block tags; it instructs them. With ad_storage denied, Google tags must not write or read advertising cookies, and conversion measurement falls back to modelled, cookieless pings. With analytics_storage denied, analytics operates without its identifiers. The distinction matters for the audit: seeing requests leave the browser in the denied state is not automatically a failure, because cookieless measurement pings are part of the design. Seeing identifiers, stored cookies, or user data in those requests is the failure.
The default state is where stores get caught. Consent Mode must be set to denied by default, in the relevant regions, before tags load, and updated when the visitor chooses. A configuration that defaults to granted and corrects itself when the banner is answered has the sequence backwards, and the seconds before correction are when the identifiers get written.
The audit sequence
In a clean browser profile, load the site and touch nothing. Record the default consent state in the data layer, list every cookie set on first load, and note which tags fired. Then deny explicitly through the banner and repeat the record, checking that storage parameters updated, that no advertising cookies persist from the default phase, and that a page two navigation keeps the denied state. Finally accept, and confirm the update propagates, because an audit that only proves tags can be restrained has not proven the system works.
Run it per region with a VPN if you sell across regimes: the default state for a visitor under a US state regime and a visitor under the GDPR are legitimately different configurations, and templates have a habit of applying one region's logic to everyone after a redesign.
Findings worth acting on
Non-Google tags are the repeat offenders. Consent Mode governs Google tags natively; the social pixel, the affiliate script, and the review widget's tracker need their own gating in the tag manager, keyed to the same consent state. An audit that stops at Google's tooling certifies the tidiest part of the page. List every third party request in the denied state and make each one justify itself in writing.
Related reading: Auditing Consent After a Theme Update: Banners That Silently Reset, Consent for Age Verification and Identity Tools: Data Collected Before a Choice, Auditing Consent When Checkout Moves to a Third Party Page.
Frequently asked questions
Does Consent Mode block tags when consent is denied?
No, it changes their behaviour. Google tags still send limited, cookieless pings for modelling, but must not read or write advertising or analytics cookies or use personal data when the relevant storage parameters are denied. Other vendors' tags are not governed by Consent Mode and need separate gating in your tag manager.
What is the most common Consent Mode misconfiguration?
Defaults set to granted, corrected only after the visitor interacts with the banner. The standard requires denied by default before tags load in regions where consent is needed. The window between page load and correction is when identifiers are written, which is what the audit's first, untouched page load is designed to catch.
Which parameters does Consent Mode v2 use?
Four: ad_storage and analytics_storage from the original version, plus ad_user_data and ad_personalization, added in v2 and required for personalised advertising features in the EEA. An audit should record all four in default, denied, and accepted states.
How often should the denied state be audited?
After any tag manager change, theme update, or consent platform change, and on a quarterly cadence otherwise. The denied state breaks silently, because nothing visible changes on the page when a tag starts misbehaving, so only a scheduled check finds it.