For years the rule was simple: before a customer email goes to Google Ads, you run it through SHA-256. On November 16, 2026, Google Ads Data Manager hashing stops being mandatory: Data Manager will accept encrypted customer data by default, decrypt it itself and match it against Google accounts. The stated payoff is a better match rate. The question nobody asks in the announcement: what do your pipelines, your records of processing and your DPO have to say about it? Here is what actually changes, what Google hasn’t said yet, and how to decide flow by flow without breaking anything less than two weeks before Black Friday.
The usual disclaimer: I describe the mechanics and what Google announced. Whether you send readable identifiers, and on what legal basis, is a call to make with your DPO.
What changes on November 16, 2026 (and what Google doesn’t say)
What Google’s email says
The news comes from an email Google sent to Data Manager users, shared on LinkedIn by Anthony Higman (ADSQUIRE) and covered by PPC Land on October 18, 2026. Google writes that it will no longer require SHA-256 hashed customer data, that it will support encrypted customer data by default, and that it “decrypts, normalizes, and matches” that data with Google account data. The rationale: better match accuracy through privacy-enhancing technology.
First caveat: as I write this on November 9, no official help page mentions the November 16 date. Everything about the deadline rests on the email as reported by the trade press (PPC Land, SHM Studio), not on Google’s documentation yet.
Which flows are affected
According to the coverage of the email, the change covers both Google Ads uses of customer data, through all four Data Manager entry points:
| Use | What goes to Google | Affected routes |
|---|---|---|
| Customer Match | customer lists (email, phone, name, address) | CRM connection, cloud storage, file upload, Data Manager API |
| Enhanced conversions and offline conversions | identifiers attached to a conversion | CRM connection, cloud storage, file upload, Data Manager API |
If you use neither Customer Match nor conversion imports through Data Manager, you are not directly affected. If you’re not sure, now is the time to take stock: my Google Ads Data Manager guide lists the sources it can connect.
The open questions
The email leaves several questions unanswered, and they matter:
- Existing hashed uploads. “No longer require” is not “reject”. Nothing suggests your hashed files will bounce, but Google doesn’t confirm they will be processed exactly as before, or at what match rate.
- An opt-out. The email describes no setting to keep sending hashes only.
- Other products. Display & Video 360, Google Analytics and call conversions aren’t mentioned.
- How long decrypted data lives. SHM Studio says unmatched records are deleted, but the email says nothing about logging or retention.
Google Ads Data Manager hashing, encryption, confidential matching: the differences
What hashing actually protected
SHA-256 turns jane.doe@example.com into a 64-character fingerprint, always the same for the same address. Google hashes its own data the same way and compares fingerprints. It’s a one-way lock: you can’t get from the fingerprint back to the email.
Except anyone can build the same fingerprint from a list of known emails. That’s why the FTC pointed out back in 2024 that hashing doesn’t make data anonymous. Under the GDPR, a hashed email is still pseudonymized personal data. The real protection hashing gave you was more modest and more concrete: the readable address never left your system.
Hashing’s other flaw is operational. A forgotten capital letter, a trailing space, a dot in a Gmail address, and the fingerprint matches nothing. A good share of disappointing Customer Match SHA-256 match rates comes from exactly that, and it’s what Google wants to recover by normalizing the data itself.
The TEE and attestation, in plain English
Decryption happens inside a trusted execution environment (TEE): confidential matching. Google’s help page says it is on by default, free, and built on Google Cloud Confidential Space. Picture a locked clean room: data goes in encrypted, gets read and matched, and only the result comes out. Attestation is the signed certificate proving which software runs inside the room. If you encrypt your data, you can require that attestation before your key is used to decrypt it.
One detail matters here. The current encrypted upload procedure still asks you to format, SHA-256 hash, Base64 encode, then envelope encrypt with a key you hold in Cloud KMS. So encryption already existed, layered on top of hashing. What the email announces is the option to skip the hashing step. And the documentation currently only names file-type sources (Cloud Storage, SFTP, HTTPS) for encrypted uploads: check the supported data sources table before assuming your connector follows.
| Hashing only | Hashing then encryption | Encryption without hashing (Nov 16) | |
|---|---|---|---|
| What leaves your system | fingerprints | encrypted fingerprints | readable identifiers, encrypted |
| Normalization | your job | your job | done by Google |
| Readable by Google | no, fingerprint comparison | no, fingerprint comparison | yes, inside the TEE |
| Key | none | you (Cloud KMS) | depends on your setup |
Your pipelines: what to check before the 16th
CRM connections and file uploads
With a native connection (HubSpot, Salesforce and the like), the connector belongs to the vendor or to Google. Ask them in writing whether the format changes on November 16 and whether you can keep sending hashed data. For manual file uploads, nothing forces you to change your preparation as long as Google accepts fingerprints: keep your script, and write down your current match rate from Data Manager diagnostics so you have a baseline.
BigQuery and cloud storage
This is the most common setup I see with clients: a scheduled query that prepares the list in BigQuery with in-house normalization. Typically:
SELECT
TO_HEX(SHA256(LOWER(TRIM(email)))) AS email_sha256
FROM `project.crm.customers`
WHERE ad_consent = TRUE
Two remarks. First, even if Google handles normalization for unhashed data, your LOWER(TRIM()) doesn’t go away as long as you send fingerprints: it’s what makes the match work. Second, look at the WHERE clause. The real GDPR question in this flow is less the format of the email than the fact that you only send customers who agreed to this processing.
Data Manager API and server-side GTM
If you feed Google Ads through the Data Manager API, reread the API documentation when the switch happens: that’s where the encrypted format is specified field by field. I compared the API with the Measurement Protocol in Measurement Protocol vs Data Manager API, quotas and allowlist included.
On the server-side GTM side, the email says nothing about web tags. Server-side enhanced conversions and Enhanced Conversions for Leads via sGTM keep working as before: nothing in the announcement asks you to touch your tags on the 16th.
The GDPR angle: records, DPIA, privacy notice
Legally, sending a hashed or an encrypted email means transferring personal data to Google either way. So the change doesn’t create a new processing activity, but it can make your description of it wrong. Three documents to reread:
- Your records of processing. If they say “only SHA-256 fingerprints are transferred” and you switch, they become inaccurate.
- Your DPIA. Many Customer Match assessments rely on the idea that the readable address never leaves the advertiser. If that’s an argument in yours, it falls if you switch, and the TEE becomes the security measure you have to describe and justify.
- Your privacy notice. It must accurately describe what goes to Google. A line like “your data is hashed before transfer” won’t survive an unhashed upload.
I haven’t found any regulator guidance on this specific change so far. The reasoning above rests on general principles: pseudonymization, accurate records, transparency toward data subjects.
Should you stop hashing? A decision grid by flow
My take: not on November 16, and not on autopilot. The match rate gain is plausible, since Google fixes normalization errors itself, but it isn’t quantified anywhere public for this change. The documentation cost, on the other hand, is certain.
| Situation | Recommendation |
|---|---|
| Hashed pipeline that works, decent match rate | change nothing, monitor the match rate after the 16th |
| Low match rate caused by normalization | fix normalization first before talking about plain text |
| Native CRM connector | ask the vendor what changes and whether the hashed option stays |
| Sensitive data (health, finance, minors) | stay on hashing, your DPIA is too exposed |
| You want to switch | test on one list, compare match rates, update records, DPIA and notice before rolling out |
Checklist before November 16
- List every flow that sends customer data to Google Ads: Customer Match lists, offline conversions, CRM connections, file uploads, Data Manager API calls.
- Record the current match rate for each flow in Data Manager diagnostics.
- Ask CRM connector vendors what changes and whether hashed uploads remain possible.
- Check that every export query only keeps customers who consented to advertising use.
- Reread records, DPIA and privacy notice, and flag every sentence that assumes hashed uploads.
- Decide with your DPO, flow by flow: hashing kept, hashing then encryption, or encryption only.
- After the 16th, recheck scheduled uploads (errors, volumes, match rates) for at least two weeks.
- Watch the Data Manager help pages, which should eventually document the deadline and what happens to hashed uploads.
Hashing was never an invisibility cloak, just a way to keep the readable address at home. Google now offers to hold it for you in a clean room. That may be a good deal for your match rates, as long as you sign it knowingly, not because an email decided for you.