Hi @ccharnay67, thanks for raising this! We are evaluating the idea, but wanted to ask whether supporting only logarithmic scaling (with pre-specified parameters) would be sufficient for this use case.

Adding support for a generic mapping is challenging. It would likely require spinning up a new javascript environment for each bidder at the end of the auction, which could have a significant performance impact. However, we could instead consider extending the existing linear scale/offset approach to support additional transformations (e.g. logarithmic). This does risk increasing complexity, but should have minimal performance impacts. This could maybe look something like your proposal, but with postprocess taking an enum instead of a generic mapping function (e.g. "linear" (default) or "log_2"). We might also need to add a mechanism to clamp the result of this to a reasonable range.

You mention that there might be other non-linear scalings that could be useful here. If you could provide any more detail, that would be very helpful for understanding the requirements here.

Hi @alexmturner, thanks for your answer!

The logarithmic scaling could be enough for our use case. Clamping is a necessity in my opinion, for timings metrics we do not know how high the value we get could be, which makes partitioning the bucket space a bit hazardous, as there is always a risk of bucket overlap.

In terms of other non-linear scalings, I can imagine a use case with the winning-bid or highest-scoring-other-bid requiring bucketization following a non-linear distribution, and neither linear nor logarithmic. We ourselves sometimes use a [1, 2, 5, 10, 20, 50, 100, ...]-style bucketization because it is convenient.

As a middle ground, do you think it would be possible to have an array of thresholds as a parameter, to give the user flexibility to bucketize browser-defined signals? In the example we gave, we would pass [1, 2, 4, 8, 16, 32, 64, 128, 254, 512, 1024], an array of 11 thresholds which we would expect to correspond to 12 buckets, with boundaries defined by the threshold. As a generalization, a list of N thresholds would give N+1 buckets. We do not have a strong opinion on whether a threshold value should fall in the bucket immediately lower or immediately greater.

function generateBid(...) {
  privateAggregation.contributeToHistogramOnEvent(
    "reserved.win",
    {
      bucket: {
        baseValue: "script-run-time",
        offset: 500n,
        thresholds: [1, 2, 4, 8, 16, 32, 64, 128, 254, 512, 1024]
      },
      value: 1
    });

  return bid;
}