Uploading a customer list to Google Ads under UK rules

On this page

1. What leaves your building is a hash, and that is a smaller comfort than it sounds
2. The ICO counts the upload as direct marketing, not as the thing before direct marketing
3. The ICO thinks you and the platform are probably joint controllers
4. The 1 April 2026 move changed the pipe, and nothing above it
5. Your lists get used by Smart Bidding whether you applied them or not
6. What a defensible record looks like at the row you're uploading

Short answer: Customer Match takes contact details your customers gave you, hashes them with SHA-256, and asks Google to find the signed-in accounts that match. The constraint has never been the upload mechanism. It's whether those people agreed to this particular thing, because under the ICO's own guidance the matching and the sharing are themselves direct marketing, not preparation for it. So you need a lawful basis for the upload, separate from whatever basis covers the email you send afterwards. The move to Data Manager on 1 April 2026 changed the pipe and left that question exactly where it was.

None of this is legal advice, and the UK position is genuinely in motion. The ICO's published direct marketing guidance is the current word, but parts of the PECR estate are being rewritten around the Data (Use and Access) Act. Get your own read before you commit a process to it.

What leaves your building is a hash, and that is a smaller comfort than it sounds

The mechanics are narrow and well documented. You upload a file of contact information — email addresses, phone numbers, mailing addresses, user IDs or mobile device IDs — and Google's help page states plainly that it doesn't receive actual email addresses: the contact information it holds for Google accounts is transformed into hashed codes using SHA-256, "a one-way hashing mechanism that is not unencrypted by Google" (Google Ads Help, checked 10 September 2026). Matching happens between hashes.

Google attaches four commitments to the file: limited use (only for creating your audiences and checking policy compliance, never to build or enhance profiles of your customers), limited access, limited sharing, and limited retention, with files uploaded via the Google Ads API deleted once matching and compliance checks are done.

Two operational limits sit underneath that. A list has a maximum membership duration of 540 days and needs at least 100 members added or updated inside that window to stay eligible. And since early March 2024, lists activated on Google Partner Inventory or third-party exchanges in the EEA, the UK and Switzerland are no longer available for web and app, so UK Customer Match runs on Google's own properties.

The hashing is real, and it still doesn't answer the legal question. A hash Google can reliably match to an identified account holder is doing the work of an identifier. That's the point of sending it.

The ICO counts the upload as direct marketing, not as the thing before direct marketing

This is the part that changes how the decision should be made, and it's the part most Customer Match discussions skip entirely.

PECR defines direct marketing as "the communication (by whatever means) of advertising or marketing material which is directed to particular individuals". The ICO's guidance then widens the frame: direct marketing purposes cover "all the activities you do with people's information that lead up to, directly enable or support sending your direct marketing messages". Its own list of examples includes "data cleansing, matching or screening for direct marketing" and "sharing data with third parties for them to use for their own direct marketing" (ICO, Identify direct marketing, checked 10 September 2026).

A Customer Match upload is a matching operation carried out for advertising, performed by giving a third party your customers' contact details. It lands inside that definition twice over.

The ICO is equally direct that targeted online advertising counts as "directed to particular individuals", giving advertising targeted on browsing history, purchase history or login information as its example — which describes signed-in account matching precisely. One dated detail for anyone working from older notes: the guidance records that on 20 August 2025 the Data (Use and Access) Act moved the DPA's definition of direct marketing into PECR.

So "we only need consent for the email" is the wrong shape of answer. The email needs its PECR basis. The upload needs a UK GDPR lawful basis of its own, and the ICO's position is that consent and legitimate interests are the two most likely to apply. If you lean on legitimate interests, the guidance names the test that decides it: whether people "would reasonably expect you to share their information with others for direct marketing".

The ICO thinks you and the platform are probably joint controllers

Google's Customer Match policy frames the relationship one way. It requires that your privacy policy "discloses that you share customer data with third parties to perform services on your behalf" — the language of a service provider acting for you.

The ICO describes the same arrangement differently. On platform audience tools, its guidance says: "Although the platform may undertake most of the actual processing, you are instigating it. This is because you provided the original information and defined the targeting parameters you want it to use. In many cases, it is likely that you and the platform are joint controllers, as you are both deciding what the information is being used for."

That passage sits under a heading about social media, and Google Ads is not social media. But the mechanism the ICO describes — hand the platform your customers' contact details, it checks its userbase, matches are added to an audience — is the Customer Match mechanism, feature for feature. Anyone treating the two as legally distinct because of the heading should be able to say why.

Joint controllers have to be transparent about the arrangement, and the ICO pairs that with an expectations test. It cites Which? research from September 2021 finding 79% of people surveyed were unaware that a platform matches profiles against uploaded customer lists. If four in five people don't know the mechanism exists, "they'd reasonably expect it" is a hard argument to run, and a privacy policy that says "third parties" without naming what happens isn't carrying the weight you need it to.

Whether consent obtained under commercial pressure — a paywall, a nag screen — counts as freely given is a separate and unsettled UK question, and it isn't solved by the upload path either.

The 1 April 2026 move changed the pipe, and nothing above it

