Consent Mode v2 server-side: what ad_user_data and ad_personalization actually do

Google Consent Mode v2 became mandatory in March 2024 for advertisers who serve ads to people in the European Economic Area, the UK and Switzerland. Without it, Google Ads stops accepting conversions and audience data for those users. Most guides describe how to set it up in the browser with gtag('consent', ...). Far fewer explain what changes when your data reaches Google from a server.

The four signals

Consent Mode v2 has four consent types:

• `ad_storage`: may the browser store advertising cookies?
• `analytics_storage`: may the browser store analytics cookies?
• `ad_user_data`: may user data be sent to Google for advertising?
• `ad_personalization`: may the data be used for personalised advertising, such as remarketing?

The first two are about the browser: they tell the Google tag whether it may read and write cookies on the page. The last two, added in v2, are about what Google may do with the data it receives.

Why only two of them work server-side

When your server sends an event to Google (GA4's Measurement Protocol or a Google Ads conversion upload), no browser cookie is being set by Google, so ad_storage and analytics_storage have nothing to control. Server-side, Google honours ad_user_data and ad_personalization. Sending the storage signals anyway does nothing, but it is a common misconfiguration that makes audits harder to read. Datafly Signal leaves them out of server payloads and sends the two that count.

That does not make the storage signals irrelevant. They still describe the visitor’s choice, and that choice has to be enforced. It just has to be enforced before the event is sent, not described inside it.

Where consent should be decided

In a browser setup, consent depends on timing: the consent banner (CMP) must load, the Google tag must load, and the two must agree before the first hit fires. Hits sent in the moments before consent is initialised can go out with the wrong state, and if the CMP fails to load, the tag can be left in an undefined state.

Server-side, the decision can be made after the event arrives and before anything is delivered:

1. The collector records the visitor’s consent state from your CMP with every event. 2. The server evaluates it against the consent each destination needs. 3. Events without the required consent are not delivered to that destination at all. 4. For Google, ad_user_data and ad_personalization are set from the same decision.

Datafly Signal works this way. If consent categories are missing or malformed, the default rule denies, so a broken banner means nothing is sent rather than everything. Each delivery decision is logged with the event, the consent state at the time, the destination and the rule that applied, so you can show what happened to a specific event later.

Supported consent platforms

Datafly Signal reads consent from any TCF v2.2 framework and from the major non-TCF platforms, including OneTrust, Cookiebot, Didomi, Sourcepoint, Iubenda, Usercentrics, Termly and Klaro. Mapping a CMP’s categories to destinations is configuration, not code.

One decision for every destination

Consent Mode is Google’s mechanism, but the same visitor’s choice applies to Meta, TikTok, LinkedIn and everyone else. Enforcing it once on the server means a withdrawal applies everywhere at the same moment, instead of relying on each vendor’s tag to read the banner correctly.

Datafly Signal is a consent-enablement toolkit rather than a compliance guarantee: the policy you configure is the policy every destination sees. What it removes is the timing gap and the guesswork.

See how Consent Mode v2 works server-side in Datafly Signal, or read the consent documentation.