michaelkleber
commented
3 years ago You mention report_result() but not report_win(), so I guess you're thinking about seller reporting, not buyer reporting? Or does this apply to both?
In 5.1 Seller reporting I mentioned the highest bid and the second-highest bid, and in Section 5.2 Buyer reporting I mentioned each buyer additionally seeing "the second-highest bid from that particular buyer". That's not far from what you just asked, though not exactly the same. Any of these signals seem reasonable to make available, we just need to nail down what consumers of the data really want.
During the temporary event-level reporting phase, though, the specific signal "the highest losing remarketing bid from the buyer that is not the winner" does immediately give away the answer to the question "Is this specific person in any interest group of any other buyer?" That seems like more information than I'd like to give out.
Could these non-winning-bid signals be only available probabilistically? Like, could we omit them half the time, even if there were other bids?
(If you want them for something like training ML models or monitoring auction pressure, I'd expect that to be enough. If you need them for something like billing, then that's a different story.)
In the FLEDGE proposal, seller’s JS will provide a report_result() function which takes as input browser_signals that captures the auction result and reports the winner event. Since the browser is responsible for running the auction ranking based on scores provided by the seller’s JS, the browser acts as a gatekeeper regarding what auction related signals are sent to report_result(). We want to confirm whether the browser will determine the winning candidate, the highest losing remarketing bid from the buyer that is not the winner and the highest losing remarketing bid from the winning buyer, and whether the information about all of these can be incorporated into browser_signals and sent to report_result() thereby enabling it to generate the auction winner event.