Scan Now
← Back to Blog
ArticleFeb 16, 20269 min read

How to Tell if Your Consent Setup Is Doing What You Think

The banner works. The CMP is installed. But is consent actually controlling what your tags do? Here's how to verify.

Why “looks fine” isn’t good enough

Every consent setup I’ve audited had one thing in common: from the outside, it looked like it was working. The banner appeared on page load, visitors clicked accept or reject, and analytics data kept flowing into GA4. From the inside, the wiring between the banner and the actual tag behavior often told a different story.

The core problem is that GTM has no built-in feedback loop for consent. When a conversion tag breaks, someone notices because the numbers drop. When a consent configuration drifts, tags still fire, data still appears in your reports, and the banner still shows up on every page. The only things that change are invisible: which consent signals are being sent, whether tags are respecting them, and how Google processes the data you send.

The good news: verifying your consent setup is straightforward once you know where to look. If you set up consent mode six months ago (or inherited a container from two years ago) and haven’t verified it since, the checks below will tell you exactly where you stand.

What correct consent behavior looks like in GTM

GTM’s Preview mode is the most direct way to see whether consent mode is behaving correctly.

In a healthy implementation, you should see this sequence in the event timeline:

  1. Consent Initialization fires before any other tags. This sets all consent types to denied for visitors who haven’t made a choice yet. It’s the CMP telling GTM: assume no consent until the visitor decides.
  2. Consent Update fires after the visitor interacts with the consent banner, reflecting their actual choices.
  3. Tags that require specific consent types either fire (if consent is granted) or remain blocked (if it’s denied).

In Preview mode’s Consent tab, each tag shows:

  • Which consent types it requires
  • The consent state at the time it fired

The key isn’t just whether tags fire, but when they fire and under which consent state. A tag that fires with the correct consent type granted is working as intended. A tag that fires before consent is determined, or with the wrong consent type, needs attention.

Verifying consent signals in the Network tab

The browser’s Network tab is the most definitive way to confirm what your consent implementation is actually sending to Google.

  1. Open your developer tools (F12).
  2. Go to the Network tab.
  3. Filter for collect to see only requests going to Google’s measurement endpoints.

Two parameters in those requests tell you almost everything about consent state: gcs and gcd.

The gcs parameter

gcs shows consent status for advertising and analytics in a compact format: G1xy, where:

  • x = ad consent
  • y = analytics consent

Common values:

  • G111 → both ads and analytics granted
  • G100 → both denied (you’ll only see this in advanced consent mode; basic mode sends nothing when consent is denied)
  • G101 → analytics granted, ads denied

If you’ve rejected all consent and still see G111 in your collect requests, your consent signals are not reaching Google’s tags.

The gcd parameter (Consent Mode v2)

With Consent Mode v2, gcd encodes all four consent types in a single string:

11<ad_storage>1<analytics_storage>1<ad_user_data>1<ad_personalization>5

Each position uses a letter code:

  • p → denied by default, no update
  • r → denied by default, then granted after user interaction
  • v → granted by default and after update

Examples:

  • 11r1r1r1r5 → user denied by default, then granted everything
  • 11p1p1p1p5 → everything denied and never updated

If a visitor clicks “Accept All” and you still see 11p1p1p1p5, the consent update isn’t reaching Google.

Whatever the banner looks like and whatever GTM shows, gcs and gcd in your network requests are the source of truth for what Google is actually receiving.

Checking your GTM consent configuration

GTM itself has tools that make consent verification more accessible than reading network parameters.

1. Consent Overview page

In GTM:

  1. Click Tags in the left navigation.
  2. Click the shield icon to open the Consent Overview.

This page groups every tag into:

  • Consent Configured
  • Consent Not Configured

Tags in Consent Not Configured fire regardless of consent state. If you see advertising tags (Google Ads, Facebook Pixel, LinkedIn Insight, etc.) in this group, they’re running without any consent governance.

This is the fastest way to spot tags that were added after your initial consent setup and never wired into the framework.

2. Consent type assignments on individual tags

Open any tag and go to Advanced Settings → Consent Settings. Check which consent types the tag requires.

The most common issue I find:

  • Advertising tags assigned to analytics_storage instead of ad_storage.

The tag is technically gated behind consent, which looks correct at a glance, but it’s gated behind the wrong type. A visitor who grants analytics consent but denies advertising consent will still trigger these ad tags.

In one container I checked, 44 advertising tags were all using analytics_storage instead of ad_storage. The intent was right. The implementation was off by one dropdown.

3. Consent Mode v2 signals

Google requires two additional consent types for any tag that sends data to Google for advertising purposes:

  • ad_user_data
  • ad_personalization

These were added in 2024 to satisfy Digital Markets Act requirements.

If your implementation predates March 2024, check whether these signals are configured. Without them, Google won’t process conversion data for EEA traffic.

You can confirm their presence:

  • In the Consent Overview (look for the v2 types), and
  • In the Network tab via the gcd parameter.

4. CMP timing (waitForUpdate)

