Data partnerships & clean rooms

# 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.

The value logic: why combine data at all

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: is there a computation that is more valuable to both parties than the data either contributes? If only one party benefits, you don't have a partnership, you have a data sale wearing a partnership costume, and it should be governed as a sale.

Three archetypes recur:

• Measurement and attribution, two parties join on identity to close a loop (ads → outcomes). The output is aggregate metrics.
• Audience enrichment and activation, one party's attributes improve another's targeting or modeling. The output is a segment or a lift model, not individual records.
• Supply-chain and operational matching, partners reconcile shared entities (shipments, patients, fraud signals) to reduce collective cost.

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.

The clean room as an architecture of constraint

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.

The four controls

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.

Choosing the topology

The centralized-versus-distributed choice is a real strategic decision, not a vendor preference:

• Centralized (data pooled in a shared governed environment) is faster to build, supports richer analytics, and is fine when you trust the environment operator. Most retail-media clean rooms are here.
• Distributed / federated (data never leaves each party) is essential when the data is regulated to the point that movement itself is the risk, health records, cross-border data under GDPR, or when a partner is also a competitor and you cannot tolerate their staff having *any* proximity to your rows.

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 governance a CDO must own

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.

Before the join: the partnership agreement

The legal agreement must specify things most templates omit. Insist on:

• Purpose limitation, computationally enforced. The contract should name the specific analyses permitted, and those analyses should mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → one-to-one to the clean room's configured query allowlist. If the contract says "measurement" but the config permits arbitrary aggregation, your contract is decorative.
• No re-identification covenant with teeth. An explicit prohibition on attempting to isolate individuals, combined with audit rights and defined breach consequences. InfoSum's non-movement architecture is partly a *legal* strategy, it makes the covenant physically credible.
• Output ownership and downstream use. Who owns the model trained inside the clean room? Can a lift segment be exported and re-used against a different population next quarter? This is where value, and risk, quietly leaks. A segment built from your data, once exported, is beyond your control.
• Data minimization at input. Contribute only the columns the approved computation requires. If measurement needs a hashed ID and a purchase flag, do not load demographics "in case they're useful later."

During operation: the controls you monitor

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.

The governance decision framework

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.

Application: the monday-morning playbook

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.View full definition → 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.

Key Takeaways

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.View full definition → 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.View full definition → 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.