Description
Private Aggregation currently supports a temporary debugging mechanism called debug mode to help developers integrate with the API and debug their usage. However, this mechanism is tied to third-party cookie eligibility and will thus be deprecated along with third-party cookies.
We’re exploring ways to continue supporting this use case. In particular, we aim to allow developers to measure the frequency of certain ‘debug events’ and to split these measurements on relevant developer-specified dimensions (e.g. advertiser or code version). We also aim to support these use cases with minimal or no privacy regressions and for this support to be available after third-party cookie deprecation.
Design idea
One possible design is to introduce a new JavaScript call that allows developers to send a contribution if a browser-defined 'debug event' occurs, e.g.:
privateAggregation.contributeToHistogramOnDebugEvent(
"insufficient-10min-budget", {bucket: 12345n, value: 67n, filteringId: 8n});
Note that this is conceptually quite similar to the contributeToHistogramOnEvent()
method already available as part of the Protected Audience extensions to Private Aggregation.
Debug events
This mechanism could support sending contributions in a range of debug events, e.g. in case of:
- insufficient budget (either 10 min or daily) to send a report
- contributions being dropped due to the per-report limit
- no reporting errors (i.e. a report is successfully scheduled to send)
- a worklet crash
That list is not exhaustive, but it should also be possible to continue to extend the list in future iterations.
Budgeting
To avoid privacy regressions, these contributions would be limited by the usual client-side contribution budget. However, this proposal would require a mechanism to “reserve” some portion of the budget for these debug events. This is necessary to allow for contributions measuring an insufficient-budget event to successfully send.
Aggregating separately
Ad techs may wish to process their debug event histogram contributions separately from other contributions. This would be possible by using a different filtering ID for those contributions. This mechanism would also allow for flexibility in which groups of contributions can be processed together or separately.
Note that this design differs slightly from Attribution Reporting’s earlier aggregate debugging proposal. That proposal sends separate debug and non-debug reports and makes sending a debug report deterministic when debug reporting is enabled. It is difficult to adapt this mechanism to Protected Audience buyers without privacy impacts.