Data Manager's consent fields are optional. That's the problem.

On this page

1. The schema says optional, and it means it literally
2. Unspecified is not denied, which is precisely what makes it dangerous
3. The obligation sits upstream of the API call, and it is Google's own policy
4. When an agency or a partner does the upload, the advertiser is still in the room
5. Five things to settle before your next upload

Short answer: the Data Manager API documents adUserData and adPersonalization as Optional, and CONSENT_STATUS_UNSPECIFIED is a real value in the enum, so an upload carrying no consent state at all is accepted and comes back successful. Treat that success as a fact about the schema and nothing else. Google's own EU user consent policy still requires you to have obtained consent before sharing data about users in the EEA, the UK or Switzerland, and Google's Customer Match help page says that where the consent fields are missing, "the consent value is determined as not consented". So the omission buys you nothing: the data is excluded from personalisation for EEA users anyway, and you are left holding the sharing event with no record of permission behind it.

None of this is legal advice. The area is genuinely unsettled in the UK: the ICO's direct marketing guidance is under review because of the Data (Use and Access) Act, and as of 7 September 2026 the regulator's own plans page — itself last dated 26 June 2026 — still lists those updates as in drafting with publication due "Summer 2026". Anything below is the position as Google and the ICO have published it, not a substitute for your own legal read.

The schema says optional, and it means it literally

The Consent object has exactly two fields. Google's reference marks both with the same one-word annotation:

• adUserData — "Optional. Represents if the user consents to ad user data."
• adPersonalization — "Optional. Represents if the user consents to ad personalization."

Each takes a ConsentStatus, which has three values: CONSENT_STATUS_UNSPECIFIED ("Not specified"), CONSENT_GRANTED and CONSENT_DENIED. The whole object is framed in the docs as Digital Markets Act consent settings, with a link out to the DMA itself.

Google's own how-to guide reinforces the reading. Where it explains building a request body, it tells you to combine your destinations and events, set the encoding, "and add any other request fields you want to include such as validateOnly and consent". Consent is listed beside a debugging flag, as something you might want.

The contrast that makes this sharp is that the same API is perfectly willing to refuse an upload on European regulatory grounds when Google decides it matters. Since 26 March 2026 the release notes carry EU_POLITICAL_ADVERTISING_DECLARATION_REQUIRED: from 1 April 2026, accounts that have not self-declared whether their ads are political under the EU Political Ads Regulation can have ingestAudienceMembers and the user list calls fail outright. Google built a hard stop for a declaration made once in the interface. It did not build one for the consent state of the individual people in the file.

Unspecified is not denied, which is precisely what makes it dangerous

The three enum values are genuinely distinct, and the difference is not academic.

CONSENT_DENIED is a record. It says you asked a person, they refused, and you carried their refusal through your systems intact all the way to the upload. CONSENT_STATUS_UNSPECIFIED is the absence of a record. It says nothing about the person and everything about your pipeline.

For processing, Google collapses the two. Its Customer Match consent page is explicit: "If these consents are missing, the consent value is determined as not consented. Data from unconsented EEA users will not be processed and cannot be used for ad personalisation using Customer Match." Since March 2024, for a Customer Match list to be usable in the EEA, both fields must be set to granted.

So the practical outcome of leaving the fields off is the worst available combination. You have performed the act that carries the obligation — sending personal data about identifiable people to Google — and you have received none of the benefit, because that data sits in the list unusable for personalisation. Teams read "Optional" as "safe default" and end up with uploads that are simultaneously exposed and inert.

Outside the EEA, the UK and Switzerland the picture differs, and it is worth being accurate about it rather than pretending the rule is global. There, an unspecified state usually reflects a genuine absence of a requirement rather than a failure to collect. That is a reason to set the fields deliberately per region, not a reason to leave them unset everywhere.

The obligation sits upstream of the API call, and it is Google's own policy

Long before any legal argument about UK GDPR, there is a contract. Google's EU user consent policy applies to anyone whose agreement with Google incorporates it, and it is short and direct: you "must ensure that certain disclosures are given to, and consents obtained from, end users in the European Economic Area, the UK and Switzerland". Failure has a stated consequence — Google "may limit or suspend your use of the Google product and/or terminate your agreement".

