Introduction
Explain Consent Initialization as the early step that writes Consent Mode default states (usually denied for non-essential storage) before GA4, Ads, or other Google tags load—covering GTM Consent Initialization tags, gtag defaults, order mistakes, and clean-session verification.
This guide is written for GTM and Consent Mode implementers who need Consent Initialization defaults denied before Google tags fire on EU traffic.
What it means
Consent Initialization is the first Consent Mode write on a page load: it establishes default consent states before measurement or ads tags run, so Google tags do not assume storage is allowed.
In Google Tag Manager this is commonly a Consent Initialization (or equivalent early consent default) tag that fires on All Pages before tags that read consent state. With gtag.js it is a consent default command before config/event calls.
For EU/EEA-oriented setups, Consent Initialization should set analytics_storage, ad_storage, ad_user_data, and ad_personalization to denied until the CMP or banner sends an update.
Order is the product: Consent Initialization must win the race against GTM, hardcoded gtag snippets, and next/script analytics in the root layout. Late defaults leave a pre-consent collection window scanners detect.
Consent Initialization is not the same as a consent update. Initialization sets defaults; Accept/Reject later fire updates that flip matching parameters to granted or keep them denied.
Never publish granted defaults in Consent Initialization for convenience or Tag Assistant demos—those settings often ship to production and fail GDPR cookie rules.
Verify Consent Initialization on the live URL: View Source / Tag Assistant Consent tab, Network before interaction, then a GDPRChecker scan for pre-consent Google cookies and requests.
Why it matters
Most Consent Mode failures are Consent Initialization failures: defaults missing, granted, or after GTM.
Searchers for Consent Initialization want GTM-specific steps tied to scanner-proof verification, not only Google Help screenshots.
Fixing initialization first usually clears more scanner findings than redesigning banner copy.
Common mistakes
- Omitting Consent Initialization so tags run with platform defaults that allow storage.
- Setting Consent Initialization parameters to granted for testing and forgetting to revert before publish.
- Placing Consent Initialization after GA4 Config / Google tags in the container firing order.
- Initializing only analytics_storage and ad_storage while leaving ad_user_data and ad_personalization granted.
- Hardcoding gtag config in the theme while Consent Initialization exists only in a staging container.
- Checking Tag Assistant after Accept and concluding initialization works for first-time visitors.
- Assuming Consent Initialization alone is a lawful cookie banner.
Practical checklist
- Add or confirm a Consent Initialization (or gtag consent default) path that runs before Google tags.
- Set all Consent Mode v2 parameters you use to denied for regulated regions.
- Place initialization above GA4, Ads, Floodlight, and other consent-reading tags.
- Wire CMP/banner updates separately for Accept, Reject, and preference changes.
- Publish the same settings to production—not only GTM Preview.
- Private window: confirm denied defaults before any Google cookie or hit.
- Reject and Accept paths: updates fire; tags obey.
- Scan with GDPRChecker; fix order; rescan after the next container publish.
How GDPRChecker helps
GDPRChecker’s free scanner shows whether Consent Initialization actually prevented pre-consent Google requests on your production URL.
Use findings to fix script and GTM order, then rescan after each Consent Initialization or CMP change.
GDPRChecker supports Consent Mode v2-oriented diagnostics; it is not a Google Certified CMP or IAB TCF CMP.