If you've gone looking for why Google flagged missing consent signals, or you've opened
GTM's Consent Overview and noticed ad_user_data or ad_personalization sitting red or
blank while everything else looks fine, you're dealing with one of the more common
half-finished Consent Mode setups: the site technically runs Consent Mode, but it's still
only sending the two original v1 signals. Consent Mode missing ad_user_data (and usually
ad_personalization right alongside it) almost never means Consent Mode is broken — it
usually means the upgrade from v1 to v2 never fully happened. Here's what these two
parameters actually control, and the places to check when they're missing or stuck denied.
Why Consent Mode is missing ad_user_data and ad_personalization
Consent Mode v1 had two consent types: ad_storage (can cookies be set for advertising)
and analytics_storage (can cookies be set for analytics). When Google introduced v2, it
added two more: ad_user_data (can user data be sent to Google at all for advertising
purposes) and ad_personalization (can that data additionally be used for personalized
ads and remarketing). A site can have ad_storage granted — cookies flowing normally —
while ad_user_data and ad_personalization are denied, missing, or simply never
mentioned anywhere in the consent commands. That's not a contradiction; it's four separate
consent decisions doing exactly what they're each configured to do. The question worth
answering is why the two newer ones are missing, not whether that's possible.
1. The default consent command predates v2 and was never updated
How to check: in DevTools console, before interacting with your cookie banner, run
dataLayer and find the consent entry with "default". Look specifically for
ad_user_data and ad_personalization as keys — not just ad_storage and
analytics_storage. If those two keys aren't present in the object at all (rather than
present and set to "denied"), the default command itself was written for Consent Mode v1
and never touched since.
The fix: update the gtag('consent', 'default', {...}) call — whether it lives
directly in your GTM container, in a custom HTML tag, or is generated by your CMP's
integration — to explicitly include ad_user_data and ad_personalization alongside the
original two. If you're using GTM's built-in Consent Settings feature rather than a raw
gtag call, open the tag's Consent Settings tab and confirm all four consent types are
listed, not just the two from before v2 existed.
2. The CMP's category mapping was never re-wired to the two new types
Most cookie banners (Cookiebot, OneTrust, Termly, and others) don't call gtag('consent', ...) directly — they map their own consent categories (typically "Marketing" or
"Advertising") to Google's consent types through a template or integration setting. Many
of these integrations shipped Consent Mode v1 support well before v2 existed, and adding
ad_user_data/ad_personalization support required either an update to the CMP's own
integration or a manual remap that nobody went back and did.
How to check: in your CMP's admin panel, find its Google Consent Mode (or "Google
integration") settings and check whether ad_user_data and ad_personalization appear as
mappable consent types at all. If your CMP's own settings screen doesn't list them, the
integration itself predates v2 and needs updating before any container-level fix will help.
The fix: update the CMP's Consent Mode integration to a version that supports v2 (all
major CMPs now do), then explicitly map your "Marketing"/"Advertising" category to
ad_user_data and ad_personalization, not just to ad_storage.
3. The default is correct, but the update call drops the two new signals on Accept
Some setups get the default right — all four consent types listed and denied — but the
gtag('consent', 'update', {...}) call that fires when someone clicks "Accept" only
updates ad_storage and analytics_storage, leaving ad_user_data and ad_personalization
permanently stuck on denied even for visitors who explicitly consented. This is a close
cousin of the update-event failure mode covered in why Google Consent Mode v2 isn't
working — same root pattern (an update call that
doesn't match the default), just missing different keys.
How to check: click Accept on your own banner, then run dataLayer again and find the
"update" consent entry. Confirm all four consent types are present and set to
"granted" — not just the two original ones.
The fix: extend whatever code fires the update call so it passes all four consent types the visitor actually agreed to, matching the same set of keys used in the default command. If the update call and the default command don't list the same four keys, one of them is incomplete.
4. "Missing" and "denied by design" look identical in the Network tab — check GTM directly instead
It's easy to mistake a signal that's correctly denied (because a visitor hasn't consented
yet, or explicitly declined) for one that's missing because it was never implemented.
Network tab requests don't clearly distinguish the two — both cases can produce a request
with a gcs parameter that simply encodes "denied." Checking dataLayer for whether the
keys exist at all, as in checks #1 and #3 above, is more reliable than reading network
requests for this specific question.
How to check: GTM's own Consent Overview panel (Admin → Container → Consent Overview, or the Consent Settings tab on an individual tag) is built exactly for this — it shows every consent type a given tag requires and whether the current test-page consent state satisfies each one, distinguishing "not satisfied because denied" from tags that don't check the newer types at all.
The fix: there's no separate fix here beyond #1-#3 — this check just tells you definitively whether you're looking at a real implementation gap or intentional denied-by-default behavior working correctly, before you spend time changing code that isn't actually broken.
5. If your traffic is EEA, UK, or Switzerland, this is also what triggers Google's warning email
Google made collecting and sharing ad_user_data and ad_personalization a requirement
for EEA traffic starting March 2024 (see Google's Customer Match consent
requirements, which state this
explicitly), with Switzerland added from July 31, 2024 (see Google's AdSense consent
requirements for
Switzerland) — and the UK is treated
the same way in practice. If any of checks #1-#3 above turned up missing signals and your
audience includes EEA, UK, or Swiss visitors, that's very likely also the cause behind a
Google Ads warning email about the EU user consent policy, not a separate problem.
What fixing this actually gets you
Fixing a missing ad_user_data/ad_personalization signal doesn't change how many
visitors consent — it changes whether Google can actually use the consent your visitors
already gave. A visitor who clicked Accept, but whose ad_user_data/ad_personalization
update never fired, is functionally the same to Google as a visitor who said no: excluded
from remarketing, undercounted in conversion measurement, the works. If a shrinking
remarketing audience is what brought you here in the first place, see is consent gating
shrinking your remarketing audience
for the broader diagnostic — a missing ad_personalization signal specifically is one of
the more fixable causes on that list, since it's a real bug rather than consent gating
doing its job correctly.
If you'd rather have this checked automatically
This is exactly the kind of gap a pre-consent scan is built to catch: which consent types
a site's default and update commands actually declare, whether all four match, and whether
that matches what's configured in GTM. Worth running once you've made the fix above, to
confirm the update call is actually reaching Google correctly and not just looking right in
your own dataLayer test.
— Petrus, Founder, ConsentCheck. More Consent Mode v2 setups I've audited than not still only send the two original v1 signals — it's a five-minute fix once you know it's happening, which is the annoying part.