Add new reporting signal script-errors

[fhoering]

The explainer of the private Aggregation API allows to retrieve latency signals of buyer/seller scripts:

• script-run-time: milliseconds of CPU time that the calling function required, when called.

• signals-fetch-time: milliseconds required to fetch the trusted bidding or scoring signals, when called from generateBid() or scoreAd() respectively

One signal that is missing is the number of client side errors that occurred inside computeBid, reportResult and reportWin functions.

Today one can pass some technical information of what happened inside the scripts to forDebuggingOnly.reportAdAuctionWin() or forDebuggingOnly.reportAdAuctionLoss() functions. However this requires that the buyer actual participates in the auction. In computeBid the buyer could decide based on some targeting filter that he doesn't want to bid at all. If a Javascript error happens in there it means no feedback will ever be given that the script failed and it might be a missed opportunity for the buyer.

While this is not an issue if it fails for every auction, because in this case the buyer would just see that he doesn’t participate in any auction anymore, it could be more complicated in some edge case where the buyer will just notice some decrease of the participation rate and doesn’t know why it happens.

We propose to add an additional signal script-errors that would allow to retrieve the number of client side errors per interest group owner and per computeBid or reportWin/reportResult.

[JensenPaul]

If a Javascript error happens in there it means no feedback will ever be given that the script failed and it might be a missed opportunity for the buyer.

I agree we could improve the reporting capabilities in this area. One possible was is an extension I touched on here. I wanted to mention a couple ways this could be reported with today's reporting APIs:

With privateAggregation.contributeToHistogram(), you can compare the bidStart and bidEnd counts:

privateAggregation.contributeToHistogram({ bucket: bidStart, value: 1 });
// run JavaScript code that could throw exception here.
privateAggregation.contributeToHistogram({ bucket: bidEnd, value: 1 });

With forDebuggingOnly.reportAdAuctionLoss(), you can get a "there-was-an-error" signal when an exception is thrown:

forDebuggingOnly.reportAdAuctionLoss("https://example-dsp.com/there-was-an-error");
// run JavaScript code that could throw exception here.
forDebuggingOnly.reportAdAuctionLoss("https://example-dsp.com/there-was-no-error");

Note that reportAdAuctionLoss() replaces the reporting URL with additional calls. The "there-was-no-error" URL could be replaced with something that doesn't actually result in a network fetch (until https://crbug.com/1442912 is fixed it'll have to be something ugly like https://localhost).

[morlovich]

An easy route may be to have more reject-reasons. We already fill some in automatically for currency errors, so it shouldn't be too hard to do it for some other kinds of errors.

[fhoering]

@michaelkleber @JensenPaul @morlovich It has been discussed in the WICG call from 17/01/2024 that we could use the Priv Agg API to track down the share of errors and then use down sampled forDebuggingOnly to get more signals on one error.

We would need more triggers in the Private Aggregation API to be able to extract exceptions for example. currently we do what has been advised here:

generateBid(interestGroup, auctionSignals, perBuyerSignals,
    trustedBiddingSignals, browserSignals, directFromSellerSignals) {
   try {
   }
   catch()  {
       globalThis.forDebuggingOnly.reportAdAuctionLoss(url_with_debug_infos);
   }
}

Linked to ticket #632

[fhoering]

Another point on using Private Aggregation API for real time monitoring.

It seems like the timeframe granularity when a report could be received would be 1h which seems too long for real time monitoring:
https://github.com/patcg-individual-drafts/private-aggregation-api#metadata-readable-by-the-reporting-origin
https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATION_SERVICE_TEE.md#disjoint-batches