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 via prevWins. 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 maps prevWins 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 for paPrevWins. igPrevWins would contain all displays & clicks at interest group level. paPrevWins will contain all displays & clicks at Protected Audience level.

function aggregatedIGWins(igPrevWins) {
  // compute aggregated numbers at interest group level
  return aggIgPrevWins;
}
function aggregatedPAWins(paPrevWins) {
  // compute aggregated numbers at Protected Audience level
  return aggPaPrevWins
}

The integers aggIgPrevWins and aggPaPrevWins would be made available in generateBid, reportWin and the key/value server. The existing field browserSignals.prevWins in generateBid 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 modelingSignals

For 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% of reportWin() 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).