Applies to: All users

This article covers Google Tag Manager timing issues that apply to all implementations.

Overview

Cookie Compliance controls when tags fire by setting Google Consent Mode defaults early in the page lifecycle and updating them after a visitor makes a choice. If your GTM tags are firing at the wrong time — too early, too late, or not at all — this guide walks through the most common causes.

How the Tag Execution Sequence Works

Understanding the order of events helps you diagnose timing issues:

  1. Cookie Compliance loads — The banner script (hu-banner.js) initializes at the top of <head>, before any analytics or advertising tags.
  2. Consent Mode defaults are set — When Google Consent Mode is on, the banner script immediately sets gtag('consent', 'default', {...}) from your configuration, with region-specific defaults where your selected laws call for them, before Google tags run.
  3. Autoblocking engages — Non-essential scripts that match a known tracker, or that you mark with the hu-block class plus data-hu-category="N" (1 Basic Operations, 2 Content Personalization, 3 Site Optimization, 4 Ad Personalization; a hu-block script without it is treated as 2), are paused.
  4. GTM loads — The GTM container script initializes. At this point, Google tags already have a consent state.
  5. Banner displays — The visitor sees the consent banner.
  6. Visitor makes a choice — Consent state updates via gtag('consent', 'update', {...}).
  7. GTM tags fire — Tags configured to fire on consent events are now released.

The most common mismatch: GTM is loaded before the Cookie Compliance script, reversing steps 2 and 4. This causes Google tags to initialize without a consent default, and Google may treat that as “granted.”

Symptom: Tags Firing Too Early (Before Consent)

Cause: GTM or Google tag scripts are loading before the Cookie Compliance banner script.

Fix:

  1. Ensure your Cookie Compliance script tag appears before GTM in <head>.
  2. If using a plugin or theme that controls script order, move the Cookie Compliance script to the earliest position.
  3. In GTM, do not call gtag('consent', 'default', ...) from a Custom HTML tag — use the Consent Initialization trigger type for any consent defaults, as this fires before all other tags.

Verify: In GTM Preview Mode, look at the Tag Assistant timeline. The consent default should appear at the very start (position 1–2 in the sequence), before any tag fires.

Symptom: Default Triggers at Step 6 Instead of Step 2

This exact pattern occurs when the Cookie Compliance script is placed in the page after GTM. The consent default is being set at step 6 (when the banner script finally loads) instead of step 2 (before GTM initializes).

Fix: Script load order. Cookie Compliance → GTM. Nothing else resolves this.

Check for plugin conflicts

Some WordPress caching and optimization plugins (WP Rocket, Autoptimize, NitroPack) concatenate or defer scripts, which can change the execution order even if your HTML has the right order. If you are using one of these:

  • Add hu-banner to the “excluded from defer/async” list.
  • Add the GTM script to the “excluded from concatenation” list so it does not bundle with other scripts.

Symptom: Tags Not Firing After Consent Is Given

Cause 1: GTM triggers not configured for consent events

In GTM, a Custom Event trigger listens for dataLayer events. With Google Consent Mode on, Cookie Compliance pushes these:

  • CC Consent Set — the consent state was applied on page load. It fires on every page view: with the visitor’s stored choice once they have one, and for a first-time visitor before they have chosen.
  • CC Consent Updated — the visitor’s choice was applied, at most once per page view (for example when they save a choice).

With Google Consent Mode on, Cookie Compliance lets GTM run, so it does not hold tags that GTM fires: gate your non-Google tags inside GTM. Give each tag that should fire after consent both triggers, so it also fires on the visitor’s second and later pages, and add GTM’s consent checks (for example Require additional consent for analytics_storage or ad_storage) so the CC Consent Set trigger does not fire the tag for a visitor who has not consented. The banner also fires browser events for your own JavaScript — config-loaded.hu, set-consent.hu (any consent change) and save-consent.hu (after the choice is stored) — but a GTM Custom Event trigger cannot see these directly.