Two of its requirements get overlooked, and both matter more once uploads are involved:

• You must retain records of consent given by end users. Not merely obtain consent — keep the evidence. That is a records problem before it is an API problem, and it is the same discipline as proving consent to a regulator.
• You must provide clear instructions for revocation. A consent you cannot honour a withdrawal against is a consent with a shelf life you have not thought about.

The Customer Match policy adds the sourcing rule on top: you may only upload information collected in a first-party context, your privacy policy must disclose that you share customer data with third parties, and you must obtain consent for that sharing where required by law or by Google's own policies.

The consent state you put in the upload is therefore a report on something that already happened on your website. If the banner never asked properly, no value in the field is honest. That chain — banner, consent state, transmission — is the same one that decides whether Basic or Advanced Consent Mode is doing anything for you, and it breaks in the same place.

When an agency or a partner does the upload, the advertiser is still in the room

The liability question comes up whenever the hands on the keyboard belong to someone other than the advertiser, and Google's policies answer it more clearly than most people expect.

The EU user consent policy scopes itself to properties "under your control, or that of your affiliate or your client". An agency does not step outside the policy by acting for someone else; the client's website is explicitly inside it. Where data comes from a genuine third-party property that nobody in the chain controls, the duty softens to "commercially reasonable efforts" to ensure that property's operator complies — softer, but not absent.

The Customer Match policy then makes the enforcement route concrete: "We may review your business for compliance with the Customer Match policy at any time... If you're a manager account, we may also contact your managed accounts to verify compliance." Compliance questions travel down the account tree. The sanction at the end of it is losing Customer Match access or account suspension.

The Data Manager API does model the partner relationship properly, which is useful and easy to misread. Data partner accounts are issued only after an approval process, and are connected to advertisers through partner links. There is a thirdPartyUserData field for identifiers that came from a third-party source, and it can only be set when the login account's type is DATA_PARTNER. That field records provenance. It does not transfer responsibility, and nothing in the schema pretends otherwise. The advertiser whose account receives the audience is still the party Google contacts.

Which makes this a contract question as much as a technical one. If a partner uploads on your behalf, the useful clauses say where the consent state comes from, who keeps the underlying records, how a withdrawal reaches them, and what happens on a compliance review. Get that written down while everyone is relaxed.

Five things to settle before your next upload

1. Set both fields explicitly, every time. Make omission impossible in your client code rather than merely discouraged.
2. Derive the value from a stored consent record, keyed to the same person as the identifier you are uploading. If you cannot join those two things, that is the project.
3. Keep the evidence behind every granted value, and keep it for as long as you are still relying on it.
4. Handle withdrawal as a delete, not just as a flag. The audience already sent needs removing, which is what the removal methods are for.
5. Log what you sent, per upload. When someone asks in fourteen months, the answer should come from your records rather than a reconstruction.

The migration that brings most teams to this API is covered separately in the five upload pipelines Data Manager replaced — the timetable, the closed allowlist windows and the developer-token trap. This post is the part of that move nobody schedules: the consent plumbing does not migrate itself, and the API will not tell you it is missing.

If the honest answer right now is that you could not produce a consent record for a given row in your customer list, fixing that is our Consent Mode v2 work.

Sources

1. 1.Google — Data Manager API, Consent reference (adUserData, adPersonalization, ConsentStatus) · Checked 2026-09-07
2. 2.Google — Data Manager API, Send events guide · Checked 2026-09-07
3. 3.Google — Data Manager API release notes (EU_POLITICAL_ADVERTISING_DECLARATION_REQUIRED, 26 March 2026) · Checked 2026-09-07
4. 4.Google — EU user consent policy · Checked 2026-09-07
5. 5.Google Ads Help — How to provide consent for Customer Match · Checked 2026-09-07
6. 6.Google — Customer Match policy · Checked 2026-09-07
7. 7.ICO — Plans for new and updated guidance: direct marketing and PECR · Checked 2026-09-07