What Changed with Consent Mode v2
Google introduced Consent Mode v2 as an evolution of the original consent framework. The key shift is that advertisers must now send specific consent signals for ad personalization and ad user data, not just analytics and functionality. This change aligns with stricter regulatory expectations in Europe and other regions. Without these signals, Google Ads and GA4 will receive less data, which can affect conversion measurement, audience building, and bidding models.
The original Consent Mode allowed websites to adjust Google tags based on whether users consented to analytics and advertising cookies. Consent Mode v2 adds two required consent parameters: ad personalization and ad user data. If a user denies either, Google will not collect data for those purposes, even if other consent types are granted.
Why Consent Mode v2 Matters for Your Accounts
If you run Google Ads campaigns or rely on GA4 for conversion data, Consent Mode v2 directly impacts your ability to measure and optimize. Without proper implementation, you may see a drop in reported conversions, smaller remarketing lists, and less accurate attribution. Google’s automated bidding models like tCPA and tROAS depend on reliable conversion signals. When those signals are missing or incomplete, model performance degrades.
Consent Mode v2 also helps you remain compliant with data privacy laws such as GDPR. By respecting user choices at the tag level, you reduce the risk of sending personal data to Google without proper consent. This is especially important as regulators increase enforcement around digital advertising.
Core Components of Consent Mode v2
Consent Mode v2 works through a consent signal that your website’s consent management platform (CMP) passes to Google tags. The signal contains four parameters: analytics storage, ad storage, ad personalization, and ad user data. Each parameter can be granted or denied. Depending on the combination of grants, Google tags behave differently.
If analytics storage is denied, GA4 will still collect event data but uses modeling to fill gaps. If ad storage is denied, Google Ads will not use cookies for advertising purposes but can still send conversion pings. The new parameters for ad personalization and ad user data control whether Google can use the data for personalizing ads and building remarketing lists.
Consent Parameters in Detail
The four consent parameters you need to configure are:
analytics_storage controls cookies or identifiers used for analytics. When denied, GA4 falls back to cookieless pings and uses conversion modeling.
ad_storage controls cookies or identifiers used for advertising. When denied, Google Ads tags do not set advertising cookies, but conversion pings can still fire without storing identifiers.
ad_personalization controls whether Google can use data for ad personalization, such as remarketing and audience targeting. This is a new mandatory parameter in Consent Mode v2.
ad_user_data controls whether Google can send user data to its advertising platforms. This is also new and mandatory. When denied, Google will not use the data for conversion measurement or attribution.
How to Implement Consent Mode v2
Implementation follows a standard sequence. First, you need a CMP that supports Consent Mode v2. Most major CMPs like Cookiebot, OneTrust, and Usercentrics have updated their platforms. If you use a custom CMP, it must be able to set the correct consent defaults and update parameters when users interact with the consent banner.
Next, you configure the default consent state on your website before any Google tags load. This is critical because tags read the default state at page load. The default should reflect the strictest possible settings until consent is obtained. For example, set all four parameters to denied initially.
Then you integrate the consent update function. When a user makes a choice on the banner, your CMP should call the consent update command with the new values. For instance, if a user accepts analytics but denies ad related options, you update analytics_storage to granted and keep the others as denied.
Finally, you verify that Google tags are respecting the consent signals. Use Google Tag Assistant or the preview mode in Google Tag Manager to check each tag’s behavior when consent parameters are granted or denied.
Step by Step Setup with Google Tag Manager
If you use Google Tag Manager, the process is straightforward. Start by creating a new Consent Overview tag. In the tag configuration, select the consent types your CMP will manage. For Consent Mode v2, you need to include all four parameters. Set the default state to denied for each.
Then configure the consent update trigger. This trigger should fire when a user clicks a button on your consent banner. The trigger passes the updated consent values to the data layer. Your Google tags will then read the updated values and adjust behavior accordingly.
For example, if you have a Google Ads Conversion Tracking tag, it will only fire conversion pings if ad_storage is granted or if ad_user_data is granted. If both are denied, the tag will not send the conversion signal. Similarly, a GA4 configuration tag will collect data only when analytics_storage is granted.
You should also configure the consent signals for any tags that use Google Ads or GA4. If you use Floodlight tags, enhanced conversions, or offline conversion import, those will also respect the consent settings.
Handling Consent Mode v2 with a Custom CMP
If you run a custom CMP, you need to implement the consent commands manually. The standard approach is to use the gtag function or data layer push to set default consent and update consent. For gtag.js, you call gtag(‘consent’, ‘default’, {…}) with all four parameters set to denied. Then you call gtag(‘consent’, ‘update’, {…}) when the user grants or denies each parameter.
For Google Tag Manager, you push the consent information to the data layer. The data layer object should include a consent section with the four parameters. For example:
window.dataLayer.push({ ‘consent’: { ‘analytics_storage’: ‘granted’, ‘ad_storage’: ‘denied’, ‘ad_personalization’: ‘denied’, ‘ad_user_data’: ‘denied’ } });
Make sure this push happens before any Google tags fire. If tags load before the consent update, they will use the default denied state.
Testing and Verifying Consent Mode v2
After implementation, testing is essential. Use the preview mode in Google Tag Manager to simulate different consent scenarios. For each scenario, check whether Google tags fire as expected. For example, when all consent parameters are denied, GA4 tags should fire but not set cookies, and Google Ads tags should not fire at all.
You can also use the Consent Mode Debugging tool in Google Tag Assistant. This tool shows you the consent state for each tag and whether the tag is respecting the consent signals. Look for warnings that indicate a tag fired without proper consent.
Another way to test is by examining the network requests made by your website. When consent is denied, requests to Google domains should not include identifiers like gclid or _ga. Instead, you should see cookieless pings with a placeholder parameter like gcs=G111.
Impact on Google Ads Performance
Once Consent Mode v2 is live, you may notice changes in your Google Ads reports. Conversions that were previously attributed might now appear as modeled conversions. Google Ads uses conversion modeling to estimate the number of conversions from users who denied consent. This modeling is based on observed patterns from users who did consent, combined with historical data.
If you rely on remarketing, lists may shrink because ad_personalization requires consent. You can still create remarketing lists based on those who granted ad_personalization, but the pool will be smaller. To compensate, consider using customer match with consented first party data or broadening your audience definitions.
For bidding, tCPA and tROAS strategies will adjust to the new data availability. Google’s models become less accurate when consent rates are low. If your consent rates drop below 50 percent, you may need to shift to a less data hungry strategy like maximize conversions without a target.
Impact on GA4 Reporting
GA4 will also reflect consent signals. When analytics_storage is denied, GA4 still collects event data but uses modeling to fill in the gaps for metrics like users and sessions. The modeled data appears in reports alongside collected data. You can see the modeled percentage for each metric in the reporting interface.
Conversion rate in GA4 may appear lower if many users deny analytics_storage, because some conversions will not be directly observed. However, Google’s modeling attempts to estimate those missing conversions. The accuracy of this modeling depends on the volume of data from consenting users and the overall consent rate.
If you use GA4 audiences for Google Ads, those audiences will only include users who granted consent for the relevant parameters. For example, an audience based on purchase events will only contain users who granted analytics_storage and ad_storage, depending on how the audience is used.
Common Pitfalls and How to Avoid Them
One common mistake is setting the default consent state to granted. This should always be denied to avoid collecting data before consent is given. If you start with granted, you risk non compliance and sending data for users who never consented.
Another mistake is forgetting to update consent when a user changes their preferences. Your CMP must call the consent update function every time the user modifies their choices, not just on the initial banner interaction.
A third issue is inconsistent consent states across different pages. If your CMP does not persist consent across sessions, users will be prompted again on every visit, and tags will revert to the default denied state until the user responds.
Finally, ensure that your CMP is configured to block Google tags from loading before consent is obtained. Some CMPs have a blocking mode that prevents tags from firing until consent is provided. This is separate from the consent update process and is necessary for full compliance.
Preparing for Future Changes
Consent Mode v2 is likely not the last update. Google may add more parameters or change how consent signals are handled. To stay prepared, keep your CMP and tag management system up to date. Monitor Google’s announcements about consent and privacy changes.
Also consider implementing server side tracking alongside Consent Mode v2. Server side tracking can capture event data from the server, bypassing some client side consent restrictions. However, server side tracking still requires user consent where applicable. Combining both approaches gives you a more complete picture of user behavior while staying compliant.
Leave a Reply