Consent default and update commands
Google Consent Mode works through two commands: a default consent state declared before any tags load, and an update issued when the user makes a choice in a consent banner. Parameters like analytics_storage and ad_storage are set to granted or denied. This page explains the default/update sequence and how it gates whether analytics events use identifiers — it is educational, not legal advice.
Default before update
Consent Mode requires a default consent state to be set before tags fire — typically denied for storage parameters in regions that need opt-in. Tags loaded under a denied default operate in a restricted way rather than dropping data entirely.
When the user interacts with a consent banner, an update command revises the relevant parameters (for example analytics_storage to granted), and subsequent behavior changes accordingly.
Parameters and ordering
Key parameters include analytics_storage and ad_storage, each granted or denied. Ordering matters: the default must be set first so no tag fires under an undefined state. Getting the sequence wrong means events may behave as if consent were granted before the user chose, which is exactly what the mechanism exists to prevent.
- default: set before any tags fire
- update: issued on the user's consent choice
- analytics_storage / ad_storage: granted or denied
How it appears in analytics and logs
If default consent is denied, tags run in a restricted mode until an update grants consent; events behave differently before and after that update.
Diagnostic use case
Configure Consent Mode's default and update states so analytics events respect the user's choice from the very first hit.
What WebmasterID can help detect
WebmasterID's privacy-first model minimises reliance on consent-gated identifiers, but understanding default/update helps when both run side by side.
Common mistakes
- Firing tags before setting the default consent state.
- Setting an update but never a default.
- Treating Consent Mode as legal compliance by itself.
Privacy and accuracy notes
Consent signals govern whether identifiers are used; they reflect privacy choices and must be honored. This is a technical overview, not legal advice — consult counsel for compliance.
Related pages
- Consent and event collection
Consent state determines whether and how analytics events may be collected. Frameworks like Google Consent Mode pass signals such as analytics_storage to adjust behaviour: with consent granted, events are collected normally; when denied, collection is restricted or limited to cookieless signals. This page explains the mechanics of consent-gated event collection — it is educational, not legal advice.
- Event batching in GA4 collection
GA4 collection can batch several events into a single HTTP request rather than one request per event, reducing network overhead. The Measurement Protocol and gtag transport both support batching within documented size and count limits. This page explains how batching works, the constraints on payload size and events per request, and why batching affects how you debug and read near-real-time data.
- GDPR and web analytics: the practical picture
The GDPR governs processing of personal data of people in the EU. For analytics that means: identifiers and IP addresses can be personal data, consent is often required for cookie-based tracking, and minimisation matters. Cookieless, first-party, anonymised measurement reduces the surface — but this is a factual overview, not legal advice.
- Privacy-first analytics
Minimise consent-gated identifiers.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.