Open mdavies-bidswitch opened 1 month ago
Using this functionality, even a publisher will be able to get details of auctions rather than depending on multiple SSP reporting.
Following up on the WICG discussion of Wed 7/17, it may be worthwhile to say we have infrastructure for both sellers and buyers to declare 3P destinations and data (fenced frames ad reporting infrastructure). Config needs to be done by seller / buyer still, but it’s feasible. For more than a year we know of 3Ps that need to get reporting; about a year ago enhanced flexibility for different kinds of reporting. The explainer here: https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md . Perhaps another way to scope this request could be to express what are the gaps between that and the problems brought forward here?
Straightforward Solution: sendReportTo The problem with sendReportTo is that it cannot be called more than once. Enable sendReportTo to be called more than once.
registerAdBeacon The problem with registerAdBeacon is that SSP and DSP need to agree on the event name that will trigger the DSP. While a standard might be established where the impression event is named "impression", but the limitation of registerAdBeacon is that it does not allow us to specify two destination URLs for an event with the same name. It is necessary for third parties to have the ability to call registerAdBeacon with the "impression" event a second time. Allow the same event name, such as "impression," to be registered multiple times with registerAdBeacon and ensure it triggers in reportEvent as many times as it is registered.
Hi Alonso,
Wanted to see if there was any further thoughts on the details of the request above. Looking at the issues the main one is the need for this to be added by either the buyer or the seller, certainly in the BSW case this would not be feasible as the logic that the buyer or seller would have to add if run via BSW and not if not run via BSW (for others this could be a logic where the 3rd parties who need reporting would not have an all or nothing approach - but triggered based on some event where the 3rd party reporting is needed)
In our case we are part of the billing chain - and pass on the PSB credentials in the chain and need to be able to add for reporting when and only when we are part of that chain and not when we are not.
Also the other issue is more general - ideally cxeeding control of when and if you get reporting on a transaction to either the buyer or seller could lead to gaps in the data chain and reporting should the DSP or SSP not actually do the work to support that as well.
Also above is a more simplified solution, does this work better?
Problem Statement:
The current PA API logic doesn't support the middle layer between Sellers and Buyers. So while DSPs and SSPs do receive impression notifications from Chrome, middle-layer technical providers (e.g. BidSwitch) by default don't. It is essential for technical providers to get impression notifications in real-time or close to that to manage budgets and shape traffic.
Proposal
It is supposed that ThirdParties put in this section contextual signals, seller origins, and buyers' specific data.
Example of a reportResultsToThirdParty() function:
similar request / issue
A similar request for aggregated reporting - https://github.com/WICG/turtledove/issues/1115
Privacy concerns
Potential issue - auction config could be modified by any script on the publisher's page, which could provide access to auction results for non-trusted third parties.