Google Ads Stops Requiring Hashed Data Nov 16, Exposing Years of Bad Uploads

Google will stop requiring SHA-256 hashed customer data in Google Ads Data Manager on November 16, 2026, and will accept encrypted data by default instead, according to a Google email reported by PPC Land. Google will normalize and match identifiers itself inside a trusted execution environment, so formatting mistakes you never knew you had should stop costing you matches. Snapshot your Customer Match rates before the switch.

The change covers Customer Match and enhanced conversions across CRM connections, cloud storage imports, direct file uploads and the Data Manager API. Google's stated reasons are "better performance," better match accuracy and fewer errors from formatting differences before hashing. No percentage, no test, no benchmark. Just the promise.

I think that last part is the actual story, and it's a slightly embarrassing one for a lot of ad accounts.

Your hashing was probably leaking matches the whole time

Hashing is unforgiving in a way most marketers never really think about. Before you hash an email or phone number, Google wants it trimmed, lowercased, phone numbers in E.164 format, and periods stripped from the local part of Gmail addresses. As PPC Land's match rate explainer puts it, one stray capital letter produces a different hash and the record simply fails. No error. No warning. Just a smaller audience.

Google's own Customer Match troubleshooting guide lists formatting errors before hashing as one of the main causes of low match rates, right next to data that wasn't hashed at all. And the match rate you see in the interface doesn't help much with diagnosis. It's bucketed, it only appears once at least 100 rows match, and Google says it tells you whether you uploaded the right data the right way, not how the list will perform.

So picture a CRM export where phone numbers are stored as "(415) 555-0123" and nobody ever converted them to +14155550123 before hashing. Every one of those phone rows was dead on arrival. If your list leaned on phone numbers (common for lead gen, call-heavy local businesses, anything B2C with SMS), you may have been running Customer Match on half a list for years without knowing.

Anyway, after November 16, Google does the normalization. The CRM connector that was quietly sending "John.Smith@Gmail.com " with a trailing space stops being your problem.

The fix for a bug you couldn't see is arriving on a date you can measure. Measure it.

Snapshot every list this week, or you'll never know if it worked

This is the part I'd actually spend 20 minutes on before the month ends. Google will almost certainly say the change improved match rates in aggregate. That number won't tell you anything about your account.

Here's roughly what I'd do:

• Record the match rate bucket and list size for every Customer Match list as of early November. List size and match rate are different measures (match rate counts any Google Account, list size counts only active, reachable users), so record both.
• Note the identifier mix per list. Email-only, email plus phone, email plus address. The lists with the most phone and address data are the ones most likely to have been broken by formatting, so they're the ones to watch.
• Check your enhanced conversions diagnostics in the same window, since the same normalization problem affects how many conversions Google can tie back to clicks.
• Re-check 2 to 3 weeks after November 16, once refreshed uploads have processed. Match results can take up to 48 hours, so don't judge on day one.

A rough benchmark: if a list's match rate bucket moves up a full tier, your old hashing pipeline was broken, and you should probably ask whoever built it what else it touches. If nothing moves on a list that's mostly clean, lowercase email addresses, that's fine too. It means your pipeline was doing its job.

My guess (and it is a guess) is that most email-only lists move by less than 5 points, and phone-heavy lists are where the double-digit jumps show up. Which would also say something about how much of the "Customer Match doesn't work for us" sentiment out there was really a formatting problem all along.

The legal premise underneath your Customer Match setup just shifted

On paper, encrypted-by-default sounds like a privacy upgrade. And in some ways it is. But a lot of data protection assessments for Customer Match were written on the assumption that only hashed values ever left the advertiser. That assumption is about to stop being true.

Here's the mechanism, as best I can read it from the email. Data arrives encrypted, then gets decrypted, normalized and matched inside Google's trusted execution environment. Google's confidential matching page describes that environment as a hardware root-of-trust setup with cryptographic attestation, and says it follows the same data processing terms as Customer Match. When Google made it the default in 2024, AdExchanger reported the pitch was that nobody, not even Google, can access the data being processed.

That may well be true. But "readable identifiers exist inside a box Google says it can't see into" is a different sentence for your legal team than "we only ever sent hashes." And to be fair, hashing was never the privacy shield people treated it as. The FTC said so plainly back in 2024 in a post titled "No, hashing still doesn't make your data anonymous": the same input always produces the same hash, which is exactly what makes matching work and exactly why the data stays linkable.

So in a weird way, Google is removing a fig leaf that regulators had already called a fig leaf. I'm not sure that makes the conversation with your DPO any easier, though. Possibly harder.

The email also leaves real gaps. PPC Land points out it doesn't say whether existing scheduled SHA-256 uploads keep working unchanged, who manages keys for direct uploads and CRM connections, whether you can choose to keep sending hashes only, or what happens to unmatched records and for how long. If your privacy review needs answers to any of those, send the questions to your Google rep now, not on November 15.

Google keeps taking over the plumbing, one Data Manager update at a time

None of this is happening in isolation. Google has spent the past year funneling every first-party data path into Data Manager. We covered how the Data Manager API consolidated three pipelines into one dependency, and then how v1.6 folded in store sales. Customer Match uploads through the Google Ads API stopped working in April. In September, Customer Match started accepting raw IP addresses and timestamps, unhashed, with EEA, UK and Swiss users excluded.

The pattern is pretty clear. Every quarter, Google takes on a bit more of the processing and asks advertisers to do a bit less. That's genuinely convenient. It also means the quality of your audience and conversion data depends more and more on a black box you can audit less and less. Which, honestly, is the same trade Google has been offering on bidding for years, just moved one layer down the stack.

One small, slightly off-topic note: if your team built a custom hashing script for Customer Match, someone is probably going to want to delete it after November 16. I'd keep it around for a few months. If the rollout gets bumpy, or your legal team decides you're sticking with hashes, you'll want it back.

Where I'd land before November 16

Three things, in order. Snapshot match rates and list sizes per list this week. Send your privacy team a two-line summary of the change (encrypted upload, decrypted inside a TEE, Google normalizes) and ask whether your current assessment still holds. Then, after the switch, compare.

I suspect plenty of accounts will find their Customer Match lists were smaller than they needed to be for a long time, for the dumbest possible reason. That's annoying to learn. It's still better than never learning it.