Data Manager Encryption Replaces SHA-256: What to Check Before November 16, 2026
If you push Customer Match lists, offline conversions or in-store purchases into Google Ads, your pipeline almost certainly contains a step that reads “SHA-256 the PII before sending.” From November 16, 2026, that step stops being mandatory. Google has started emailing advertisers to say Data Manager will accept encrypted customer data by default instead of hashed data. Here is what the switch to Data Manager encryption actually means, what the email says, what it conspicuously does not say, and the nine checks worth running on your uploads before the date so you do not wake up to silently broken match rates.
What changes on November 16, 2026
There is one primary source: a Google email titled “Encryption in Google Ads Data Manager.” Anthony Higman of ADSQUIRE posted it on LinkedIn on October 18, 2026, and PPC Land published an analysis the same day. The line that matters, as quoted there: starting November 16, 2026, Google “will no longer require hashed customer data (SHA-256) for Google Ads Data Manager and will instead support encrypted customer data by default.”
The email then describes the mechanics. Data Manager will decrypt, normalize and match the data inside a trusted execution environment (TEE). The order of operations flips. Until now the advertiser normalized the data and hashed it, and Google only ever worked with irreversible digests. Under the new default, normalization moves to Google’s side, inside an isolated environment that the data reaches in encrypted form.
Google’s stated reasoning, from the same email: the update is meant “to offer better performance and to leverage our latest innovations in privacy-enhancing technology,” and it “improves match accuracy using privacy-enhancing technology and minimizes errors caused by formatting discrepancies prior to hashing.”
The practical consequence is simple: your normalization stops being a source of match failures. Which is exactly why the shape of what your pipeline must send changes too — and that is a job to finish before the date, not after.
What the email does not say
This part matters more than the headline, because confident retellings are already circulating that the source does not support. As of publication Google has not shipped a dedicated help article, and the visible portion of the email leaves several operational questions open:
- Whether hashing remains a supported option. “No longer require” plus “by default” implies an alternative exists, but the email does not describe one. It also does not forbid SHA-256.
- What happens to scheduled uploads that keep sending hashes after November 16 — whether they keep working, get converted, or start failing. Not stated.
- Who holds the encryption keys on the non-API routes (CRM connections, cloud storage imports, direct file uploads). The Data Manager API has documented key wrapping through cloud KMS since December 2025; the other routes do not have an equivalent public description.
- Whether products outside Google Ads are affected. The email names Customer Match and enhanced conversions. Display & Video 360 and Google Analytics, which also ingest through the Data Manager API, are not mentioned.
Anything beyond that — “the advertiser keeps the key,” “Google physically cannot read the data,” “hashed files will be rejected” — is currently interpretation by publishers and consultants rather than a Google statement. Plan the migration against the facts, and verify against your own logs.
How the current setup works: hashing, normalization and confidential matching
To judge the size of the change, it helps to recall what the present flow demands. You take an email address, a phone number or a postal address, force it into a canonical form, and compute SHA-256 — a fixed 64-character hexadecimal string. The normalization rules documented for the Data Manager API are strict, and they are where most silent losses come from:
- phone numbers in E.164 format (plus sign, country code, no spaces or brackets);
- addresses assembled from given name, family name, postal code and a two-letter country code;
- everything lowercase, no punctuation, no leading or trailing whitespace;
- Gmail addresses stripped of dots and of anything after a plus sign before hashing.
Get one of those wrong and you produce a different digest. The record simply fails to match, with no error anywhere. That is precisely the pain Google’s wording addresses: formatting discrepancies before hashing stop being a failure mode when the receiving side does the normalizing.
The second layer is confidential matching for encrypted first-party uploads, launched in September 2024, where matching happens inside a trusted environment, only matched records leave it, and unmatched customer data is deleted. It applies to Customer Match and Data Manager by default, at no extra cost. The November change does not remove that layer — it changes the format in which data arrives at it.
Data Manager encryption: which upload routes are affected
Per the email, the new default covers all four paths into Data Manager:
| Route | Typical owner | What to check |
|---|---|---|
| CRM connections | Sales ops, lead gen, B2B | Whether the vendor flips the connector itself, and by when |
| Cloud storage imports | Ecommerce, large accounts | Who builds the file and where the hashing step lives in it |
| Direct file uploads | Smaller accounts, manual exports | The export template and the runbook of whoever does it by hand |
| Data Manager API | In-house engineering, agencies | Client version, encryption scheme, key management |
The products sitting on top of that data are named in the email: Customer Match and enhanced conversions built on first-party data. Offline data that arrives through Data Manager belongs in the same bucket — for instance Store Sales through the Data Manager API. If you are still assembling this stack, start from the overview in Data Manager and first-party data without three pipelines.
Nine checks to close before November 16
- Inventory every flow. List every place data leaves for Google: audience lists, offline conversion imports, store sales, conversion enrichment. Most teams find more than they remember, especially where a contractor set something up two years ago.
- Locate the hashing step. For each flow, name where SHA-256 is actually computed: a warehouse SQL query, an export script, the CRM itself, a CMS plugin, a vendor connector. That step is what the migration touches.
- Ask vendors for a plan. If data leaves through a CRM or CDP connector, the vendor owes you one answer: do they switch automatically and when, or is action required on your side? Google’s email goes to advertisers, not necessarily to integrators.
- Record a match-rate baseline. Capture current match percentages and audience sizes per list before November 16. Without that number you cannot tell “it improved” from “half the records stopped arriving.”
- Check lists sitting near minimum size thresholds. An audience balanced on the edge of the eligible size can stop serving after any matching change, and you will see it as lost reach rather than as an upload error.
- Alert on upload health, not just dashboards. The worst case is a silent failure: the job runs, the file is accepted, nothing matches. An alert on accepted-row counts and on match-rate drops earns its keep here.
- Settle the key question. For the API route, decide where the key lives and who administers it in cloud KMS, and write it into your access policy. For the other routes, record that Google has not publicly described it rather than inventing an answer for your legal documentation.
- Update your privacy paperwork. Policies and data protection assessments are often written as “only irreversible hashes are transmitted.” If the actual format changes, that sentence needs review — a lawyer’s job, started early rather than after a complaint.
- Declare an observation window. One week before and two weeks after November 16, freeze bidding strategy changes and audience composition. Otherwise you will not separate the platform change from your own edits. The fast way to isolate a drop is covered in diagnosing a performance drop through change history.
What not to do
Do not panic-disable working uploads on November 15. The email does not declare hashing forbidden, and a stopped data flow degrades your signal with certainty, while continuing in the old format might degrade it. Equally, do not rewrite the pipeline “just in case” against an undocumented scheme. Until Google publishes guidance for your specific route, the sane posture is a ready plan plus a baseline, and a switch triggered by documentation or by real errors.
One more thing: this is not an occasion to start collecting more personal data than you did before. Changing the transport format does not move the responsibility for lawful processing. That stays with the advertiser.
What the teams who prepare actually gain
Remove normalization errors from the equation and every measurement mechanism fed by first-party data benefits: Customer Match precision, the quality of the signal reaching Smart Bidding, the reliability of enhanced conversions. The effect is not uniform, though. It scales with how messy your data was. An account where phone numbers lived in three formats and plus-addressed emails were mangled will see a difference; an account with a clean warehouse will barely notice.
It also helps to remember that matching is only one layer. Signal leaks earlier too — in the browser, in blocked requests, in attribution gaps. If that part is still open, look at serving Google tags from your own domain and at the new Customer Match upload columns. Together those three move more than any one of them alone.
Finally, while you are tidying data, check whether something else on the 2026 calendar is about to break your operations. The EU political advertising declaration is the current favourite for blocking routine campaign edits with no warning. And if you want a quick win on the spend side in parallel, the usual candidate is n-gram analysis of your search terms.
When infrastructure is not your job
Not every team has an engineer who can rewrite an export in a week. If you run traffic while the technical plumbing hangs on a contractor — or on you, in your spare time — at least split the ownership explicitly: who owns the data format, who owns monitoring, who owns the account. We cover the account side of that: Google Ads agency account rental takes platform stability off the table while you sort out the data, and the full list of what we help with sits on the PPC Rebels services page.
Timeline: how Google got here
| Date | What happened |
|---|---|
| September 2024 | Google launches confidential matching: first-party data matched inside a trusted environment, on by default for Customer Match and Data Manager, at no extra cost. |
| April 2025 | At its Data Protection Forum, Google describes the flow: data encrypted before entering the environment, matching inside it, only matched records leaving, unmatched customer data deleted. |
| December 2025 | The Data Manager API launches with documented XChaCha20-Poly1305 encryption and wrapped keys held in cloud KMS. At this stage encryption is an option layered on hashing. |
| May 2026 | A field for encrypted user identifiers appears in the Data Manager API — a clear signal of the direction of travel. |
| October 18, 2026 | Google’s email “Encryption in Google Ads Data Manager” becomes public, carrying the switch date. |
| November 16, 2026 | Data Manager encryption becomes the default format; the SHA-256 requirement is lifted. |
The chain matters for one reason: this is not a sudden, one-off change. Google keeps moving personal data processing inside an isolated environment, and each step makes the advertiser’s own data preparation less decisive. Teams whose export exists as “a script the previous contractor wrote” will meet this topic again.
What auditing one flow looks like in practice
Take a common case: an ecommerce account that pushes a 540-day buyer list to Customer Match every night, plus offline conversions from call-centre calls. The audit takes an evening.
- Where the flow starts. A BigQuery view,
crm.customers_for_google, containingTO_HEX(SHA256(LOWER(TRIM(email)))). That single view is your migration point — not the whole pipeline. - What ships the file. A scheduler triggers a script, the script drops a CSV into a bucket, Data Manager picks it up. So the route is “cloud storage import,” and switching format means editing two things: the SQL and possibly the column schema.
- What the match rate is today. Open the audience and write down list size, match percentage and the date of the snapshot. Do the same for offline conversions: rows sent versus rows accepted over the last 14 days.
- Where it will break quietly. Call records store phone numbers in three shapes — local format, E.164, and no country code at all. Today a chunk of them simply never matches. Once Google handles normalization, that chunk may start matching, so conversion counts can rise without sales rising. Note that in the report commentary now, or in December somebody will credit it to a creative test.
- Who owns what. The analyst owns SQL and format, the buyer owns volume and audience monitoring, legal owns the data-flow description. If all three roles are the same person, writing the plan down before the date matters more, not less.
The lesson from this example is unglamorous: the migration itself usually touches one or two steps of code, while the real work is measuring before and after. Teams that only do the first part spend the following month arguing about whether anything improved.
FAQ
What exactly happens on November 16, 2026?
According to Google’s email, Data Manager stops requiring SHA-256 hashed customer data and supports encrypted customer data by default, decrypting, normalizing and matching it inside a trusted execution environment.
Does Data Manager encryption make hashing banned?
Nothing in the published portion of the email bans it; it says Google “will no longer require” hashing. Whether the old format continues to be accepted after that date is not described, so rely on your own upload logs and on Google’s help documentation once it appears.
Does this only affect Customer Match?
The email names Customer Match and enhanced conversions, and covers all four upload routes: CRM connections, cloud storage imports, direct file uploads and the Data Manager API. It says nothing about DV360 or Google Analytics, which also use the Data Manager API.
I upload files manually through the UI. Do I need to do anything?
Less than an engineering team does, but yes. Know what format your file is prepared in, and check the match percentage on your list after November 16. A sharp move in either direction is a reason to rebuild the export template.
Will match rates actually improve?
Google promises better accuracy from removing formatting errors, but gives no percentage, test or baseline. The only people who will know their real delta are those who recorded a match rate before the change.
Who holds the encryption key?
For the Data Manager API, key wrapping through cloud KMS has been documented since December 2025. For CRM connections, storage imports and direct uploads, the email does not address it.
Does this mean Google now sees my data in the clear?
The accurate statement is that data is decrypted and normalized inside a trusted execution environment. Both “Google sees everything now” and “Google cannot see anything” claim more than the email does. If the answer is legally material to you, ask a Google representative in writing and keep the reply.
Do my GDPR obligations change?
Changing the technical format does not move controllership — it stays with the advertiser. What can change is whether your documented description of the data flow still matches reality, and that is worth checking with counsel before the date.
My CRM vendor is not responding. What now?
Put the request in writing, record a match-rate baseline, and alert on accepted-row volume. If uploads start failing after November 16, you will have a date and numbers to escalate with instead of a feeling that something got worse.
How does this relate to confidential matching?
Confidential matching is the layer where the matching happens inside an isolated environment, live since 2024. The November change alters the format in which data reaches that layer: encrypted and decrypted inside, rather than hashed before it leaves you.
Could this break audiences that work today?
There is no direct statement that it will, but the risk concentrates in scheduled automated uploads that nobody watches. That is why monitoring plus a recorded baseline is the one genuinely mandatory piece of preparation.
Where should I watch for official information?
The Google Ads Data Manager help section and the Google Ads API release notes — that is where precise wording and field names usually land. Until then, treat every detail, including the ones in this article, as a description of an email rather than documentation.