Customer Match uploads moved and the old road closed

From 1 April 2026, first-party data uploads to Google run through the Data Manager API. Anything still calling the old Google Ads API path for Customer Match stopped working, and the failure looks like nothing at all: your nightly sync reports an error into a log nobody reads, your audience lists quietly stop refreshing, and your remarketing performance decays over weeks.

This is the classic silent break. Nobody gets an email. The lists still exist in the interface with their old member counts and a last-updated date that slowly ages.

Check whether it hit you

Three checks, in order.

Open Google Ads, go to your audience manager, and look at the last updated date on every Customer Match list. Anything that has not refreshed since late March is your answer.

Then find whatever runs the upload. It might be a script your developer wrote, a scheduled job in your data warehouse, a connector in your customer data platform, or a feature inside your CRM. Ask the owner which API version it calls. If the answer is a Google Ads API version and the offline user data job service, it is on the dead path.

Then check whether anyone is monitoring the job at all. In most mid-market setups this was built once by a contractor and never instrumented. If a failed upload does not raise an alert somebody sees, the migration is only half your problem.

What the new path requires

The Data Manager API consolidates first-party ingestion for Google, which is a genuine improvement over having audience uploads, conversion uploads and enhanced conversions each speak different dialects. It also enforces a few things the old path let slide.

Hashing is strict. SHA-256, hex encoded. Before hashing: strip leading and trailing whitespace, lowercase everything, remove all periods from the local part of Gmail addresses where applicable, and put phone numbers into E.164 format with the country code. For Australian mobiles that means the country code with the leading zero dropped. Get this wrong and the upload succeeds with a match rate near zero, which is worse than failing, because it looks like it worked.

Consent fields are required, not optional. Each record carries ad user data and ad personalisation consent status. Sending granted for records where you cannot evidence consent is not a technical decision, it is a legal one, and it should be signed off by someone whose name is on the privacy policy.

Match rates will tell you the truth about your data. A clean CRM with email plus phone plus name plus postcode on most records lands in a healthy band. A list of email addresses alone, half of them role accounts, will not. Upload multiple identifiers per record where you have them, because Google matches on any of them and each one you add lifts the rate.

Lists need enough matched active members before they can serve. Below that threshold the list sits in the audience manager looking populated and reaching nobody. The audience manager shows serving eligibility per network, so check there rather than assuming a large upload means a usable audience.

The work worth doing while you are in there

A forced migration is the cheapest possible excuse to fix the segmentation you have been meaning to fix.

Most accounts upload one list called something like All Customers, which is the least useful audience you can build. While you are rewriting the job, split it:

Customers who bought in the last 90 days, for exclusion from acquisition campaigns so you stop paying to reach people who already own the thing.

High-value customers by lifetime revenue, for lookalike expansion where the seed quality decides everything downstream.

Lapsed customers past your typical repurchase interval, for genuine win-back rather than generic remarketing.

Open opportunities in the CRM, for bidding support during an active sales cycle, which is where a considered purchase is actually won.

That last one is the one almost nobody builds and it is the highest leverage of the four in B2B, because it puts media weight behind deals that already have a human working them.

Set it up so it cannot fail silently again

Whatever rebuilds the upload, three requirements go in the specification.

The job writes a record of every run: timestamp, records sent, records accepted, match rate. Somewhere a person can see it without asking a developer.

A failed run, or a match rate that drops more than ten points from the trailing average, raises an alert to a human. Email or a chat channel, it does not matter which, as long as somebody owns it.

Someone diarises a quarterly check on Google's developer changelog for this API. Deprecations get announced months ahead. The reason this one hurt is not that Google hid it. It is that nobody on the client side was reading.

Deprecations do not break things loudly. They break things on a Tuesday, into a log file, and you find out from a performance report six weeks later.