Aggregate reporting from Turtledove

[jonasz]

Hi Michael,

In a couple places (#16, #35) it was mentioned that there will be a mechanism to gather aggregate data from Turtledove auctions. It seems that both Aggregate Reporting and Conversion Measurement with Aggregation proposals would be safe to use in Turtledove, but there is a number of questions that would be great to discuss:

1. When could such aggregate reports be sent - for every bid, or only for winning bids?
2. I'd assume it is the bidding function that will have access to some kind of aggregate reporting API, and will be able to issue custom aggregate report requests. Further questions are based on this assumption, but let me know if you see it differently.
3. What kind of data could be used for aggregate reporting? Can we assume we could derive the aggregate reporting key and value from everything that bidding data accepts? (contextual signals, interest group signals, userSignals (OBTD), recentAdEvents (Browser-side recent advertising events #44))
4. Do you envision some kind of limit on how many such aggregate reports could be requested?
5. Aggregate Reporting API mentions string keys and values, whereas Conversion Measurement with Aggregation works with integer values. Do you think both APIs could be accessible from Turtledove?

These details impact what kinds of models we can design and train effectively, so it would be great if you could share your thoughts, even if you don't have an exact design in mind yet.

As a side note, there may be other interesting implications to these design choices. If we assume flexible reporting is available, Turtledove API may be used for the explicit purpose of gathering cross-site aggregate information for collaborating sites, for example "what percent of an advertiser's visitors also visit some chosen publisher". Another example would be the lookalike audience targeting use case (described in @benjaminsavage's proposal). Depending on the exact details (what data can we use for reports, whether numeric values are supported, ...) this use case could be supported to varying degrees.

Best regards,
Jonasz

[michaelkleber]

1. When could such aggregate reports be sent - for every bid, or only for winning bids?
2. I'd assume it is the bidding function that will have access to some kind of aggregate reporting API...

Yes, all bidding functions should be able to send aggregate reports.

3. What kind of data could be used for aggregate reporting? Can we assume we could derive the aggregate reporting key and value from everything that bidding data accepts?...

Yes, that seems right to me.

4. Do you envision some kind of limit on how many such aggregate reports could be requested?

The privacy properties of aggregate reporting do need some sort of limit. For example, it might turn out that the more reports you send about the same auction, the more noise each one would be subject to, so that the total amount of information you reveal ends up staying the same. @csharrison FYI.

5. Aggregate Reporting API mentions string keys and values, whereas Conversion Measurement with Aggregation works with integer values. Do you think both APIs could be accessible from Turtledove?

The Conversion Measurement API is the more developed of these proposals, and the Aggregate Reporting API's string-concatenation approach was only introduced to handle its unusual blind-append semantics. So I would expect numerical reporting here. But if there's some use case that you think can't be adequately supported with that limit, please do open an issue (probably on the Conversion Measurement API repo) and let's discuss it.

[JensenPaul]

Closing this issue as it represents past design discussion that predates more recent proposals. I believe some of this feedback was incorporated into the Private Aggregation proposal. If you feel further discussion is needed, please feel free to reopen this issue or file a new issue.