Hello,

From the documentation on extended PA reporting, when using browser-defined signals to calculate the bucket or the value for reporting, all we can do as post-processing is applying scale and offset.

We have a use-case, for timing signals like script-run-time, where we would like to use a non-linear bucketized timing as bucket. At the moment, we could do buckets of width 5ms by using scale 0.2, but we cannot create a bucket for [0-1ms[, another for [1-2ms[, then [2-4ms[, [4-8ms[, …

With the current state of the API, the only way we found to do it was to reserve 1000s of buckets, one per ms of timing up to a certain value, and do the logarithmic bucketization on our end. This is very inconvenient, as it forces us to block a bigger part of the keyspace than needed, only because we cannot post-process the Chrome internal metrics.

We are considering logarithmic buckets in this example because it makes sense for timings, but it would be good to be able to provide a function as a post-processing callback, which would take the value returned by signal as input and would return the actual bucket/value we want. This could still be combined with scale and offset as follows: bucket = postprocess(inputSignal) * scale + offset. This definition avoids issues with backwards compatibility, as scale default is 1.0 and default offset is 0. Below is an example of what it could look like.

const logarithmicBuckets = (timing) => {
  if (timing == 0n)
    return 0n;
  if (timing >= 1024n)
    return 11n;
  return BigInt(1 + Math.floor(Math.log2(Number(timing))));
}

function generateBid(...) {
  privateAggregation.contributeToHistogramOnEvent(
    "reserved.win",
    {
      bucket: {
        baseValue: "script-run-time",
        offset: 500n,
        postprocess: logarithmicBuckets
      },
      value: 1
    });

  return bid;
}

What do you think?