Category: Google Consent Mode
analytics_storage
Also known as: analytics_storage consent parameter, analytics_storage consent type
Simply put
analytics_storage is one of the consent settings used in Google's Consent Mode to indicate whether a user has agreed to storage used for analytics purposes, such as analytics cookies. When it is set to 'denied,' Google's tags are instructed not to use that storage, though limited cookieless measurement may still be possible through mechanisms like URL passthrough. It is one of several signals a website communicates to Google based on a user's cookie consent choices.
Formal definition
In Google Consent Mode, analytics_storage is a consent parameter that governs storage (such as cookies) related to analytics functionality. It functions as an upstream qualifier that controls which identifiers are sent with analytics pings; when set to 'denied,' cookie-based storage is withheld and Google may fall back to cookieless approaches such as URL passthrough to send event- and session-based analytics data (including key events). It is one of four consent parameters used in Consent Mode v2, alongside ad_storage, ad_user_data, and ad_personalization, where implementation of the full v2 signal set is required primarily for properties serving EEA/UK users that rely on Google's ad-related services; properties not using those services are not compelled to implement Consent Mode v2 in the same way. The state of analytics_storage (granted or denied) is intended to reflect the user's consent decision, but the parameter itself is a technical signal and does not by itself determine whether the underlying consent is valid under the ePrivacy rules governing storage on a user's device or under the GDPR governing any resulting personal data processing; those assessments require separate legal judgment and vary by jurisdiction.
Why it matters
analytics_storage sits at the boundary between a user's cookie consent choice and how Google's analytics tags behave, which makes it a practical concern for anyone responsible for accurate measurement and defensible compliance. When the parameter is set to 'denied,' Google's tags are instructed not to use cookie-based storage for analytics, and the platform may fall back to limited cookieless measurement such as URL passthrough to send event- and session-based data. Misconfiguring this signal, leaving it 'granted' when a user has not consented, for example, can mean storage is used on a user's device without a valid legal basis under the ePrivacy rules that govern such storage in most EU jurisdictions and the UK.
Who it's relevant to
Web developers and analytics implementers
Those configuring Google tags and consent management platforms need to map a user's consent choices to the correct analytics_storage state and understand its behavior, including the fact that a 'denied' state permits limited cookieless measurement through mechanisms such as URL passthrough rather than disabling analytics entirely. Correct wiring between the consent mechanism and the parameter is a technical prerequisite for the signal to reflect the user's actual decision.
Privacy officers and data protection professionals
This group is responsible for confirming that the default and granted states of analytics_storage align with a valid legal basis. Because the parameter is a technical signal and not a determination of validity, they must separately assess whether storage on the user's device is permitted under the applicable ePrivacy rules and whether any resulting processing complies with the GDPR, recognizing that these obligations differ across the EU, the UK, and US state regimes.
Marketing and measurement teams
Teams relying on Google Analytics data should understand how a 'denied' analytics_storage state affects the completeness and nature of measurement, since cookieless fallback data differs from cookie-based collection. This helps set realistic expectations about data quality when consent is not granted, without pressuring consent design in ways that could undermine its validity.
Legal counsel
Counsel advising on whether analytics_storage should default to granted or denied for particular audiences must consider jurisdiction, the categories of data involved, and evolving guidance from the relevant data protection authorities. The parameter supports a compliance strategy but does not replace the legal judgment required to determine lawfulness in a given context.
Inside analytics_storage
Consent state parameter
analytics_storage is one of the consent parameters used in Google Consent Mode. It governs whether storage (such as cookies) related to analytics may be used, for example to measure visits and sessions. It is set to a granted or denied state based on the user's choices.
Relationship to consent obtained via a CMP
The analytics_storage signal is typically driven by the outcome of a consent management platform (CMP) interaction. When a user consents to analytics purposes, the parameter is generally set to granted; when they decline or before a choice is made, it is set to denied. The CMP collects and records the consent; analytics_storage communicates that decision to Google tags.
Behavior when denied
When analytics_storage is set to denied, Google tags are designed not to write or read analytics cookies. Depending on configuration, some non-cookie, aggregated or modeled signals may still be sent in certain implementations, which is a contested area and depends on the specific product and settings in use.
Distinction from ad-related parameters
analytics_storage is separate from ad-related consent parameters such as ad_storage, ad_user_data, and ad_personalization. Analytics consent and advertising consent are distinct categories and should be captured and signaled independently rather than treated as a single toggle.
Legal basis it depends on
Because analytics cookies typically require prior consent under EU and UK ePrivacy rules (with the GDPR governing any resulting personal data processing), the analytics_storage parameter should reflect a valid, freely given, specific, informed, and unambiguous consent where such consent is required. The parameter is a technical signal and does not itself establish a lawful basis.
Common questions
Answers to the questions practitioners most commonly ask about analytics_storage.
Does setting analytics_storage to 'granted' by itself make my analytics cookies compliant?
No. analytics_storage is a technical signal that tells a tag whether it may use cookies or similar storage for analytics purposes; it does not, on its own, establish a valid legal basis. In most EU and UK contexts, analytics cookies typically require prior, freely given, specific, informed, and unambiguous consent obtained through a clear affirmative action before the parameter is set to 'granted'. The signal reflects a consent decision but does not create or replace one, and it does not substitute for the underlying compliance work such as providing adequate information and honoring the user's choice. Whether your configuration is lawful depends on facts outside the parameter itself, including how consent is collected and logged.
Is implementing analytics_storage through Consent Mode mandatory for all traffic from the EEA?
Not universally. The obligation to implement Google's Consent Mode signals, including analytics_storage, generally applies to sites and apps that rely on certain Google advertising and related services for users in the EEA and UK, rather than to every property serving EEA traffic. Properties that do not use those Google services are not compelled by Google to implement Consent Mode, though they may still choose to. Separately from any vendor requirement, the underlying legal duty to obtain consent for non-exempt analytics storage arises from the ePrivacy rules and GDPR, and that duty exists independently of which technical mechanism you use to reflect the consent decision.
What is the practical difference between analytics_storage set to 'denied' versus not sending the signal at all?
When analytics_storage is set to 'denied', the associated tags are instructed to operate without reading or writing analytics-related cookies or similar storage, adjusting their behavior accordingly. Omitting the signal entirely leaves behavior to default configuration, which may vary and could result in storage being used before a consent decision is captured. Because the default state matters, it is generally advisable in EU and UK contexts to configure a default of 'denied' for non-exempt analytics before consent is obtained, then update to 'granted' only after a valid affirmative choice. The exact behavior depends on your tag setup and vendor implementation, so this should be verified in your own configuration.
How should analytics_storage interact with a consent management platform (CMP)?
In a typical setup, the CMP captures the user's consent choice and passes that decision to the tagging layer, which then sets analytics_storage to 'granted' or 'denied' accordingly. The CMP is generally responsible for collecting the choice, presenting the required information, and maintaining a record of consent, while the analytics_storage parameter is the downstream signal that governs tag behavior. It is important to confirm that the CMP and the tag configuration are correctly integrated so that the signal reflects the actual choice, and to remember that the CMP supports compliance but does not by itself guarantee it; legal judgment remains necessary.
Should the default state of analytics_storage be the same for EU users and US users?
Not necessarily, because the applicable requirements differ by jurisdiction. In most EU and UK contexts, non-exempt analytics storage generally requires prior opt-in consent, which points toward a default of 'denied' until consent is given. Several US state frameworks instead commonly rely on an opt-out model, where analytics may operate unless the user exercises a choice to opt out. Because of this, organizations often configure the default state based on the user's location or applicable law. The appropriate approach depends on the specific regimes that apply to your users and on facts not covered by the parameter itself, so scope each configuration to the relevant jurisdiction.
Do I still need to keep records if analytics_storage reflects the user's choice?
Yes, in most EU and UK contexts the ability to demonstrate that valid consent was obtained is generally expected, and the analytics_storage signal alone does not constitute a durable consent record. The signal governs tag behavior at runtime but is not designed as an audit log. Consent record-keeping is typically handled by the CMP or a separate logging mechanism that captures what the user was shown and what they chose. What specifically must be retained, and for how long, can depend on the applicable framework and evolving guidance from data protection authorities, so confirm your record-keeping approach against the requirements that apply to you.
Common misconceptions
Implementing Consent Mode, including the analytics_storage parameter, makes a site compliant with EU and UK cookie rules.
Consent Mode is a technical mechanism for signaling consent states to Google tags; it supports compliance but does not replace a compliant consent mechanism or legal judgment. Compliance depends on how consent is actually collected, presented, and recorded, and on the applicable law in each jurisdiction.
Every website must implement Consent Mode v2, including analytics_storage, for EEA and UK visitors.
The requirement to implement Consent Mode v2 applies to sites and apps that rely on Google Ads-related services and features for users in the EEA and UK. Properties that do not use those services are not compelled by Google to implement Consent Mode v2, though they still remain subject to applicable ePrivacy and data protection obligations for analytics cookies.
Setting analytics_storage to granted by default is acceptable as long as a banner is shown.
Where prior consent is required, as is generally the case for analytics cookies in the EU and UK, the parameter should default to denied until the user provides a clear affirmative action. Defaulting to granted can mean analytics cookies are set before valid consent, which is widely regarded as non-compliant in those jurisdictions. Requirements differ under opt-out based US state frameworks.
Best practices
Default analytics_storage to denied for users in jurisdictions requiring prior consent, such as the EU and UK, and only set it to granted after the user provides a clear affirmative action through your CMP.
Keep analytics consent distinct from advertising consent by managing analytics_storage separately from ad-related parameters, so users can accept or decline each purpose independently.
Ensure the consent state signaled by analytics_storage is driven by, and stays synchronized with, the actual choices recorded in your CMP, and maintain consent records to support record-keeping obligations.
Confirm whether Consent Mode v2 applies to your property based on your use of Google Ads-related services for EEA and UK users, rather than assuming it is universally mandatory.
Account for jurisdictional differences: opt-in consent for analytics is generally required in the EU and UK, while several US state frameworks rely on opt-out signals, so align your analytics_storage logic with each user's applicable regime.
Treat Consent Mode and the analytics_storage parameter as tools that support compliance, and validate your overall banner design, consent capture, and legal basis with qualified privacy or legal advice rather than relying on the technical signal alone.
