Skip to main content

Fixing Google Consent Mode v2: Tags Firing Before Consent Updates

 You have implemented Google Consent Mode v2. You have added the script to your <head>. Yet, your Google Analytics 4 (GA4) data looks wrong. You might be seeing a significant drop in users from the EEA (European Economic Area), or conversely, you see data being collected even when you suspect it shouldn't be.

The culprit is almost always a race condition.

In the asynchronous world of modern web development, your Google Tag Manager (GTM) container often initializes and fires tags (like the GA4 Configuration tag) before your Consent Management Platform (CMP) has finished processing the user's choice or updating the Data Layer.

If the tag fires before the consent update, it uses the "Default" state (usually denied). The user's subsequent "Grant" is ignored for that page view. This guide breaks down the root cause of this synchronization failure and provides the code-level architectural changes required to fix it.

The Technical Root Cause: The Data Layer Queue

To understand why your tags are failing, you must visualize the dataLayer as a chronological queue of events.

When a browser loads your page, several scripts fight for execution priority. Google Consent Mode v2 relies on two distinct commands:

  1. default: Sets the baseline consent (usually denied for storage/analytics).
  2. update: Updates the state based on stored user preferences or a new interaction with the cookie banner.

The Race Condition Scenario

In a broken implementation, the execution order often looks like this:

  1. Script: CMP loads (sets default consent).
  2. Script: GTM Container loads.
  3. GTM Event: gtm.js (Container Loaded) fires.
  4. Trigger: GA4 Configuration Tag fires on "All Pages" (triggered by gtm.js).
    • Current State: Denied.
    • Result: Google tags send "ping" data without cookies (Advanced Mode) or are blocked entirely (Basic Mode).
  5. Script: CMP retrieves user cookies or detects user interaction.
  6. Data Layer: CMP pushes the update command.
    • Current State: Granted.
    • Result: Too late. The page view data was already sent with the "Denied" signal.

To fix this, we must decouple tag firing from the generic "Page View" and strictly couple it to a "Consent Signal."

The Solution: Event-Driven Tag Execution

We cannot rely on script ordering in the DOM alone because network latency varies. The only robust solution is to modify your GTM triggers to wait for a specific Data Layer event that indicates consent has been established.

Step 1: Correcting the <head> Script Order

Before touching GTM, ensure your code implementation follows the strict ordering required by Google. The default command must appear inline, immediately before the GTM container snippet.

Do not load the default settings via an external file; it introduces network latency that GTM cannot wait for.

<head>
  <!-- 1. Define dataLayer and the gtag helper function immediately -->
  <script>
    window.dataLayer = window.dataLayer || [];
    function gtag() { dataLayer.push(arguments); }
    
    // 2. Set the DEFAULT consent state synchronously
    // Adjust 'region' as needed for GDPR compliance
    gtag('consent', 'default', {
      'ad_storage': 'denied',
      'ad_user_data': 'denied',
      'ad_personalization': 'denied',
      'analytics_storage': 'denied',
      'wait_for_update': 500 // Milliseconds to wait for the update command
    });
  </script>

  <!-- 3. Load your CMP (e.g., OneTrust, Cookiebot) here -->
  <script src="https://cdn.cmp-provider.com/loader.js" async></script>

  <!-- 4. Load Google Tag Manager -->
  <script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
  new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
  j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
  'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
  })(window,document,'script','dataLayer','GTM-XXXXXX');</script>
</head>

Key Technical Detail: Note the wait_for_update: 500 parameter. This tells Google tags strictly implemented via gtag.js to hold execution for 500ms to allow the CMP to push an update. However, this parameter does not automatically control GTM tags firing on standard triggers.

Step 2: Creating a "Consent Ready" Event

Your CMP (Cookiebot, OneTrust, Usercentrics) likely pushes a custom event to the Data Layer when consent is determined.

  • OneTrust: Pushes OneTrustGroupsUpdated.
  • Cookiebot: Pushes cookie_consent_update.
  • Generic: If your CMP does not push an event, you must add a callback to push one yourself.

We will create a Custom Event Trigger in GTM that serves as our new "Page View" trigger.

