Data clean rooms have become the default answer to a reasonable question: how do you collaborate on audience data without exposing raw PII to a partner? The architecture is sound. Two parties bring their data into a neutral computation environment, queries run against the joined dataset, and only aggregated results leave the room. No raw records cross the wall. Privacy engineers are satisfied. Legal signs off. The deck goes to the CMO.
The problem isn't the room. The problem is what walks into it.
The Identity Layer Is Load-Bearing
Every clean room analysis — overlap sizing, reach estimation, incrementality modeling, suppression logic — depends on matching records across the two datasets inside the room. That matching happens on an identity key: a hashed email, a RampID, a UID2, a proprietary graph node. Whatever key is used, its quality determines whether the join reflects reality or reflects the optimistic assumptions baked into whichever identity graph resolved your records in the first place.
When buyers evaluate clean room partnerships, the conversation almost always focuses on the privacy architecture and the query interface. Rarely does it focus on the resolution rate of the incoming data, the recency of the graph that produced the keys, or the population coverage of the chosen identity namespace. Those are not secondary concerns. They are the actual determinants of whether the output number is meaningful.
A clean room can tell you that your CRM file overlaps with a publisher's logged-in audience at a rate of 34%. What it cannot tell you, without additional interrogation, is whether that 34% was computed against the 60% of your CRM records that resolved cleanly, or against the full file. Those are very different overlap rates, and they imply very different reach projections.
Resolution Debt Compounds Inside the Room
Think of it as resolution debt — the gap between the records you brought to the clean room and the records that actually participate in the join. This debt accumulates at several points before a single query runs.
First, your CRM file goes through onboarding. Some percentage of records resolve to identity keys. The rest fall off. That falloff is rarely random: it skews toward older records, records with personal email addresses rather than work addresses, records from geographic markets with lower graph coverage, and records for demographics that are structurally underrepresented in the identity graph you're using. What remains is a resolved subset that may not be representative of your actual customer base.
Second, the publisher brings their data through the same process. Their logged-in users or deterministic matches also carry resolution rates that vary by the identity namespace they used. If your data was resolved to namespace A and theirs was resolved to namespace B, the clean room needs a bridge between those namespaces. That bridge introduces its own match rate, its own latency, and its own error surface.
By the time the query runs, you are measuring the overlap between two already-filtered populations. The clean room reports that overlap accurately. It has no obligation to report what fell off before the computation started.
Recency Is a Hidden Variable
Graph recency compounds the problem. Identity graphs are not static. Emails change, device associations shift, household compositions move. A graph that resolved your customer records six months ago may have assigned keys that no longer correspond to the same people in the publisher's current dataset. Clean room queries are typically run against static resolved files or periodically refreshed keys — which means the join may be comparing your customer data from Q1 against a publisher audience snapshot from Q3 using identity keys that were accurate at two different points in time.
For suppression use cases, stale identity keys mean you're suppressing people who may no longer be reachable at that key — and reaching people you intended to suppress because their key has changed. For measurement use cases, the control and exposed groups may have been segmented using identity states that have since drifted, introducing systematic error into any incrementality calculation that follows.
None of this is visible in the query output. The clean room returns numbers that look precise because they are precise — they're precise measurements of an imprecisely constructed input.
What to Actually Audit
Buyers who want clean room outputs they can act on should ask four questions before they run a single query.
What is the resolution rate of my incoming file, broken out by identity namespace? Not the headline match rate from the onboarding vendor — the rate at which records resolved to the specific key the clean room will use for joining. If your onboarding vendor reports a 75% match rate but only 45% of records resolved to the namespace your publisher partner uses, the effective working dataset is 45% of what you think it is.
What is the publisher's resolution rate for their contributing dataset, and against which namespace? If they can't answer this, the overlap estimate you receive is not interpretable in absolute terms — only in relative terms, which limits its utility for reach planning.
What is the age of the identity keys on both sides? Keys older than 90 days carry meaningful drift risk for most consumer datasets. Keys older than 180 days in high-churn categories — streaming, retail, financial services — should be treated as approximate.
Is the unresolved population on my side systematically different from the resolved population? Run a basic demographic and behavioral comparison between the records that resolved and those that didn't. If the unresolved population over-indexes on high-value segments — recent purchasers, lapsed customers you're trying to win back — the clean room analysis will systematically undercount the most important people.
The Room Is Only as Honest as the Input
Clean rooms are genuinely useful infrastructure. The privacy guarantees are real. The ability to run collaborative analysis without raw data transfer is a meaningful advance over the alternatives. But the analytical validity of what comes out is entirely a function of the identity quality that went in — and that identity quality is not the clean room's responsibility to validate. It's yours.
The vendors who built the room will show you query interfaces, privacy budgets, and differential privacy parameters. They will not show you a dashboard that says your effective working dataset is 41% of your CRM file because the rest didn't resolve to a namespace your partner uses. That number exists. It's just nobody's job to surface it unless you ask.
Ask before you build the analysis. The room will run either way. The question is whether you're measuring something real.