cc @hostirosti @ruclohani for visibility.

Thanks for filing, @alois-bissuel . I agree a more flexible way of consuming privacy budget should help satisfy the use case. Between use-case (1) and (2) you mention, do you expect the keys to be similar or will e.g. (2) query finer grained slices?

Hello,
+1 for the hourly and daily use case request

It would be super useful for us if it would be possible to increase the limit from 1 to 2. i.e. that the same aggregatable report could appear in two batches and hence contribute to two summary report.
This is crucial for our clients for two main reasons:

1. Facilitate our hourly->daily (or possibly daily->weekly if SNR is too low) pulls strategy, which will enable our clients to get noiser data first, and data with improved SNR later
2. Fault-tolerance: in case an internal issue happens on our side on the hourly request and we lost the aggregation service response, we would be able to fallback to the daily response (and vice versa)

For our use case, we expect the keys to be similar.

Hi,
@alois-bissuel thanks for bringing this up. We have similar cases and addressing them seems very valuable, especially from an operational point of view.
At first glance, the second solution (dividing 128 bits into several buckets) seems to be better.

@alois-bissuel quick clarification, you said:

Both methods have their pros and cons, the latter being more precise (as one doesn't burn some of my budget for the two use cases at the same time)

Is this true? If we split the key space into a few sections and allowed you to query those sections independently, you still need to allocate separate budget across those key spaces, just in the form of the client's L1 contribution bound rather than an epsilon.

Is this because the two use-cases will actually have different data / keys, and so querying the "high latency / detailed" key space during a low latency query is wasteful?

Catching up on my issues, sorry for the delay:

Thanks for filing, @alois-bissuel . I agree a more flexible way of consuming privacy budget should help satisfy the use case. Between use-case (1) and (2) you mention, do you expect the keys to be similar or will e.g. (2) query finer grained slices?

As there will be less data available for use-case (1) (ie the fast-pace aggregation case), I expect us to encode less things in the key to have more data aggregated per key.

Both methods have their pros and cons, the latter being more precise (as one doesn't burn some of my budget for the two use cases at the same time)

Is this true? If we split the key space into a few sections and allowed you to query those sections independently, you still need to allocate separate budget across those key spaces, just in the form of the client's L1 contribution bound rather than an epsilon.

Indeed, I was not clear there. I was thinking of separate encoding for both use case and thus a finer budget tracking. Of course the L1 budget still applies. I guess that my first proposal (ie allocating an epsilon budget per pass) rules out a different encoding per use case, hence my remark (and your final comment).

FYI, the Aggregation Service team is currently looking into supporting requerying, which could help with this use case. If you're interested, please take a look at privacysandbox/aggregation-service#71.

Hi,
To help reduce latency in aggregation jobs, the Aggregation Service team is considering introducing the ability to cache the aggregated contributions from aggregatable reports and enable it to be used in subsequent multiple aggregation jobs. Please take a look at our proposal and let us know what you think.