Attribution API(s)

[erik-anderson]

Per discussion in the WICG Attribution Reporting API repo issue #262 and during an ad-hoc call around multi-party compute and measurement, there’s a common desire among many implementers to work on one or more attribution-related proposals within the PATCG.

The high-level class of use cases to be supported here is to perform a calculation across source events and trigger events which occur across different contexts. In the advertising use case, a source event is typically an ad impression, and a trigger event is typically a conversion event. Many such use cases are collected and tracked in the Advertising Use-cases doc in web-adv.

The high-level privacy goal of any such solution is to prevent revealing individual cross-context behavior. Consensus is still needed on what mechanisms are required to achieve this goal; the approaches listed below use different combinations of aggregation, entropy reduction, and differential privacy.

Generally speaking, there are multiple variants which serve different use cases and approach preserving privacy in different ways. They are not mutually exclusive:

• Event-level reporting:
  • Reporting for clicks, e.g. “Private Click Measurement” (PCM) and “Attribution Reporting for Click-Through Measurement”
  • Reporting for views, e.g. “Attribution Reporting for View-Through Measurement”
• Aggregate-level reporting using helper services:
  • APIs, e.g. “Attribution Reporting API with Aggregate Reports”
  • Server-to-server protocols, e.g. https://datatracker.ietf.org/group/priv/about/, “Multi-Browser Aggregation Service Explainer”
  • Cryptography: various discussions; some in ISRG, IETF, and in W3C repos
• App-to-web variants of the above, e.g. PCM’s approach and “Android Cross App and Web Attribution Measurement”
• Cross-device variants of the above, e.g. Attribution Reporting API’s approach and Facebook’s proposal in web-adv.

These various use cases and proposals often have significant intersections, e.g. the APIs available to register a source event and a meaningful activity may be shared, but the outputs the browser provides may be different (e.g. the data flows can differ significantly in terms of who receives a given report, when they receive the report, and what processing needs to be done to make it useful). The privacy aspects of the proposals may differ significantly too where some explicitly allow for cross-site tracking of individual user activity but not identity, and others disallow both.

We would like to work on all of the above in PATCG. Given there are similar-but-competing proposals, the critical thing is to start the conversation in the PATCG about how to approach unification and then decide from there the path to specifying interoperable approaches. The first proposed step is to attempt to reach consensus on the desired use cases and privacy goals as well as the mechanisms required to achieve those privacy goals.

When we see clear places where work should and is already happening elsewhere, e.g. the IETF, we will attempt to proactively redirect interested parties to those locations.

Given the wide variety of concepts under the “attribution measurement” area, we anticipate many separate GitHub issues will be needed to hash out the details of different aspects. We’d like to see a Work Item accepted and a dedicated repo get created so we can start these conversations in a more centralized location.

[eriktaubeneck]

Thank you for writing this up @erik-anderson. Just wanted to call out Facebook support for working on this problem, and volunteer myself to contribute to any workgroup in the problem space.

[csharrison]

Ditto for myself and Google. Happy to work on this.

[martinthomson]

I am also supportive of this. This is the most important of the use cases. It's also the least conflicted in the sense that we don't need to engage deeply on the topic of the virtues (or otherwise) of tracking.

[alextcone]

Volunteering to work on this problem as well.

[AramZS]

Noting that the group has chosen to pick up private measurement and the associated proposals as part of its initial focus. This proposal will be considered as part of that process. Accordingly, I am moving this issue to the stand alone repo created to manage that conversation.