Data clean room

What is a data clean room?

A data clean room is a controlled environment where two or more organisations analyse their combined data without either side seeing the other's raw records. Each party brings a dataset, the records are matched on an agreed key, and only pre-approved queries run against the joined data. What comes back is a result, usually an aggregate, not a copy of anyone's customer list.

The point is collaboration without a handover. A retailer and a brand can measure whether an ad campaign led to purchases, yet neither ships its underlying customer or ad data. The environment runs the agreed analysis and returns only the outputs both sides approved.

Most clean rooms today are cloud services. Snowflake, AWS Clean Rooms, Google Ads Data Hub and Databricks each offer one, with different plumbing but the same promise: work on shared data, keep the raw rows on your own side.

The controls that make it work

A clean room is only as safe as the limits it enforces. Four controls do most of the work.

• Approved queries only. Analysts cannot write free-form SQL against the other party's table. They run query templates that both sides agreed in advance, so no one can quietly ask a question that singles out one person. Snowflake uses JinjaSQL templates for this; AWS Clean Rooms calls them analysis templates.

• Minimum group sizes. An output row must cover enough people to hide any single one. In AWS Clean Rooms you set an aggregation constraint such as COUNT(DISTINCT hashedemail) >= 100, and the minimum must be at least 2. Any row that covers fewer matched people is dropped before you see it.

• Output filters. The service checks results before releasing them and removes rows that fall below the threshold. Google Ads Data Hub, for example, filters out any row built from fewer than a set number of unique users, and null identifiers do not count toward that total.

• No raw export. The other party's underlying rows never leave their side. You get agreed query results, not a downloadable copy of their records. Query logs record what was run, so both sides can audit the collaboration afterwards.

Matching relies on shared keys, often a hashed email or another identifier, which is the same problem that entity resolution solves elsewhere. If the keys are messy, the analysis is weak no matter how strict the room is.

Advertising measurement: a worked example

Take a brand that ran ads with a retailer and wants to know if they paid off. The brand loads its exposure data, who saw which ad, and the retailer loads its purchase data. The two tables are joined on a hashed email, so neither raw list is revealed.

The retailer sets its aggregation constraint so any result row must cover at least 100 distinct matched customers, and it requires every query to join against the brand's table, which stops the brand from listing the retailer's whole customer base. The brand runs an approved query and gets back a table like "exposed customers who then bought, by region." A region with only three matching customers never appears, because it falls under the minimum. The brand learns that shoppers who saw the ad converted better, without ever holding a single name.

What clean rooms are used for

The technique grew up in advertising and still lives mostly there, but the pattern travels.

1. Advertising measurement. Match ad exposure against sales to see whether a campaign drove purchases, without either side handing over its customer file.

2. Audience overlap. Two companies check how many customers they share, in aggregate, before deciding whether a partnership is worth it.

3. Retail media. Retailers let brands analyse shopper behaviour against their own campaign data, a common way to sell insight rather than the underlying data.

4. Healthcare and research. Hospitals or researchers combine sensitive records to study outcomes across a population while individual patient data stays on the source side.

A clean room is not anonymisation

This is the part people get wrong. A clean room controls who can query the data and what the output looks like. It does not turn the inputs into anonymous data. The records each party brings are still personal data, held on their own side.

That distinction matters. Anonymisation and pseudonymisation, data masking and synthetic data change the records themselves. A clean room leaves the records as they are and restricts access and output instead. The approaches are often combined, but they are not the same guarantee.

Minimum group sizes lower the risk that a result points back to one person; they do not remove it. Someone who runs many overlapping queries, or who already knows a lot about a small group, can still narrow things down. That is why some clean rooms add differential privacy, which injects controlled noise so that no single record measurably changes the answer.

The law does not go away either. If you start from personal data, GDPR still applies to the processing inside the room: you need a lawful basis, a defined purpose and appropriate safeguards, and usually a data sharing agreement that sets out roles, retention and responsibilities. A clean room is a strong control and a sensible part of a data governance setup. It is not a stamp that makes the data anonymous.