Verify consent mode set up as 0% consent rate detected
Google reports that ad_user_data is denied for every visitor, so the consent rate reads 0%. Check the consent default for ad_user_data and ad_personalization, check that the banner sends an update when a visitor accepts, and confirm a setup meant for the EEA is not applied everywhere. Then publish and read the rate again.
At a glance
- Where it shows
- The Diagnostics tab in the Google tag settings.
- What stops
- No ad stops. Data from visitors whose ad_user_data signal reads denied is not used for ads, even where they would have agreed.
- How serious
- A diagnostic, not a penalty. The cost is audiences and matched conversions that do not build.
What it means
Consent mode sends Google a signal for each kind of consent: ad storage, analytics storage, ad user data and ad personalization. The ad_user_data signal says whether a visitor's data may be used for ads. A rate of 0% means that signal reads denied for every visitor, which is a setup fault and not a sign of refusals.
Google has two messages for this. This one appears when ad_user_data is sent as denied regardless of region. A separate one, 0% consent rate detected in some regions, appears when it is always denied outside the EEA, and Google warns that can break remarketing there. A zero in every region means not even a visitor who accepts ever reaches granted, so the default and the banner's update are where to look.
What actually triggers it
A banner that never sends an update
The default denies, as it should until someone answers, but the banner sends no consent update when a visitor accepts. Google lists this as its own consent problem, Consent doesn't update. A banner from a consent platform should send the update itself; when it does not, the platform's settings or its support are the next stop.
A default hard-coded to denied with no region rule
A default written for the EEA and placed on every page, with no region setting, denies everywhere. If the banner also fails to update, the rate is zero worldwide. Check which regions show the zero before changing anything: outside the EEA only points to the region rule.
A default that reads after the tags that need it
A tag that reads consent before the default is set sees the state before any choice. The default must run before any tag uses or updates consent, as the consent guidance requires.
Fix it in this order
- Open the consent default in the container and read the values it sets for ad_user_data and ad_personalization.
- Check the regions the default covers. An EEA-only setup needs a region rule, or it applies everywhere.
- Confirm the default runs before any tag that reads consent. The order check is on the page for default consent set too late.
- Accept on the banner yourself and confirm in Tag Assistant that a consent update follows with ad_user_data granted. A banner that sends nothing leaves every signal denied.
- Create a version of the container and publish it, then read the consent rate again in Tag Diagnostics.
Often confused with
0% consent rate detected in some regions
Denied outside the EEA only. That points at a region rule applied to the whole site, not a banner that is missing.
The default is set, but after tags have already read consent. That is a timing fault, also reported as Consent mode installation out of order, and its fix is the order of the default, not its values.