We propose to create the ability of having some event level signals for bidding and reporting. The signals proposed here describe the interaction between the user and the advertiser and don’t aim for identifying the users uniquely. It would be very beneficial to advertiser performance to have these additional event-level signals in generateBid and reportWin. We propose to have a set of browser provided signals and a set of ad-tech provided signals.

In the long-term, one could envision a system where these signals are used in generateBid per query but reported through Aggregate Attribution Reporting API. However, given the challenges there (e.g. issues/289, the latency of receiving aggregate data, and the need to reconstruct bid/cost at event level) we propose to have them in event level reporting in the short-term for the first versions of the Fledge framework.

Browser Provided

1. Recency - How long ago was a user last added to the userlist.
2. Join Count - How many times a user has been added to a userlist (this is currently available in generateBid, but not reportWin).

These signals could be stored and updated by the browser at interestGroup registration time. Then, they could be provided to generateBid as part of browserSignals for bidding optimization. Finally, by providing these signals to reportWin, they could be used for training ML models.

For both of these signals bucketed values would suffice and some noise could be added.

Ad-tech Provided

There are additional signals we would like to include which would be difficult for the browser to provide as it won’t have easy access to non-FLEDGE ad placements. These signals capture top features of the user interaction with the advertiser (e.g. data on previous conversions/clicks that the user had with this advertiser). This information is available from the 1P data that the advertiser knows about the user. Then, these signals can be passed into bidding as part of the interestGroup, possibly as part of userBiddingSignals or as a new field. The browser could then make these signals available in some form to reportWin to enable ML model training.

There are a couple ways we imagine that Chrome could enable these signals in reporting while controlling their information content and limiting the privacy impact:

1. Chrome could provide a set of bits that ad-tech could fill. This could be 10-15 bits that Chrome could add noise to as well.
2. Chrome could provide a set of few ordered enums with the assumption that some noise would be added.
3. Chrome could enable a set of few numerical values (e.g. between 0 and 1) which would have Laplace noise added to them.