How TagManifest checks consent

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.

TagManifest operates on two distinct layers of the consent stack:

Tag layer (GTM container analysis)

Checks tag-level consent configuration in Google Tag Manager.
Evaluates both Built-In and Additional consent settings.
Validates whether the consent types used by tags are correctly configured.

Page layer (on-page consent infrastructure scan)

Detects presence of CMP scripts (e.g., OneTrust, Cookiebot, CookieYes, and others).
Identifies tracking scripts that load outside GTM.
Reads consent defaults and related signals from the page source.

These two layers together give visibility into how consent is implemented in GTM and how consent infrastructure appears on the page. However, there are two important areas explicitly outside TagManifest’s scope:

CMP configuration & cookie classification (upstream of GTM)

Your CMP’s cookie classification dashboard determines which cookies belong to which consent categories.
If a cookie like _ga is misclassified as "Necessary" in Cookiebot, OneTrust, or another CMP, then GA4 cookies can be set regardless of GTM’s consent settings.
Because the CMP is upstream of GTM in the consent stack, incorrect cookie categorization can override otherwise correct tag-level consent controls.
TagManifest can detect that a CMP is present on the page, but it cannot inspect or validate how that CMP’s cookie categories and rules are configured.

Server-side cookies set via HTTP response headers

Cookies set on the server side in HTTP response headers do not go through GTM.
They also bypass the CMP’s client-side logic, because they are created before any browser-side consent checks can intervene.
As a result, these cookies are invisible to client-side audits, including TagManifest.

Because of these limitations, the consent panel includes a scope disclaimer that clarifies:

TagManifest’s findings are diagnostic signals and threads to pull, not formal compliance determinations.
The tool is intentionally precise about what it covers (GTM tag consent configuration and page-level consent infrastructure) and explicit about what it does not cover (CMP cookie classification logic and server-set cookies).

Used correctly, TagManifest helps you identify misconfigurations and gaps in the tag and page layers of your consent stack, while reminding you that CMP configuration and server-side behavior must be reviewed separately for a complete compliance picture.

TagManifest evaluates consent at two distinct layers of the consent stack:

Tag layer (GTM container analysis)

Checks tag-level consent configuration in Google Tag Manager.
Reviews Built-In and Additional consent settings.
Validates whether consent types applied to tags are correct and aligned with their purpose.

Page layer (on-page scan)

Detects the presence of Consent Management Platform (CMP) scripts such as OneTrust, Cookiebot, CookieYes, and others.
Identifies tracking scripts that load outside of GTM (directly on the page or via other script loaders).
Reads consent defaults and related signals exposed in the page source.

These two layers together give visibility into how consent is implemented both in GTM and on the page, but they do not cover CMP configuration internals or server-side cookies.

What TagManifest does not cover

CMP configuration and cookie classification

The CMP’s own configuration (e.g., in OneTrust or Cookiebot) determines how individual cookies are classified into consent categories (Necessary, Analytics, Marketing, etc.).
If a cookie like _ga is classified as “Necessary” in the CMP, then GA4-related cookies can be set regardless of GTM’s consent settings.
Because the CMP is upstream of GTM in the consent stack, misclassified cookies in the CMP can effectively override correct tag-level consent configuration in GTM.
TagManifest can detect that a CMP is present on the page, but cannot inspect or validate the CMP’s internal cookie classification rules or category mappings.

Server-side cookies set via HTTP response headers

Cookies set directly by the server in HTTP response headers bypass both GTM and the CMP’s client-side logic.
These cookies may not be visible to client-side JavaScript in a way that a browser-based scanner can reliably audit.
As a result, no purely client-side audit (including TagManifest) can fully see or evaluate these server-set cookies.

How to interpret TagManifest’s consent findings

The consent panel includes a scope disclaimer that explicitly states these limitations.
TagManifest’s findings are diagnostic signals and threads to pull, not formal compliance determinations.
The tool is most valuable when it is:
Precise about what it does cover (GTM tag consent configuration and on-page consent infrastructure).
Explicit about what it does not cover (CMP internal configuration and server-side cookie behavior).

In practice, use TagManifest to:

Verify that GTM tags are wired correctly to consent signals.
Confirm that a CMP is present and that non-GTM scripts are not obviously bypassing consent.
Then, separately review your CMP’s cookie classification dashboard and server-side implementations to close the remaining gaps.

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

Enter your URL or upload your container JSON and check the consent panel. The scan runs in your browser. JSON uploads are processed in your browser, 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.

The structural gap is consistent at scale: across ~2,000 B2B SaaS containers, native Google tags show 100% consent configuration while Custom HTML sits at 20%. Templates enforce it. Custom HTML doesn't.