Introduction
Define Consent Signals in plain language: the machine-readable consent states a banner or CMP emits so analytics and ads tags know whether storage and advertising uses are granted or denied—especially Google Consent Mode defaults and updates—and how to verify them with a clean-session scan.
This guide is written for Marketers and engineers wiring Google tags, CMPs, and Consent Mode who need a clear definition of Consent Signals and how to verify them on a live site.
What it means
Consent Signals are the structured yes/no (or granted/denied) states your consent layer sends to tags so they know whether cookies, ads personalization, or user-data uses are allowed for this visitor and session.
In Google Consent Mode v2, the core Consent Signals include parameters such as analytics_storage, ad_storage, ad_user_data, and ad_personalization—set as defaults before tags load, then updated when the user Accepts, Rejects, or changes preferences.
A banner UI alone is not a Consent Signal. Signals only exist when the CMP or runtime writes defaults/updates that GTM, gtag, or other loaders can read before non-essential collection runs.
Correct order matters: denied defaults first, then the Consent Signal update on choice, then tags that respect those states. Defaults after GTM has already fired are a common failure.
Map categories carefully: analytics consent to analytics_storage; marketing/ads consent to ad_storage, ad_user_data, and ad_personalization as applicable—do not grant ads signals when the user only accepted analytics.
Consent Signals complement—not replace—lawful consent UX. Reject must be equal and enforceable; scanners still fail if cookies set before any signal exists.
Verify Consent Signals on production with a private window (Tag Assistant / dataLayer / Network) plus an independent GDPRChecker scan for pre-consent cookies and requests.
Why it matters
Teams searching Consent Signals usually struggle to translate CMP clicks into tag behavior Google and scanners can observe.
Competitor Consent Mode content is dense; a definition page that routes to setup and verification guides captures mid-funnel research traffic.
Wrong or late Consent Signals cause both measurement gaps and compliance findings—fixing the signal path protects campaigns and audits.
Common mistakes
- Showing Accept/Reject without emitting Consent Mode updates.
- Setting all Consent Signals to granted by default in the EU.
- Loading gtag/GTM before denied defaults are written.
- Mapping Accept all to every ads parameter when the user chose analytics only.
- Testing only after Accept in the same browser profile.
- Assuming Consent Signals equal IAB TCF / TC String certification.
- Treating Tag Assistant green status as proof no pre-consent cookies exist.
Practical checklist
- Inventory which tags read Consent Mode or CMP Consent Signals.
- Set Consent Mode v2 defaults to denied for non-essential storage before Google tags load.
- Wire banner Accept/Reject/preference changes to the matching parameter updates.
- Confirm category mapping for analytics vs ads signals.
- Private-window test: no non-essential Google cookies/requests before interaction.
- Reject path: ads and analytics signals stay denied; tags stay blocked across two navigations.
- Accept path: only granted categories unlock; confirm update events fire.
- Scan the live URL with GDPRChecker; fix script order; rescan after GTM publishes.
How GDPRChecker helps
GDPRChecker’s free scanner helps validate the outcome of Consent Signals: whether cookies and third-party requests still appear before any choice on your production URL.
Use findings to prioritize default order and blocking fixes, then rescan after CMP or Consent Mode changes.
GDPRChecker supports Consent Mode v2-oriented diagnostics and runtime checks; it is not a Google Certified CMP or IAB TCF CMP.