A Consent Management Platform (CMP) May Be Blocking Tags: What It Means and How to Fix It

What does "a consent management platform (CMP) may be blocking tags" mean?

It is an informational warning from Google Tag Assistant, the tool you use to debug Google Tag Manager, Google Analytics, and Google Ads tags. It appears when Tag Assistant detects a consent management platform (a cookie banner) that is preventing one or more Google tags from firing. Google's own documentation is explicit that this is often expected behavior, not a fault. Your CMP is blocking tags before consent because, in most of the world, it is legally required to.

Is the warning actually a problem?

Usually, no. There are two situations, and only one of them is a bug. In the first, the warning is expected: your tags are blocked before consent and then fire normally once the visitor accepts. Nothing is broken. Tag Assistant flags the CMP so you are aware of it, but consent is working. In the second, the warning points to a real issue: your tags stay blocked even after the visitor consents. That almost always means your CMP is not sending a consent update to Google, so the tags never get the signal that they are now allowed to run. That is the case worth fixing.

Why your CMP blocks Google tags before consent

Under the GDPR, the ePrivacy Directive, and a growing list of US state laws, analytics and advertising tags that read or write cookies need a legal basis before they run. For most sites that basis is consent. A consent management platform enforces this by holding those tags until the visitor chooses. Google describes three ways a CMP can do this: automatic script blocking, consent checks inside Google Tag Manager, and manual blocking. All three produce the same Tag Assistant warning.

Google Analytics is the tag this comes up on most. Our guide to whether Google Analytics is GDPR compliant covers what a lawful GA4 setup needs, and how often sites with a banner still fire GA before consent (76% of the 669 we scanned).

The wrong fix: letting tags fire before consent

Most CMPs offer a setting with a name like "Allow Google tags to fire before consent." Turning it on makes the warning go away, because the tags are no longer blocked. It also fires tracking before the visitor has agreed to anything, which is the exact behavior that regulators fine and that pixel-tracking and wiretap lawsuits are built on. Clearing the warning this way trades a harmless diagnostic message for real legal exposure.

The right fix: Google Consent Mode v2

The correct fix keeps tags blocked before consent and tells Google's tags what the visitor decided, so they fire correctly the moment consent arrives. That is what Google Consent Mode v2 does in its basic mode: you set the consent signals to denied before any Google tag loads, hold the tag until the visitor consents to its category, and send the consent update when they decide. A tag that loads after that already knows the consent state instead of firing on stale defaults, and everyone who accepts is measured in full. Google also offers an advanced mode, where the tag loads before consent and sends cookieless "pings" while the signals say denied. Those pings are still requests to Google that carry the visitor's IP address and page URL before anyone agreed, which is why we do not recommend it. Our Consent Mode v2 setup guide walks through both modes and the code.

1. Set your consent defaults to denied for ad_storage, ad_user_data, ad_personalization, and analytics_storage before any Google tag loads.
2. Keep functionality and security storage granted so the site itself works.
3. Send a consent update the moment the visitor accepts, switching the granted signals on.
4. Keep the Google tags themselves held until consent. Do not switch to advanced mode to let them load early for the cookieless pings: a ping is still a request to Google, sent before the visitor agreed.
5. Reload in Tag Assistant and confirm the consent state moves from denied to granted after you accept.

// Basic mode: the Google tag itself stays held until consent.
// These calls set the state it reads the moment it does load.

// Before any Google tag loads: deny by default
gtag('consent', 'default', {
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  analytics_storage: 'denied',
  functionality_storage: 'granted',
  security_storage: 'granted',
  wait_for_update: 500,
});

// When the visitor accepts your banner: grant what they allowed
gtag('consent', 'update', {
  ad_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted',
  analytics_storage: 'granted',
});

How ConsentStack handles this

ConsentStack runs Consent Mode v2 in basic mode by default. Its Google integration sets the denied defaults for ad_storage, ad_user_data, ad_personalization, and analytics_storage before any Google tag can load, keeps functionality and security storage on, and turns on Google's own privacy settings (ads_data_redaction and url_passthrough). The Google tags themselves stay held until the visitor consents to their category, so nothing reaches Google first. The moment a visitor accepts, ConsentStack sends the consent update and the tags load with full measurement. A held tag cannot leak, which is what our scanner is really checking.

You still decide which tags belong in which category, and correct setup always matters, but the consent-mode plumbing that trips up most sites is handled for you. That is the difference between a banner that looks compliant and one that actually behaves correctly: blocked before consent, firing the instant it is given, and never leaking in between.

How do I know if my tags are actually leaking?

The Tag Assistant warning tells you a CMP is present. It does not tell you whether tags fire before consent. The only way to know is to load your site, refuse consent, and watch what still runs. ConsentStack's free compliance scanner does exactly that: it visits your site, rejects the banner, and reports which trackers and cookies fired anyway. If Google Analytics or an ads tag shows up in that report, your tags are leaking, no matter what the banner looks like.