Confidential Matching in Google Ads 2026: Encrypted First-Party Uploads

Every first-party data project eventually stalls in the same meeting. Not because the engineering is hard, but because someone from legal or security asks a reasonable question: what exactly are we sending to Google, and who on their side can read it? The honest answer used to be “SHA-256 hashes of emails and phone numbers, and after that it comes down to trusting the platform.” Confidential matching changes that answer. Matching now happens inside a hardware-isolated environment that platform staff cannot inspect, and if you want more control, you can encrypt the data with your own Cloud KMS key so that only attested, Google-signed code running inside that environment can decrypt it.

This guide covers how confidential matching actually works, what it does and does not buy you, and the exact sequence for setting up encrypted uploads through Google Ads Data Manager — which roles to grant, which fields to map, and where the pipeline usually breaks in silence.

What confidential matching is and which problem it solves

Confidential matching is a way of matching your first-party records — emails, phone numbers, addresses — against Google accounts, where the matching itself runs inside a Trusted Execution Environment (TEE). Three practical consequences follow.

• Isolation happens at the processor level. The memory holding your records during processing is encrypted in hardware. The host OS, the hypervisor and infrastructure administrators cannot read it.
• The code inside is fixed and signed. Only a specific image, audited and signed by Google with a known fingerprint, executes inside the environment. Swapping it for something slightly different is not something that can happen quietly.
• It is externally verifiable. Attestation lets your side release the decryption key only to a caller that has proven it is running in Confidential Space with the expected code fingerprint.

For Customer Match audiences built through Data Manager, confidential matching is already the default technique. There is no toggle to find. The optional layer on top — the one security teams in regulated industries usually ask for — is encrypting the data with your own key before it leaves your environment. That is what the documentation calls “confidential matching with encryption.”

Put simply: the TEE is baseline protection you already have. Encrypting with your own key upgrades “we trust the platform” into “we technically control who can decrypt.”

How it works under the hood

Trusted Execution Environments without the jargon

A normal cloud VM is protected logically: a hypervisor separates you from neighbours and an access policy separates you from administrators. A TEE adds a hardware boundary. The processor carves out an enclave whose memory is encrypted with a key the host and hypervisor never see. Even with full root on the physical machine, a memory dump of that enclave is unreadable.

Google implements this through Confidential Space, a purpose-built environment that runs only a pre-approved, signed image. For an advertiser, the technology matters less than the consequence: between “we uploaded hashes” and “someone inside the platform could in theory export them” there is now a hardware barrier rather than an internal policy.

Attestation: proving the right code is running

Attestation is the part most people skim past, and it is the part that makes the whole scheme meaningful. The flow is:

1. The confidential match service starts in Confidential Space and receives an OIDC token asserting facts about itself: environment type, image fingerprint, support status.
2. That token is presented to your Workload Identity Pool (WIP) provider in Google Cloud.
3. Your provider enforces an attribute condition you defined in advance: the environment must be CONFIDENTIAL_SPACE, the image fingerprint must match the one Google publishes, and the support attribute must be STABLE.
4. Only when the condition passes does the service gain the identity it needs to call your Cloud KMS key and unwrap the data key.

Decryption access is therefore granted by cryptographic proof, not by contract. If the image changes and its fingerprint stops matching the condition you wrote, the key is never released and the upload fails closed.

Envelope encryption: three layers

The encryption scheme is envelope encryption. Three layers, and mixing them up is where most first attempts fail.

Layer	What it is	Where it lives	What it does
KEK (Key Encryption Key)	Key-encrypting key	Cloud KMS, your project	Wraps the DEK. Never leaves KMS
DEK (Data Encryption Key)	Data-encrypting key	Generated by you, shipped wrapped	Encrypts field values with XChaCha20Poly1305
Data	Normalised PII	In the upload file	SHA-256 → Base64 → DEK encryption → Base64

Note the exact order for every value: normalise first (lowercase, trim whitespace, phone numbers in E.164), then SHA-256, then Base64, then encrypt with the DEK, then Base64 again for transport. Skip a step or reorder two and you produce a file that looks perfectly valid and matches nothing — with no error to tell you why.

What you get, and what you don’t

It is worth being precise here, because the feature solves one problem well and touches nothing adjacent.

You get	You don’t get
Hardware isolation of PII processing from platform staff and infrastructure	A higher match rate — that depends on the quality and coverage of your list
Technical proof of who can decrypt, and with which code	A legal basis for processing, or a substitute for user consent
An argument that survives internal security review	Permission to upload where personalised advertising policy forbids it
A kill switch: revoke the KEK and decryption stops	Any direct effect on bidding, learning or account structure

The first item in the right column gets misread constantly. Confidential matching changes how data is processed, not what the match returns. A list that matched at 40% will still match at 40%. Coverage gains come from somewhere else entirely — list completeness, contact freshness, number of sources — which is the subject of working with Customer Match and first-party data, not cryptography.

