Consent mode allows web and app developers to adjust tag and app SDK behavior based on user consent choices.
This article introduces consent mode basics. Consent mode has additional capabilities such as region-specific behavior, the ability to redact information that was previously stored, and the ability to pass information in URLs when consent is denied. For information on how to use consent mode and these additional features, see:
How to manage consent
Managing user consent requires the following:
Obtain the user's choice to grant or deny consent for storing information about their behavior. You are responsible to obtain users' consent on your website or app.
Communicate the user's consent choice to Google using Google's consent mode.
Ensure that Google tags, third-party tags, and app SDKs behave according to the user's consent choice.
For requirements 1 and 2, you can implement either a third-party Consent Management Platform (CMP) or a custom solution. Consent mode lets you set a default consent state on your website or app, so it meets the third requirement. When a website visitor or app user indicates their consent choices, tags and SDKs with consent checks adjust their behavior and user consent choices are preserved across their interaction with the website or app.
Consent mode terminology
The following terms have a special meaning in the context of consent mode:
- Consent checks: Causes tags and SDKs to modify behavior based on consent state and consent type.
- Consent state: Represents user choices and can be granted or denied, for each consent type. Tags and SDKs with consent checks modify their behavior as described in How consent affects tag behavior.
- Consent type: Indicates the type of storage. Consent can be
deniedfor each type.
Consent types include:
|ad_storage||Enables storage, such as cookies (web) or device identifiers (apps), related to advertising.|
|ad_user_data||Sets consent for sending user data to Google for online advertising purposes.|
|ad_personalization||Sets consent for personalized advertising.|
|analytics_storage||Enables storage, such as cookies (web) or device identifiers (apps), related to analytics, for example, visit duration.|
|functionality_storage||Enables storage that supports the functionality of the website or app, for example, language settings|
|personalization_storage||Enables storage related to personalization, for example, video recommendations|
|security_storage||Enables storage related to security such as authentication functionality, fraud prevention, and other user protection|
Tags that support consent mode
Tags and SDKs for the following Google products contain built-in consent checks and adjust their behavior based on consent state:
- Google tag
- Google Analytics (includes Google Analytics for Firebase SDK)
- Google Ads (includes Google Ads Conversion Tracking and Remarketing; support for Phone Call Conversions is pending.)
- Conversion Linker
How consent affects tag and app SDK behavior
In general, when users grant consent, tags function normally.
When users deny consent for ad personalization or ad user data, tags or app SDKs can't use user data for ad targeting purposes.
When users deny consent for storage, consent-aware tags or app SDKs do not store cookies (web) or device identifiers (apps). Instead, tags communicate consent state and user activity by sending cookieless pings (web), or signals (apps), to the Google server. This enables Google Ads and Google Analytics 4 properties to model conversions, see Consent mode modeling.
The following signals communicate consent state:
Consent state pings: Consent state pings are sent from each page the user visits where consent mode is implemented. These pings communicate a consent state of granted or denied for each consent type, such as ad storage or analytics storage.
Conversion pings: Conversion pings are sent to indicate that a conversion has occurred.
Google Analytics pings: Google Analytics pings are sent on each page of a website using Google Analytics when events are logged.
Pings can include:
- Functional information (such as headers added passively by the browser):
- User Agent
- Aggregate / non-identifying information:
- An indication for whether or not the current page or a prior page in the user's navigation on the site included ad-click information in the URL (e.g., GCLID / DCLID)
- Boolean information about the consent state
- Random number generated on each page load
Besides allowing the consent state to modify tag behavior, you can also redact
stored data when a user denies consent. For example, a user might have granted
consent to store data for ads and then change their mind and deny consent. If
ads_data_redaction, when the user denies consent, Google Ads will
delete the stored information.
Google tags with built-in consent checks might check for
analytics_storage or both. The following table shows tag behavior by consent
types when consent is granted or denied and when
ads_data_redaction is set to
Tags with built-in consent checks amend their behavior based on different
consent states. The following table explains tag behavior by consent types,
consent state, and whether
ads_data_redaction is set to
|Consent type(s)||Denied or granted||Behavior|
Personalized advertising is disabled, the following features won't receive data:
Personal data collection for online advertising is disabled, including:
||denied and true||
Consent mode modeling
To mitigate any data collection gaps, Google products use these pings to model your metrics for your measurement solutions. In order to protect user privacy, your tag or app SDK needs to meet a certain data collection threshold. You can find more information about what is modeled and under which circumstances in the articles linked below:
- Google Ads consent mode modeling
- Google Ads online conversion modeling
- Google Analytics conversion modeling
- Google Analytics behavioral modeling