Rapid Aggregation Proposal

[appascoe]

Use Case

Accurate campaign pacing is a common concern for the Aggregate Reporting API. As stated during the W3C web-adv working group, we've observed that a delay of 24 hours in feedback can result in a decline of ~10-11% spend on publishers in our experimental group, and that also includes overspend safety mechanisms, which do not appear readily available for implementation under the Aggregate Reporting API proposal.

Perhaps this delay of 24 hours can be adjusted to aid in this, but this is a complementary proposal that may also help.

Proposal

The fundamental issue is maintaining some level of differential privacy before reporting. For more sophisticated reporting, we of course want to be able to do things such as:

const entryHandle = window.writeOnlyReport.get('campaign-123');
entryHandle.set('country', 'usa');
entryHandle.append(“visits”, “1”);
...
// any number of other dimensions of interest

But most of these data are not particularly relevant for pacing considerations. I propose a more limited API call:

const entryHandle = window.writeOnlyRapidReport.get('campaign-123');
// only cost/spend entries permitted

From here, the report could be subjected to a much, much shorter delay as differential privacy is likely to be achieved that much sooner. Additionally, because the data aggregates more quickly, we could use less noise/quantization in the reporting to help pace more accurately (or, conversely, if we wanted to increase the speed of reporting back, the noise could be increased). Perhaps it's worthwhile considering an explicit API function for incrementing cost values to enforce it's the only mechanism to write things into this rapid report.

Essentially, I'm arguing that there are two distinct purposes for reporting:

• Collecting an array of information to provide insights into how often, where, etc. ads are displayed, so advertisers can make tuning adjustments.
• Dynamically pacing campaigns to keep performance in check, avoid critical overspend failures, and also to observe underspend issues (which may be due to configuration issues).

Given these distinct use cases, I think it makes sense to have separate API calls that reflect them.

[csharrison]

Hey Andrew, thanks for the feedback. I definitely think a lot of this proposal is stale in light of the recent work on the aggregation service design: https://github.com/WICG/conversion-measurement-api/blob/master/SERVICE.md

You could definitely imagine a new API integrating with the aggregation service that has shorter delays. I don't necessarily think reducing the information in the report is even necessary, since it should be on the caller to create groups large enough that the output is not drowned out by noise.

I agree that there are potentially some classes of reports that prefer to get data sooner for pacing reasons.

[dmarti]

Another possible use case for this proposal is QA. A variety of things could break in production, some of which could be hard to detect in advance.

• Site has an error in a deploy
• A new release of a third-party script (not tested by the site) causes an error in combination with the site's own code
• A new browser release has a bug that affects only a few sites

Site administrators need to be able to check their reported metrics with minimal delays to be able to roll back broken versions or to detect problems and deploy workarounds.