How To Diagnose If Google’s Consent Mode Is Implemented Correctly

Learn how to diagnose and verify if Google’s Consent Mode is implemented correctly. This guide explains key GA4 and GTM checks, common setup mistakes, and best practices to ensure accurate modeled data and privacy compliance across all regions.

Rob English

Lead Implementation Specialist

A privacy-focused web analytics implementation specialist, with 19 years experience in development across marketing, advertising and analytics.

Getting Consent Mode right isn’t just a technical checkbox, it’s the foundation for compliant, reliable data collection. Too often, marketers and analysts assume Consent Mode is “on” and working as expected, only to discover that their modeled data isn’t populating, thresholds aren’t met, or consent signals are firing out of order. These small details can lead to big gaps in reporting and compliance exposure.

In this post, we’ll look at how to diagnose whether Consent Mode is implemented correctly and what to watch out for when reviewing your setup. Along the way, we will use the terms consent management and Consent Mode interchangeably, but it’s important to note the difference:

Consent management refers to the overall handling of user consent across your website—for all tags and tracking technologies, not just Google.
Consent Mode, on the other hand, is Google’s specific framework that adapts how Google tags like Analytics, Ads, and DoubleClick behave when consent is denied, allowing modeled data to fill in those gaps.

Step 1: Check Key GA4 Settings

Data Display → Reporting Identity

The first place to check in GA4 is your Reporting Identity. Making sure we've selected the Blended Reporting Identity type. Without this type selected, modeled data from non-consented sessions won't be available in reporting.

If Blended is already enabled, GA4 will tell you whether thresholds have been met and if modeling has started.

Common surprise: It’s possible to have Blended enabled but still have no modeling active.
This can happen for a few reasons:

The thresholds just haven’t been met yet. They can be found here under Prerequisites
This is more likely a problem if you’ve just recently enabled Consent Mode on your website
There’s a problem with your tag implementation onsite (eg. non-consented Google tags are outright blocked vs.having Consent Mode adjusted to a denied state, meaning no denied instances of events ever reach GA4 - this threshold will never be met)

Step 2: Review Consent Settings in GA4

Navigate to Data Collection and Modification → Consent Settings.

Under consent settings we can get an overview of some of the consent signals being ingested on the incoming data streams. Reviewing this page can be informative, as it shows what consent signals are active or not on your data streams.

Step 3: Review Your Tag Implementation

If you are using Google Tag Manager to deploy your Google product tags, it’s very helpful in assessing your Consent Mode set-up, as it has additional features (both specifically for consent mode, and for general use) that can help to troubleshoot all touchpoints. I’ll speak to some of these first, and then speak to steps to troubleshoot your implementation when you don’t have GTM (maybe you’ve direct deployed GA4, or maybe you are using a different tag manager like Tealium, or Ensighten).

GTM’s Container Quality and Tag Diagnostics Report

Firstly, GTM’s Container Quality and Tag Diagnostics report can be very helpful to identify potential consent mode implementation issues, such as:

Some pages missing consent for EEA users
Website/App missing EEA consent for ads personalization
Consent mode installation out of order - this flag has made assessing this for a number of sites, extremely quick to identify, and I’ll speak to this later
Verify consent mode set up as 0% consent rate detected
0% consent rate detected in some regions

Step 4: Use Tag Assistant for Real-Time Troubleshooting

Next up, having Tag Assistant available to review the state of your container, event by event, as data is pushed onto your dataLayer and tags is extremely helpful in assessing Consent Mode implementation issues. It can help us see the order of operations of Consent Mode signals, as well as Consent Management signals. I really like this as it very easily outlines, visually, the historical view of the dataLayer, consent management and tagging tied to it, in your tag manager.

Step 5: Evaluate How Your Consent Manager Loads

Is the Consent Manager Deployed Through GTM?

If so, how is it deployed, when does it load, and is it handling Default Consent Mode flags as part of the template?

The consent manager (if deployed through GTM) should be set to load on Consent Initialization. Any later than this, and we can start to see inconsistencies in Consent mode settings ESPECIALLY if that template also handles the Default Consent Mode flags. Loading it on Consent Initialization ensures that it loads before tags execute.

If you have a late loading consent manager (with or without Default Consent Mode flags), you could start to see inconsistencies in consented tracking, in that, a user denies tracking, but the Consent Manager is implemented on page after some tracking has already occurred, or been sent with fully accepted Consent Mode flags. If we then think of subsequent pages on your website, where, say OneTrust loads in too late, you could see tracking occur even if you’ve denied consent simply because the CMP hasn’t loaded yet.

Step 6: Identify What Handles Default Consent Mode Flags

If the Consent Manager is not loaded through GTM, or if it’s not set up to handle the Default Consent Mode flags, what is? Is it another template, is it something in the page, or an unknown?

There are other Consent Mode specific templates in GTM that can be used to define your Default Consent mode flags. As well the Consent Manager itself, may push signals into the page for Consent Mode - more likely for Consent Updates than Defaults.

