Data Clean Room Architecture: Privacy-Preserving Joins

Q: What is a data clean room and how is it different from data sharing?

A data clean room is a controlled environment in which two or more organisations compute agreed aggregate results over the join of datasets they are not permitted to hand each other. It differs from data sharing in one decisive way: no participant ever receives the other party’s rows. Instead, each party keeps its data in its own account or storage, attaches a policy that allowlists the shapes of query that may run against it, and the room executes permitted queries on isolated compute and returns only aggregates that clear a minimum group size or carry differential-privacy noise. The practical consequences are that the join key is never exposed as a list, that row-level output is impossible by construction rather than by trust, and that both parties can audit which questions were asked. Data sharing, by contrast, transfers a copy and relies on contract and good behaviour to limit use. In 2026 the distinction matters because regulators treat a transferred copy as a new processing purpose that needs its own legal basis, whereas a clean room can often be framed as computation over data that never left the controller’s estate. That framing still requires a data protection impact assessment, but it is a far easier conversation with a privacy office than a file transfer.

Q: Why did data clean rooms become urgent in 2026?

Two forces converged. The first is the retirement of the browser-level alternatives. On 17 October 2025 Google announced it would retire most of the Privacy Sandbox technologies, including the Attribution Reporting API, Protected Audience, Private Aggregation and Shared Storage, citing low adoption, having already decided to keep third-party cookie choice in Chrome rather than remove cookies outright. The industry had been planning to move cross-party measurement into those browser APIs; that road is now closed, and cross-party measurement has to happen somewhere else. The second force is regulation moving in the opposite direction. Purpose limitation under GDPR, the consent architecture of India’s DPDP Act, and sector rules in financial services and health all make sending a partner a customer file a governance failure even when both parties are willing. The result is that retailers, publishers, banks and health networks who need to answer overlap, incrementality and attribution questions have exactly one pattern that satisfies both their data team and their privacy office, and that pattern is the clean room. It is not a new idea, but it is now the only mainstream one left standing.

Q: How does a clean room enforce privacy technically?

Through three layers stacked in a fixed order. The identity layer governs how records from different parties can be matched: a bare hashed email is not protection, because every party holds an email list and can reverse the hash, so serious rooms use a neutral match provider that exposes only a pairwise pseudonym, or a private set intersection protocol in which each party learns only the size of the overlap. The analysis-rule layer constrains what queries may run. AWS Clean Rooms, for example, lets each table owner attach an aggregation rule that permits only COUNT, SUM and AVG along approved dimensions, a list rule that permits scoped row-level overlap output for activation, or a custom rule that restricts querying to pre-approved analysis templates; Snowflake’s clean rooms take the same template-first approach with owner-registered JinjaSQL templates and no arbitrary SQL unless explicitly enabled. The output layer applies minimum-group thresholds or differential-privacy noise to every result so that permitted queries cannot be combined to reveal individuals. Google’s Ads Data Hub filters result rows that fall below roughly 20 unique users in its default noise-injection mode, and AWS Clean Rooms can add calibrated noise while consuming a finite privacy budget. Each layer answers a different question and each fails differently, which is why all three are needed.

Q: Should I build my own data clean room or use AWS, Snowflake, Databricks or Google?

Rent one unless you have a specific reason not to. The vendor rooms are mature enough that the engineering effort of building your own is rarely justified, and the privacy proof and audit burden of a homegrown room is considerable. The two legitimate reasons to build are that your partners all sit on a platform you do not control and cannot join, or that you need a privacy model no vendor ships, typically full private set intersection with a custom differential-privacy accountant, or execution inside a trusted execution environment for regulated data. When choosing between vendors, compare on who each room assumes the counterparty is rather than on query engine. AWS Clean Rooms works cleanly when every member has an AWS account and bills Spark SQL compute per second in CRPU-hours with a 60-second minimum; Snowflake Data Clean Rooms suit parties already on Snowflake, with other regions reachable through Cross-Cloud Auto-Fulfillment; Databricks Clean Rooms run all-party-approved notebooks in an ephemeral central room and suit lakehouse-native, machine-learning-heavy collaborations; Google Ads Data Hub only answers questions about Google’s own ad data. If your partners are heterogeneous, the realistic topology is two rented rooms fed by one internal governed pipeline, not one universal room.

Q: What does AWS Clean Rooms cost in 2026?

