Debug Google Consent Mode in Chrome DevTools

What Google Consent Mode traffic looks like

Consent Mode is a signaling layer with two visible surfaces: consent pushes in the dataLayer, and encoded consent state plus cookieless pings on the wire.

Endpoint pattern

google.com/ccm/collect: cookieless pings when storage consent is denied; enhanced-conversions form data flows through google.com/ccm/form-data. /ccm/collect is a delivery method shared by GA4, Google Ads, and Floodlight, not its own tracker

Transport

HTTP hits to /ccm/collect without cookies; the consent commands themselves travel as dataLayer pushes, not network requests

Key parameters

id / tid / tids tracking ID: a G- measurement ID, AW- conversion ID, or DC- Floodlight ID · en event name · dl page URL

Data layer objects

gtag's consent API pushes ["consent", "default", {…}] before any tag fires and ["consent", "update", {…}] when the CMP answers, carrying ad_storage, analytics_storage, and (since v2) ad_user_data and ad_personalization, each granted or denied

Consent signals

Google tags encode consent state into their hits: gcs, a compact code like G111 reflecting storage grants, and the richer v2 gcd parameter

Debugging Google Consent Mode with Event Watcher

• Consent command pushes appear in the stream as they happen, including the default push that fired before DevTools opened, captured as historical, which matters because ordering is the whole game in Consent Mode.
• A dedicated parser decodes /ccm/collect hits. It reads the tracking ID and routes the event to the platform it actually belongs to: GA4, Google Ads conversion, or Floodlight.
• Event name, parameters, IDs, and consent signals render as readable sections instead of a raw query string.

Google Consent Mode and consent

Consent Mode is itself a consent signal, so the extension treats it as a source, not a subject: consent default and consent update pushes are read directly, mapping analytics_storage to analytics and ad_storage plus the v2 ad signals to marketing.

Cross-checking against the CMP integrations verifies the handoff: do the CMP's categories and its relayed consent commands agree? /ccm/collect events are the denied path by design: labeled as Consent Mode traffic, not flagged. See debugging Google Consent Mode v2.

Common debugging scenarios

• No consent default before tags fire. The classic misconfiguration: the default push must precede every Google tag, and the stream's ordering shows whether it did.
• CMP grants, gcs says denied. Compare the CMP's update push against the gcs/gcd values the parser surfaces on subsequent hits. Stale defaults or a missing update relay are the usual causes.
• v2 signals missing. ad_user_data and ad_personalization absent from the update push means the CMP template predates v2, a compliance gap for EEA ad measurement.
• Everything routes to /ccm/collect. Storage consent is being denied for all users. Check whether the update push ever fires, or whether a region rule is broader than intended.
• Which script pushed the consent update? Source attribution answers whether the CMP, GTM, or site code sent it. See which script pushed this dataLayer event.