The Shift from Consent Mode v1 to v2
Google introduced Consent Mode v2 in 2024 to align with evolving privacy regulations and the phasing out of third‑party cookies. While the first version of Consent Mode already provided a way to adjust tag behavior based on user consent, the second version adds a new layer: the requirement to send two distinct consent signals for ads and analytics separately. This shift has a direct impact on how Google Ads and GA4 model conversions when consent is denied.
Under Consent Mode v1, when a user declined consent, Google would still collect data without cookies and use it for modeling, provided the website had a consent banner that communicated the denial. In Consent Mode v2, Google requires separate defaults and updates for ad_storage, ad_user_data, analytics_storage, and now also personalization_storage and functionality_storage for GA4. The most critical change is the introduction of ad_user_data, which controls whether user data can be sent to Google for advertising purposes. Without this signal, Google cannot use data for ad modeling, including conversion modeling.
This means that if your implementation does not explicitly pass ad_user_data with a value of granted when consent is given, or you fail to set it to denied appropriately, Google may either stop modeling altogether or rely on incomplete signals. The result can be a sudden drop in reported conversions, especially if a large portion of your audience declines consent.
What Happens to Conversion Modeling When Consent Is Denied
Conversion modeling in Google Ads uses observed conversion data from users who have granted consent and behavioral patterns from other users to estimate the likelihood of conversions for users who have not. With Consent Mode v2, Google’s modeling depends on receiving both ad_storage and ad_user_data consent signals. If both are denied, Google cannot collect any data from that user for ad purposes, and therefore cannot include the user in the modeled conversion calculation. However, Google can still use aggregated data from users who consented if the implementation sends the correct signals.
The key difference from v1 is that previously, when a user denied consent but the site still sent a ping with consent denied, Google could use that ping for modeling. Now, for ad modeling to work, Google needs explicit permission to use user data. If ad_user_data is denied, Google cannot model conversions even if ad_storage is granted. This has led to reports of underreporting in Google Ads, particularly for accounts that rely heavily on modeled conversions.
Detecting Issues with Your Consent Mode v2 Setup
Marketers should monitor several metrics after implementing Consent Mode v2. A sudden decline in Google Ads conversions that does not correspond to a change in traffic or campaign performance is the first red flag. Another sign is a drop in the number of conversions marked as observed versus modeled in the Google Ads conversion tracking report. If the proportion of observed conversions increases while the total decreases, it may indicate that modeling is not filling the gaps effectively.
In GA4, check the Modeled conversions metric under the Advertising section. If it drops to zero or close to zero, your consent signals may not be passing correctly. Also review the consent configuration in Google Tag Manager or directly in gtag to ensure that the default consent state is set before the page loads. A common mistake is setting the default consent state too late, causing Google to treat the user as having no consent signals at all.
Practical Steps to Preserve Conversion Modeling Accuracy
1. Set Default Consent States Correctly
Your consent management platform (CMP) must set the default consent state for ad_storage, ad_user_data, analytics_storage, and personalization_storage to denied before any Google tags fire. This ensures that users who have not yet interacted with the banner are treated as non-consenting until they make a choice. After the user makes a decision, your CMP should update the consent state accordingly. For model accuracy, the most common best practice is to use a CMP that supports Google’s Consent Mode API and is certified by Google.
2. Use Google Tag Manager’s Consent Overview
Google Tag Manager provides a Consent Overview tab that shows which tags have been blocked by consent settings. Before publishing your Consent Mode v2 setup, verify that all Google Ads and GA4 tags are blocked when the corresponding default consent types are set to denied. This prevents data leakage and ensures that Google only receives data when it has permission.
3. Pass ad_user_data as Granted When Consent Is Given
Many implementations correctly handle ad_storage but forget to update ad_user_data. In Consent Mode v2, you need to call gtag('consent', 'update', { 'ad_user_data': 'granted' }) when a user accepts advertising cookies. Without this, Google Ads will not be able to use the user data for modeling, even if other consent types are granted.
4. Validate with Google’s Tag Assistant
Use the Tag Assistant extension in Chrome to simulate consent events and verify that the correct consent signals are being sent. The tool shows the current consent state for each type and lets you check if tags fire only when appropriate. Run tests with both accepted and rejected consent to ensure your setup works both ways.
How to Interpret Google Ads Reporting Post-Implementation
After implementing Consent Mode v2 correctly, you may still see a drop in total conversions if a significant portion of your audience declines consent. This is expected because Google can only model conversions for users who provide either ad_storage or ad_user_data consent. The modeling will fill in some gaps, but it cannot fully compensate for a high consent denial rate.
Google provides a Conversions modeling coverage metric in Google Ads reports that shows the percentage of conversions that were modeled. If this percentage is low (e.g., below 10%), it may indicate that either consent rates are low or your implementation is not sending the required signals. Compare this metric across segments such as device, browser, or geography to identify where modeling is failing.
In GA4, the Modeled conversions metric under the Monetization or Advertising reports gives similar insight. A sudden drop in this metric after switching to Consent Mode v2 points to a missing or incorrectly set ad_user_data signal.
Common Implementation Mistakes and Fixes
Mistake 1: Delaying the Default Consent Command
If your CMP loads after Google tags have started collecting data, the default consent state will not apply to those tags. Always place the default consent command before any tag manager snippet or gtag.js script. In Google Tag Manager, this means setting the default consent state in a tag that fires on All Pages with priority, or using the Consent Initialization trigger.
Mistake 2: Using Only analytics_storage Without ad_user_data
Some CMPs only include the older consent types. For Consent Mode v2, you must also handle ad_user_data. If your CMP does not support it, you may need to manually add the consent update calls in a custom HTML tag or update your CMP settings.
Mistake 3: Not Updating Consent After Rejection
If a user rejects consent, you must explicitly call gtag('consent', 'update', { 'ad_storage': 'denied', 'ad_user_data': 'denied', 'analytics_storage': 'denied' }). Failure to do so may leave the default state (which is usually denied), but explicit updates are required for accurate reporting and to ensure Google knows the user made a choice. Without the update, Google may not include the user in modeling algorithms that require a consent decision.
Mistake 4: Not Testing Across Different Browsers
Consent signals can behave differently in browsers with Intelligent Tracking Prevention (ITP) like Safari or in incognito mode. Test your implementation on Chrome, Safari, Firefox, and Edge to ensure the signals are preserved and tags fire correctly.
How Consent Mode v2 Affects GA4 Reporting
GA4 uses consent signals for two primary purposes: data collection for analytics and modeling for behavioral reporting. Without analytics_storage granted, GA4 will not collect cookies for user measurement, but it can still collect data for modeling if other signals are present. However, with Consent Mode v2, if analytics_storage is denied, GA4 will also lose the ability to model certain reports such as user acquisition reports. The modeling for GA4 is separate from Google Ads modeling, so you may see discrepancies between the two platforms.
To maintain GA4 modeling, ensure that the default consent state is set before the GA4 configuration tag fires. Also, use the Send consent updates with analytics events option in your CMP to synchronize consent with GA4 events. This helps GA4 build more accurate modeled conversions and user metrics.
When to Consider Server-Side Tagging
For websites that experience high consent denial rates (above 40%), relying solely on client-side Consent Mode may result in significant data loss. Server-side tagging with Google Tag Manager’s server container offers a way to capture additional data that can be used for modeling, provided you respect user consent. When using server-side tagging, you can still implement Consent Mode v2 on the client, but the server container can consolidate and enrich the data before sending it to Google. This can improve the quality of modeled conversions because the server can use first-party data that is not blocked by browser restrictions.
However, server-side tagging does not bypass consent. You must still obtain and respect user consent on the client and send the consent state to the server. The server container should then check the consent state before forwarding events. This approach adds complexity but can recover some of the modeling accuracy lost due to consent denial or browser limitations.
Monitoring and Ongoing Maintenance
Consent Mode v2 is not a set-and-forget solution. Google regularly updates its consent requirements and modeling algorithms. Marketers should schedule quarterly audits of their consent setup, using Tag Assistant and the Google Ads consent reporting dashboard. Also, stay informed about changes to Google’s Consent Mode policy because non-compliance can result in suspension of ad personalization features.
Track the consent rate trend over time. If consent rates fall below 30%, consider revisiting your consent banner design or placement. A/B test different banner designs and wording to improve opt-in rates without misleading users. Higher consent rates directly improve the accuracy of conversion modeling.
Finally, document your consent configuration. In the event of a Google audit or a data privacy inquiry, you will need to demonstrate that you are collecting and processing consent correctly. Maintain a record of your CMP settings, consent updates, and any modifications you made to tags.
Leave a Reply