Introduction
Google Analytics 4 sets cookies and sends identifiers that qualify as personal data under GDPR. Loading gtag.js or GA4 through Google Tag Manager on every page without prior consent is one of the most common—and most penalized—compliance failures on EU-facing sites.
Blocking GA4 before consent means the tag does not execute, does not call googletagmanager.com or google-analytics.com for measurement purposes, and does not write _ga or related cookies until the user opts into analytics. Consent Mode denied defaults help, but many sites also need hard blocking at the template or runtime layer.
This guide covers ordering, GTM patterns, Consent Mode interaction, and how to verify blocking actually works—not just that a banner appears.
What it means
Script order determines outcomes. If GA4 loads before your consent default or blocking shim, the first pageview may fire with cookies anyway. Put a synchronous guard first in head, set denied consent defaults, then load GTM or gtag only after analytics consent—or keep tags blocked until update fires.
In GTM, replace All Pages triggers on GA4 Configuration tags with triggers tied to consent state— for example a custom event when analytics_storage becomes granted, or built-in consent-aware firing when properly configured. Preview mode can hide mistakes if you already granted consent in your browser.
Consent Mode with analytics_storage denied prevents cookie writes in many cases but tags may still load if you include the snippet. For strict interpretations, prevent the GA4 tag from firing at all until opt-in, then call consent update immediately before configuration fires.
Duplicate installs break blocking. GA4 hardcoded in the theme plus a GTM tag, or plugins that inject analytics independently, bypass your CMP. Inventory every path that loads gtag, analytics.js legacy, or measurement protocol endpoints.
Server-side GA4 still processes identifiers. If you forward events server-side after client collection, blocking must happen client-side first. Server GTM should not receive full payloads when analytics consent is denied.
Why it matters
CNIL, ICO, and other authorities explicitly cite Google Analytics in enforcement guidance. Pre-consent GA4 cookies are easy for scanners to detect and hard to defend when your banner claims waiting for consent.
Analytics vendors are not your DPO. Google's documentation optimizes for data collection; your legal obligation is to stop non-essential processing until opt-in. Blocking is your responsibility in the template and tag rules.
Fixing GA4 blocking often improves overall stack hygiene—marketers discover orphaned pixels, duplicate containers, and theme plugins that fired silently for years.
Common mistakes
- Consent Initialization set to granted in GTM for testing, then published.
- Blocking the banner but not the GA4 tag inside GTM.
- Using async GTM in head before the guard script.
- Only blocking google-analytics.com but allowing doubleclick or googletagmanager requests.
- Forgetting staging domains that mirror production tags without blocking.
- Assuming IP anonymization replaces consent—it does not.
- Checking Tag Assistant while logged into Google accounts with prior consent cookies.
Practical checklist
- List every GA4 and gtag entry point across theme, plugins, and GTM.
- Install runtime-guard synchronously as the first script in head.
- Set analytics_storage denied before any Google script loads.
- Gate GA4 Configuration tags on analytics consent, not All Pages.
- Test in private window with network filter for google-analytics and googletagmanager.
- Confirm Reject leaves GA4 fully silent on subsequent pages.
- Align cookie policy text with observed blocking behavior.
- Schedule re-scan after each GTM publish.
How GDPRChecker helps
GDPRChecker runtime protection intercepts configured analytics domains and scripts until the user enables the analytics category in your banner. Tracker rules in the dashboard map GA4, GTM, and common Google endpoints to that category automatically or via custom patterns.
The compliance scanner's pre-consent behavior phase loads your page as a new visitor would and flags google-analytics.com, googletagmanager.com, and related requests before any Accept click—surfacing leaks that Tag Assistant misses when your browser already consented.
Setup verification confirms runtime-guard.js appears before GTM in HTML and heartbeat signals prove the runtime is active on production, not only in the dashboard preview.