-
Notifications
You must be signed in to change notification settings - Fork 227
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Per-buyer latency reporting #299
Comments
On trusted server latency: are you looking for aggregated stats of the latency distribution for requests in general or the latency of each specific request? The former is something that we should be able to provide reasonably easily, from the server directly - it shouldn't be too hard to aggregate those into a histogram that's privacy safe. We haven't thought yet about how to return individual latencies as that might be a nice side channel to pass information out of the server. |
Aggregated data should be fine, but the goal is to understand the per-buyer e2e latency/impact from the client, not the server. |
Besides providing buyer performance data to the seller, can Chrome also provide the buyer performance data to the buyer as well? This will help the buyer figure out which IG's bidding take too long. A couple of functionalities we would like to have:
|
Is there any update on this issue? Reporting of the latency contributors seems a fairly important functionality for the ability of sellers and buyers in FLEDGE auctions to work together to debug latency issues and optimize the infrastructure to minimize user-facing latency. |
Hi all, please take a look at our latest proposal. In addition to other capabilities, it proposes extending the Private Aggregation API to allow for aggregate reporting of various latency metrics. We'd appreciate any feedback! We also plan to discuss this proposal at the upcoming FLEDGE WICG call on Wednesday 9 November. |
Can you clarify the below text in the context of this issue?
(Emphasis mine) I.e., is this a new requirement of buyers in FLEDGE – to specify the appovedSellers -- or is it only required if Buyers want to allow Sellers access to additional metadata in reporting? If the latter, it does not seem like the per-buyer data will be entirely trustworthy. |
I think that document should update |
@av-sherman, this is the case. |
Would it be possible to expand the API to allow Sellers the option to require this field be set, thus excluding any IGs from buyers that aren’t sharing latency data? This way, Sellers can be confident that the data returned by the API is reflective of the auction being run. Possibly this can be done via a new field in Note: there may be value for buyers if Chrome provided some sort of feedback mechanism for when IGs are affected by this. |
This feature has landed in Chromium and will be shipping in M112 (112.0.5615.20 or newer) and M113 (113.0.5627.0 or newer).
|
Closing as I believe this was implemented. Feel free to reopen if you have further questions. |
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.
The text was updated successfully, but these errors were encountered: