Versioning of aggregatable reports

[adhir111]

how to maintain versioning of aggregatable reports , if any keyset changes or some become obsolete , we will need versioning to filter or choose right domain files otherwise extra noise will be introduced against the changed keysets by aggregation service

[maybellineboon]

Hi @adhir111 ,

Can you confirm which API you're using for reporting? Are you using Attribution Reporting API or Private Aggregation API?

Thanks!

[adhir111]

We are using both Attribution Reporting API and Private Aggregation API
@maybellineboon

[maybellineboon]

Hi @adhir111 ,

For Attribution Reporting API, for now, you can use context_id provided you do not use source_registration_time to perform some sort of versioning. The context_id will contain which version of keys you are using for the specific advertiser. So that when you perform batching, you will get a gauge of which version of keys should be included in the batch. Take into account the batching guidance for batching reports in aggregation service. If your batch will include both version of keys, you will need to include both version of keys in the domain file.

For Private Aggregation, you can use both context_id and assigning a bit in the key to perform key versioning. For context_id, you can use it the same way as Attribution Reporting API where you will use the context_id to identify which version of key is used for the report and include the keys required for all the context_id included in the batch.

Additionally, we're coming up with a feature called flexible filtering where you can specify the version in the filtering_id.

One caveat to highlight, if you're using both version of keys in the same reporting window, because the keys are different, the summary report will aggregate both keys and add noise to it. When you're merging the values, you might end up adding the noise as well.