Implementing Google Consent Mode v2 in GTM step by step

Implementing Consent Mode v2 in Google Tag Manager has one golden rule: the default state must be declared before any Google tag runs. If it arrives late, Google already fired its tags without consent and the damage is done. Here's the correct sequence, with the details that usually go wrong.

Prerequisites

• A GTM container installed on the site.
• A CMP that emits the consent event (or a banner that updates the dataLayer).
• Your cookie inventory classified by category (how to audit it).

Step 1: default state in Consent Initialization

Create a tag that calls gtag('consent', 'default', …) with the 7 parameters set to denied, and assign it to the Consent Initialization - All Pages trigger at the highest priority. It's the first thing that runs in the entire container, before any other tag.

gtag("consent", "default", {
  ad_storage: "denied",
  analytics_storage: "denied",
  ad_user_data: "denied",
  ad_personalization: "denied",
  functionality_storage: "denied",
  personalization_storage: "denied",
  security_storage: "granted",
  wait_for_update: 500,
});

Two key details:

• wait_for_update: 500 gives a window (in ms) for the user's decision to arrive before tags decide how to behave. If your banner loads slower, raise it.
• security_storage: 'granted' is usually left granted because it covers security functions (fraud prevention), not tracking.

Step 2: update after the choice

When the user accepts or rejects in the banner, fire gtag('consent', 'update', …) with the granted permissions. The usual pattern: your CMP pushes a dataLayer event (e.g. cmp_consent_update) that triggers an update tag.

gtag("consent", "update", {
  ad_storage: "granted",
  analytics_storage: "granted",
  ad_user_data: "granted",
  ad_personalization: "granted",
});

Important: the update must reflect exactly what the user chose per category. If they accepted analytics but not marketing, only analytics_storage becomes granted.

Step 3: gate your tags

Enable GTM's built-in consent templates: each Google tag (GA4, Google Ads) automatically respects the state. For custom or third-party tags, use the additional consent checks in the tag settings, so they wait for the relevant permission.

Step 4: validate

Don't trust that it "looks like it works." Verify with data:

Tool	What to check
Tag Assistant	That tags wait for consent and don't fire early
Network tab	The gcs parameter (e.g. G100, G111) in requests to Google
Consent Mode (GA4)	That modeling activates with enough data

To interpret the gcs parameter, see our GCS codes guide: it tells you at a glance whether the signals arrive in the right order.

Common mistakes (and how to avoid them)

• Declaring the default state after Consent Initialization. This is the #1 failure: tags fire without consent. Check the priority and trigger.
• Forgetting ad_user_data and ad_personalization (mandatory since March 2024). Without them, Google turns off personalization even if the user accepts.
• Not propagating the change mid-session when the user updates their choice from the preferences icon.
• Confusing basic with advanced: in basic, no pings are sent, so you lose all data modeling.

A note on the server side

If you use server-side tagging (a server GTM container), consent must travel there too. The server container receives the client's events along with the consent state, and should only forward them to Google, Meta or whoever applies if the permission is granted. It's a frequent mistake: the banner blocks correctly in the browser, but the server container keeps forwarding everything. Treat the server as an extension of your consent logic, not a parallel path that bypasses it.

Conma generates the GTM template and the snippet pre-configured with the 7 parameters and the correct order, so you skip almost all of this manual setup and its mistakes. Learn the details in our Consent Mode v2 guide.