Clarification on ReportLoss() design

[Elena6918]

The Github main document says advertisers can implement a reportLoss() function to learn about auction results with the support of PrivateAggregation API. What's the current status of this design? What information will be passed in the reportLoss() function?

[JensenPaul]

Loss reporting is supported today in a couple different ways:

1. The Private Aggregation API can be used to queue up aggregate reports that are only sent when a bid loses, by calling privateAggregation.contributeToHistogramOnEvent(“reserved.loss”, ...) from generateBid().
2. For now, as a temporary mechanism, event-level loss reporting is supported by calling forDebuggingOnly.reportAdAuctionLoss(...) from generateBid().

Closing this issue as I think I've answered your clarification question. Feel free to reopen or file another issue if you have further questions.

[Elena6918]

Thanks for your clarification. I'm still confused about how to differentiate reasons an ad did not win. My understanding is that the losing buyer will query all buckets value with possible losing reasons after batching the encrypted reports. However, the aggregation service will output 0+noise if the bucket value is not present in the contribution.

For example, if the losing reason is "invalid bid" and a contribution is generated as:

bucket: 502n // 500n + 2n (2n is the value associated with bids below the auction floor, see bid-reject-reason below)
value: 1

When the buyer query with a bucket key list [500, 501, 502, 503], the output would be four histograms with values 0+noise, 0+noise, 1+noise, and 0+noise. In this case, how can the buyer tell 502 is the actual bucket on the report?

[michaelkleber]

With aggregate reporting using privateAggregation.contributeToHistogramOnEvent(“reserved.loss”, ...) technique, you're quite right: you cannot tell what happened in any single report, because there is too much noise added to histograms. The intended use of private aggregation in general is to collect a lot of reports and aggregate them together, to learn things across many browsers instead of learning about a single user.

[Elena6918]

Is there a way to tell from the encrypted report which scenario triggers the report (i.e. winning or losing)?
Does the contribution budget of 
 $l_1$ bound across all PA APIs, such as privateAggregation.contributeToHistogramOnEvent(“reserved.loss/win/always”, ...) and privateAggregation.contributeToHistogram() in reportWin()?
If not, it seems that the buyer needs to batch multiple days of reports (even with 30-day reports where a site's losing reason all contribute to bucket 502n, it's still not likely that the value of bucket 502n is large enough to differentiate with other buckets such as 503n where the output is 0+noise) and queries with a fairly long list of bucket keys.

[michaelkleber]

You can see more info about aggregatable histogram contributions here. The report context will be "api":"protected-audience" for both winning and losing reports, so you should use different buckets for winning vs losing outcomes for cases where distinguishing them is important. The reports will all draw on the same contribution budget, which is a rolling time window per reporting site; see more details here.

How readily you can distinguish a zero vs nonzero bucket in your aggregate histogram depends on your chosen value for epsilon and on how much budget you allocate to that bucket. In particular, using value: 1 is appropriate if your goal is to aggregate over a lot of people, while value: 65536 puts all of your budget for this time window into a single measurement, in a way that makes it possible to see a signal with many fewer events. Check out our developer documentation for Noise Lab for much more on this and related topics!

[Elena6918]

Thanks for your clarification! When Protected Audience API is deployed, can buyers choose their own epsilon value? Or will it be a fixed value that is enforced by the aggregation service?

[michaelkleber]

The Aggregation Service's initial experiment plans are:

• Our initial experiment will support a range of epsilon values for testing, up to epsilon=64. This allows adtechs to experiment with different aggregation strategies and provide feedback on the utility of the system, with different privacy parameters.

And there is an issue soliciting that kind of feedback at WICG/attribution-reporting-api#485.