# Data Partnerships and Clean Rooms
In 2021, Apple's App Tracking Transparency prompt did something no privacy regulation had managed: it made the identifier-based ad economy collapse almost overnight. Meta alone booked a $10 billion revenue hit in 2022. But the more interesting story is what the survivors did. Retailers like Walmart, Kroger, and Albertsons discovered that the first-party purchase data sitting in their warehouses was suddenly the most valuable currency in advertising—not because they sold it, but because they found a way to let brands *use* it without ever handing it over. That mechanism was the data clean room. And it turned Walmart Connect into a business generating over $4 billion in annual ad revenue.
This lesson is about the machinery behind that shift: how two organizations combine data to create value neither could unlock alone, while proving to regulators, boards, and each other that no raw record ever changed hands. As a CDO, you will increasingly be asked to sign off on these arrangements. Getting the governance wrong exposes you to regulatory liability; getting the architecture wrong destroys the economics. Both failures land on your desk.
Start with the strategic question, because the technology is downstream of it. A data partnership exists to resolve an information asymmetry between two parties who each hold a fragment of a complete picture.
Consider the canonical retail-media case. A consumer packaged goods brand knows who saw its ads but not who bought the product. A retailer knows who bought the product but not what advertising influenced them. Neither can measure ad effectiveness alone. Overlap their data on a common key—a hashed email, a loyalty ID—and both parties learn something worth paying for: the brand gets true return-on-ad-spend, the retailer gets a monetizable measurement product. The value is created *at the intersection*, and it is genuinely mutual.
This is the test you should apply to every partnership proposal that crosses your desk:
Three archetypes recur:
Notice what each has in common: the *output* is narrow and aggregated, while the *input* is sensitive and raw. The entire discipline of clean rooms is about widening the gap between those two things—maximizing the value of the output while minimizing the exposure of the input.
A data clean room is best understood not as a product but as a set of enforced constraints on a joint computation. The vendors—Snowflake, Google Ads Data Hub, AWS Clean Rooms, Habu, InfoSum—differ in topology, but they all implement the same four controls. As a CDO, evaluate any clean room against these, not against feature lists.
1. Isolation of inputs. Each party's raw data stays under its own control. In a "distributed" clean room (InfoSum's model), the data never physically moves at all—computation is federated and only encrypted intermediate results traverse the boundary. In a "centralized" model (Snowflake's data sharing), data sits in a governed environment but neither party can query the other's rows directly.
2. Restriction of operations. The clean room permits only pre-approved query types. You cannot run SELECT *. You run an approved join-and-aggregate. This is the control most CDOs underweight, and it is the one that matters most.
3. Aggregation and output gating. Results below a minimum group size are suppressed. If a query would return a metric for a segment of 3 people, the clean room returns null. This is what prevents differencing attacks—the technique of running two nearly identical queries and subtracting the results to isolate one individual.
4. Logging and mutual auditability. Every query, by both parties, is logged and visible. Neither side operates in the dark.
Here is the critical insight for a technical leader: the clean room's privacy guarantee comes almost entirely from control #3, not from the encryption in control #1. Executives fixate on "the data never moves." But a poorly configured clean room with strong encryption and *no output gating* leaks individuals trivially. Encryption protects data at rest and in motion; it does nothing against a legitimate query designed to isolate a person.
This is why the aggregation threshold is your single most important governance parameter. A concrete configuration in AWS Clean Rooms looks like this:
analysisRuleAggregation:
aggregateColumns:
- columnNames: [purchases]
function: SUM
joinColumns: [hashed_email]
outputConstraints:
- columnName: user_id
minimum: 100 # suppress any output row backed by <100 users
type: COUNT
dimensionColumns: [campaign_id, region]The minimum: 100 is not a technicality. It is the difference between an aggregate insight and a re-identification vector. If your partner pushes to lower it "for more granular results," understand exactly what you are trading away.
The centralized-versus-distributed choice is a real strategic decision, not a vendor preference:
The mistake is defaulting to whatever the vendor sells. A bank partnering with a fintech on fraud signals and a grocer partnering with a CPG on ad measurement have different threat models and should not use the same topology.
The technology vendors will sell you the platform. They will not sell you the judgment, and it is the judgment that keeps you out of the news. Here is the governance stack you own.
The legal agreement must specify things most templates omit. Insist on:
Clean rooms fail through accumulation, not through a single dramatic breach. The named risks:
Differencing attacks. A partner runs query A over a segment, then query A′ over the same segment minus one known attribute, and subtracts. Defenses: minimum aggregation thresholds *plus* query-overlap monitoring *plus* a cap on total queries. No single control suffices—this is defense in depth.
Averaging attacks. Repeated slightly-varied queries with added noise, averaged to cancel the noise. If your clean room uses differential privacy (as Google's ADH does), you must manage a privacy budget—a finite epsilon consumed by every query. When the budget is exhausted, querying stops. Treat epsilon as a governed resource with an owner, not a default someone set once.
The insider-with-context problem. Aggregate outputs are only "anonymous" relative to what the recipient already knows. A partner who already holds substantial data about the same population can combine your aggregates with their prior knowledge to re-identify. This means your aggregation threshold should be set based on *the partner's likely auxiliary knowledge*, not on an abstract standard. A threshold of 50 might be safe against a stranger and reckless against a firm that already holds overlapping identity data.
Run every proposed partnership through four gates, in order. Fail one, and you stop:
1. Legal basis — do we have a lawful basis for this specific use of this specific data under every applicable regime? (Consent scope is where retail-media deals most often fail.)
2. Value symmetry — is the joint output more valuable than what we contribute, and is that value mutual?
3. Technical containment — do the configured controls (topology, allowlist, thresholds, budget) make the contractual promises physically true?
4. Reputational tolerance — if this appeared on the front page described accurately, could we defend it? Legal and defensible are not the same standard.
Gate 4 is the one CDOs skip and regret. Cambridge Analytica was, in the narrow, arguably permitted by Facebook's platform terms at the time. It was not defensible.
Vérification des acquis
1. According to the lesson, what is the fundamental strategic precondition that makes a data partnership worth pursuing?
2. What was the essential innovation retailers used to monetize their first-party purchase data after the identifier-based ad economy collapsed?
3. The lesson states that as a CDO, both governance failure and architecture failure 'land on your desk.' What does this reveal about the nature of clean-room decisions?
4. Select ALL correct answers. In the canonical retail-media clean-room case, what does each party learn that it could not derive alone?
Sélectionnez toutes les réponses correctes.
5. Select ALL correct answers. Which principles about data partnerships are supported by the lesson?
Sélectionnez toutes les réponses correctes.
You have a partnership proposal on your desk—a large media company wants to combine audiences with your first-party datafirst-party dataData collected directly from your own customers and prospects through your own channels: your most reliable and privacy-compliant source.Voir la définition complète → for a co-selling motion. Here is how you actually move.
Week one: interrogate the value logic before touching technology. Write, in one sentence, the joint computation and who benefits. If you can't, there is no deal. Then identify the minimum data columns each side must contribute for that computation to work. This column list becomes the input specification for everything downstream.
Week two: threat-model the partner specifically. What does this partner already know about the overlapping population? That answer sets your aggregation threshold and determines whether you need federated topology. A partner with deep identity graphs is a higher re-identification risk than one without, regardless of their good intentions.
Week three: align contract and configuration as a single artifact. Do not let legal draft the agreement while engineering configures the platform in isolation. Every permitted purpose in the contract must correspond to an allowlisted query; every prohibited use must be blocked in config, not merely forbidden in prose. When these two documents disagree, you have a latent breach.
Ongoing: govern the outputs, not just the inputs. The seductive error in clean rooms is believing the work ends when raw data is protected. The value—and the residual risk—lives in what leaves the room. Maintain a register of every model and segment produced, its permitted uses, and its expiry. A lift segment is a derivative of personal data and should decay, not persist indefinitely.
One organizational note: clean rooms create a new internal stakeholder collision. Your commercial team wants more queries and lower thresholds; your privacy team wants fewer and higher. Do not arbitrate this ad hoc. Establish a standing review—the same governance body you use elsewhere—with authority to set thresholds and privacy budgets as policy. The parameter that determines your regulatory exposure should not be set by whoever files the ticket.
1. The privacy guarantee lives in output gating, not encryption. Set and defend the minimum aggregation threshold as your single most important parameter, and calibrate it to what your specific partner already knows—not to a generic standard.
2. Make the contract and the configuration one artifact. Every permitted purpose must mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Voir la définition complète → to an allowlisted query; every prohibition must be enforced in config. Prose the platform doesn't enforce is decorative.
3. Govern the outputs, not just the inputs. Models and segmentssegmentsDividing a market into distinct groups of customers who share similar needs, characteristics or behaviours, so each group can be served with a tailored approach.Voir la définition complète → built inside the clean room are derivatives of personal data. Maintain a register with permitted uses and expiry dates—the residual risk leaves the room with the results.
4. Run every partnership through the four gates—legal basis, value symmetry, technical containment, reputational tolerance—and treat gate four as non-negotiable. Legal and defensible are different standards, and the gap between them is where careers end.
5. Choose topology from the threat model, not the vendor. Federated when a partner is a competitor or the data movement itself is the regulated risk; centralized when you trust the environment and need richer analytics.