Open fhoering opened 8 months ago
For those of you who don’t know me, my name is Leeron and I’m a Product Manager working on Topics API and Protected Audience API. 👋
Appreciate the thoughtful proposal, Fabian. We are evaluating a slightly different proposed design, based on a few points:
These points considered, here is our latest proposal:
There are some open questions we still need to answer:
We welcome feedback on this proposal.
@leeronisrael Thanks for the update on this.
Earlier we considered allowing callers to set a time interval in ms. This open-ended configuration has privacy risks. A better solution is for the browser to offer a fixed set of lookback time intervals. What time interval options should the browser offer?
We would like to have those time intervals: 1H, 1 day, 7 day, 1 month/4 weeks, 3 months/90days
As we're optimizing our auction logic, we realize that for proper bidding, so this feature is very important for us as well.
Summary
Historic displays and clicks of a user are one of the most important signals to optimize the performance of Protected Audience campaigns. Those signals bring value if they are available on both, same interest group scope and cross interest group scope. We propose a function that aggregates display & click signals, which signals would be then propagated to the bidding logic, the key/value server call and the reportWin call.
Design
Today,
browserSignals
already contains previous displays made to this user on this interest group viaprevWins
. First,prevWins
would be enriched with a boolean when one of these displays has been clicked (discussed in WICG meeting here). Second, it would be also enriched with previous displays and clicks from Protected Audience level (cross interest group, same owner).Chrome would call an additional function
aggregatedPrevWins
in the bidding script that mapsprevWins
to an 8 bit number. For privacy reasons we would understand if this number is different between interest group (IG) and Protected Audience (PA) levels (6 bits for IG level, for example 2 bits for PA level).Here is an example where we use 2 functions, for example 6 bits for
igPrevWins
, 2 bits forpaPrevWins
.igPrevWins
would contain all displays & clicks at interest group level.paPrevWins
will contain all displays & clicks at Protected Audience level.The integers
aggIgPrevWins
andaggPaPrevWins
would be made available ingenerateBid
,reportWin
and the key/value server. The existing fieldbrowserSignals.prevWins
ingenerateBid
could stay the same.We propose to add this as a new field in addition to
modelingSignals
and that can only encode display and click information. It seems more isolated and distinct from advertiser user data that can be passed in modelingSignalsFor privacy reasons the noising schema could be similar as today for
modelingSignals
. As only 8 bit instead of 12 bit would be used here we could add less noise than the 1% for modeling signals. A randomly-selected 0.1% ofreportWin()
calls, a uniformly-generated random value in the range of the field's bucketing scheme is returned instead of the true value.Chrome could add some configuration option for the update frequency of the aggregated fields
aggIgPrevWins
&aggPaPrevWins
(instant, every 10 seconds, every 10 minutes, every hour) because it could allow tuning utility (most up to date is best) vs the ability to do HTTP caching on key/value server calls (a stable value is best).