Data 360 Clean Rooms: collaborating on customer data without moving a single row

Two companies have overlapping customers and a reason to work together — a retailer and a brand that sells through it, a bank and a co-brand partner, a media network and an advertiser. Both would benefit from knowing where their audiences overlap and how a campaign performed across the seam. And both legal teams will, correctly, refuse to let a single raw customer record cross the boundary. Emailing a hashed list around is how you end up in a regulator’s file; standing up a shared warehouse means someone owns everyone’s PII, which is worse.

The clean room is the architecture that dissolves that standoff. It’s a governed environment where two parties’ datasets can be joined and queried together, but neither side can see the other’s row-level data and the only thing that ever comes out is an aggregate — a match rate, an overlap count, an incrementality lift — that reveals nothing about any individual. Salesforce shipped its own version, Data 360 Clean Rooms — beta in Summer ‘25, generally available in December 2025 — built directly on the zero-copy foundation the rest of the platform already runs on. If you’ve been treating clean rooms as an ad-tech curiosity, the fact that one now lives inside the CDP you use for identity resolution and activation changes the calculus.

This post is the practitioner’s read: what a Data 360 Clean Room actually is, the privacy machinery that enforces the promise (because “trust us” is not a control), the native-versus-bring-your-own split, and the credit and limit realities nobody puts on the announcement slide.

What a clean room actually is — and what it isn’t

Strip the marketing and a clean room is three guarantees enforced by machinery rather than by contract:

1. Neither party sees the other’s raw records. You contribute your data, your partner contributes theirs, and the join happens inside a boundary where row-level access is denied to everyone — including, in a well-built room, the room’s operator.
2. Only pre-agreed questions can be asked. You don’t get an open SQL prompt against your partner’s customer base. You get a small set of queries both sides approved in advance, and nothing else runs.
3. Only aggregates come out, above a minimum size. Results are counts, rates, and lifts — never a list of people — and they’re suppressed below a threshold so a “segment of one” can’t be reverse-engineered into an identity.

What it isn’t is a data-sharing agreement with a nicer UI. A zero-copy share gives a trusted consumer live query access to your data; that’s the right tool when you want a partner to see rows. A clean room is the opposite posture — collaboration between parties who explicitly must not see each other’s rows, where the shared output is the only artifact anyone is allowed to keep. Confusing the two is the most common conceptual error, and it matters because it drives which legal review you need and which control failures you’re guarding against.

How a Data 360 Clean Room works

The mechanics are more approachable than the ad-tech vocabulary suggests. A collaboration in Data 360 Clean Rooms has two roles: a provider, the party that contributes data, and a consumer (also called the subscriber), the party that wants insight from it — and in a two-way collaboration each side plays both roles at once. The whole arrangement is governed by a collaboration template, which Salesforce describes as the single source of truth for the collaboration: it names the participants, the data each contributes, the queries that may run, and who is allowed to see the results. Think of it as the operating manual and the contract fused into one enforceable object.

The pieces you configure:

• Contributed data. Each party maps the datasets it’s bringing — customer tables, transactions, exposure logs — from its own Data 360 estate. Because the room sits on zero-copy foundations, contributing data is closer to pointing at it than to shipping a copy into a shared tenant.
• Allowed queries. These are the pre-approved SQL queries the room will execute. The word doing the work is pre-approved: a query that isn’t on the list doesn’t run, which is what stops a collaborator from fishing for individuals one clever WHERE clause at a time.
• Access rules. The room’s governance layer decides who contributes data, who is permitted to run which queries, and who receives the output. These three privileges are separable — the party that runs a query is not necessarily the party allowed to see the unfiltered result.
• The join key. Overlap analysis is only as good as the match, and this is where the rest of Data 360 earns its keep. The same identity discipline that keeps your match rules from over-merging two real customers governs how cleanly your records line up against a partner’s. Garbage identity in, meaningless overlap out.

Run a query and the room returns an aggregate result the access rules permit you to see. Crucially, every execution is logged — the requester, the timestamp, the query logic, and which privacy policies were applied — so the collaboration produces an audit trail, not just an answer. In a data-sharing arrangement that a regulator might one day ask about, that log is the deliverable that keeps you out of trouble.

The privacy machinery that enforces the promise

A clean room’s whole value is that the guarantees are structural, not contractual. Data 360’s clean rooms layer several privacy-enhancing controls, and it’s worth knowing what each one actually does, because “the clean room protects privacy” is a sentence, not a control. The ones Salesforce documents:

Pre-query hashing and anonymization. Direct identifiers — emails, phone numbers — are hashed or anonymized before any query runs, so the matching happens on tokens rather than on raw PII sitting exposed in a shared workspace.