Setting up encrypted uploads, step by step

The sequence below assumes you already build audiences through Data Manager and connected first-party sources, and now want to add your own encryption layer.

Step 1. Prepare the Google Cloud side

You need a Google Cloud project and two roles for whoever does the setup:

• Cloud KMS Admin — to create the keyring and the KEK itself;
• IAM Workload Identity Pool Admin — to create the pool and a provider carrying the attestation condition.

Create the KEK in Cloud KMS and record its full resource path; that becomes your kek_uri. Then create a Workload Identity Pool and an OIDC provider inside it, writing the attribute condition: environment equals CONFIDENTIAL_SPACE, image fingerprint matches Google’s published signature, support attribute is STABLE. Grant the match service account permission to decrypt using that KEK.

Step 2. Prepare the data

This is where the real engineering lives. For every record:

1. Normalise the value. Emails lowercase and trimmed. Phone numbers in E.164 with country code. Names, postal codes and country per Customer Match formatting rules.
2. Compute SHA-256 of the normalised value.
3. Base64-encode the hash.
4. Encrypt the result with your DEK using XChaCha20Poly1305.
5. Base64-encode the ciphertext — that is the value written to the file.

You generate the DEK yourself, wrap it with your KEK, and the wrapped result becomes encrypted_dek, shipped alongside the data.

Step 3. Deliver the file to a supported source

Source	Best for	Watch out for
Google Cloud Storage	Scheduled exports from a warehouse	Most predictable option; permissions scoped at bucket level
SFTP	Files produced by an agency or a legacy system	Key rotation and who else can read the directory
HTTPS	One-off or infrequent uploads	Fine for a pilot, weak for a daily cadence
CRM / database	When your internal system is the source of truth	Requires extra connection steps and access approvals

Step 4. Map the fields in Data Manager

Alongside the usual column mapping, provide two extra fields: encrypted_dek (your wrapped data key) and kek_uri (the KMS resource path of your KEK). The same screen takes the WIP provider name, which ties the upload to the attestation conditions you configured in step 1.

Step 5. Validate on a small batch

Do not start with the full list. Take one or two thousand records whose expected match rate you can reason about, and compare the result against that expectation. A match rate far below what you predicted is almost always a pipeline bug, not a platform problem.

Where this breaks in practice

The failures below do not throw errors. They quietly return near-zero matches, which is why they cost weeks.

• Normalising after hashing. The hash must be computed on the normalised value. SHA-256 of Ivan@Mail.com with a trailing space and capitals will never match anything.
• One Base64 too many or too few. There are exactly two encodings: after hashing and after encryption. Getting that count wrong produces garbage that still parses.
• Phone formatting. A number without a country code, or with spaces, brackets and dashes, is a different string and therefore a different hash.
• Key drift. Rotating the KEK without updating the connection stops decryption. Write the rotation runbook before production, not after the first outage.
• An over-tight attestation condition. Pinning to a stale image fingerprint means uploads stop the next time the image is updated. Verify the fingerprint is current when you configure it.
• Forgotten consent. Encryption does not create a legal basis. Upload only contacts whose consent you actually collected — which still ties back to Consent Mode v2 and privacy signalling.

Fitting it into the wider measurement stack

Confidential matching is one brick, not a wall. It pays off only when the rest of the stack exists.

1. Identifier capture on site. With nothing collected, there is nothing to upload. The base layer is enhanced conversions, which attach hashed user data to the conversion event.
2. Durable event delivery. Blockers and browser restrictions cut signal. That gap is closed by server-side tagging with sGTM and Google tag gateway as a first-party measurement layer.
3. Offline outcomes. When the sale closes away from the site, connect Store Sales and offline purchase uploads or a standard offline conversion import.
4. Patching partial tag data. Where the tag fired but user data went missing, supplemental conversion data let CRM uploads complete those events.
5. Measuring the payoff. Judge the work with the Data Strength Uplift metric rather than a feeling that things improved.

Build those five and your data stops being a pile of exports and starts behaving like one system. Understanding that system end to end saves far more budget than any single setting — in PPC Rebels Google Ads training measurement is taught as exactly that: a system, not a checklist.

Getting through internal security review

In practice the blocker is approval, not code. Three questions come up almost every time; here are answers that actually address them.

“Where does the personal data physically go?” The uploaded file contains no raw values — only encrypted representations of hashes. Decryption requires your Cloud KMS key, and that key is released only to a caller that passes attestation. The matching itself executes in an isolated environment whose memory is encrypted in hardware.

“Who inside the platform can read it?” By construction, neither infrastructure administrators nor staff: the key is granted not to people but to code with a verified fingerprint running in Confidential Space. That is materially different from “there is an internal policy against accessing it” — here the restriction is cryptographic.

