We would like Chrome to provide per-buyer latency data to sellers as an additional input to reportResult. This will support sellers in optimizing UX and revenue implications of FLEDGE.
Specific per-buyer signals that would be useful:
- The latency and payload size (in bytes) of each trusted bidding server call
- The number of interest groups the user has joined
- The number of and total CPU time across generateBid invocations
- The number of and total CPU time across scoreAd invocations
It would also be helpful to have the latency of the trusted scoring server call.
This data will be integral in optimizing the usage of runAdAuction and the knobs sellers have (e.g., perBuyerTimeouts, perBuyerGroupLimits, perBuyerGroupExecutionLimitsMs if accepted) in order to mitigate any adverse impacts from running third-party buyer code on the client.
Note: we anticipate that this could be seen as introducing privacy drawbacks. However, we don’t believe that this increases the privacy risks in FLEDGE Origin Trials #1, though it would be reasonable to move these signals to aggregated reporting, once available.
Motivating use case
In manual tests we’ve run locally, we’ve observed runAdAuction latency varying from 100s of milliseconds to dozens of seconds. In such local test environments, we’ve been able to isolate specific components, such as latency associated with trusted server calls, number of interest groups joined, specific generateBid/scoreAd invocation times, etc.
However, during the Origin Trials, we won’t have as much insight into how long each part of the FLEDGE auction takes on real end users’ browsers. We will need support from Chrome in the form of reporting or debugging APIs to bridge the gap. This will help impose per-buyer on-device runtime limits, and generally help sellers understand the amount of client-side resources being consumed by each buyer.
We would like Chrome to provide per-buyer latency data to sellers as an additional input to reportResult. This will support sellers in optimizing UX and revenue implications of FLEDGE.
Specific per-buyer signals that would be useful:
It would also be helpful to have the latency of the trusted scoring server call.
This data will be integral in optimizing the usage of runAdAuction and the knobs sellers have (e.g., perBuyerTimeouts, perBuyerGroupLimits, perBuyerGroupExecutionLimitsMs if accepted) in order to mitigate any adverse impacts from running third-party buyer code on the client.
Note: we anticipate that this could be seen as introducing privacy drawbacks. However, we don’t believe that this increases the privacy risks in FLEDGE Origin Trials #1, though it would be reasonable to move these signals to aggregated reporting, once available.
Motivating use case
In manual tests we’ve run locally, we’ve observed runAdAuction latency varying from 100s of milliseconds to dozens of seconds. In such local test environments, we’ve been able to isolate specific components, such as latency associated with trusted server calls, number of interest groups joined, specific generateBid/scoreAd invocation times, etc.
However, during the Origin Trials, we won’t have as much insight into how long each part of the FLEDGE auction takes on real end users’ browsers. We will need support from Chrome in the form of reporting or debugging APIs to bridge the gap. This will help impose per-buyer on-device runtime limits, and generally help sellers understand the amount of client-side resources being consumed by each buyer.