Cause 2: Consent level mapping mismatch

The tag is checking for analytics_storage: 'granted' but the consent mode parameter mapping does not grant it at the visitor’s chosen consent level.

Fix: Review your Consent Mode parameter mapping in the Cookie Consent tab → Laws, languages & signals → Consent signals → Google Consent Mode v2. Each signal is mapped to a purpose category, not a level. By default analytics_storage maps to Site Optimization, which visitors grant by choosing Balanced or Personalized. If you map it to Ad Personalization instead, visitors who choose Balanced keep it denied and the tag stays blocked.

Symptom: Site Kit Tags Stay Blocked Even After Consent

Cause: On Cookie Compliance v3.1.0+, the plugin registers as a WP Consent API CMP. Google Site Kit — when used as your GTM/GA4 source — now reads consent directly from the WP Consent API instead of (or in addition to) Google Consent Mode. If the WP Consent API integration is off, or the WP Consent API plugin is not installed, Site Kit can fall back to a deny-by-default state and stay blocked even though GCM v2 reports granted.

Fix:

  1. Install and activate the WP Consent API plugin (free, from WordPress.org).
  2. In the WordPress admin, go to Compliance → Cookie Consent tab → Technical Settings (classic settings screen: Cookie Consent Settings) and confirm the WP Consent API toggle is on. On v3.1.0+ it is on by default.
  3. Reload a fresh session and check the browser console. consent_api.consent_type holds one value for the whole site, based on the laws you selected: 'optin' if GDPR, UK PECR, LGPD or POPIA is selected, 'optout' if only CCPA, Other US State Laws or PIPEDA are selected, and an empty value if no laws are selected or the integration is off. It does not change with the visitor’s location. After the visitor chooses Balanced or Personalized, wp_has_consent('statistics') should return true.

Note: Google Consent Mode v2 and the WP Consent API are independent paths — Cookie Compliance fires both. GCM v2 gates Google-side tag execution (analytics_storage, ad_storage, ad_user_data, ad_personalization); the WP Consent API gates consumer plugins server-side (Site Kit, WooCommerce, Burst, etc.). Both must be configured correctly for Site Kit to fire as expected.

Symptom: Consent Mode v2 Parameters Missing

If Google Consent Mode is enabled but only v1 parameters (ad_storage, analytics_storage) are being sent, and the v2 parameters (ad_user_data, ad_personalization) are missing:

Fix: Ensure Google Consent Mode is enabled in the WordPress admin at Cookie Consent tab → Laws, languages & signals → Consent signals → Google Consent Mode v2. When enabled, Cookie Compliance automatically sends all four parameters required for Consent Mode v2.

If GA4 is still showing consent warnings for EEA streams after enabling, verify with Tag Assistant that all four parameters appear in the consent update.

Debugging Checklist

  1. Cookie Compliance script is in <head> and loads before GTM.
  2. No caching or optimization plugin is deferring or reordering scripts.
  3. In Tag Assistant: consent default appears at step 1–2 (before GTM container loads).
  4. GTM triggers for post-consent tags use both the CC Consent Set and CC Consent Updated dataLayer events, with GTM consent checks on the tag.
  5. Consent Mode is enabled in the WordPress admin Cookie Consent tab → Laws, languages & signals → Consent signals.
  6. Parameter mapping is correct for all four v2 parameters.
  7. No duplicate gtag('consent', 'default', ...) calls in GTM (conflicts with the Cookie Compliance banner).

Stale Configuration Warning

If you recently changed your Consent Mode settings, use Purge Cache in the WordPress admin (Cookie Consent tab → Technical Settings) to force the banner to reload the latest configuration. Some server and edge caches can serve an older version for up to 1 hour.

Still Not Working?

Contact support with:

  • Your App ID (found in the WordPress admin or portal Account page)
  • A GTM Preview Mode screenshot showing the tag timeline
  • Browser console output (F12 → Console) from a fresh incognito window
Was this article helpful?
YesNo