CONSENTCHECK
← Blog

GA4 firing before consent? Here's the actual fix

Jul 25, 2026

Confirming that GA4 fires before consent is the easy part — the DevTools method for that is the same one covered here. Actually fixing it means figuring out which of three genuinely different GA4-specific gaps you're looking at, because the fix is different for each.

1. The GA4 configuration tag isn't checking consent at all

How to check: in GTM, open your GA4 Configuration tag and check its Consent Settings (in the tag's Advanced Settings section, or under Consent Overview for the tag). If analytics_storage isn't listed as a required consent type for this tag, GTM will fire it regardless of the current consent state — this is a tag-level setting, separate from whether Consent Mode is implemented elsewhere in the container at all.

The fix: in the tag's Consent Settings, add analytics_storage as an additional consent check if it isn't already there. GTM's native GA4 tag type does this automatically in most current setups, but tags migrated from older configurations, or built from a copied/duplicated tag, can lose this setting silently.

2. The consent default itself doesn't cover analytics_storage correctly

How to check: in DevTools console, before interacting with your banner, run dataLayer and find the consent entry with "default". Confirm analytics_storage is present and set to "denied". If it's missing entirely, or the whole default entry is missing or arrives late, this is actually the ordering/completeness problem covered in why Google Consent Mode v2 isn't working and consent default fires after GTM loads — not a GA4-specific issue at all. Worth ruling this out first, since it's the more common root cause and the GA4 tag itself may be configured correctly.

The fix: fix the underlying default/ordering issue per those two articles. Once the default is genuinely correct and fires first, a properly-configured GA4 tag respects it automatically.

3. Enhanced Measurement events fire independently of the base tag's consent check

How to check: GA4's Enhanced Measurement (automatic scroll tracking, outbound clicks, site search, video engagement, file downloads) is enabled by default on most GA4 properties. In DevTools Network tab, watch for collect requests specifically tied to scroll or click events — not just the initial page_view hit — before you've interacted with the consent banner.

The fix: this is a genuine GA4-specific gap, not a GTM misconfiguration — Enhanced Measurement events are generated by the GA4 tag's own JavaScript once it loads, and Google's documentation doesn't expose a separate, independent consent setting for Enhanced Measurement events specifically — it's governed by the base configuration tag's own consent state, not a setting you configure on its own. In practice, that means if the base configuration tag fired even once before consent (even briefly, due to a timing issue elsewhere), Enhanced Measurement listeners can already be attached for that page load. The most reliable fix is making sure the base GA4 configuration tag itself never fires pre-consent in the first place, per checks #1 and #2 above.

Confirming the fix actually worked

How to check: run the same incognito/Network-tab check from the top of this article — zero collect requests before any interaction. Then also click Accept and confirm requests do start flowing — a fix that blocks GA4 permanently regardless of consent isn't a fix, it's a different bug, and it's easy to accidentally create one while fixing the other.

If GA4 traffic looks lower after the fix, that's expected

Once GA4 genuinely stops firing before consent, your measured traffic will reflect only consenting visitors — a real, expected drop, not a sign something else broke. If this overlaps with a shrinking remarketing audience specifically, see is consent gating shrinking your remarketing audience for how to tell the difference between "working as intended" and a separate problem.

If you'd rather have this checked automatically

A pre-consent scan checks exactly the behavior this article walks through by hand — whether GA4 requests fire before a consent default is set, and whether Enhanced Measurement events leak through separately — worth running once you've made a fix to confirm it actually took.

Petrus, Founder — ConsentCheck. Enhanced Measurement specifically is the gap people miss most often after they've already fixed the "obvious" Consent Mode default issue — it's the one extra check worth the ninety seconds it takes.

FAQ

I confirmed GA4 fires before consent. What's the actual fix, not just the check?

Depends which of three places is broken: the GA4 configuration tag isn't respecting Consent Mode at all (add or fix the consent check in its tag settings), Enhanced Measurement events are firing independently of the base config tag's consent state (a known GA4-specific gap, not a GTM misconfiguration), or the consent default/update itself is incomplete for analytics_storage specifically. Each has a different fix, covered in this article -- the DevTools check alone doesn't tell you which one it is.

Does GTM's GA4 Configuration tag automatically respect Consent Mode?

Yes, by default, as long as Consent Mode is correctly implemented elsewhere in the container -- GTM's native GA4 tag type checks analytics_storage automatically. The most common reason it doesn't in practice is that the consent default itself isn't set correctly before the GA4 tag fires (an ordering problem, not a GA4-specific one), not that the GA4 tag is ignoring consent on purpose.

Why does GA4 still fire even after I fixed the Consent Mode default?

Check whether you're using GA4's Enhanced Measurement (automatic scroll, click, and engagement tracking) -- these can fire through paths that don't always route through the same consent check as the base configuration tag, depending on how the tag was set up. This is a real, GA4-specific gap distinct from the general Consent Mode ordering issues covered elsewhere on this site.

How do I verify the fix actually stopped GA4 from firing before consent?

Clear cookies or use a fresh incognito window, open DevTools Network tab, filter for 'collect', and reload without touching the banner. Confirm zero requests to google-analytics.com/g/collect or analytics.google.com/g/collect before you interact with anything. This is the same behavioral check as before the fix -- the difference is what you're confirming has changed, not a different method.

Want to know if your own site does this?

Scan your site free