Provide an explainer

[jwrosewell]

The TAG design review request for this specification (w3ctag/design-reviews#1229) has no explainer, and the README says the explanation can be found up front in the specification itself.

Wide review is now under way (#425) and invites readers from outside the Working Group. Many of them work in advertising, measurement, policy or law rather than browser engineering. For those readers the specification is unwieldy, and the words it relies on carry different meanings in their fields. Martin Thomson, one of the six editors, described discovering exactly this in a recent public discussion (archived copy) with Alan Chapell. The word attribution meant something different to his readers than it did to him.

An explainer would give every reviewer a common starting point. The following contents would serve wide review best.

• The problem being solved and for whom.
• What the API does and does not do. For example, it reports associations between impressions and conversions, and experiments remain necessary
  to measure causal effect (Limitations section #441).
• The terms it relies on and what they mean here, starting with attribution itself.
• The parties involved and what each one can see, websites, intermediaries, browsers and aggregation services.
• The alternatives that were considered and the reasons this design was chosen.
• Known limitations.

Some of this information also belongs with the review request itself. The TAG's request template has fields for previous reviews, for major unresolved issues or opposition, and for the alternatives considered. In the filed request the first is answered "N/A", although the TAG reviewed the predecessor proposals IPA (w3ctag/design-reviews#823) and the Attribution Reporting API (w3ctag/design-reviews#724), and the other two are unanswered. Whether this information sits in the explainer or in the review request documents, reviewers arrive better informed with it than without it.

The following material is already public and would help any reviewer, whether referenced from the explainer, the review request or both.

• The concerns the UK Competition and Markets Authority recorded against the Attribution Reporting API, this specification's predecessor, in its
  reports between 2022 and 2025. Its Q1 2024 update report records concerns that coarser measurement "may make it harder for publishers to value their ad inventory" and that dependence on browser APIs for measurement "raises concerns about the ability to audit and verify results". Its summary of testing found publisher revenue per impression around 30 per cent lower without third-party cookies even with the Privacy Sandbox tools available.
• Movement for an Open Web's analysis, What does AI Think of the W3C's Attribution Specification?, 17 December 2025. MOW is a not-for-profit which I direct.
• The objection in Retire the proposal due to breach of W3C antitrust guidelines #388, filed 4 March 2026.
• The methodological thread opened by Rick Bruner on the Working Group's mailing list, 26 May 2026.
• Don Marti's issues Canary domain #448, WebExtensions section #449 and GPP integration #450, 8 June 2026, together with his articles.
  • Why no simulated attribution cartel reports?
  • Arguments for the attribution cartel
  • Attribution tracking on an alternate timeline
  • Explaining why the attribution cartel is a privacy menace (almost)
  • What happens when the attribution cartel meets advertising's halo effect(AdExchanger)

A first draft could be produced quickly from the specification and the group's discussions.

[bkardell]

Speaking only for myself: While there is a lot more above that I am not commenting on, I can agree with the simple note that I personally believe an explainer would be generally helpful. This isn't a requirement of the process and members disagree. However, based on some suggestions made in recent discussions among membership on this topic about the value of explainers, vs in-spec intro text - I used Claude to try to generate a starting point: https://gist.github.com/bkardell/495b7d717b6e25867c1015815c0c29c1 maybe if someone is willing they could proof and improve it.

[AramZS]

We will discuss the idea of an explainer, not the wide variety of topics that are far out of bounds of the request for what this group would produce, which is a technical explainer. @bkardell thank you for your suggestion.

[AramZS]

As a quick follow-up note: where this group has closed a discussion issue as resolved we will not be following up on it since we have resolved that in the issue.