Aggregation Threshold Policy

Two companies agree to measure a campaign together without either seeing the other's customers. The environment is built, the join runs, and the output policy says results must cover at least 50 people. A week later one party runs the same query twice with a one-day difference in the date filter and subtracts the answers.

The threshold protects a single result; it does not protect a sequence of them. That is the property most implementations miss, and it is why an aggregation threshold is a policy rather than a number.

Why it matters

Shared analytics between organisations is now routine — retail media, healthcare research, fraud consortia — and the legal basis usually rests on the claim that no individual is identifiable in the output. That claim is made about the mechanism, so a mechanism that leaks through differencing invalidates the agreement, not merely the result.

It also matters because the cheaper alternatives fail in ways that look like successes. Exchanging hashed identifiers feels like a control and is a deterministic rename: each party can hash its own known population and test membership, which is exactly the disclosure the arrangement exists to prevent.

Implementation patterns

• A minimum cohort size, commonly in the tens, applied to every returned aggregate, with suppression rather than rounding when the cohort is too small.
• Query budgets and overlap limits, so the same party cannot run many near-identical queries. This is the control that addresses differencing, and it is the one usually absent.
• A fixed approved query set for recurring analyses. Ad-hoc query review does not survive contact with a monthly schedule; approving the queries once and running them unattended does.
• Suppression of complementary cells, so that a suppressed small group cannot be recovered by subtracting the published groups from a published total.
• Logging every query and its requester, kept by the environment rather than by either party, because the evidence must be neutral to be useful in a dispute.

Industry example

National statistical offices have applied exactly this pattern since the 1970s and formalised it in statistical disclosure control literature from 1996 onward: minimum cell sizes, complementary suppression, and a cap on how many tabulations a researcher may request from the same microdata — typically a handful per study, decades before commercial clean rooms existed. Modern data-sharing environments have rediscovered the same three controls for the same reason. The lesson worth taking is that the threshold alone was never the control; it was always the threshold plus the query limits.

Failure scenarios

• Differencing by repeated near-identical queries, which defeats any per-result threshold.
• Complementary disclosure: a small group suppressed while the total and all other groups are published, so the suppressed value is arithmetic.
• A threshold set on rows rather than on distinct subjects, so 50 transactions by 2 people satisfy a rule intended to require 50 people.
• Hashed-identifier exchange adopted instead, disclosing membership while appearing technical.
• Differential privacy applied to campaign measurement, where the noise required lands on precisely the small-cohort effects being measured, producing an answer that is private and untrustworthy.

Trade-offs

Thresholds and query budgets cost analytical power, and they cost it unevenly: small segments — which are often the commercially interesting ones — become unmeasurable. That is the trade being made, and it should be stated to the business before the environment is built rather than discovered when the first useful question is refused.

The operating burden is also real: query approval, output review, an agreement on who may run what, and a bill neither party wants to own.

When not to use it

For a one-off measurement where cohorts are large and only counts are needed, an agreed aggregate signed off by both legal teams delivers the answer in a fortnight rather than a quarter, and most partner analytics is this case dressed up as a platform requirement.

When the requirement is per-customer scores returned to the partner, none of this helps — that is a disclosure, and the honest response is to renegotiate the requirement rather than engineer around it. And when both parties already sit on the same cloud data platform, native sharing with policies gives the same guarantees without a separate environment to operate, which is usually the better answer for a recurring analysis.

Interview question

Q: You have built a clean room with a minimum cohort size of 50. A partner runs the same query each day with slightly different date ranges. What have you failed to prevent, and what would you add?

What a strong answer covers: differencing across a query sequence, which a per-result threshold cannot address · query budgets and overlap limits as the missing control · complementary cell suppression · thresholds counted on distinct subjects rather than rows · neutral logging held by the environment · why hashed-identifier exchange and differential privacy each fail this use case for different reasons · and the recognition that for a one-off with large cohorts an agreed aggregate is the proportionate answer.

Quick check

Quiz: Why is a minimum cohort size insufficient on its own? Because an individual can be isolated by differencing two overlapping queries that each satisfy the threshold, so query budgets and overlap limits are part of the control.

Flashcard: Why is exchanging hashed identifiers not anonymisation? It is a deterministic rename, so each party can hash its own known population and learn which of its customers appear in the other's data.