Most CMPs expose a waitForUpdate parameter that controls how long GTM waits for the CMP to load before firing tags.

  • If waitForUpdate = 0ms, GTM doesn’t wait for consent state before making decisions.
  • In advanced mode, this means GA4 won’t send cookieless pings before consent, which is the core mechanism for recovering 65–80% of conversion data from visitors who deny consent.

In one container, this single parameter caused roughly 8,000 organic search sessions per month to be misattributed as “Direct.” The CMP loaded and collected consent, but GA4 had already made its decisions before the consent state arrived.

Google recommends setting waitForUpdate to 500ms, which usually gives the CMP enough time to initialize without noticeably delaying page load.

Validating the consent handshake via dataLayer and console

For a deeper look at the handshake between your CMP and GTM, open your browser console (F12 → Console) and type:

```js

dataLayer

```

You should see consent-related events near the top of the array, before any tracking events.

A properly configured implementation shows:

  1. A consent default push (setting all types to denied).
  2. A consent update push after the visitor interacts with the banner.

If tracking events appear before consent events, there’s a timing issue: tags may be executing before they know the visitor’s consent state.

Checking persistence across pages

Navigate to a second page and inspect dataLayer again. The consent state should carry over from the previous page.

If every page starts with default denied consent and then re-asks, your CMP isn’t persisting the visitor’s choice (e.g., via cookies or localStorage). That usually means:

  • The consent banner reappears on every page, and
  • The first page load of each navigation always fires tags in a denied state.

Advanced mode: verifying cookieless pings

If you’re using advanced consent mode:

  1. Deny all consent.
  2. Check the Network tab for collect requests.

You should still see requests with gcs=G100. These are the cookieless pings that enable Google’s conversion modeling. They contain:

  • Functional info (page URL, timestamp, referrer)
  • No cookies, no client IDs, no persistent identifiers

If you deny consent and see zero collect requests, then either:

  • You’re running basic mode (expected), or
  • You’re in advanced mode but a timing issue is silently turning it into basic mode.

That distinction matters: advanced mode with working cookieless pings lets Google model conversions for non-consenting visitors. Advanced mode with broken timing behaves like basic mode, but without anyone realizing the modeling data isn’t flowing.

Inspecting Google’s internal consent state

One more console check:

```js

googletagdata.ics

```

This object shows the internal consent state that Google’s tags are actually using. You’ll see each consent type:

  • ad_storage
  • analytics_storage
  • ad_user_data

A 30-minute verification checklist

If you want to get confident in your consent setup in about 30 minutes, run this sequence:

  1. Open GTM’s Consent Overview. Confirm all advertising and analytics tags are in Consent Configured.
  2. Spot-check consent type assignments on your ad tags. Confirm they use ad_storage, not analytics_storage.
  3. Open Preview mode. Verify that Consent Initialization fires before any measurement tags.
  4. Click “Reject All” on the consent banner. Confirm that ad tags stay blocked.
  5. Check the Network tab for collect requests. Verify that gcs and gcd reflect the denied state.
  6. Click “Accept All.” Confirm that gcs updates to G111 and tags fire as expected.
  7. Check your CMP’s waitForUpdate setting. Confirm it’s set to at least 500ms.

For a faster pass, TagManifest can map every tag against its consent configuration from your container export. Upload the JSON, and the consent dashboard shows:

  • Which tags are gated behind which consent types
  • Which tags have no consent requirement
  • Whether v2 signals are configured
  • Whether a CMP is detected and how its timing is set

You get a complete map of the consent configuration without clicking through each tag individually.

Where to start if this feels like a lot

If the full audit checklist feels like more than you need right now, start with just two steps:

  1. Open the Consent Overview in GTM.
  2. In Preview mode, reject all consent and see what still fires.

Those two checks alone catch the majority of consent configuration gaps I see in real containers.

Most setups I’ve verified weren’t broken in dramatic ways. They were:

  • Off by a dropdown (wrong consent type)
  • Missing a parameter that didn’t exist when the implementation was built (v2 signals)
  • Using a timing value that defaulted to zero when a template was re-imported

These are small configuration details with specific fixes, not fundamental architecture problems. The hardest part is getting visibility into the current state. Once you can see what’s configured, the fixes are usually an afternoon of focused work.

If you’re still getting oriented on how consent mode works in GTM, Where to Start with GTM Consent Mode organizes the best resources by learning stage. And if consent is just one of the things you’re sorting out in a container you recently inherited, you’re in good company.

consent-debug-helpers.js
/* Quick console checks for consent debugging */

// 1. Inspect dataLayer events
console.log(dataLayer);

// 2. Inspect Google internal consent state
console.log(google_tag_data && google_tag_data.ics);

// 3. Simple helper to log current consent types if present
(function logConsentState() {
  if (!window.google_tag_data || !google_tag_data.ics) {
    console.warn('No google_tag_data.ics object found');
    return;
  }
  const ics = google_tag_data.ics;
  console.table({
    ad_storage: ics.ad_storage,
    analytics_storage: ics.analytics_storage,
    ad_user_data: ics.ad_user_data,
    ad_personalization: ics.ad_personalization,
  });
})();

Audit your GTM container

TagManifest gives you an instant health score and prioritized fixes.

Scan Your Container