Private joins. The overlap itself is computed without either side exposing its raw keys to the other. The parties learn that records match and how many — not which identifiers the other party holds.

Aggregation thresholds. The room returns only aggregated output and suppresses any result computed from fewer than a minimum number of individuals. This is the plain-language defense against re-identification: if an overlap segment resolves to three people, the room refuses to report it rather than handing you a group small enough to de-anonymize by inspection.

Query limits and frequency capping. Even individually-safe aggregate queries can, run over and over with slightly different filters, triangulate an individual. Throttling how often and how many queries can run against a dataset is the defense against that patient, probing attack — the one aggregation thresholds alone don’t stop.

Pre-approved query templates. You can’t hand the room arbitrary ad-hoc SQL. It runs only the query patterns the collaboration template allows, which is what turns “trust the analyst” into “the analyst structurally cannot ask the dangerous question.”

A clean room’s promise is only as strong as its weakest exposed query. Aggregation thresholds stop the obvious re-identification; frequency capping and pre-approved templates stop the patient one. Treat all of them as required, not optional, for any collaboration touching regulated data.

A note on differential privacy, because it comes up in every clean-room evaluation. Differential privacy — injecting calibrated statistical noise and tracking a per-dataset privacy budget that caps how much can be learned across many queries combined — is the strongest mathematical guarantee in the category, and it’s a first-class, documented feature of Snowflake’s and AWS’s clean rooms. If your collaboration touches data where formal DP is a compliance requirement rather than a nice-to-have, confirm the exact noise-and-budget behavior of whichever room you’re standing up against its current documentation before you promise a regulator anything — the marketing category word “clean room” does not by itself tell you which of these controls are switched on.

None of this is free of trade-offs. Aggregation and any noise injection mean the number you get back is approximately right, which is fine for audience sizing and lift measurement and wrong for anything that needs to be exact. And limits that are too tight will block the legitimate analysis your partner is paying to run. Tuning that balance — enough protection to satisfy both legal teams, enough fidelity to answer the business question — is the actual work, and it’s a conversation between data, legal, and the partner, not a checkbox.

Native room vs. bring your own clean room

Data 360 gives you two deployment postures, and picking wrong means either rebuilding later or paying for capability you won’t use.

	Native Data 360 Clean Room	Bring Your Own Clean Room (BYOCR)
Where the room lives	Inside Data 360, on its zero-copy engine	An external room (e.g. AWS Clean Rooms) that Data 360 connects to
Best when	Both parties are Salesforce-centric, or you want templates a business team can run	Your partner already standardized on another clean-room platform
Data movement	Contributed in place via zero-copy	Governed by the external room’s model
Reach	Salesforce ecosystem and connected sources	Meets partners where they already collaborate

The native room is the path when you want business teams to launch collaborations from out-of-the-box templates — audience overlap, suppression, reach, and lift are the ones Salesforce ships — without a data-science team standing behind them, and when the counterparties are already in or near the Salesforce ecosystem. The catch worth surfacing early: the native room assumes both parties are Data 360 customers with the right licenses. If your partner has never heard of Data 360, the native room isn’t the meeting point.

That’s exactly why Bring Your Own Clean Room exists. A large advertiser or retail-media partner may have standardized on AWS Clean Rooms, and Data 360’s native integration there lets you collaborate on their turf — Data 360 acting as the orchestration and governance layer while the compute sits in AWS — without forcing a platform migration into the deal. The honest framing: BYOCR is a reach play. It trades some of the native experience for the ability to say yes to a partner who was never going to move.

It also helps to know the neighbors, because a partner may propose a room you didn’t pick. Snowflake’s clean rooms are deep and SQL-first with strong differential privacy, but they assume everyone’s in Snowflake. LiveRamp (which absorbed Habu) leads on cross-web identity and turnkey activation, at a price. AWS Clean Rooms is the infrastructure-level engine — and, via BYOCR, the one Data 360 actually rides on top of. Data 360’s distinctive bet is reusing its zero-copy federation as the privacy boundary and wrapping it in templates a business team can run, rather than making the clean room a separate warehouse skill to hire for.

Both rest on the same foundation the rest of Data 360 uses. If you want the mechanics of why data can be queried where it lives instead of copied, that’s the zero-copy integration story — clean rooms are one of the more consequential things that architecture unlocks, because “the raw data never moved” is exactly the property a privacy lawyer wants to hear.

Where the credits and limits actually bite

Clean rooms don’t escape the thing that governs everything else in Data 360: consumption billing. Contributing data, running queries, and activating results are all operations, and operations draw credits from the same fungible pool the rest of your platform spends. Two practical consequences follow.

