The difference between ad_user_data and ad_personalization
They are two of Consent Mode v2's four signals and they gate different things. ad_user_data sets consent for sending user data to Google for advertising purposes. ad_personalization sets consent for personalised advertising, which is what a remarketing audience is for. Deny the first and nothing user level arrives; deny the second and it arrives but cannot target that person.
Two questions, asked at two different points
Consent Mode originally asked one advertising question, and it was about storage: may we keep an advertising identifier on this device. That is ad_storage, and it is still there doing the same job.
Version two added two more, and the thing worth noticing is that neither of them is about storage. They are about use. ad_user_data asks whether user data may be sent to Google for advertising purposes. ad_personalization asks whether it may be used for personalised advertising. Both of those wordings are Google's own, from its tag platform consent documentation. So a modern advertising setup is gated at three points rather than one, and the three are independent: a visitor can be represented by any combination of them.
That independence is why the distinction matters. Most banners hide it behind one advertising switch, which is a reasonable design, but it means the mapping underneath is doing work nobody sees. The plain version of the wider model is in Consent Mode v2 in plain English.
Which one stops your remarketing
The short answer is both, at different points in the chain. You will read that one parameter is the remarketing one, which is tidier than the truth.
ad_personalization is the signal that speaks to the use itself. It sets consent for personalised advertising, and personalised advertising is what an audience list is for, so a visitor who denies it is not someone you can act on that way.
ad_user_data sits upstream. It sets consent for sending user data to Google for advertising purposes, and if it is denied there is no user level data arriving for an audience to be assembled from. The list is not blocked so much as never fed. The same denial has a separate effect on your conversion counting, which we took apart in what happens to a Google Ads conversion when ad_user_data is denied.
Where this stops being academic is Customer Match. For data belonging to people in the EEA, Google requires both consent fields to be granted before the list can be used, and treats a missing value as not consented. Build around either signal alone and you can end up with an uploaded list you are not permitted to use, which is worse than an empty one, because it looks like it worked.
The combination nobody designs for
Set the two extremes aside. Both granted behaves as you expect, and both denied puts you in modelling territory, which is the case we covered when visitors reject cookies outright.
The interesting state is ad_user_data granted with ad_personalization denied. It is a completely coherent thing for a person to want: measure my visit, count me in your conversion numbers, do not follow me around. It is also the state we most often find unrepresented, because a banner with one advertising category cannot produce it and a banner with several often maps them all back to one signal anyway.
The reverse, personalisation granted while user data is denied, is a symptom rather than a design: permission to personalise using data that is not allowed to arrive. Find it live and you are usually looking at a mapping filled in field by field rather than reasoned through.
How to see which signals your site actually sends
You can settle this on one page load, and the first step catches most people out.
Do not try to read these two from gcs
The
gcsparameter carriesad_storageandanalytics_storageonly. Reading a healthy lookinggcsvalue and concluding the advertising signals are fine is a false pass that looks exactly like a real one, because that parameter was never going to mention them.Look at gcd instead, as a cross check
The
gcdparameter travels on hits to Google services and encodes all four consent types along with how each state was generated. Google treats it as an internal implementation that may change, so use it to confirm what you already believe rather than as the source of truth.Read the consent state in Tag Assistant or preview
This is the answer you act on. It lists all four consent types with their on page values, at each event, which is the only view that shows you a value and the moment it changed in the same place.
Test the mixed state on purpose
Accept measurement and decline personalisation, if your banner allows it, and watch whether the two signals actually diverge. If they always move together, your categories are mapped to one switch whatever the interface suggests.
Check the update, not just the default
Denied defaults are easy to get right and easy to stop there. What matters is the update that fires after the visitor chooses, and whether it carries all three advertising signals or only the one the setup was originally built with. The same discipline as checking the consent signal on the outgoing request.
What to do once you know
If your banner offers a single advertising category, map it to all three advertising signals, and make sure the update sends them together. That is a defensible design.
If your banner offers separate choices, then the mapping has to honour them, because an interface that shows granularity while the implementation collapses it is the worst of both: you have taken on the complexity and kept none of the benefit, and the visitor was shown a choice that did not exist.
Either way, check first whether the two Consent Mode v2 signals are being sent at all. An install that predates them can look healthy from its settings screen while sending only the original pair, which is a different problem from any visitor declining anything.
Velo sends all four signals from one category mapping you can read on a single screen, so the state a visitor chose is the state that leaves the page. How it is wired is on the product page.
Common questions
What people ask about this topic.
What is the difference between ad_user_data and ad_personalization?
They ask two different questions about the same visitor. ad_user_data asks whether user data may be sent to Google for advertising purposes at all. ad_personalization asks whether that data may then be used for personalised advertising. Denying the first means Google receives nothing user level to work with. Denying the second means the data arrives and may be used for measurement, but not to target that person. They are independent, so a visitor can grant one and deny the other, and a setup that treats them as a single advertising toggle cannot represent that.
Which one stops my remarketing lists?
Both do, at different points. ad_personalization is the signal that governs personalised advertising, which is the use a remarketing audience exists for. ad_user_data sits upstream of it: with that denied there is no user level data reaching Google to build an audience from in the first place. For Customer Match on data from the EEA, Google requires both consent fields to be granted, so treating either one as the single switch will leave you with a list you cannot use.
Can I read ad_user_data and ad_personalization from the gcs parameter?
No, and this is the most common way people conclude their setup is fine when it is not. The gcs parameter carries ad_storage and analytics_storage only. The two Consent Mode v2 signals travel in gcd, which is present on hits to Google services and encodes all four consent types along with how each state was generated. Google treats these as internal parameters that can change, so use them as a cross check and read the consent state in Tag Assistant or your tag manager's preview for the answer you act on.
What happens if my consent tool never sends the two new signals at all?
The advertising side of your setup behaves as though those consents were never obtained. That is a different situation from a visitor declining, and it is worth ruling out first, because an older install that predates Consent Mode v2 can look completely healthy while sending only the original pair. Check what is actually leaving the page rather than what the consent tool's settings screen claims.
Should my banner offer these as separate choices?
It does not have to, and most do not. The point is that your category mapping has to be able to express the states your visitors can reach. If one advertising category maps to all three advertising signals, a visitor either grants everything or nothing on that side, which is a defensible design. What is not defensible is a banner that shows separate choices and then maps them to a single signal, because the interface promises a granularity the implementation does not deliver.
Your banner, your consent,
your data — all in one place.
