GTM / Tag Trigger Timing Troubleshooting

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.min.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', {...}) with the appropriate denied/granted states based on your configuration and the visitor’s region.
  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 Cookie Compliance, 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. 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 Protection tab → Consent Modes → Google Consent Mode v2. Each signal is mapped to a purpose category and is granted once the visitor allows that category. For example, if a tag requires analytics_storage: 'granted' and you have mapped that signal to Ad Personalization, visitors who choose Balanced do not grant it 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 → Settings tab → Technical Settings (classic screen: Cookie Consent Settings section) and confirm the WP Consent API toggle is on. On v3.1.0+ it is on by default.
  3. Reload a fresh session. In the browser console, consent_api.consent_type should return 'optin' if GDPR, UK PECR, LGPD or POPIA is among your selected laws, or 'optout' if only CCPA, Other US State Laws or PIPEDA are (one value for the whole site, not per visitor), and wp_has_consent('statistics') should match the visitor’s choice.

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 Protection tab → Consent Modes → 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 Protection tab → Consent Modes.
  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 (Compliance → Settings 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

Still need help? Contact Us Contact Us