Most GTM audit tools check whether tags have consent settings. That's useful, but it's a low bar. A tag can have consent configured and still be non-compliant if it's gated behind the wrong consent type, missing a v2 signal, or relying on a consent mechanism that doesn't actually protect it. TagManifest checks for correctness, not just presence. Here's what that covers and why the consent audit works the way it does.
Two layers of consent in GTM
GTM consent isn't one setting. It's two mechanisms that work independently, and the container JSON doesn't clearly distinguish between them.
Built-In consent checks are embedded in Google's native tag templates. When you create a Google Ads Conversion tag, the template automatically checks ad_storage, ad_personalization, and ad_user_data before deciding how to behave. GA4 tags check analytics_storage. These are greyed out in the GTM UI. You can't edit them, and they're always active when consent mode is running on the page.
Additional consent checks are configured by whoever manages the container. Three options: "Not set" (hasn't been reviewed), "No additional consent required" (relies on Built-In), or "Require additional consent for tag to fire" (adds a hard gate on top of Built-In). Simo Ahava's consent settings post covers the mechanics in detail.
The problem is that Custom HTML tags, LinkedIn Insight tags, Reddit Pixels, and community templates have no Built-In consent. For those tags, Additional consent is the only protection. A Custom HTML tag with "No additional consent required" has no consent gate at all.
In the container JSON, both scenarios look the same: consentStatus: NOT_NEEDED. TagManifest resolves this with a Built-In consent map that knows what each tag template enforces. A native Google Ads tag with NOT_NEEDED gets a different treatment than a Custom HTML tag with the same value. Same JSON, different meaning, different severity.
What the consent audit checks
The consent rules fall into four areas.
Consent type correctness. Are ad tags gated behind ad consent? The most common misconfiguration we see is ad tags using analytics_storage as their consent type. Someone copies consent settings from a GA4 tag when setting up Google Ads or Microsoft UET tags, and the ad tracking ends up gated behind analytics consent instead of ad consent. The tags fire when a visitor grants analytics but denies advertising, which is the opposite of what both the visitor and the implementer intended.
DMA readiness. Google's Digital Markets Act requirements mean that advertising tags without ad_user_data and ad_personalization won't process conversion data for EEA traffic. These consent types were added with Consent Mode v2 in 2024. Containers that predate the update often have ad tags that work but are missing the v2 signals, which means European conversions are silently dropped.
The double-gate problem. When someone adds Additional consent on top of correct Built-In consent, the tag requires both consent types to fire. A Google Ads tag with Built-In ad_storage and Additional analytics_storage needs a visitor to grant ad consent AND analytics consent. If they grant one but not the other, the tag stays silent. This suppresses conversion data and is harder to diagnose than a straightforward misconfiguration because both consent mechanisms are doing their job. They're just conflicting with each other.
CMP integration. Is a consent management platform detected? Is it firing on the Consent Initialization trigger? Is waitForUpdate configured so GTM actually waits for the CMP to report consent state before tags make decisions? If waitForUpdate is 0, GTM isn't waiting at all. Tags make consent decisions in a vacuum, and the CMP banner is cosmetic.
Why it works this way
The two-layer approach exists because we kept running into the same pattern in production containers. The most common consent finding wasn't "missing consent." It was correct Built-In consent with an unnecessary or incorrect Additional check layered on top.
Our own earlier version of the audit didn't make this distinction. It read consentStatus: NOT_NEEDED and flagged it as a consent bypass. For Custom HTML tags, that's accurate. For native Google tags, it's Google's recommended configuration. The automated scan was flagging correct setups as problems, and that burned real time on remediation plans that turned out to be wrong.
The Built-In consent map fixes this. It's a static lookup that knows Google Ads templates enforce ad_storage, ad_personalization, and ad_user_data. GA4 templates enforce analytics_storage. Microsoft UET templates enforce ad consent types. Custom HTML enforces nothing. With that context, every consent finding can be evaluated against what the tag template actually provides, not just what the JSON says.
What the consent audit doesn't check
TagManifest checks GTM tag consent settings. That's one layer of a larger consent stack.
Your CMP's cookie classification dashboard determines which cookies map to which consent categories. If _ga is classified as "Necessary" in Cookiebot or OneTrust, GA4 cookies fire regardless of what GTM says. The CMP is upstream of GTM in the consent stack, and miscategorized cookies override tag-level settings.
Server-side cookies set in HTTP response headers bypass GTM and the CMP entirely. Third-party scripts loaded outside GTM (hardcoded in page templates, injected by WordPress plugins, loaded by third-party embeds) create cookies that no GTM audit can see.
The consent panel includes a scope disclaimer that says this explicitly. Findings are threads to pull, not compliance declarations. The tool is more useful when it's precise about what it covers and honest about what it doesn't.
The MCP reference tools
TagManifest's MCP server includes two reference tools alongside the audit: get_rule_reference and get_concept_reference. These return structured explanations of consent rules and concepts with validated citations from Google's consent mode documentation, Simo Ahava, and DMA regulatory sources.
The reference tools exist because consent findings are only useful if the person reading them understands why they matter. A finding that says "ad tag using analytics_storage" needs context: what Built-In consent covers, what Additional consent does, why the consent type matters for DMA compliance. The knowledge base covers 12 core concepts (built-in consent, consent mode v2, DMA requirements, advanced vs basic mode, and others) and 20+ individual rule references.
If you're using an AI copilot to work through audit findings, the MCP tools give it the same context a human consultant would bring. Structured data from the audit, validated reference material from the knowledge base. Deterministic findings, contextual interpretation.
Try it
Upload your container JSON and check the consent panel. The scan runs entirely in your browser. Nothing leaves your machine, nothing gets stored. The consent findings will tell you what's configured, what's misconfigured, and what to investigate further outside GTM.
If you want to go deeper on any finding, the consent and compliance category reference covers all 12 consent rules with examples and fix directions. Reading the consent dashboard walks through each section of the consent view. And if you're still building your understanding of consent mode, where to start with GTM consent covers the foundations.