Data clean rooms became the standard answer to a specific commercial problem. Third-party cookies degraded, mobile identifiers became opt-in, and the advertising industry lost the shared identifier that let any two parties recognise the same browser. What remained was first-party data: the customer lists that brands, retailers, publishers and platforms hold directly, each accurate and each isolated.
A clean room is the venue where two of those datasets are joined without either party receiving the other's rows. Both sides upload into an environment they do not fully control, a matching process runs, and the output is restricted to aggregate results: overlap counts, conversion attribution, audience sizing, campaign measurement.
The join key is a hashed email, and hashing is not anonymising
Matching needs a shared identifier. The one the industry converged on is the email address, normalised in an agreed way and then hashed, usually with SHA-256. Both parties compute the same hash over the same address, the values match, and the record is linked.
This is frequently described as a privacy measure. It is a formatting convention. A hash is deterministic and the input space is small enough to enumerate: the set of plausible email addresses is not a secret, and precomputed tables covering billions of them have been circulating for years. A hashed email is not a de-identified value, it is a stable pseudonym, and a stable pseudonym is exactly what a tracking system wants.
This is the same mechanism behind hashed email identity resolution, which is why the same identifier that links your grocery purchases to your streaming habits also survives you clearing cookies, changing devices, and switching browsers. It is more durable than the cookie it replaced.
Under GDPR, data that can be attributed to a person with the help of additional information is pseudonymised, not anonymised, and remains personal data. Hashed emails fall on that side of the line, which is why clean-room arrangements are structured around contracts, purpose limitation and access control rather than a claim that the data stopped being personal.
What the clean room actually restricts
The controls are real and worth stating precisely, because the criticism is not that they do nothing.
- No raw export. Neither party can download the other's records. Queries run inside the environment and only results come out.
- Aggregation minimums. Results below a threshold of matched users are suppressed, so a query cannot return a group small enough to identify one person.
- Query review. The permitted operations are constrained, and some platforms review query patterns for attempts to isolate individuals.
- Noise, in some implementations. A minority apply differential privacy with a stated budget, which is the only one of these controls that comes with a mathematical guarantee rather than a policy.
Together these prevent the crudest misuse. They do not change the underlying fact, which is that a linkage was created between two datasets about the same identified person, and that linkage now informs decisions about them.
Differencing is the attack the thresholds invite
Aggregation thresholds have a well-understood weakness. If a system will answer "how many people in this audience bought the product" for any audience above a minimum size, an analyst who can define audiences precisely can ask about a group, then ask about the same group with one member's attributes excluded, and read an individual answer out of the difference between two aggregates that were both individually compliant.
Platforms guard against this by tracking query history and refusing results that differ by too little from an earlier one. That defence works against the naive version. It becomes a running contest as soon as the analyst varies filters across many dimensions and reconstructs the difference indirectly, which is the same problem statistical agencies have spent decades on with census disclosure.
An aggregate is not automatically private. Two aggregates are frequently less private than one, and the number that matters is how many an analyst is allowed to ask for.
The formal solution to this is differential privacy, which accounts for cumulative disclosure across every query against a fixed budget and then stops. Adopting it means accepting noisy measurement numbers, which the buyers of advertising measurement have generally not wanted, so most deployments use thresholds and audit rules instead.
What a cryptographic version would look like
There is a category of protocol that solves the stated problem with mathematics rather than access control. Private set intersection lets two parties compute the size of the overlap between their sets, or operate on the intersection, without either learning anything about the elements that are not shared. Secure multi-party computation generalises that to arbitrary joint functions.
Some clean rooms use these primitives for parts of the matching step. Many do not, and the distinction is not usually visible from the product description, because both are marketed with the same vocabulary. The difference is where the protection lives:
| Approach | What stops the operator from reading both files |
|---|---|
| Administrative clean room | Contract, access control, audit logging, the operator's own policy |
| Confidential computing enclave | Hardware isolation plus attestation, with the vendor's chain of trust |
| Private set intersection | The protocol; nothing is transmitted that reveals non-shared elements |
The right question to ask of any deployment is which row it is in, because that determines whose good behaviour the guarantee depends on. This is the same distinction that separates end-to-end encryption from a provider promising not to look.
The part with no user interface
Cookie banners and app tracking prompts, whatever their flaws, at least appear. Clean-room processing happens between two companies you already have a relationship with, using data you already gave them, in an environment you will never see named. There is no prompt, no toggle, and no notification when your record is matched.
The levers that exist are upstream of the room:
- Break the join key. The match runs on your email address. A distinct address per service, through aliasing, means the hashes do not agree and the records do not link. This is the single most effective step available, and it works without asking anyone's permission.
- Send the opt-out signals that carry legal weight. Global Privacy Control is treated as a valid opt-out of sale and sharing under several US state laws, and applies to the collection that feeds these datasets.
- Exercise deletion rights at the source. A clean room operates on the files each company holds. Removing yourself from those files is upstream of every match they can compute, which is what makes broker opt-outs and access requests worth the effort.
- Read loyalty terms as data terms. A loyalty programme is the mechanism that attaches a name to a purchase history, and the purchase history is what makes the retailer's side of the match valuable.
The clean room is a reasonable answer to the question the industry asked itself, which was how to keep matching customers after the shared identifier went away. It is not an answer to the question users would ask, which is whether the matching should happen. Being clear about which question a technology answers is most of what evaluating it consists of.