Back to blog
|7 min read

CMP and GA4: Validating the Consent Signal Timing

The timing between when a user's browser loads the page, when the CMP initialises, when the consent signal is communicated to GA4, and when GA4 fires its first event is one of the most technically nuanced aspects of a compliant analytics implementation. A timing mismatch at any step can result in tracking occurring before valid consent has been obtained.

The Correct Sequence for Consent-Aware GA4 Firing

For a first time visitor with no consent cookie stored, the correct sequence is: page loads, the gtag consent command fires with default consent states set to denied, the CMP JavaScript initialises and renders the consent banner, the user interacts with the banner and accepts or declines, the CMP fires the gtag consent update command reflecting the user's choice, and GA4 then sends its first event payload with the appropriate consent state.

The critical requirement is that the default consent states are set to denied before the page_view event fires.

If ga4 fires page_view before the default consent command, you have a window where tracking occurs without consent state being set.

This window can be as short as milliseconds or as long as several seconds depending on how quickly scripts load, but it is legally significant regardless of duration.

Common Timing Failures and How to Identify Them

The most common timing failure is loading the GA4 tag before the CMP script.

If the CMP loads asynchronously and GA4 is loaded synchronously in the page head, GA4 will fire page_view before the CMP has had any opportunity to set consent state.

A second failure mode is the "consent on load" problem: some CMP implementations read a previously stored consent cookie and call the gtag consent update before the CMP renders the banner, this is correct for returning users who already consented, but it requires the CMP to reliably trigger this call before the first GA4 event fires on every page.

A third failure is race conditions in GTM: if both the CMP and the GA4 configuration tag are loaded by GTM, the order depends on the GTM tag firing priority settings and load order, which may not consistently favour the CMP.

To identify timing failures, use the browser's network panel with request timing displayed, look at the timestamps of the first GA4 collect request and compare it against the first CMP API call.

Testing Consent Timing Across Different Scenarios

Effective consent timing validation requires testing across multiple user scenarios, not just a single first visit test.

Test the first visit with no cookies, the return visit where the user previously accepted, the return visit where the user previously declined, and a page load on a slow network connection where scripts may load in a different order.

For each scenario, verify: that the consent state communicated to GA4 matches what the user chose (or what the stored preference says), that no GA4 cookies are set before consent is granted, and that the first GA4 event payload reflects the correct consent state.

Slow network testing is particularly important because consent timing failures often only manifest when the CMP loads slowly relative to GA4, on a fast connection, the millisecond difference may be invisible, while on a slow 3G connection, the timing gap can be seconds.

Using Chrome DevTools with network throttling set to "Slow 3G" while running consent timing tests reveals failures that fast network testing would miss.

Ready to audit your GA4 property?

Run a full GA4 audit in under 10 minutes. Free to start.

Start Free Audit