Somewhere in your company there is a privacy review that approved sending customer lists to Google. I would bet it contains a sentence like this one: only hashed identifiers leave our systems. On November 16, that sentence stops describing how Google Ads Data Manager is built.
Google has been emailing advertisers who use Data Manager for Customer Match and enhanced conversions. The email says that “starting on November 16, 2026, we will no longer require hashed customer data (SHA-256) for Google Ads Data Manager and will instead support encrypted customer data by default.” It names every route in: CRM connections, cloud storage imports, direct file uploads and the Data Manager API. And it describes what happens next in one plain line: “Google Ads decrypts, normalizes, and matches this data with Google account data inside a hardware-isolated trusted execution environment.”
Read that sequence slowly. Decrypt, then normalize, then match. You cannot lowercase an email address you cannot read. So for a moment, inside a sealed machine that Google operates, your customers’ actual email addresses, phone numbers and postal addresses exist in the clear. That is not a scandal. It may even be the better design. But it is a different design from the one most marketing teams told their lawyers about, and it arrives in about three weeks.
How the notice surfaced
The email is undated. It became public on October 18, when Anthony Higman, founder and CEO of the agency ADSQUIRE, posted a copy on LinkedIn. PPC Land reported it the same day and quoted the full visible text. Search Engine Watch followed on October 24, and the change tracker AdShift logged the same notice. As of this weekend, Google’s own help pages have not caught up. Its guide to confidential matching with encryption still tells you to format each field, hash it with SHA-256, encode it, and only then encrypt it.
So the operator facts are these. There is a date. There is a stated reason: Google says the change “improves match accuracy” and “minimizes errors caused by formatting discrepancies prior to hashing.” There is no number attached to that claim. And there are no replacement instructions yet, which means nobody should rip hashing out of a working pipeline this weekend.
Why hashing was always a bit of theater
Hashing turns an email address into a fixed 64 character string. The same input always gives the same output, which is the whole point: Google hashes its own account data the same way and compares strings. It is also why the system was fragile. A trailing space, a capital letter or a phone number missing its country code produces a completely different hash that matches nothing. Google’s API rules have advertisers lowercase everything, strip dots and plus suffixes from Gmail addresses, and format phone numbers to a strict standard before hashing. Every one of those steps was yours, or your CRM vendor’s, or your agency’s. When one failed, rows quietly fell out of your audience and you had no way to tell a formatting miss from a customer without a Google account.
Meanwhile the privacy benefit was thinner than the paperwork implied. In July 2024 the Federal Trade Commission’s technology staff published a post with the blunt title “No, hashing still doesn’t make your data anonymous”. The argument is simple. Email addresses and phone numbers come from small, guessable sets, so a hash of one can be reversed by guess and check, and even a hash nobody reverses still works as a unique identifier that can follow a person over time. The agency’s line for companies is direct: they “should not act or claim as if hashing personal information renders it anonymized.”
What hashing really bought marketers was a story. Plain-text addresses never left the building. You could say that to your customers, your legal team and your clients, and it was true even if the protection behind it was modest. From November 16 the story changes to: plain-text addresses leave the building inside an encrypted envelope, and Google opens the envelope inside a room it says nobody can see into.
The sealed room is real, and it is old news
None of the trusted execution environment part is new. Google launched what it calls confidential matching on September 12, 2024. Google’s Kamal Janardhan wrote that the system isolates business data during processing so that nobody, Google included, can access it, and that it became the default for Customer Match and Data Manager with no action required and no added cost. It runs on Google Cloud’s Confidential Space, which Google’s help center notes has had an independent security review by NCC Group.
There is one detail in that help page worth underlining. Attestation, the cryptographic proof that only the matching code touched your data, is tied to the optional route where you encrypt the data yourself with keys you control in Google Cloud’s key management service. The page says that advertisers who choose to encrypt get attestation that only confidential matching logic was used. The email does not say whether encryption by default means that same customer-held key setup for every route, or something lighter for a marketer dragging a CSV into the Google Ads interface. Search Engine Watch and PPC Land both flag the same open questions: whether existing hashed uploads keep working after the date, whether there is an opt-out, and what happens to records that do not match.
So the honest summary is narrower than the headline. The room was already there. What changes is what walks into it. Until now it received strings the advertiser had already scrambled. From November 16 it receives readable records, sealed in transit, opened inside.
This is the last step of a long pull inward
Taken alone, this would be a plumbing update. In context it is the end of a year in which Google moved almost every first-party data route into one pipe it controls. According to PPC Land’s record, Customer Match uploads through the Google Ads API stopped working on April 1, 2026. New offline conversion imports through that API were blocked on June 15. In September, Customer Match file uploads started accepting raw IP addresses, unhashed, outside Europe, the UK and Switzerland. And Search Engine Watch points out that Data Manager’s Smart hash feature already normalizes and hashes fields automatically for some connections.
Each move had a reasonable justification. Together they shift a piece of work, and the control that came with it, from the advertiser’s side of the wall to Google’s. Formatting and hashing used to be a job your data team or integration partner did before anything left your systems. That job is where you decided exactly what went out. After November 16 it happens inside Google’s environment, against Google’s normalization rules, with Google’s account of how well it worked.
That is not sinister. It is how every platform behaves once it decides the advertiser is the weakest link in the match. But marketers should notice which way the control is flowing, because the same logic shows up everywhere right now: the platform rewrites the ad, the platform picks the image, the platform cleans the list. Each step is pitched as removing your errors. Each step also removes your checkpoint.
The upside is real, and it lands in your bidding
Here is the part growth teams will like. If Google is right that formatting errors cost matches, then fixing them should mean bigger Customer Match audiences and more conversions credited through enhanced conversions. Those credited conversions feed Smart Bidding. Smaller advertisers who upload spreadsheets by hand have probably been leaking rows for years without knowing it.
That also means your numbers may move on November 16 for reasons that have nothing to do with your campaigns. Match rates could jump. Reported conversions could tick up. A bidding strategy fed more conversions will bid differently. If you have no baseline, you will not be able to tell a real lift from a measurement change, and someone in a quarterly review will take credit for the plumbing.
The governance bill comes due first
The cost side is paperwork, and it arrives before the upside. Data protection impact assessments, vendor reviews and client contracts were often written on the premise that only hashed values left the advertiser. Agencies that run uploads on behalf of clients made that promise too. Your privacy notice may describe the hashing. Some of those documents will be fine with a sealed environment, attestation and Google’s existing data processing terms. Some will need a rewrite. None of them will update themselves, and the email puts no condition on the date. November 16 is when the new processing starts, whether your paperwork has caught up or not.
There is also a negotiating point hiding here. Advertisers with strict data policies have had a real option since 2024: encrypt with your own keys and get attestation. If default encryption turns out to be something less than that for the routes most marketers actually use, the strict-policy teams should know before the date, not after.
What to do this week
Find who prepares your identifiers. Search Engine Watch recommends asking exactly this before November. For every Customer Match list and enhanced conversions feed, write down whether formatting and hashing happen in the CRM export, the connector, an agency script or Google’s import. That is the component that changes.
Do not remove hashing yet. Google’s current documentation still requires it, and the email gives no new request format. Keep existing pipelines running until Google publishes instructions.
Snapshot your match rates now. Export upload diagnostics and match rates for every list, plus four weeks of enhanced conversions volume. Date it. Without that, the “improves match accuracy” claim cannot be checked and any jump in conversions after the 16th cannot be explained.
Send your privacy lead one paragraph. Quote the email’s “decrypts, normalizes, and matches” line and ask whether any assessment, client contract or privacy notice says only hashed data leaves your systems. Agencies should do this per client.
Ask your Google rep four questions in writing. Will existing hashed uploads still be accepted after November 16? Is there a way to keep sending hashed data only? Who holds the encryption keys for direct file uploads and CRM connections? Will attestation be available on the default route, or only with customer-managed keys?
Flag the date to whoever owns bidding. If match rates jump, expect Smart Bidding to react. Annotate the week in your reporting so nobody mistakes a pipeline change for a creative win.
The shift itself might be a net improvement. Hashing was weak protection dressed as strong protection, and a verified sealed room could genuinely beat it. But “might be better” is not the same as “approved.” Your customers’ email addresses are about to be readable inside someone else’s hardware, and the people who signed off on the old arrangement deserve to hear that from you before November 16, not from a match rate chart afterward.
