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

[eysegal]

As we're optimizing our auction logic, we realize that for proper bidding, so this feature is very important for us as well.

[jeremybaoty]

Hi folks,

This is Jeremy, PM on the Protected Audience API, taking over Leeron’s original work.

I want to provide an update here. Firstly, we are working to support clickiness signals, which is the propensity of a user to interact with ads. Here is our latest proposal - most of Leeron’s original proposal still holds true, with a few tweaks and details.

Part 1: Register views and clicks

1. Eligible view and click events would be identified via an HTML or JavaScript attribute called “attributionsrc”, the value of which is typically an advertiser or ad-tech provider endpoint. This integration is the same as what’s already used for Attribution Reporting API (ARA), so that adtechs wouldn't need to duplicate these integrations for clickiness.
2. Views and clicks would be registered by returning a new HTTP response header to requests initiated by the “attirbutionsrc” attribute which are eligible. The request and response headers would be unique for clickiness (i.e. distinct from ARA).
3. This response header would include a list of origins that can be used to indicate which other parties can include these views and clicks in their aggregated counts.

Part 2: Take view and click signals into PA bids

1. In the interest group definition, buyers can identify the list of providing origins from whom view and click events should be included in their aggregated counts. Without this list, the browser would default to only including those views and clicks that were registered by the interest group owner’s origin.
2. At auction time, the browser would sum the view and click counts for this user over the following lookback time windows:
   1. Past hour
   2. Past 24 hours
   3. Past 7 days
   4. Past 30 days
   5. Past 90 days (if the maximum interest group lifetime is beyond 30 days)
3. For interest groups that specified a list of providing origins, the corresponding generateBid() call would receive those aggregated view and click counts as part of the browserSignals arguments.

Part 3: Lifespan of view and click data

1. View and click data will automatically be deleted after the maximum interest group lifetime.
2. If a user turns off “site-suggested ads” (user-facing name for Protected Audience API) or blocks any site in “site-suggested ads”, all view and click data for that user will be deleted.

Let me know if you have any questions or comments about this proposal. Thanks a lot!

[fhoering]

@jeremybaoty Thanks for this proposal. It will be very valuable.

Eligible view and click events would be identified via an HTML or JavaScript attribute called “attributionsrc”, the value of which is typically an advertiser or ad-tech provider endpoint. This integration is the same as what’s already used for Attribution Reporting API (ARA), so that adtechs wouldn't need to duplicate these integrations for clickiness.

It would likely not be aligned with FF reporting events as they have their own firing mechanisms compared to img & script tags. Can you clarify how this could work in a consistent way ?

View and click data will automatically be deleted after the maximum interest group lifetime.

What about IG that are re-created all the time and therefore extend their lifeftime ? Will the counters be erased or not ? ideally they would not.

[kodaikureishi]

@jeremybaoty
Thank you for this proposal.

I would like to verify whether the click and view data from other interest groups can be utilized in PA bids.
In Fledge, only the previous wins from the registered interest group are available.
However, it appears that this proposal allows for the use of previous clicks and views from other interest groups.

The available information in FLEDGE is as follows.

{ 'topWindowHostname': 'www.example-publisher.com',
  'seller': 'https://www.example-ssp.com',
  'topLevelSeller': 'https://www.another-ssp.com',
  'requestedSize': {'width': '100sw', 'height': '200px'}, /* if specified in auction config */
  'joinCount': 3,
  'recency': 3600000,
  'bidCount': 17,
  'prevWinsMs': [[timeDeltaMs1,ad1],[timeDeltaMs2,ad2],...], /* List of this interest group's previous wins. */
      /* Each element is milliseconds since win and the entry from the interest group's 'ads' list
         corresponding to the ad that won though with only the 'renderURL' and 'metadata' fields. */
  'wasmHelper': ..., /* a WebAssembly.Module object based on interest group's biddingWasmHelperURL */
  'dataVersion': 1, /* Data-Version value from the trusted bidding signals server's response(s) */
  'adComponentsLimit': 40, /* Maximum number of ad components generateBid() may return */
  'multiBidLimit': 5, /* If set, maximum number of bids that can be returned at once;
                         see perBuyerMultiBidLimits */
}

[jeremybaoty]

Hi @fhoering, sorry for the delayed responses.

It would likely not be aligned with FF reporting events as they have their own firing mechanisms compared to img & script tags. Can you clarify how this could work in a consistent way ?

Firstly, thanks for sharing the feedback! Today, we do not support automatically updating browser signals (like the clickiness proposal) based on FFAR events like clicks happening. However, we do understand the needs you have previously communicated to our product team, and see value in supporting FFAR events for clickiness. We are currently in the process of evaluating this request against other current priorities and don’t yet have a timeline for support but hope to communicate one soon as we complete planning for 2025.

What about IG that are re-created all the time and therefore extend their lifeftime ? Will the counters be erased or not ? ideally they would not.

We’re assuming by “counters” you are referring to the registered amount of views and clicks associated with an existing IG. Let us know if that is incorrect.

The number of views and clicks reported are on a per-user basis, and are not tied to interest groups. There is also no way to extend the lifetime of view and click events past the longest possible lifetime of an interest group. We set the lifetime of these events to be the same as the maximum interest group lifespan, but this doesn’t mean that these events can have their lifetime extended like interest groups can.

In addition, as mentioned in the proposal, the lookback time windows are fixed and the longest one is 90 days. This means there is no way to check view and click data older than 90 days.

[jeremybaoty]

@jeremybaoty Thank you for this proposal.

I would like to verify whether the click and view data from other interest groups can be utilized in PA bids. In Fledge, only the previous wins from the registered interest group are available. However, it appears that this proposal allows for the use of previous clicks and views from other interest groups.

The available information in FLEDGE is as follows.

{ 'topWindowHostname': 'www.example-publisher.com',
  'seller': 'https://www.example-ssp.com',
  'topLevelSeller': 'https://www.another-ssp.com',
  'requestedSize': {'width': '100sw', 'height': '200px'}, /* if specified in auction config */
  'joinCount': 3,
  'recency': 3600000,
  'bidCount': 17,
  'prevWinsMs': [[timeDeltaMs1,ad1],[timeDeltaMs2,ad2],...], /* List of this interest group's previous wins. */
      /* Each element is milliseconds since win and the entry from the interest group's 'ads' list
         corresponding to the ad that won though with only the 'renderURL' and 'metadata' fields. */
  'wasmHelper': ..., /* a WebAssembly.Module object based on interest group's biddingWasmHelperURL */
  'dataVersion': 1, /* Data-Version value from the trusted bidding signals server's response(s) */
  'adComponentsLimit': 40, /* Maximum number of ad components generateBid() may return */
  'multiBidLimit': 5, /* If set, maximum number of bids that can be returned at once;
                         see perBuyerMultiBidLimits */
}

Hi @kkodai,

Clickiness signals indicate a user's propensity to interact with ads in general, and this is an important feature in a lot of bidding models today. In this clickiness feature, we allow adtechs to record view and click events of a certain user and use aggregated counts of these events as inputs in the PA generateBid() process - one way to use it is to calculate the click-through rate of a user through this and let generateBid() take that into account.

This is to say - clickiness is user specific, not IG/ad specific - it records a users' propensity to view/click ads as a whole, instead of view/click a specific ad from a specific domain. On the other hand, prevWins records a particular IG's previous wins in auctions and this is IG-level information. These two signals are very different in nature.

We welcome your feedback if you don’t think this can solve your use cases.

Lastly, @kkodai would you please add your full name and affiliation to your GitHub profile?