What should I validate first when 'consent_default' vs 'consent_update': which comes first in gtm numbers disagree?

Start with date range, attribution model, conversion/key-event definition, reporting identity, and cross-domain or consent effects. Those five variables explain most “mystery” mismatches.

When is a discrepancy a tracking bug instead of a reporting difference?

It becomes a tracking problem when the gap is unexplained after scope alignment, or when one source is clearly missing sessions, events, revenue, or campaign context that should be present.

'consent_default' vs 'consent_update': Which Comes First in GTM (2026)

Default or update first in GTM?

The consent_default command must fire before any tag — typically as the first script in <head> or as a Consent Initialization tag in GTM with priority 100. The consent_update command fires after the user interacts with the cookie banner.

Reversing this order causes the "a tag read consent before a default was set" warning, breaks Consent Mode entirely, and silently sets your consent defaults to "granted" for any tag that fired before the default was registered — a serious GDPR violation in the EU/UK.

The order is non-negotiable. This post covers exactly how to enforce it in both gtag.js and GTM.

Why the order matters

Google's tags don't operate on a "wait and see" model with consent. When a Google tag fires, it checks the consent state at that moment. If no consent state has been set yet, the tag's behaviour falls back to its built-in defaults — which historically meant "treat consent as granted and set cookies".

This is why ordering is the entire game:

Default fires first → tag reads denied state → no cookies set, cookieless ping (Advanced) or no hit (Basic). Compliant with GDPR/UK PECR.
Tag fires first → no consent state set → tag falls back to default-granted behaviour → cookies set without consent. Not compliant.

Even if the user never sees a banner, even if you're in a region without consent requirements, the order matters because Google's documentation now warns about it explicitly and Tag Assistant flags it as an error.

The implementation pattern in gtag.js

For sites using gtag.js directly (not GTM), the consent default must be the first script in <head>, before the gtag.js library load:

The wait_for_update: 500 parameter tells gtag.js to wait up to 500ms for a consent_update command before firing tags. This is critical — without it, tags can fire with the default state before the user's banner choice is processed.

The consent_update command then fires from your CMP code after the user interacts with the banner:

The update must happen on the page where the user interacted with the banner, before any page transition. If the user accepts on page A and navigates to page B before the update command fires, the consent state is lost for the page A session.

The implementation pattern in GTM

For GTM, the mechanism is different but the principle is identical. Use a Consent Initialization tag with priority 100.

Step 1 — Create the Consent Initialization tag

In GTM:

Tags → New → Tag Configuration → Custom HTML (or use a Consent Mode template from the Community Template Gallery)
Tag content:

Triggering → Consent Initialization - All Pages (this is a built-in GTM trigger that always fires before any other trigger)
Advanced Settings → Tag firing priority → 100 (highest possible)
Name it: CMP - Consent Default - All Pages

Step 2 — Create the Consent Update tag

This tag fires when the user interacts with your CMP banner. The trigger is a custom event your CMP pushes to dataLayer (e.g., cmp_accept, cmp_reject, cookiebot_consent_update).

Where {{Consent - ad_storage}} etc. are GTM Variables reading from your CMP's dataLayer values.

Triggering: a Custom Event trigger matching your CMP's consent-update event.

Step 3 — Wire your tags to the consent state

For Google tags (GA4 Configuration, GA4 Event, Google Ads Conversion, Floodlight), GTM has built-in consent checks — they automatically respect analytics_storage and ad_storage without manual configuration.

For non-Google tags (Meta Pixel, LinkedIn Insight, TikTok Pixel, Hotjar, etc.), you need to manually configure consent gating:

Tag → Advanced Settings → Consent Settings → Require additional consent for tag to fire
Add the relevant consent type (typically ad_storage for marketing pixels, analytics_storage for analytics tools)

This means non-Google tags will be blocked until the relevant consent is granted, rather than firing in cookieless mode like Google tags do.

Need to validate whether consent timing is distorting your GA4 data?

Audit consent setup

The "tag read consent before a default was set" warning

If you see this warning in Tag Assistant or GTM Preview mode, your consent_default is firing too late. Common causes:

The Consent Initialization tag has lower priority than another tag. Set it to priority 100. Set GA4 Configuration to a lower number (e.g., 50).
The CMP script tag is loading before the consent default. Move the consent default into a Custom HTML tag with the Consent Initialization trigger, not into the CMP's own loading sequence.
A hardcoded gtag.js or GA4 snippet exists outside GTM (e.g., in your theme <head>). Find and remove it — it's bypassing GTM's consent ordering entirely.
Server-side GTM is forwarding events that arrived before consent. The fix is server-side: ensure the sGTM client checks the incoming event's gcs/gcd parameters before forwarding.

Run this diagnostic in Tag Assistant: load a fresh incognito session, watch the tag-firing sequence. The very first event in the sequence must be your consent_default tag. If anything else fires before it, you have an ordering problem.

What happens with a missing or wrong default

The four failure modes ranked by severity:

Critical: default not set at all

Tags fire with no consent state. Google's tags fall back to default-granted behaviour. Cookies set, no consent recorded. EU/UK GDPR violation. Most CMPs will catch this in their compliance scan, but custom implementations can ship to production without it being noticed.

High: default set after first tag fires

Default exists but fires too late. Tags that fired before the default treat consent as granted; tags that fired after treat it as denied. Inconsistent behaviour, partial cookie setting, the dreaded Tag Assistant warning. Half-compliant.

Medium: default set to granted

Default exists but values are granted instead of denied. Cookies set without explicit consent. GDPR violation in EU/UK. Often happens when developers copy/paste examples from non-EU documentation.

Low: default set, update never fires

Default fires correctly, but the user's banner choice never updates the consent state. Tags continue firing in cookieless mode forever. Compliant but loses analytics/ads functionality after consent. Usually a CMP wiring issue.

The four-pattern audit

To diagnose any consent ordering issue, run these four tests in order. The first failure tells you the problem class:

Test 1 — Default present? Open DevTools → Network → look at the very first GA4 collect request. Is gcs present?

Yes → continue to Test 2
No → Consent Mode not installed at all. Add the consent default.

Test 2 — Default value correct? Inspect the same request. What's the gcs value before the user touches the banner?

G100 → correct (Advanced mode, denied default)
G111 → wrong: default is granted (GDPR violation in EU/UK)
(no hit at all) → Basic mode with denied default — also correct, but means no modelling

Test 3 — Default fires first? Open Tag Assistant → load a fresh incognito session → look at the firing sequence. Is the consent default tag the first event?

Yes → continue to Test 4
No → ordering problem. Set Consent Initialization priority to 100. Remove any hardcoded GA snippets outside GTM.

Test 4 — Update fires on banner interaction? With Tag Assistant or DevTools open, click Accept on the banner. Watch for a new collect request. Does gcs change to G111?

Yes → fully working
No → CMP update wiring is broken. Check the CMP's dataLayer push event and the GTM trigger matching it.

Region-specific defaults

Consent defaults can be scoped per region using the region parameter. Common pattern: denied for EU/UK, granted everywhere else.

The two commands together: EU/UK users get denied defaults (compliant); other users get granted defaults (no banner needed for many regions). The order: denied region command first, granted fallback second. Google reads the most specific match — region-scoped wins over global.

US-state caveat: California (CCPA), Colorado (CPA), Virginia (VCDPA), and others now require opt-out flows. Adding US states to the denied region list is increasingly recommended even though Google doesn't strictly require it.