Are Consent Default and Update statuses out of order, or inconsistent?

This is a scenario we’ve seen frequently. In the case of missing Consent Default signals, it means that Consent mode is undefined at page load, and won’t be set until the Consent Manager pushes the updated signals to the page based on user preference stored in a cookie, or elsewhere. This can lead to any tags that have been configured to fire during the page load, before the CMP loads, to fire inaccurately: whether to fire when they shouldn’t have or to be blocked when they shouldn’t have. Consent Defaults are extremely important to set.

Step 7: Check for Inconsistent Consent Mode Settings

In the case of inconsistent Consent Mode settings, it’s important to validate (and this can be done with or without Tag Assistant) the Consent Mode (gcs) parameter on your Google tagging itself. We’ve run into scenarios, where tagging at page load was in a completely granted state, but post page load events were capturing a signal in which Analytics was granted but Ads was denied. This had a significant impact to Landing page and campaign tracking.

Step 8: Review Geo-Targeted Consent Flags

Are there different Consent Mode flags for different geo-targeted regions? If so are they conflicting?

While helpful to be able do define separate Consent Mode flags for differing geo-locations it’s important to be aware of how these differing sets of flags have been categorized, as you could run in to circumstances where two of these sets conflict with one another, resulting in unexpected behaviour in your tracking.

Step 9: Verify How Google Tags Behave in a Denied State

When consent is in a denied state, do Google tags fire at all?

It’s important to ensure that if you are using Consent Mode modeling (or wish to), that the Google product tags themselves are set to always fire, but that their consent mode flags will adjust accordingly based on consent settings. This means Google tags could follow a different triggering rule or load rule than other non-Google marketing pixels, in that we don’t want to block them when consent is denied, but make sure that they always fire, just with adjusted Consent Mode settings. If the tags are always blocked on Consent denied, Cookieless pings will never be sent to the Google servers, and one of the thresholds to enable modeling, will never be met (you have to have events sending to Google in a denied state).

This can play into this next point.

Step 10: Check for Auto-Blocking by Your CMP

Is auto-blocking being used by your CMP?

Autoblocking is a feature available to most CMPs. In my opinion (and I believe it’s generally a best practice throughout the community), autoblocking should never be used when you are using a tag manager. It can block the tag manager itself if you aren’t careful, and can impact Consent Mode signals. The purpose of autoblocking is more to help manage onsite tagging that isn’t consolidated in a single location. Oftentimes it can do this without code updates to the site, but in many cases needs updates to be made to each tags specific code snippet, to identify it for autoblocking. Autoblocking could outright block Google tags, so that even though you’ve defined consent mode settings for those tags, the tag just never fires, and you’ll lose those non-consented signals that are used for modeling purposes in Google tags. Autoblocking is a feature that needs to be monitored and maintained long term as well to ensure functionality, and in my experience is often overlooked in this regard.

Step 11: Don’t Forget Geo-Targeting and Global Visitors

Are you considering ALL geo-targeted regions that visit your website?

Not just for Consent Mode, but Consent Management in general. If visitors can land on your website and be tracked, it doesn’t matter if you intend to sell them something or not. Tracking can be a violation of their local privacy regulations. Because of this it’s very, very important to assess the state of your tracking for different geo-targeted regions. I always do a check on our clients sites for the EU, regardless of whether they serve content or products to the EU, to give a fully informed state of what consent looks like. Knowing your consent state for everyone is extremely important to ensure broad compliance globally.

Step 12: Treat Privacy as an Ongoing Practice

Privacy and compliance are ongoing practices. When we look at the landscape, even just in the US alone, laws are constantly changing, or adapting. In the last bit we’ve seen Germany say Google Tag Manager is illegal. Vermont rolled out its Reproductive Health amendment, and class actions are being filed against companies for web tracking tech under the CIPA law in California. All perfect examples of how privacy and consent, must be an ongoing practice. As such, consent mode and consent management integration cannot be “set and forget” methodologies or technologies, as doing so can put a company in non-compliance very, very quickly.

Final Thoughts

Diagnosing Consent Mode correctly requires both technical validation and ongoing vigilance. By reviewing your GA4 settings, GTM configuration, consent manager behavior, and geo-targeted consent states, you can ensure your setup delivers accurate, privacy-compliant insights.

Getting Consent Mode right means striking the right balance, protecting user privacy while maintaining the measurement clarity your marketing strategy depends on.

Need Help Auditing Your Consent Mode Setup?

Getting Consent Mode right is critical for both compliance and accurate measurement. Even small implementation errors can lead to missing data, modeling gaps, or privacy risks that go unnoticed until it’s too late.

At Napkyn, our data solutions experts specialize in auditing, implementing, and optimizing Consent Mode across GA4, GTM, and your consent management platform. We help ensure your tracking respects user privacy while maintaining the insights your marketing team relies on.

Book a Consent Mode Audit or reach out to learn how we can help you restore data confidence and protect your compliance posture.

More Insights