In short
Consent Mode v2 is Google’s framework for passing user consent state with every Google tag and API call. It carries four signals, ad_storage, ad_user_data, ad_personalization, and analytics_storage, that tell Google what each user has permitted. Since March 2024 it is required for EEA and UK traffic to use Google’s ad personalization and measurement features. The practical consequence is direct: without ad_user_data consent, Google cannot use your hashed identifiers, which breaks Enhanced Conversions and Customer Match for that user. Consent Mode also enables Google’s modeled conversions, which estimate the conversions lost when users decline, so reporting stays usable rather than collapsing to only consented traffic. Implementation has two halves. Your consent management platform records the user’s choice, and Consent Mode transmits that choice to Google. A complete setup wires both the tag-level signals and the server-side propagation, so the consent state survives the entire pipeline rather than being lost at the first hop.
Why does Consent Mode decide your Google performance?
Without ad_user_data consent, Google cannot use your hashed identifiers, which breaks Enhanced Conversions and Customer Match for that user. Consent Mode also enables modeled conversions to fill gaps left by declined consent.
How do you implement Consent Mode v2?
Your CMP records the choice; Consent Mode transmits it. Datahash implements both the tag-level signals and the server-side propagation so consent survives the whole pipeline.
How does consent state change Google performance?
A user accepts analytics but declines ad personalization. With Consent Mode v2 in place, Google records the analytics event, withholds the identifiers it may not use, and models the missing ad conversion, so measurement continues within the limits the user set.
Reference: Google Ads Help, about consent mode