-
Notifications
You must be signed in to change notification settings - Fork 216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Aggregated click and display signals #957
Comments
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.
We would like to have those time intervals: 1H, 1 day, 7 day, 1 month/4 weeks, 3 months/90days |
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).The text was updated successfully, but these errors were encountered: