When you scan a GTM container with TagManifest, the Consent tab is where the highest-stakes findings surface. Consent is the area of a GTM audit where the gap between "looks fine" and "actually works" is widest. A container can have a CMP installed, a banner displayed on every page, and data flowing into GA4, while simultaneously sending advertising data to Google without valid consent for every European visitor. The dashboard surfaces exactly those gaps, organized so you can assess your consent posture in about 60 seconds.
This piece assumes you've scanned a container and you're looking at the Consent tab trying to figure out what it's telling you. If you're still building your understanding of how consent mode works in GTM, where to start with GTM consent mode covers the conceptual foundations first.
What the consent dashboard answers
The dashboard is structured around three questions, in order of regulatory significance.
Do you have a CMP? A consent management platform is the mechanism that collects visitor choices and communicates them to GTM. Without one, consent mode has no input. Tags either fire unconditionally or sit behind consent types that never get granted.
Is it wired correctly? Having a CMP installed is necessary but not sufficient. The CMP needs to fire on the right trigger, at the right time, with the right consent types mapped to the right tag categories. Each of these can be misconfigured independently.
Are your tags using the right consent types? This is where the most common problems live. A tag can be gated behind consent and still be non-compliant if it's gated behind the wrong consent type. An advertising tag on analytics_storage instead of ad_storage will fire when a visitor grants analytics consent but denies advertising, which is the opposite of what both the visitor and the implementer intended.
Everything on the Consent tab maps back to one of these three questions.
The consent management overview
The top of the dashboard shows four cards that give you the high-level picture before you look at anything else.
CMP Detected tells you whether TagManifest found a consent management platform in your container. The scanner checks tag names first, looking for known CMP platforms (Cookiebot, OneTrust, Usercentrics, Quantcast, iubenda, and others), then falls back to inspecting Custom HTML tags for CMP code patterns like Cookiebot, OneTrust, CookieConsent, or window.__tcfapi. If neither check finds anything, this card shows "No" and the rest of the consent dashboard should be interpreted in that context: your container has no mechanism for collecting consent choices.
CMP Platform identifies which CMP is installed, when one is detected. This matters because different CMPs integrate with GTM differently, and knowing which one you're working with determines which documentation to follow and which configuration options to look for.
ad_storage Tags shows how many of your advertising tags have ad_storage as a required consent type. This is the correct consent type for tags that set advertising cookies (Google Ads conversions, Floodlight, remarketing pixels). If this number is zero but you have advertising tags in your container, those tags are either ungated or gated behind the wrong consent type.
ad_user_data Tags shows how many tags have the Consent Mode v2 signal configured. ad_user_data was introduced in 2024 to satisfy Digital Markets Act requirements. For sites serving EEA traffic, Google will not process advertising conversion data unless this signal is present. If you have ad tags but this count is zero, your container predates the v2 requirement and hasn't been updated.
CMP status, DMA readiness, and ad tag consent types
Below the overview cards, three status indicators give you pass/fail assessments for the consent areas that matter most.
CMP status
This indicator has three states, and the distinction between the first two is important.
A green checkmark with the CMP name and "on Consent Initialization" means the CMP is detected and firing on GTM's dedicated Consent Initialization trigger. This is the correct configuration. The Consent Initialization trigger fires before all other triggers, which means the CMP sets the default consent state before any tags make consent decisions.
A yellow warning showing the CMP name with "not on Consent Initialization trigger" means the CMP exists but fires on the wrong trigger. The most common misconfiguration is a CMP firing on All Pages or DOM Ready instead of Consent Initialization. When this happens, there's a timing window where tags can fire before the CMP has set the consent state. In advanced consent mode, this means GA4 won't send cookieless pings during that window, losing the measurement recovery that advanced mode is supposed to provide. In basic mode, tags may briefly fire without any consent state at all.
A red X with "Not detected" means no CMP was found. If you serve EU or UK traffic, this is the first thing to address.
DMA readiness
The Digital Markets Act requires specific consent signals for Google advertising products when serving EEA visitors. The DMA readiness indicator checks three conditions simultaneously:
- Whether advertising tags exist in the container (if they don't, DMA requirements don't apply and this shows as "N/A")
- Whether any of those ad tags have
ad_user_dataconsent configured - Whether any ad tags are using the wrong consent type (
analytics_storageinstead ofad_storage)
All three must pass for "Compliant" status. If it shows issues, the indicator tells you specifically what's missing: "no ad_user_data coverage" or "[N] ad tags using wrong consent type." These aren't cosmetic problems. Without ad_user_data, Google won't process conversion data for EEA traffic, which means your European advertising attribution silently degrades.
Ad tag consent types
This indicator focuses on the single most common consent misconfiguration: advertising tags gated behind analytics_storage instead of ad_storage.
The distinction matters operationally. analytics_storage controls whether GA4 sets analytics cookies. ad_storage controls whether advertising platforms set tracking cookies. When a visitor grants analytics consent but denies advertising, tags gated behind analytics_storage fire, and tags behind ad_storage don't. An ad conversion tag on analytics_storage fires in exactly the scenario the visitor said no to.
Green means all your ad tags use ad_storage. Yellow tells you how many use the wrong type. In the containers I've scanned, this mismatch shows up more often than any other consent finding. The usual cause is someone selecting the first consent type in the dropdown without checking whether it's the right one for the tag category.
Reading the consent type distribution
The consent type distribution chart shows every consent type configured across your active tags, sorted by how many tags use each type.
Each row is a consent type name, a proportional bar, and a tag count. The bars use two colors: advertising-related types (ad_storage, ad_user_data, ad_personalization) are highlighted differently from other types (analytics_storage, functionality_storage, etc.). This visual separation helps you spot imbalances quickly.
What to look for:
Matching ad counts. In a correctly configured container, ad_storage, ad_user_data, and ad_personalization should have roughly the same count. If ad_storage shows 15 tags but ad_user_data shows 3, twelve of your advertising tags are missing the v2 consent signals. Those tags will have their EEA conversion data partially or fully suppressed by Google.
analytics_storage dominance. If analytics_storage has a count significantly higher than what you'd expect from GA4 tags alone, some non-analytics tags are probably using it. Cross-reference with the ad tag consent types indicator above to see if advertising tags are among them.
Non-standard types. If you see consent types that aren't part of Google's standard set (ad_storage, analytics_storage, ad_user_data, ad_personalization, functionality_storage, personalization_storage, security_storage), those are custom consent types. They're not inherently wrong, as some CMPs support custom categories, but they won't be recognized by Google's built-in consent behavior and need explicit trigger logic to function.
Consent configuration states across your tags
The consent configuration breakdown shows three states across all tags in your container:
Requires Consent (NEEDED) means the tag has at least one consent type assigned and will only fire when that consent type is granted. This is the correct state for any tag that collects user data or sets cookies.
No Consent Required (NOT_NEEDED) means someone explicitly marked this tag as not requiring consent. This isn't automatically a problem. Some tags legitimately don't need consent: a tag that loads a font, sets a language preference, or handles form validation doesn't collect personal data and doesn't set tracking cookies. The question to ask is whether the tags in this category are actually consent-exempt, or whether they were marked this way to avoid dealing with consent configuration.
Not Configured (NOT_SET) means no consent decision has been made for this tag at all. It has no consent types assigned and wasn't explicitly marked as exempt. These tags fire regardless of the visitor's consent choice, not because someone decided they should, but because nobody configured them. In containers that have had multiple people adding tags over time, this is where consent drift shows up most clearly. Someone adds a new Google Ads conversion tag, doesn't know about the consent framework, and the tag goes live without any consent governance.
The proportions matter. Say a container shows 80% of tags requiring consent, 5% explicitly exempt, and 15% unconfigured. That tells a clear story: the original implementation was solid, but subsequent additions weren't held to the same standard.
Consent findings and what to do about them
The bottom of the Consent tab shows all consent-related findings from the scan, organized by tier.
Errors are the highest-priority items. Two consent rules can trigger errors:
- No CMP detected. The container has tags requiring consent but no mechanism for collecting consent choices. Without a CMP, consent types exist in the configuration but never get granted or denied, which means tag behavior depends on GTM's default handling rather than actual visitor choices.
- CMP detected but consent mode not wired. A CMP exists in the container but 80% or more of tags have no consent configuration. The CMP is collecting choices, but those choices aren't connected to tag behavior. This is the "cosmetic consent" scenario: the banner gives visitors the impression their choices are being respected, while tags operate independently of those choices.
Optimizations cover the more common configuration issues. These are findings that affect compliance or measurement but don't indicate a fundamentally broken setup. The consent type mismatch (ad tags using analytics_storage), missing v2 signals (ad_user_data, ad_personalization), CMP timing (waitForUpdate at 0ms), tags bypassing consent (NOT_NEEDED on GA4 events), and non-standard consent types all appear here.
Each finding includes a description of what the problem is and a recommendation for what to do. The findings are designed to be actionable without additional research, though for deeper context on any specific issue, the full consent audit guide covers each category in detail.
Connecting consent findings to the work plan
The consent findings you see on this tab also appear in the Issues tab and feed into the work plan on the Summary panel, organized by effort rather than severity. A CMP timing fix (waitForUpdate from 0 to 500ms) is a 5-minute change. Adding v2 consent types to existing ad tags takes 30 minutes. Correcting consent type mismatches across 40+ tags is a focused afternoon. Retrofitting consent configuration for all unconfigured third-party tags is a project.
This effort-based framing is deliberate. Knowing that you have 11 consent optimization findings is less useful than knowing that six of them are quick fixes you can ship today and five require a planning session. The work plan groups them that way so you can decide what to tackle in this session and what goes on the backlog.
If you've scanned your container and the consent dashboard is showing findings, the consent compliance audit guide walks through each issue type with examples and fix directions. If you haven't verified your consent setup recently and want to understand what correct behavior looks like in practice, the consent verification guide covers the browser-level and GTM-level checks that confirm whether your implementation is doing what you think it is.