Configuration in GTM:

  1. Go to Triggers > New.
  2. Trigger Type: Custom Event.
  3. Event Name: consent_update (Replace this with your CMP's specific event name, e.g., OneTrustGroupsUpdated).
  4. Name: Event - Consent Ready.

Step 3: Configuring the Consent Initialization Trigger

Google has introduced a native trigger type called "Consent Initialization - All Pages". This fires before the standard "Initialization" and "All Pages" triggers.

This is where your CMP tag (if you are injecting the banner via GTM) should fire. However, for the tags consuming the data (GA4, Google Ads), we need to ensure they fire only after the update.

Step 4: Reassigning GA4 and Ads Tags

This is the most critical step. You must stop using "All Pages" for your primary tracking tags.

  1. Open your Google Tag (the GA4 configuration tag).
  2. Remove the Initialization - All Pages or All Pages trigger.
  3. Add the new Event - Consent Ready trigger you created in Step 2.
  4. Repeat this for the Google Ads Conversion Linker and Google Ads Remarketing tags.

Why this works: GTM will load. It will see the tags, but it won't fire them. It waits. The CMP loads, checks the user's cookies, and pushes the consent_update event to the Data Layer. Only then does GTM execute the GA4 tags. At this exact moment, the update command has already been processed, ensuring the tag reads the correct granted state.

Handling Single Page Applications (SPAs)

If you are using React, Vue, Angular, or Next.js, the logic above only solves the initial page load. Subsequent route changes usually rely on "History Change" events.

In an SPA, the consent state usually persists in memory after the first load. However, you must ensure your "Virtual Page View" tags check consent status.

The React/Next.js Hook Approach

If you manage consent state within your application state (not just GTM), you can force a GTM update push on route changes.

// Example: A custom hook for Next.js app router or React Router
import { useEffect } from 'react';
import { usePathname, useSearchParams } from 'next/navigation';

export const useGtmConsentListener = () => {
  const pathname = usePathname();
  const searchParams = useSearchParams();

  useEffect(() => {
    // 1. Ensure dataLayer exists
    window.dataLayer = window.dataLayer || [];

    // 2. Logic to verify consent is still valid (optional, depends on CMP)
    // 3. Push a Virtual Page View that GTM can listen to
    window.dataLayer.push({
      event: 'virtual_page_view',
      page_path: pathname,
      page_query: searchParams.toString(),
      // Explicitly passing consent state can be helpful for debugging
      consent_state_snapshot: 'granted' 
    });
    
  }, [pathname, searchParams]);
};

In GTM, your Virtual Page View trigger does not need to wait for a consent_update event on subsequent navigations because the consent state is already established in the browser session.

Deep Dive: Verifying the Fix

You cannot assume this works; you must verify the execution sequence. Use the GTM "Preview" mode (Tag Assistant).

  1. Enter Preview Mode and load your site.
  2. Look at the Summary column on the left.
  3. Find the Consent tab at the top of the event log.

The Correct Sequence

You should see the events in this specific order:

  1. Consent (Default): Shows the defaults set in your <head>.
  2. Message / gtm.js: GTM loads. No GA4 tags should fire here.
  3. Consent (Update): Your CMP processes the user choice.
  4. consent_update (Custom Event): The event we configured.
  5. Tags Fired: Your GA4 and Ads tags should appear attached to this event.

If you click on the GA4 tag and switch to the "Consent" tab, you should see "On-page Update" listed with status "Granted" (assuming you accepted cookies).

Common Edge Case: The "No Interaction" User

What happens if a user lands on the page and ignores the banner?

  1. The default state is denied.
  2. The CMP loads but the user hasn't clicked anything.
  3. Does the CMP fire an update event?

Crucial Logic: Most modern CMPs (like Cookiebot) fire a callback even if no interaction happens, simply to confirm "The existing consent is... nothing."

If your CMP does not fire an event when the banner is simply displayed (without interaction), your GA4 tags will never fire. This is compliant but might not be desired for "Basic" modeling.

The Fix for Non-Interaction: You may need a fallback timer or a "CMP Loaded" event. If 2 seconds pass and no consent choice is made, you might choose to fire tags (which will be blocked by GTM's built-in consent checks anyway if the default is denied), allowing Google to receive the pingless signal for behavioral modeling.

Conclusion

The failure of Google Consent Mode v2 implementations rarely lies in the configuration of the consent mode itself, but rather in the synchronization of the initialization sequence.

By moving your primary tracking tags off the native "All Pages" trigger and onto a CMP-driven custom event, you ensure that the gtag('consent', 'update') command has always executed before data collection begins. This ensures compliance with EEA regulations while maximizing the data fidelity for users who have granted consent.

Labels: