Google Tag Manager now ships with built-in consent types, a Consent Initialization trigger, per-tag consent checks, a consent overview report, and deep integration with Consent Mode v2. If you run a GTM container on a site that serves EU visitors, a misconfigured consent setup doesn't just break compliance — it silently corrupts your data.

This guide covers every piece of GTM's consent architecture, from defaults to server-side containers. Where there are bugs, we call them out.

1. GTM's Built-In Consent Features: The Three Layers

GTM's consent system operates on three layers, and mixing them up is the most common source of broken setups.

Consent Type (Built-In)

GTM recognizes a set of built-in consent types that Google's own tags understand natively: ad_storage, analytics_storage, ad_user_data, ad_personalization, functionality_storage, personalization_storage, and security_storage. These aren't arbitrary strings — they're the vocabulary Google tags use to decide what data they can collect. When a consent type is set to denied, Google tags that depend on it switch into a restricted mode: no cookies written, no user identifiers stored.

You can also define custom consent types (arbitrary strings like marketing_cookies or social_media) for non-Google tags. Custom types only work with the Additional Consent Checks feature described below.

Consent Check (Built-In Tag Behavior)

Google tags are consent-aware by default. A GA4 tag automatically checks analytics_storage: if denied, it still fires but in a restricted, cookieless mode — sending consent-aware pings with no identifiers. You don't configure this; it's baked in. The critical point: these tags fire regardless of consent state — they adjust behavior, they don't block themselves.

Additional Consent Checks (Per-Tag Setting)

For tags that aren't consent-aware by default — Custom HTML tags, Custom Image tags, third-party vendor templates — you need to explicitly tell GTM which consent types must be granted before the tag fires. You do this in the tag's Advanced Settings > Consent Settings, by selecting "Require additional consent for tag to fire" and listing the consent types. Unlike built-in consent checks, Additional Consent Checks actually block the tag from firing until the required types are granted. This is the equivalent of a hard gate.

2. Setting Up Consent Defaults with the Consent Initialization Trigger

Before any tag can respect consent, your container needs to know what the default consent state is. This is the job of the Consent Initialization – All Pages trigger.

Every GTM web container ships with this trigger pre-built. It fires before all other triggers, including the Initialization trigger. The firing order is:

Consent Initialization — for tags that set default consent state
Initialization — for tags that need to run early (first-party data setup, etc.)
Page View / DOM Ready / Window Loaded — the standard triggers

Your consent management platform (CMP) tag — the tag that loads your cookie banner and sets default consent — must fire on the Consent Initialization trigger. If it fires on All Pages or Initialization instead, there's a race condition: other tags may fire before defaults are set, and they'll assume consent is granted (because no state was defined yet).

Step-by-Step: Setting Defaults

Create or open your CMP tag (e.g., a CookieBeam Consent Mode tag, or a custom template).
Under Triggering, assign the Consent Initialization – All Pages trigger.
In the tag configuration, set defaults for all consent types you use. For an EU-first site, the typical defaults are denied for ad_storage, analytics_storage, ad_user_data, and ad_personalization.
Use the wait_for_update parameter (in milliseconds) to tell Google tags how long they should wait for a consent update before falling back to the defaults. A value of 500 is standard; anything above 2000 risks delaying page rendering.

In Advanced mode, these defaults control what happens before the user interacts with the banner. In Basic mode, tags don't load at all until consent is granted, but defaults still matter as a fallback if your CMP fails to load.

3. Building a Custom Consent Template

If your CMP doesn't provide a GTM template, or if you want full control over consent mechanics, you can build a custom template using GTM's consent APIs. Simo Ahava's widely-used Consent Mode template is the canonical reference implementation for this approach.

The Consent API Methods

GTM exposes four consent-related methods to custom templates:

setDefaultConsentState — Sets the initial consent state. Accepts an object mapping consent types to 'granted' or 'denied', plus an optional region array and wait_for_update value. You call this in the default command path of your template.
updateConsentState — Pushes a consent update. GTM processes it immediately after the current event and its tags finish. This is what you call when the user clicks Accept or Reject on your banner.
isConsentGranted — Returns a boolean for whether a specific consent type is currently granted. Useful for conditional logic inside templates.
addConsentListener — Registers a callback that fires whenever a specific consent type changes. The listener receives the consent type and its new value.

The "Accesses Consent State" Permission

Any custom template that calls these methods must declare the "Accesses consent state" permission in the template's Permissions tab. Without it, the API calls silently fail — no error, no warning, just broken consent. The permission lets you specify whether the template needs to read, write, or both for each consent type.

