FYI: Flexible Contribution Filtering Launching in M128

27 views
Skip to first unread message

Akash Nadan

unread,
Jul 12, 2024, 4:08:14 PM (4 days ago) Jul 12
to Attribution Reporting API announcements

Hi All,


Starting in M128, developers using the Attribution Reporting API will be able to optionally specify a “filtering ID” per aggregatable value when performing a trigger registration. Filtering IDs allow for aggregation service queries to be split by a developer-specified dimension. This provides more flexibility, e.g. to process some measurements at different cadences to others. Further detail is available in the explainer.


This change will apply to all users on Canary versions released after Thursday 18 July 2024 and will roll out to the other channels (Dev, Beta and Stable) in their future M128 releases. M128 Stable is planned to be released in August 2024.


To use the new filtering ID feature, you will need to upgrade your Aggregation Service release to version 2.5 or later. After this change, starting in M128+ from July 18, all reports’ version field will use the updated value of "1.0" (instead of "0.1"), even if filtering IDs are not specified. Guidance for older versions is provided below:

  • If you are using version 2.4, the new report version is supported but the filtering ID feature is not supported. Ad techs intending to use filtering IDs should update to version 2.5 so that reports are processed correctly.   

  • If you are using Aggregation Service release 2.3, you should filter out reports with the new version number before each aggregation to avoid job failures.

    • Note: Aggregation Service release 2.3 does not support the new report form and will reach end-of-support on August 2nd i.e. before M128 reaches Stable. All previous releases (2.2 and before) have already reached end-of-support and can no longer be used.


If you process the "debug_cleartext_payload" field, please note that the payload format will slightly change in this new version. Each contribution will have a new "id" entry containing the filtering ID encoded as a big-endian bytestring (alongside the existing "bucket" and "value" entries).


If you have any questions or comments, reply to this post or open an issue in the Privacy Sandbox Dev Support repository on GitHub.


Thanks,

Akash


Reply all
Reply to author
Forward
0 new messages