How Google's Built-In Consent Works and When It Doesn't
Google Tag Manager has two consent enforcement models. Additional consent requires each tag to declare the consent types it needs, and the tag only fires when the user grants them. Built-in consent works differently: certain native Google tag types check consent state automatically at runtime, without any declaration in the tag's settings. The tag type itself contains the logic.
Five tag types have built-in consent: Google Ads Conversion Tracking, Google Ads Remarketing, GA4 Event (and Configuration), Conversion Linker, and Google Tag. When a Consent Management Platform sets consent state through the Consent Initialization trigger, these tags read that state and behave accordingly. If a user denies ad_storage, a Conversion Linker tag won't write cookies and falls back to URL parameter persistence instead. If analytics_storage is denied, GA4 sends cookieless pings containing only consent state, timestamp, basic geo, and an ad-click indicator, with no cookies, client IDs, or persistent identifiers attached.
This is Google's recommended approach, and adoption is growing. It also creates a problem for every audit tool that treats consent configuration the same way across all tag types.
Built-in consent at runtime
A native Google tag with built-in consent doesn't need consentSettings in the GTM container JSON. The consent logic lives in the tag template code that Google maintains, and when the tag fires, it calls an internal function that checks whether the relevant consent types (ad_storage, analytics_storage, ad_user_data, ad_personalization) have been granted, denied, or left unset.
The behavior on "denied" varies by tag type. GA4 switches to cookieless measurement mode. Conversion Linker stops writing first-party cookies but persists click identifiers in the URL. Remarketing tags suppress the network call entirely. Google Tag checks all four consent types and adjusts its behavior per-signal. These aren't boolean gates but graduated responses built into each tag's runtime code, which means the tag degrades gracefully rather than simply switching off.
Simo Ahava's consent mode documentation remains the most thorough public reference on how these mechanics work at the template level.
Three conditions for built-in consent to function
Built-in consent functions correctly when three things are true simultaneously.
First, a CMP exists on the page. The CMP is the mechanism that sets consent state in the first place, and without one, there's no consent signal for the tag to read.
Second, the CMP fires on the Consent Initialization trigger. This is a special trigger in GTM that fires before All Pages, before any tags execute. If the CMP loads later (on DOM Ready, on Window Loaded, or asynchronously after the page renders), tags will read consent state before it's been set. The timing is critical because built-in consent doesn't queue or retry: it reads the state once at fire time and acts on whatever it finds.
Third, default consent state is configured. Before the user interacts with the consent banner, the CMP should set a default state (typically "denied" for ad_storage and analytics_storage in regions that require opt-in). This default is what tags read during the window between page load and user interaction. Without it, the consent types exist in an undefined state that different tags interpret differently.
When all three conditions are met, built-in consent works exactly as designed. Tags check the state, respect the answer, and adjust their behavior. NOT_NEEDED in the tag's consent configuration is correct because the tag type handles it natively.
When NOT_NEEDED becomes dangerous
Remove any one of the three conditions and the behavior changes in ways that are invisible from the GTM interface.
The most common failure is the simplest one: no CMP at all. When no CMP has set consent state, Google's default behavior treats undefined consent as "granted." The tag checks for consent state, finds nothing, and proceeds as if the user said yes. Built-in consent without a CMP is not consent enforcement. It's a false sense of security that looks correct in the configuration but does nothing at runtime, because the mechanism that makes it work (the CMP setting state) was never installed.
The second failure mode is timing. A CMP that loads asynchronously or fires on a trigger later than Consent Initialization creates a race condition where tags execute, check consent, find no state, and fire with full permissions. By the time the CMP sets the correct defaults, the data has already been sent. Google's own documentation warns about this in the context of the "A tag read consent state before a default was set" error, but the warning is buried in troubleshooting pages that most implementers never see.
The third failure is overblocking. Some CMPs block Google tags at the platform level while the GTM container also has additional consent requirements configured on the same tags. The CMP prevents the tag from loading entirely, which means the tag never gets the chance to send even a cookieless ping. For GA4, this means losing measurement data that would have been privacy-safe under denied consent, because the CMP and the tag are both trying to enforce consent, and the combination is more restrictive than either intended.
Regional misconfiguration is a fourth failure that shows up in multinational containers. Consent defaults are set by region using ISO country codes, and a typo, a missing region, or a miscategorized jurisdiction can result in users in opt-in regions receiving "granted" defaults. The tags work correctly given the state they receive. The state itself is wrong.
Consent auditing for built-in tag types
Most GTM audit tools treat NOT_NEEDED as a finding. Tag has no consent configured, flag it. This made sense before built-in consent existed, but now it produces false positives on the exact tags that Google recommends configuring this way.
The distinction matters because it changes how you read a consent audit. A container with 15 native Google tags showing NOT_NEEDED and a properly wired CMP is compliant. The same container without a CMP is not. The tag configuration is identical in both cases, and the context is everything.
A useful consent audit needs to answer a different question: not "does this tag have consent configured?" but "given what this tag type does natively and how this container's CMP is set up, is the consent enforcement working?" That question requires understanding which tags have built-in consent, whether a CMP exists, whether it fires at the right time, and whether default state is set for the right regions. TagManifest splits consent findings by tag type for this reason. Native tags with built-in consent in a properly wired CMP container get a low-severity informational finding ("no action required"), while Custom HTML ad pixels in the same container get a high-severity finding.
Two contradictory defaults in one system
Google Tag Manager contains two contradictory defaults. At the container level, GTM implements privacy-by-default: when no consent values are set, advertising tags send no data. At the individual tag level, undefined consent variables default to "granted". These two behaviors coexist, and which one you encounter depends on whether a CMP has initialized consent state at all, or whether specific consent types were left out of the CMP's configuration.
This is not a bug but the result of building consent into a system that predates consent requirements. The tags need to function in containers that don't use consent mode at all (the "granted" default) while the platform needs to protect privacy when consent mode is active but the user hasn't consented yet (the "no data" default). Understanding which default applies in which situation is the foundation of every consent audit, though Google's documentation describes both behaviors rarely in the same place or with the same emphasis.
The built-in consent model is the right direction. It moves consent enforcement from container-level configuration (which is fragile, depends on the implementer, and breaks when tags get copied between containers) into the tag template code (which Google maintains, updates, and tests). For containers using native Google tags with a properly configured CMP, it's the most reliable consent enforcement available. The challenge is recognizing when the conditions aren't met and the reliable behavior becomes a liability.