Introduction
Set up GA4 with cookie consent controls that work reliably across banner, GTM, and runtime. This is a step-by-step practical implementation guide.
What it means
GA4 should not initialize tracking cookies before user consent where required.
Consent state must be mapped consistently between CMP, GTM, and GA4 tags.
Testing should cover accept, reject, partial consent, and withdrawal scenarios.
Deployment checklists reduce regressions from container and plugin updates.
Why it matters
Regulators, customers, and automated scanners increasingly treat published policies and live site behavior as one system. Gaps between what you say and what your site does create enforcement and commercial risk.
Fixing issues early is cheaper than retrofitting consent, tag managers, and legal pages after a complaint or failed enterprise security review.
Common mistakes
- Sending analytics hits before consent or lawful fallback conditions.
- Assuming Consent Mode alone satisfies all GDPR consent requirements for tracking.
- Configuring banner UI without validating tag manager runtime behavior.
- Ignoring regional and purpose-specific consent requirements.
- Failing to document implementation decisions and evidence.
Practical checklist
- Inventory GA4, GTM, Ads, and connected Google services.
- Map legal basis and consent needs for each data flow.
- Block non-essential tags until valid consent signals.
- Configure consent state propagation in GTM and app code.
- Validate requests in browser/network across consent states.
- Log consent events and policy versions for auditability.
- Re-test after container changes and vendor updates.
How GDPRChecker helps
GDPRChecker scanner is useful for confirming whether Google-related scripts or requests still appear before consent. It helps teams separate UI assumptions from actual runtime behavior.
GDPRChecker runtime monitoring can alert teams when GTM or site updates reintroduce pre-consent tracking. This ongoing verification is valuable because consent integrations can drift over time.