Support for aggregation over a set of keys
Closed this issue · 4 comments
Hello,
Currently, the aggregation service does a sum of the values on the set of keys which is declared in the output domain files. This explicit declaration of keys mean that the encoding must be well-done at report creation time (eg on the source and trigger side for ARA or in Shared Storage for Private Aggregation API). This is quite inflexible in its use.
To bring in some flexibility, I propose to add a system to the aggregation service where a predeclared set of keys would be summed by the aggregation service. This set of keys would constitute a partition of the key space for the service not to violate the DP limit. A simple check done by the aggregation service could reject the query if a key is in two sets.
Here is what the output domain file would look like. I am not sure "super bucket" is a great name, but this is the only I could think of right now.
| Super bucket | Bucket |
|---|---|
| 0x123 | 0x456 |
| 0x123 | 0x789 |
| 0x124 | 0xaef |
| 0x125 | 0x12e |
The aggregation service would provide the output only on the "super buckets".
The operational benefits of this added flexibility would be huge. Currently, one has to decide on an encoding before knowing what one can measure. For ARA or PAA for Fledge, this means having a very good idea before hand of the size and the performance of the campaign. When the campaign is running, then adjustment have to be made if the volume estimate was not good (or if the settings of the campaign are changed). Encoding change can be difficult to track, especially in ARA where sources and triggers both contribute to the keys, but at different point in time. This proposal allows to have a fixed encoding, and adjust after the fact (using the volume of reports as a proxy) the encoding actually used.
Hi @alois-bissuel
Thanks for the feedback. I think this is very similar to your feedback in WICG/attribution-reporting-api#470 (and previously #1 ). But wanted to confirm before marking as duplicate. Let us know.
Thanks.
Indeed, this is a duplicate of WICG/attribution-reporting-api#470, albeit a little bit more detailed. Feel free to keep the one in the most relevant repo.
Thanks @alois-bissuel. We'll keep WICG/attribution-reporting-api#470 as the primary issue to track this, and close this issue.
Closing as duplicate of WICG/attribution-reporting-api#470