§ 5.3 — Machine-readable privacy capabilities for interoperable clean-room activation #69

Which section?

5.3 — Audience reach

Field(s) involved

activation_route

Your comment

Section 5.3 defines activation_route with publisher_side, clean_room, and id_partner options. However, clean_room identifies the activation mechanism without describing the privacy capabilities or restrictions associated with that implementation.

Clean-room implementations can differ in permitted matching methods, output granularity, aggregation thresholds, differential privacy support, and identifier-export restrictions. Consequently, two sellers may declare the same activation route while offering materially different privacy properties.

Recommendation: Consider introducing optional, structured privacy-capability metadata associated with clean-room activation options, using a common machine-readable vocabulary across providers.

This could describe:

• Permitted output granularity (aggregate-only versus permitted record-level outputs).
• Supported privacy-enhancing mechanisms, where applicable.
• Minimum aggregation thresholds and output restrictions.
• Identifier matching and export restrictions.
• Whether capabilities are supported, required, or enforced.

The schema should also distinguish explicitly unsupported, unknown, and undisclosed capabilities. Missing metadata should not be interpreted as evidence that a privacy capability is present or absent.

A versioned reference to an external privacy-capability profile could be an alternative if these details fall outside OpenProposal's intended scope.

Interoperability benefit: Standardized privacy-capability metadata would enable buying agents to compare clean-room activation options across providers and evaluate proposals against advertiser-specific privacy requirements without relying on proprietary descriptions.

This proposal does not require OpenProposal to mandate differential privacy, prescribe specific clean-room technologies, or certify regulatory compliance.

Question for maintainers: Would optional, route-specific privacy-capability metadata fit within Section 5.3, or would a versioned external capability profile be more appropriate?

Concrete scenario

An advertiser requires audience activation with aggregate-only outputs, no identifier exports, and enforced minimum aggregation thresholds.

Two publishers offer clean-room activation:

Publisher A: Its clean-room configuration enforces aggregate-only outputs, prohibits identifier exports, and applies minimum aggregation thresholds.

Publisher B: Its clean-room configuration allows identifier-based matching and certain record-level outputs under different access and disclosure restrictions.

Both publishers indicate clean_room as an available activation_route.

However, the current field does not communicate these differences. A buying agent evaluating the proposals cannot determine from activation_route alone which option satisfies the advertiser's privacy requirements.

With standardized, route-specific privacy-capability metadata, the agent could compare both offers against the advertiser's requirements using consistent field definitions.

If a required capability is unknown or undisclosed, the agent could flag the proposal for clarification rather than incorrectly assuming compatibility.

Expected outcome: Enable automated, privacy-aware comparison of clean-room activation options across different providers without standardizing the underlying clean-room implementations.

You are commenting as

Individual, no organisational position

Before you submit

• I have read CONTRIBUTING.md and agree my contribution may be published under this repository's licence.
• This comment contains no confidential or commercially sensitive information.