The migration is real and dated. The Google Ads Developer Blog announced on 4 March 2026 that "starting on April 1, 2026, the Google Ads API will no longer accept new adopters of Customer Match", and every Customer Match help page now opens by recommending Data Manager or the Data Manager API and telling you to avoid the Google Ads API for new integrations.

What the new path adds is genuine. Google's comparison lists confidential matching and encryption as supported in the Data Manager API and not supported in the Google Ads API, drops the developer token requirement, and replaces the offline-job workflow with plain ingestion requests. If you're building this now, build it there.

What it doesn't touch is a single sentence of the Customer Match policy. First-party context only. Privacy policy disclosure. "Obtain consent for such sharing where required by law or any applicable Google policies governing personalized ads and/or user consent." Nothing from anyone under 13. No overly narrow targeting. Sensitive categories out. Identical on both sides of the migration, and Google reserves the right to review compliance at any time and to suspend accounts for serious or repeated violations.

The one thing the migration did change about consent is where the fields live, and Data Manager's consent fields are documented as optional — an upload with no consent state attached is accepted and returns success. Acceptance is a fact about the schema, not a finding about your permission.

Your lists get used by Smart Bidding whether you applied them or not

Here is the operational detail that catches people, and it's in Google's own documentation rather than anywhere obscure. Campaigns using Smart Bidding and optimised targeting "automatically include all the Customer Match lists in your account" to improve performance. You opt out by changing a setting or removing the list; manual bidding strategies are the exception, and Google says the lists aren't used there.

So the compliance boundary isn't the campaign you deliberately pointed at a list. It's every list sitting in the account. A test upload from two years ago, still inside its 540-day window, is in scope for a campaign nobody associated with it. That's worth an inventory before it's worth a policy: list by list, where did these people come from, what were they told, and is there a record you could show someone.

What a defensible record looks like at the row you're uploading

Google's manual upload flow asks you to tick a box confirming that "this data was collected and is being shared with Google in compliance with Google's Customer Match policies", and notes that you must upload only consented data. That tickbox is an assertion by you. It isn't evidence, and it doesn't become evidence because the upload succeeded.

The EU user consent policy applies to end users in the European Economic Area, the UK and Switzerland, so UK traffic is squarely inside it, and it turns the record into a contract term: obtain legally valid consent, "retain records of consent given by end users", give clear instructions for revoking it. Failure has a stated consequence — Google may limit or suspend your use of the product.

For the API paths, both consent fields have to be set to granted for a list to be usable for personalisation in the EEA, and Google's help page is explicit that where they're missing "the consent value is determined as not consented". Note the territorial wording carefully: that help page is scoped to the EEA, while the underlying user consent policy names the UK. Read the policy, not the article summarising it.

What that means for a record you could actually defend:

1. It's per person, not per campaign. A banner-level consent rate tells you nothing about the row you're about to send.
2. It survives the journey to the upload. Consent captured at the point of collection and lost before the CRM is the same as no consent, because you can't produce it against the identifier you shared.
3. It records the sharing, specifically. "Agreed to marketing emails" is not a record of agreeing that their email address would be given to Google for matching.
4. It carries a timestamp and a version. What were they shown, and when. Proof of consent has five parts, and most banner logs give you three.
5. Revocation reaches the list. Suppression that stops your emails but leaves someone in a 540-day audience is a half-built process.

If your uploads are running and nobody can answer point two, stop uploading before you fix anything else. That's the one where the exposure compounds every time the sync runs.

Getting the consent state to travel from the banner to the row — and to Google in a form that reflects what the person actually chose — is the work we do. The uncomfortable version of the advice is that most accounts we look at are asserting a permission nothing in their stack ever recorded.

Sources

1. 1.Google Ads Help — About Customer Match (540-day membership, auto-inclusion in Smart Bidding, EEA/UK partner inventory) · Checked 2026-09-10
2. 2.Google Ads Help — How Google uses Customer Match data (SHA256, limited use, retention) · Checked 2026-09-10
3. 3.Google — Customer Match policy (first-party context, consent, sensitive categories) · Checked 2026-09-10
4. 4.Google Ads Help — How to provide consent for Customer Match · Checked 2026-09-10
5. 5.Google — EU user consent policy (EEA, UK and Switzerland; retain records of consent) · Checked 2026-09-10
6. 6.Google Ads Developer Blog — Changes to Customer Match Support in the Google Ads API (4 March 2026) · Checked 2026-09-10
7. 7.Google — Data Manager API, Upgrade Customer Match from the Google Ads API (confidential matching, encryption) · Checked 2026-09-10
8. 8.ICO — Direct marketing guidance: Identify direct marketing (PECR definition; matching and screening as a direct marketing purpose) · Checked 2026-09-10
9. 9.ICO — Direct marketing guidance: Plan your direct marketing (platform audiences, joint controllers, lawful basis) · Checked 2026-09-10
10. 10.Which? — Are you still following me? Consumer attitudes to data collection methods for targeted advertising (September 2021) · Checked 2026-09-10
11. 11.ICO — Plans for new and updated guidance: direct marketing and PECR · Checked 2026-09-10