Aggregated click and display signals

[fhoering]

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).

[leeronisrael]

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:

• We’ve received feedback that it’d be helpful to include views and clicks from ads that occur outside of PA auctions. We included a mechanism for adtechs to register those events with the browser.
• We prefer not to add another computation required prior to the auction (i.e., aggregatedPrevWins function), due to latency and technical complexity reasons
• We prefer to make accessible a more limited signal, rather than providing the full event level view and click information (i.e., paPrevWins) for privacy reasons

These points considered, here is our latest proposal:

1. Eligible view and click events are identified via an HTML attribute or JS (e.g., <img src="..." registerClick="https://dsp.example"... >) and by default for Fenced Frame reporting (automatic click beacons, reportEvent)
2. Views and clicks are registered by returning a new HTTP response header on requests which are eligible (e.g., “Click-Count” or “View-Count”)
3. The response header parameter accepts some number of origins that can access the information in their bidding worklets
4. Buyer's Interest Group object declares up to 3 lookback window durations, and which domains' impression and click counts it would like to know.
5. At bidding time, browser counts the views and clicks for the buyer-defined time intervals
6. Each buyer’s generateBid() receives their view and click counts in its arguments (e.g, browserSignals)

There are some open questions we still need to answer:

• 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 welcome feedback on this proposal.

[fhoering]

@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