Key Design Decisions

Default vs. Update command — Add a dropdown that toggles between "Default" (calls setDefaultConsentState) and "Update" (calls updateConsentState). Most implementations use a single template with two tag instances.
Region-specific defaults — setDefaultConsentState accepts a region parameter (ISO 3166-2 codes array). Call it multiple times with different regions for different defaults per geography.
Firing trigger — Default instance fires on Consent Initialization. Update instance fires on a custom event your CMP pushes to the data layer.

4. Blocking Tags Until Consent: Trigger-Based vs. Consent-Based Approaches

There are two fundamentally different ways to prevent a tag from firing without consent, and they have different trade-offs.

Approach A: Consent-Based (Additional Consent Checks)

Open the tag's Advanced Settings > Consent Settings, select "Require additional consent for tag to fire," and list the required consent types (e.g., ad_storage). The tag won't fire until those types are granted.

Pros: Clean, declarative, visible in the consent overview report. Tags automatically fire once consent is granted — you don't need to build trigger logic for the post-consent path.

Cons: The once-per-page refire bug (covered in the next section). Limited to consent types — you can't block on arbitrary conditions.

Approach B: Trigger-Based (Custom Events)

Skip Additional Consent Checks. Set the tag's trigger to a custom event your CMP fires after consent is granted (e.g., analytics_consent_granted).

Pros: No refire bug. Full control over timing. Combinable with other trigger conditions.

Cons: More work. The consent overview report won't reflect these tags (it only tracks Additional Consent Checks).

Which to Choose

For Google tags (GA4, Google Ads), use their built-in consent behavior. For third-party once-per-page tags, be aware of the refire bug (next section). For repeated-event tags (scroll/click tracking), Additional Consent Checks work well.

5. The "Additional Consent Checks" Refire Bug

This is one of GTM's most frustrating behaviors, and it catches experienced implementers off guard. Here's the exact mechanism:

When a tag has Additional Consent Checks configured and is triggered by a trigger set to fire Once Per Page (or a trigger that only fires once, like Page View), GTM evaluates the trigger first. If the trigger fires but consent is denied, GTM blocks the tag — correct. But it also records that the trigger has "used" its one firing opportunity for that page. When the user later grants consent, the trigger doesn't fire again, because GTM already counted it. The tag never fires for that page load.

In practical terms: a user lands on your site, the banner shows, they browse for 30 seconds, then click Accept. Your Facebook Pixel — on a Page View trigger with Additional Consent Checks requiring ad_storage — never fires. The conversion is lost.

Workarounds

Trigger-based blocking. Remove Additional Consent Checks; trigger the tag on a custom event your CMP fires after consent (e.g., marketing_consent_granted).
Change to "All Page Views." The tag fires when consent is eventually granted, but you risk double-firing on SPAs. Add a Custom JavaScript variable as a firing guard.
Synthetic event after consent update. Have your CMP push {event: 'consent_update_complete'} after calling updateConsentState. Trigger once-per-page tags on that event. The tag fires exactly once, at the moment consent is granted.

Option 3 is the cleanest: it preserves once-per-page semantics while working around the timing issue. Your CMP must push this event after every consent update, including for returning visitors with stored consent.

6. Reading the GTM Consent Overview Report

GTM includes a consent overview report that gives you a bird's-eye view of how consent is configured across your container. To enable it:

In GTM, go to Admin > Container Settings.
Under Additional Settings, check Enable consent overview.
Click Save.

Now, in the Tags view, you'll see a shield icon in the top-right area. Clicking it opens the consent overview.

What the Report Shows

The report groups all tags into two buckets:

Consent Not Configured — Tags in the "not set" state. No Additional Consent Checks have been applied, so the tag relies entirely on its built-in consent behavior (if it has any) or fires unconditionally.
Consent Configured — Tags where you've explicitly set the Additional Consent Checks to either "No additional consent required" or "Require additional consent for tag to fire."

How to Interpret It

The goal: zero tags in "Not Configured" without a deliberate reason. Google tags (GA4, Google Ads) in that bucket are fine — they have built-in consent checks. But a Custom HTML tag with no consent configuration fires regardless of consent state, which is a compliance risk.

Work through it: for each unconfigured third-party tag, set Additional Consent Checks or switch to trigger-based blocking. For tags you intentionally want to fire without consent, set them to "No additional consent required" so they move into the Configured bucket as an audit trail.

7. GTM + Consent Mode v2: Wiring the Four Signals