First, watch the query cadence. A clean-room collaboration that a marketing team leaves refreshing on a fast schedule is a meter, same as a segment or a calculated insight. The discipline is identical to the one in the credit-optimization playbook: match refresh frequency to the freshness a business decision actually needs, and keep the collaboration on Digital Wallet’s weekly review so an experiment doesn’t quietly become a line item. A quarterly overlap analysis republishing daily is pure waste.

Second, activation is where the value and the next cost both live. An overlap count is an insight; a suppression list or a matched audience pushed to an ad platform is an outcome. Activating clean-room results runs into the same segmentation-and-activation plumbing — and the same related-attribute and per-row realities — as any other Data 360 audience. Salesforce has been extending the room toward provider-side activation so results can be actioned with partners directly rather than exported and reconciled by hand; treat the activation surface as the fast-moving part of the product and verify current capability against the docs before you design a workflow that assumes it.

The limits that matter most day to day are the privacy ones, and they’re features, not bugs: queries below the aggregation threshold return nothing, and a spent privacy budget blocks further analysis. Teams new to clean rooms read these as errors and file tickets. They’re the product working. Design the collaboration — and set the partner’s expectations — around the fact that some questions will, by design, refuse to answer.

The use cases that justify the build

Clean rooms are overkill for most data problems and exactly right for a specific few. The pattern is always the same: two parties, a genuine reason to collaborate, and a hard legal wall against sharing rows.

• Retail media and co-marketing. A retailer and a brand measure how a campaign performed against the retailer’s purchase data without the retailer handing over its customer list. This is the highest-volume use case and the one retail media networks are built on.
• Audience overlap and incrementality. Two partners size how much their audiences overlap before committing to a co-marketing spend, and measure incremental lift afterward — the questions that decide whether a partnership is worth renewing.
• Financial services partner analytics. A bank and a co-brand partner analyze shared-customer behavior under privacy constraints strict enough that raw-data sharing was never on the table.
• Healthcare and life sciences collaboration. Aggregate analysis across parties where the regulatory floor makes row-level exchange a non-starter, and where the audit trail is as important as the answer.

In every one of these, the clean room isn’t making a new analysis possible in theory — you could always do it if everyone trusted everyone. It’s making it possible in practice, because the machinery lets both legal teams sign off on a collaboration they’d otherwise veto. That’s the actual product: not the join, but the yes.

What to do about it

If you have partners you’d collaborate with data on but never have because sharing rows was a non-starter, the clean room is the unlock, and the first move is a conversation, not a configuration. Name the specific question — overlap, lift, suppression — because that determines the allowed queries and whether aggregation thresholds alone suffice or you need a differential-privacy budget on top. Decide native versus BYOCR by asking where your partner already collaborates, not by which one demos better. And get your identity house in order first: a clean room grounded on messy match rules produces overlap numbers that are precise, auditable, and meaningless.

Then treat it like every other Data 360 capability — a metered one. Put the collaboration on the same consumption review as your segments and insights, match query cadence to decision cadence, and don’t let a privacy-safe experiment become an un-owned meter. The clean room removes the legal objection to collaborating on data. It doesn’t remove the engineering discipline of running Data 360 well — and the teams that get value from it are the ones that bring both.

Understanding the basics

What is a data clean room?

A data clean room is a governed environment where two or more parties can join and analyze their datasets together without any party seeing the other’s raw, row-level records. Only pre-approved queries run, and only aggregated results — above a minimum size threshold — come out, so the collaboration reveals patterns and overlaps without exposing individuals. Data 360 Clean Rooms is Salesforce’s implementation, built on the platform’s zero-copy foundation so contributed data is queried where it lives rather than copied into a shared location.

How is a clean room different from zero-copy data sharing?

They solve opposite problems. Zero-copy sharing gives a trusted consumer live query access to your data — you want them to see the rows. A clean room is for parties who explicitly must not see each other’s rows: the data is joined behind privacy controls, and the only output is an aggregate that reveals nothing about any individual. Use zero-copy when you’re extending access to a trusted internal or partner team; use a clean room when two independent parties need a shared answer but not shared data.

What stops someone from de-anonymizing a clean room result?

Layered controls. Aggregation thresholds suppress any result computed from fewer than a minimum number of people, so you can’t isolate an individual by narrowing a query. Private joins compute overlap without exposing raw match keys. And differential privacy adds calibrated noise plus a per-dataset privacy budget that caps how much can be learned across many queries combined — the defense against triangulating an individual from a series of individually-safe aggregates. Every query is also logged with the privacy policy applied, producing an audit trail.

---

Weighing a clean room for a partner collaboration and trying to work out native versus bring-your-own, or whether your identity data is clean enough to trust the overlap? Talk to us — grounding Data 360 collaborations in governed, auditable architecture is the integration work we do.