Consent Mode is not a consent banner. The banner is the consent management platform (CMP) — OneTrust, Cookiebot, Didomi, and others. Consent Mode is the parameter layer underneath: four signals — ad_storage, analytics_storage, ad_user_data, ad_personalization — that the CMP writes on the page after the visitor chooses, and that Google Ads, GA4, and Floodlight tags read when they fire. The CMP collects consent; Consent Mode communicates it.
What Google branded “Consent Mode v2” added ad_user_data and ad_personalization to the original analytics_storage and ad_storage. Around early 2024, Google began treating the v2 signals as effectively required for advertisers using EEA-resident audience data in Google Ads remarketing, audience features, and measurement reporting — without them, those features stopped receiving data from that region. Specifics have shifted since; check Google’s current docs.
The implementation choice matters. Google’s documentation describes two paths when consent is denied: a “basic” path where tags are blocked until consent is granted, so Google receives nothing; and an “advanced” path where tags fire stripped-down “cookieless” pings without identifiers, feeding Google’s modeling layer for signals it would otherwise lose. Google steers brands toward the advanced path because the modeling has more to work with.
Consent Mode is web-and-Google-specific. It does not cover iOS app tracking, which is governed by App Tracking Transparency, and it does not by itself establish the lawfulness of consent collection under GDPR, ePrivacy, or CCPA/CPRA — that responsibility sits with the CMP configuration and the brand. What it does is preserve a measurement bridge built on the first-party data the brand still has, plus Google’s modeling of the gaps.