Google Consent Mode v2 requires four consent signals: ad_storage (advertising cookies), analytics_storage (analytics cookies), ad_user_data (sending user data for ads — new in v2), and ad_personalization (remarketing lists — new in v2). All four must be set in both your default and update commands. For the full comparison of Advanced vs. Basic modes, see which should you use.

The v2 signals exist because Google needs to distinguish storing cookies locally from transmitting user data server-side. Leaving ad_user_data or ad_personalization unset causes Google Ads to treat them as denied, which silently kills enhanced conversions and audience matching even when ad_storage is granted.

Implementation Checklist

Set all four defaults in your CMP tag's Consent Initialization configuration. If your banner groups them under a single "Marketing" toggle, map that toggle to ad_storage, ad_user_data, and ad_personalization together.
Verify with Tag Assistant. Check the Consent tab and confirm all four signals appear at each stage: default (after Consent Initialization), update (after user choice), and on subsequent page views (after stored consent loads).
Check downstream. In GA4, confirm consent mode is recognized under Admin > Data Streams > Consent settings. In Google Ads, check the diagnostics page for signal coverage warnings.

8. Server-Side GTM Consent: How Consent Flows to the Server Container

If you run a server-side GTM container, you need to understand how consent signals travel from browser to server.

The flow is straightforward: your web container collects consent via the CMP. Google tags in the web container automatically embed consent parameters in the HTTP requests they send to the server container — you don't pass them manually. Server-side Google tags (GA4, Google Ads) read these embedded signals and adjust their behavior accordingly.

You do not need a consent banner or defaults in the server container. All consent collection happens in the web container.

What You Do Need to Configure

Region-specific settings. If your web container uses region-specific defaults (denied for EEA, granted for US), enable region-specific settings in the server container so server-side tags interpret signals correctly.
Non-Google tags. Third-party server-side tags (Facebook CAPI, TikTok Events API) are not automatically consent-aware. You need to add consent logic — either through Additional Consent Checks or trigger-based gating. See our server-side consent enforcement guide for patterns.

9. How CookieBeam Integrates with GTM

CookieBeam provides an official GTM template that handles consent signal injection automatically. Install the CookieBeam Consent Mode tag on the Consent Initialization – All Pages trigger, and it:

Sets defaults for all seven consent types using setDefaultConsentState, with region-aware configuration pulled from the CookieBeam dashboard.
Loads the banner from the CDN.
Updates consent state via updateConsentState on every user choice, mapping CookieBeam categories to Google and Microsoft consent types.

The template handles Google Consent Mode v2 (all four signals) and Microsoft Consent Mode (Clarity + UET) in a single tag. The mapping: Marketing → ad_storage + ad_user_data + ad_personalization + UET; Analytics → analytics_storage + Clarity; Preferences → functionality_storage + personalization_storage; Necessary → security_storage (always granted).

CookieBeam also pushes a data layer event after every consent update, so the synthetic-event workaround for the refire bug (section 5) works out of the box. If you use CookieBeam's consent events as triggers for third-party tags, the bug won't affect you.

For the full installation walkthrough — banner ID, template import, regional config, testing checklist — see the GTM Integration Guide.

Putting It All Together: A GTM Consent Audit Checklist

Use this checklist to verify your GTM container's consent setup is complete and correct.

CMP tag fires on Consent Initialization. Open GTM Preview and confirm your CMP tag fires on the Consent Initialization trigger, before any Initialization or Page View tags.
All four v2 signals are defaulted. In the Consent tab of Tag Assistant, verify ad_storage, analytics_storage, ad_user_data, and ad_personalization all show a default state immediately on page load.
Consent updates propagate. Click Accept on the banner and confirm all consent signals update to granted in Tag Assistant.
Consent overview is clean. Enable the consent overview report and verify every third-party tag is in the "Consent Configured" bucket. Intentionally unconsented tags should be marked "No additional consent required."
Once-per-page tags refire after consent. Test a conversion pixel with Additional Consent Checks: deny consent on load, then grant it. Does the tag fire? If not, switch to trigger-based or synthetic-event-based blocking.
Server container respects consent. If using sGTM, verify that server-side tags don't fire when the web container sends denied consent signals. Check the server container's Tag Assistant for consent state on incoming requests.
Returning visitors get stored consent. Accept cookies, reload the page. Consent signals should show granted immediately at Consent Initialization, without waiting for a banner interaction.
Declined visitors stay blocked. Reject cookies, reload. All marketing and analytics tags should remain in their denied/restricted state.

A container that passes all eight checks is correctly wired. Repeat this audit every time you add a tag — consent configs drift, and a periodic compliance check catches regressions before regulators do.