“What can we do if something goes wrong?” Revoke the KEK. New uploads become undecryptable and the process halts. Key control stays on your side, which is usually the strongest point in the conversation: you hold a switch you operate yourself.

Write those three answers down in a short internal note alongside the data flow diagram and the list of owners. It saves weeks at the next audit and when people rotate off the team.

Alternatives, and when they fit better

Encrypted upload is not the only way to put first-party data to work. Compare honestly before building infrastructure.

Approach	What it gives	What it costs
Data Manager upload without your own key	Default TEE protection, minimal setup	Fine for most, but does not satisfy a formal encryption mandate
Upload with your own encryption	Key control and verifiable attestation	Cloud infrastructure, a preparation pipeline, a rotation policy
Enhanced conversions only, no lists	Better attribution without exporting the database	No audiences for targeting or exclusion
Offline upload of closed deals	Feeds real value instead of lead counts	Needs a durable click identifier and CRM discipline

The right answer is usually a combination: enhanced conversions as the base layer, offline data for value, Customer Match for audiences — with encryption layered on only where company policy demands it. Whatever you feed in, sanity-check the values with conversion value rules and value-based bidding, or fuller data will simply make wrong bids more confident.

Pre-launch checklist

• Legal basis documented; consent collection verified.
• KEK created in Cloud KMS, resource path recorded.
• WIP provider created, attestation condition written and tested.
• Cloud KMS Admin and IAM Workload Identity Pool Admin granted to the right person.
• Pipeline reproduces the exact order: normalise → SHA-256 → Base64 → DEK encrypt → Base64.
• encrypted_dek and kek_uri mapped in the connection settings.
• Pilot run on 1,000–2,000 records; match rate in the expected range.
• Key rotation runbook written, owner assigned.
• Monitoring in place — successful uploads dropping to zero should raise an alert, not be discovered a month later.

Do you actually need the encrypted path?

Often, no. If your list is modest, you have no internal encryption mandate, and security review passes without objection, the default TEE protection is enough. The encrypted path adds genuine operational weight: keys, roles, a preparation pipeline, a rotation policy.

It earns its keep when at least one of these is true: your company formally requires PII to be encrypted when shared with third parties; you operate in a regulated sector and face external audits; the list is large enough that a leak would be a serious incident; or the upload decision is blocked by security specifically, and you need a technical argument rather than a promise.

FAQ

Do I have to switch confidential matching on?

No. For Customer Match audiences created through Google Ads Data Manager it is the default technique. Only the additional encryption with your own key requires setup.

Will it improve my match rate?

No. How data is processed does not change how much of it matches. Match rate comes from list quality, freshness, volume and correct normalisation before hashing.

How is this different from just hashing with SHA-256?

Hashing is one-way, but identical inputs always produce identical hashes, so hashes of common emails are comparable against a dictionary. Encrypting with a key you control adds a layer where, without access to your KEK, the data is not even reducible to hashes.

Which Google Cloud roles are required?

Cloud KMS Admin for key management and IAM Workload Identity Pool Admin for the pool and provider with attestation conditions. Grant them narrowly and temporarily rather than as standing access.

What happens if I revoke the KEK?

New uploads can no longer be decrypted and will fail. That is the intended behaviour and effectively your kill switch — controlling the key means controlling whether processing can happen at all.

Can I upload data without consent since it is encrypted?

No. Encryption is a technical safeguard, not a legal basis. Consent requirements and personalised advertising policy restrictions apply in full.

Which data sources are supported?

Google Cloud Storage, SFTP, HTTPS, and CRM or database connections. The last requires additional setup steps on the source side.

Why did matches drop to almost zero after enabling encryption?

Almost always a pipeline error: wrong operation order, an extra or missing Base64 encoding, unnormalised values, or phone numbers not in E.164. Debug on a small batch with a known expected outcome.

Do I need to change anything in my campaigns?

Not directly. What changes is the source and protection of the data, not account structure. If the resulting audiences become fuller and fresher, revisit the strategies and observation settings that consume those lists.

How do I demonstrate this to an auditor?

Point at the attestation design: decryption access is released only when verifiable conditions are met — Confidential Space environment and a matching signed-code fingerprint. That is a checkable technical claim, not a policy statement.

Is this worth it for a small advertiser?

Usually not. Smaller accounts get more from fixing contact capture and measurement accuracy first, and adding encryption later if a requirement appears.

What should I read next?

Start with Data Manager and first-party data, then look at where measurement leaks in the Google Ads and GA4 conversion discrepancy guide, and what replaces the fading cross-site signal in third-party cookies and Privacy Sandbox.

The takeaway: confidential matching does not make advertising perform better on its own. It removes the objection that keeps first-party data sitting in a CRM for years instead of reaching the ad platform. The value shows up the moment that objection disappears and the data finally gets there — after which the work is coverage and freshness.

If your bottleneck is infrastructure rather than data, that is a separate track: PPC Rebels handles Google Ads agency accounts and advertiser verification.