Applies to: All users

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

Overview

Compliance by Hu-manity.co 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. 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 — The plugin immediately calls gtag('consent', 'default', {...}) with the appropriate denied/granted states based on your configuration and visitor location.
  3. Autoblocking engages — Non-essential scripts with hu-block class or data-hu-category attributes 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 Compliance by Hu-manity.co, 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 Compliance banner script.

Fix:

  1. Ensure your Compliance script tag appears before GTM in <head>.
  2. If using a plugin or theme that controls script order, move the 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 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, create a Custom Event trigger using one of these DOM events fired by Compliance by Hu-manity.co:

  • config-loaded.hu — Banner config loaded
  • save-consent.hu — Visitor saved a consent choice
  • revoke-consent.hu — Visitor revoked consent
  • change-consent.hu — Consent state changed (any direction)

Use the appropriate event as a trigger for tags that should fire after consent.

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. Verify that the consent level mapping matches what the tag requires. For example, if a tag requires analytics_storage: 'granted' and you have mapped that to Level 3 (Personalized), but most visitors select Level 2, the tag will stay blocked.

Symptom: Site Kit Tags Stay Blocked Even After Consent

Cause: On 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 → Configuration 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, wp_get_consent_type() should return 'optin' (EU/UK/EEA) or 'optout' (US state laws), and wp_has_consent('statistics') should match the visitor’s choice.

Note: Google Consent Mode v2 and the WP Consent API are independent paths — 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, Compliance by Hu-manity.co 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. 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 the save-consent.hu event or equivalent.
  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 Compliance banner).

Stale Configuration Warning

If you recently changed your Consent Mode settings, use Purge Cache in the WordPress admin (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
Was this article helpful?
YesNo