Request for help on multiple TAG reviews on measurement APIs

[torgo]

Hi PATCG folks! In the TAG, we're looking at several API reviews such as

• Attribution Reporting API
• IPA
• Private Aggregation API

...and we're also aware of Private Click Measurement which hasn't been submitted for TAG review.

All of these proposals seem to be in the same category of "measuring advertising effectiveness". We're wondering if there's something we can look at that puts these different API proposals in context and compares them? Also, since the members of the TAG are not experts in the advertising domain, we sometimes get stuck on terms of art that we're unfamiliar with or which are used in ways we don't understand. For example, in the review for Protected Audience some terms of art are being used, such as "creative" and "k-anonymity", which are not defined or given adequate references. We're wondering if PATCG might be the right place to create a glossary of these terms?

[npdoty]

Overview and comparison of attribution/measurement proposals would be a helpful deliverable for this CG, to facilitate outside review and to set up the Working Group deliverable more clearly.

On the advertising-related terminology, the Improving Web Advertising Business Group has some documentation that might be useful (and that might generally be a good place for glossary and use-case development):
https://github.com/w3c/web-advertising/blob/main/support_for_advertising_use_cases.md
https://github.com/w3c/web-advertising/blob/main/OnlineAdvertisingParticipants.md

K-anonymity, however, isn't an advertising-specific term, and should just be defined wherever it's used with a reference to either the academic literature or some more accessible overview. PATCG has typically preferred not to rely on k-anonymity as a strong metric of privacy protection, so I don't expect it to be very heavily used here.

[csharrison]

We put this together in the docs-and-reports repo: https://github.com/patcg/docs-and-reports/tree/main/design-dimensions. It doesn't list every difference across the APIs but it tries to list out major ones.

[torgo]

Hi @csharrison it doesn't look like Private Aggregation API is on this list... Can you help clarify this? 🙏🏻

[csharrison]

Hey @torgo , good call-out, I apologize for the oversight. The list I linked is focused on only solutions to the "cross site attribution measurement use-case" where the system joins up events across sites and performs an aggregation / anonymization step. The Private Aggregation API is a little bit different mostly because it is more generic than the other designs. It can plug-and-play in multiple different contexts. Right now there are integrations both within Protected Audiences and Shared Storage.

That being said, it shares an aggregation backend with ARA, so at least from an aggregation perspective they should be more or less compatible. A few key differences between PAA and ARA are:

• The "privacy unit" (the scope in which we limit information transfer) is slightly different in PAA because we don't have a notion of "source" / "destination" sites like we do in ARA / IPA / etc
• Any number of sites' data can impact the aggregation key, whereas in ARA / IPA / PCM every report will embed data from two sites (the source and destination site).
• The API surfaces is different in that Private Aggregation API works with a worklet-style Javascript API, vs. ARA's HTTP header approach

We have some high level documentation explaining differences here, but you're right it might make sense to include this in a broader "cross-site measurement" comparison doc produced by this group.

cc @alexmturner

[torgo]

Thanks - relating to our multiple TAG reviews in this space, the TAG is always concerned with developer complexity - which we've tried to outline in our design principles doc. As we are considering adding one or more of these capabilities to the web platform, can I please encourage the group to consider the application of this principle?

[csharrison]

Yes, it's a good call-out @torgo, thank you. The unfortunate reality is that we are trying to build replacements for extremely mature technology (3PCs) that prop up huge #s of use-cases with barely any platform involvement needed (just placing a <img> tag, etc). Doing this in private manner means that it's difficult to design something similarly simple (from the platform POV) - we need to be intimately aware of the data flows, computations, etc. This presents a challenging trade-off between privacy, the # of supported use-cases, and complexity.

That being said, we have been considering developer complexity as a principle when designing these things: the recent discussion in the PATCG at TPAC explicitly calls out developer ergonomics / complexity in a few of the comparison rows here that we discussed (see "Ease of advertiser adoption").

[torgo]

Hi @csharrison see above comment on our review request for Attribution Reporting API... Has there been any progress on developing a unified approach here? As noted, we're kind of "on hold" on these different advertising reporting APIs due to the multiple proposals being worked on...

[csharrison]

Hey @torgo , there has definitely been some progress (see e.g. discussions around the new proposal from Apple), but in terms of concrete proposals we don't have anything unified yet. The group is still working on it.