Two retailers want the size of their shared customer overlap and the average basket of that overlap group without either seeing the other's customer list. Which technique fits the requirement as stated?

What the requirement is really asking

Two properties: neither party learns the other's membership list, and both learn one aggregate over the intersection. That rules out every design where somebody holds both lists at once, however trustworthy they are.

Private set intersection does precisely this. Both sides blind their identifiers under a protocol where matched elements can be counted without either side learning the unmatched ones, and extensions such as private join and compute (Google published and open-sourced one in 2019) return a sum over the matched rows without revealing which rows matched.

What it costs

Rounds of protocol over the full identifier sets, with communication roughly linear in list size, so a run over tens of millions of identifiers is a batch job measured in minutes to hours rather than an API call. It is one query shape, agreed in advance: you cannot explore, you can only run the computation you both signed up to. That constraint is the privacy property, not a limitation to be engineered around.

Why the other options fail

• Differential privacy on each side's export. DP protects individuals in a released statistic. Exporting each side's full customer list with noise still hands the other party a customer list, and the identifiers must be exact for a join to work, so the noise either breaks the join or does not protect anyone. DP belongs on the output of the computation, and it is a good addition to a small intersection where the count itself is identifying.
• Fully homomorphic encryption over a clear join. The option contradicts itself: the join is in the clear. General FHE over a large join is also several orders of magnitude slower than the plaintext computation, which is why production deployments are narrow, fixed circuits rather than arbitrary SQL.
• A clean room in one retailer's account. This moves trust rather than removing it: the host controls the environment, the query logs and the egress. It is nonetheless what most real partnerships use, hosted by a neutral third party with an agreed query allowlist, aggregation thresholds and audit — because it is operable by analysts and PSI is not.

When not to reach for PSI

If both parties accept a neutral operator, contracts and audit logs, use the clean room. It costs a fraction of the engineering, supports more than one question, and adds threshold and noise controls at the output. Reach for PSI when a contract is not enough: the counterparty is a competitor, a regulator has said the lists must not be combined, or the identifiers themselves are the sensitive asset.