AWS Clean Rooms charges the member who runs queries for compute, measured in Clean Rooms Processing Unit hours, billed per second with a 60-second minimum charge, with no upfront cost and no resources to manage. You choose an instance type and worker count, which together determine the CRPU capacity per hour; AWS’s own worked example uses the default CR.1X configuration with 16 instances for 32 CRPUs per hour, and prices it at $2.00 per CRPU-hour, so three 3-minute queries a day come to about $9.60 per day or $3,504 per year. Pricing varies by region, so check the pricing page for yours. Differential privacy, when enabled, is billed as an incremental per-CRPU-hour charge, and machine-learning features such as custom modelling are billed per million records. The practical cost lesson is that clean room spend is driven by query cadence and query duration rather than by data volume at rest, which means the analysis-rule design and the discipline of the analysts asking questions have a direct effect on the bill. Budget for the compute of exploration during the first collaboration; it is usually higher than steady state.

Q: Is hashing the join key enough to anonymise data in a clean room?

No, and treating it as anonymisation is one of the most common and most serious mistakes in clean room projects. A SHA-256 hash of an email address is a deterministic pseudonym: anyone who holds a list of candidate emails can hash them and match, and every party in a clean room, by definition, holds exactly such a list. Under GDPR and similar regimes a hashed identifier is therefore pseudonymised personal data, not anonymous data, and the full set of obligations continues to apply. The correct designs are either a neutral match provider that holds the raw key and exposes only a collaboration-specific pairwise pseudonym to each party, so that neither side can link the pseudonym back to its own raw list, or a private set intersection protocol in which the parties jointly compute the overlap without either learning the other’s membership. Beyond the identity layer, the design rule to enforce is that no participant should be able to run a query whose result is the list of identifiers the parties share; that is what the analysis-rule layer is for. State the matching model explicitly in the data protection impact assessment, because it is the first thing a diligent privacy reviewer will ask about.

Q: When is differential privacy necessary in a clean room, and what does it cost in accuracy?

Differential privacy is necessary whenever the counterparty is one you would not trust with the raw table and the collaboration allows many queries over time. A minimum-row threshold on its own is defeated by differencing: ask for a count with a condition and a count without it, subtract, and you learn about the individuals in the difference even though every result cleared the threshold. Ads Data Hub’s legacy difference-checks mode exists precisely to catch this by comparing each result against earlier ones and filtering rows that would expose small groups. Differential privacy answers the same attack more generally by adding calibrated noise to every result so that any individual’s presence changes the output distribution by a bounded factor, and by charging every query against a finite privacy budget so that the bound holds across all queries combined. The cost is real: counts become noisy, the number of questions is finite, and the analyst who wants the exact number has to be told there is no exact number. Small segments become unusable, which is a feature rather than a bug. Most teams therefore enable differential privacy only for collaborations with untrusted partners and rely on thresholds for the rest, and write the budget and its refresh cadence into the partnership contract rather than treating it as a configuration knob.

Q: When should you NOT use a data clean room?

Do not use a clean room when a simpler mechanism satisfies both the partner and your legal team. If the counterparty will accept a periodic aggregate report that you generate yourself from your own data, and your privacy office is comfortable with that report, a clean room adds cost, latency and a second platform to govern for no privacy gain. Do not use one when the real requirement is row-level output, for example a matched customer list to push to an activation partner; that is an overlap export with a scoped list rule, and calling it a clean room does not change the fact that identifiers are leaving. Do not use one to launder data you had no right to process for the purpose in the first place, because purpose limitation, retention and consent obligations apply to what you put in regardless of how carefully you control what comes out. And do not stand up the platform before the two legal teams have agreed the list of business questions, the aggregation dimensions and the minimum group size, because that agreement is the analysis rule, and a room without it either permits nothing useful or permits too much. The clean room is the right tool for recurring aggregate questions between parties who cannot share rows; for everything else it is ceremony.

Satyam Kumar

ブログに戻る

ai-architecture

Data Clean Room Architecture: Privacy-Preserving Collaboration Without Handing Over the Data (2026)

By Satyam KumarSeptember 6, 202614 min read

data clean room data clean room architecture privacy-preserving collaboration aws clean rooms snowflake data clean rooms databricks clean rooms ads data hub differential privacy private set intersection privacy sandbox retirement analysis rules aggregation threshold second-party data data collaboration gdpr purpose limitation dpdp act

Data Clean Room Architecture: Privacy-Preserving Collaboration Without Handing Over the Data (2026)

Frequently Asked Questions

この記事を共有する

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

AI＆クラウドアーキテクト。数百万人にスケールするシステム構築を支援。

LinkedIn GitHub

Data Clean Room Architecture: Privacy-Preserving Collaboration Without Handing Over the Data (2026)

Frequently Asked Questions

この記事を共有する

Comments

Leave a comment