-
Notifications
You must be signed in to change notification settings - Fork 232
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
Request for event-level ReportLoss API #930
Comments
Hello @nurien2, could you please add your first and last name and affiliation to your GitHub profile? A few clarifications on your request:
|
thanks @JensenPaul for you answer:
Yes, we are proposing that buyers have a new function ReportLoss in their bidding script that would look like
browserSignalsForReportLoss would be different from browserSignals in the reportWin function, and would not include privacy-leaking information, such as the interest group name or the modelingSignals. In case the buyer wins the top-level auction, they receive a report via ReportWin. In case they lose the top-level auction, they receive a unique report per lost component auction via the new ReportLoss function with all their losing bids.
Ideally, we would also like to receive a toplevelauctionid (referred to as “opportunityid” in the original request), but if it seems complicated, let’s focus on the ReportLoss endpoint first. |
Hi @nurien2 Can you help us understand what is the gap between the requested feature, and what is already possible using Private Aggregation (especially if we don't provide opportunityid)? Thanks |
Hello @renanfel
What we are asking is an event-level API, while the Private Aggregation API provides aggregated report. To get the same granularity as our requested API, we would need to encode in the 128 bits an identifier of the component auction and keep some buckets for the bid value. However, if we were able to perform the call to PA API once per component auction (instead of once per GenerateBid call) and recover the max bid value for a given buyer, we could bucketize with the contextual features directly (no need to encode an identifier), this would prevent from having very small contributions (and overcome the noise issue), and would limit the number of bits used for this use case. To my understanding, this is not currently possible with Private Aggregation API. |
Aha! This sounds like a feature we ought to be able to be able to add. Take a look at the section on Triggering reports — if we added a new trigger that was something like Of course we need to figure out the exact semantics. But a solution that would let you get the information you're looking for out of the Private Aggregation API seems like an excellent goal. |
Hello @michaelkleber, This would be an interesting feature for sure. We will perform some analyses on how we can exploit this new trigger and state if it covers our needs. We will come back to you with our findings. |
Am I correct in understanding that by highest you mean highest made by your origin? (Additional bids are also a bit of a wrinkle here since they don't run generateBid(), so don't get a chance to register private aggregation stuff). |
Oh I was interpreting "highest" as being scoped over all bids in the component auction, irrespective of which origin's IG did the bidding. Nicolas, please set us straight here! Does every bidder get one such trigger, or only one bidder per component auction? Also, what notion of "highest" are you hoping for if the bid's monetary value and the seller's desirability score don't put things in the same order? |
... also, how should bid modification by component auctions be handled? |
hello @morlovich and @michaelkleber,
What we meant is highest made by our origin. Every origin taking part in the auction mechanism (either at component level or top-level depending on the trigger) will be able to contribute with this trigger, and not only the best losing origin. So every bidder get one trigger.
While comparing and ranking candidates from a unique component auction based on their desirability score makes sense (the seller applies the same scoring function across the candidates), comparing scores across different component auctions seems irrelevant. The only quantities that can be compared across component auctions are the bid values, so we recommend a ranking based on those latters. Additionally, we want to filter out candidates getting a zero desirability score, as they are invalid candidates from the seller standpoint.
We agree additional bids would be complicated to consider with this trigger for the very reason you mentioned. We are fine to ignore those bids.
If the ranking is based on bid value, for comparing candidates from different component auctions (top-level auction trigger), the ordering should be performed on bid values after bid modification by component auctions. If the ranking is based on desirability scores, as we suggest for the component auction trigger, we can suppose that bid modifications are incorporated into the score computation. |
Request:
We would like an event level ReportLoss API.
Background:
As of today, we can access reports through several APIs, and each of them present the following drawbacks:
highestScoringOtherBid
inaccurateRationale:
The event level reporting currently allow us to build a reliable bid shading strategy. This is beneficial for both advertisers, as a DSP can better spend their budgets, and publishers, as a loss in precision would likely result in a decrease of the bid levels and impact their revenues.
Proposed solution:
We are suggesting the creation of an event level ReportLoss API, which would provide a subset of the data that we currently have with the ForDebuggingOnly API:
The output should not contain any user identifier nor user data nor any interest group identifier, thus should satisfies privacy constraints. We acknowledge that our demand would receive some concerns regarding privacy and technical feasability, thus we propose to:
perform a 5% sampling, seeded on opportunityId, to prevent from sending too many reports, if not sufficient:
The text was updated successfully, but these errors were encountered: