Protected Audience participation versus number of interest groups on the browser

[fabricegaignier]

We define participation as the presence of at least one forDebuggingOnly report for a call to the KV server (there is always one if generateBid is executed, even partially executed) and participation rate as the number of participations / the number of KV calls.

Our original set-up is to set maxTrustedBiddingSignalsURLLength to its maximum value. And we count the number of interest groups in each KV call.
We are always setting enableBiddingSignalsPrioritization to false

We notice that the more Interest Groups on the browser (as seen from our KV server, see above) the lower our participation rate.
Between 10 interest groups and 40 interest groups participation rate drops by around 15%.

Our hypothesis was that the round trip from the browser to fetch TrustedBiddingSignals in our KV server was responsible for this phenomenon due to a combination of:

• latency induced by the computation in the KV server
• latency induced by the network due to a large payload in our KV response

So we ran 2 experiments:

In the first experiment we set a smaller value for maxTrustedBiddingSignalsURLLength. The behaviour of this feature has been confirmed in this ticket: #1335
Splitting the calls to the KV server reduces both the processing time of our KV server per batch and the size of the returned payload per batch. The first batch to return should execute generateBid without awaiting for the other batches to return.

It did not change anything in our participation rate

In the second experiment we do not touch maxTrustedBiddingSignalsURLLength (and keep it at its maximum value), but we limit the number of Interest Group evaluations by our KV server to 10 interest groups. Interest groups not evaluated return an empty TrustedBiddingSignal associated to the TrustedBiddingSignalsKey, triggering a ForDebuggingOnly report in generateBid.

Again this reduces the processing time of our KV server and the size of the returned payload (per batch).

And again it did not change anything in our participation rate

So this decrease in participation rate is not due to the latency of the call to our KV server, increasing with the number of interest groups on the browser.

The only hypothesis left from our point of view is that the issues lies with the browser itself. As we observe a correlation with the number of IG but our mitigation does not appear to fix the issues, the true underlying issue might be something correlated with the number of Criteo's IG, perhaps the total number of IG.
We would therefore need to understand better what could prevent generateBid from executing once the TrustedBiddingSignals are received by the browser.

If maxTrustedBiddingSignalsURLLength doesn't work priorityVector response to the trusted bidding signals fetch will not work. And we have no other option to filter out interest groups from a Chrome device (out of all those proposals https://developers.google.com/privacy-sandbox/private-advertising/protected-audience-api/latency#buyer_bidder_best_practices).

In the meantime, browsers with the most interest groups are the most valuable ones from our perspective.

[michaelkleber]

Hi Fabrice: I think the new reserved.once trigger for contributeToHistogramOnEvent(), and the associated per-participant metrics, would be a great way to get more insight here. The metrics participating-ig-count and percent-igs-cumulative-timeout, for example, would help understand whether the perBuyerCumulativeTimeout is the source of the gap you're seeing.

This work is described in pending Pull Request #1272, and you can follow the roll-out in #1151. The new metrics should be available in 50% of Chrome Beta now.

[fabricegaignier]

Hi Michael,
The metrics you propose are triggered within generateBid. Our problem as described in the ticket is that generateBid is not executed at all.
So it will not help getting more insight on this problem.

[michaelkleber]

Ah! Perhaps I misunderstood your question. Is your participation rate measuring times that some but not all of your IGs were able to participate in an auction? Or times when none of your IGs got to participate? (Or do you not have enough information to tell the difference?)

[fabricegaignier]

Participation is defined at the really beginning of the ticket: We are counting times when none of our IGs got to participate (so no generate bid at all)

When at least one is executed, we consider participating.
This is why we cannot rely on a mechanism that would be triggered within our bidding script

[jungyanl]

Hi, I came across this comment #1367 (comment) while trying to find out why the percent-scripts-timeout metric is not working in my browser. It throws the error TypeError: Bucket's 'baseValue' is invalid.

The metrics script-run-time and signals-fetch-time are working fine for me. I am calling privateAggregation.contributeToHistogramOnEvent in generateBid.

Is this because the new metric is still being rolled out? When would it be rolled out to the general public / 100%?

My Chrome version is 131.0.6778.205 (Official Build).

Our code snippet

privateAggregation.contributeToHistogramOnEvent('reserved.always', {
        bucket: {
            baseValue: 'script-run-time',
        },
        value: 1
    });  // this works
   
privateAggregation.contributeToHistogramOnEvent('reserved.once', {
        bucket: {
            baseValue: 'percent-scripts-timeout',
        },
        value: 1
    }); // this throws the error; same thing when using reserved.always