Third Party reporting
Opened this issue · 17 comments
The original description is outdated, the actual proposal can be found here:#1220 (comment)
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
- Provide a new mechanism for ThirdParties enrollment.
- The ThirdParties (or Buyers on behalf of ThirdParties) provide their signals in the ext.3p_ig_signals section of an OpenRTB response as follows:
'ext': {
'3p_ig_signals': {
'https://www.third-party-1.com/': {
'url': 'https://www.third-party-1.com/thirdPartyReport.js',
'data': {
'https://www.example-dsp.com/': 'someDataOfThirdParty1',
'https://www.another-buyer.com/': 'someOtherDataOfThirdParty2',
...
}
}
}
}
It is supposed that ThirdParties put in this section contextual signals, seller origins, and buyers' specific data.
- Support the new key in auction config, e.g. - thirdParties, where Seller could declare ThirdParties based on the ext.3p_ig_signals in OpenRTB response.
- Support the new key in auction config e.g. - perBuyerThirdPartySignals, where Seller could declare what ThirdParties are eligible to get reporting data for a given Buyer and signals for them. This key is based on the ext.3p_ig_signals in the OpenRTB response.
- The seller has to take into account all the ThirdParties data from ext.3p_ig_signals and form the sections thirdParties and perBuyerThirdPartySignals in the auction config as follows:
const AuctionConfig = {
'seller': 'https://www.example-ssp.com/',
'interestGroupBuyers': [
'https://www.example-dsp.com/',
'https://www.another-buyer.com/',
],
'thirdParties':
'https://www.third-party-1.com/': https://www.third-party-1.com/thirdPartyReport.js,
'https://www.third-party-2.com/': 'https://www.third-party-2.com/thirdPartyReport.js',
...
},
'perBuyerThirdPartySignals': {
'https://www.example-dsp.com/': {
'https://www.third-party-1.com/': someDataOfThirdParty1,
'https://www.third-party-2.com/': someDataOfThirdParty2
},
'https://www.another-buyer.com/': {
'https://www.third-party-1.com/': someOtherDataOfThirdParty2
},
...
},
...
};
- Add the logic to execute reportResultsToThirdParty() function from the specific ThirdParty's worklet (thirdPartyReport.js). The function is called at the same time as won Buyer's reportWin. It is called only for those ThirdParties that are defined in perBuyerThirdPartySignals section for this Buyer. The arguments to the function are auctionConfig, browserSignals, and a section of perBuyerThirdPartySignals that is specific for these Buyers and ThirdParties. The purpose of the function is to send reporting data to a ThirdParty.
Example of a reportResultsToThirdParty() function:
reportResultsToThirdParty(auctionConfig, browserSignals, ThirdPartySignals) {
sendReportTo('https://www.third-party-1.com/reporting?bid=${browserSignals.bid}&dsp=${browserSignals.interestGroupOwner}&signals=${thirdPartySignals.signals}');
}
similar request / issue
A similar request for aggregated reporting - #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.
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?
In the WICG call from 2024-09-04 we discussed the possibility of adding a default FF impression event (or maybe two impression_start, impression_commit) similar to what has been already added with default click events (reserved.top_navigation_start and reserved.top_navigation_commit, https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md).
@michaelkleber @shivanigithub
We found another use case where this feature might be interesting. For billing currently the SSP usually bills based on reportResult.sendReportTo events (because this is the only event they have available without DSP cooperation) and the DSP might use FF report events because they allow custom event data. This means that SSP reporting and DSP reporting are not necessarily aligned.
Also linking this Google 360 ticket which looks related if multiple default events are available or Allow-Fenced-Frame-Automatic-Beacons is extensively used.
Any news on #1220 (comment) ?
It looks to me more like a bug fix or a small patch than a new feature. Do you think anything could be blocking on you side ?
It would be great to also understand what the impression_start, impression_commit events signify. For impression_start, it could mean a few things, e.g. does the adtech like to know:
- that the request for the renderURL was started by the browser or
- that the iframe completed loading or
- that the iframe was visible to the user
Similarly what would impression_commit represent?
/cc @blu25
I mostly made up 2 events without thinking too much on when they actually should be triggered.
To come back to this ticket, to be able to align DSP & SSP billing and 3rd party reporting the display event should be aligned with the trigger of sendReportTo in reportResult.
I suppose this is fired now at the very beginning of triggering the iframe/fenced frame, so I guess it corresponds to "that the request for the renderURL was started by the browser or". Do you confirm ?
In any case there would be cases left where custom events are needed, like the 50%/1 sec viewability event
We could add it to some WICG call to ask for more feedback if more than a default display event is needed. I guess it depends on how easy it is and if there is use case.
@shivanigithub
To summarize, the proposal would be to add a new automatic reserved.impression beacon that would be sent exactly at the same time as sendReportTo. In the long run, potentially sendReportTo could be removed and replaced by the more generic beacon API. In the meantime, having a coordination across beacons and sendReportTo would still allow to reduce discrepancies if some DSPs & SSPs still use sendReportTo.
Normally this event is triggered when the iframe is loaded for display and hopefully the ecosystem will agree that this could be used as default impression billing event.
The new beacon could be used by sellers and buyers and also with multiple different urls (to fulfill 3rd party reporting requirements).
Here is an example:
registerAdBeacon({
'reserved.impression': 'https://adtech.example/imp?buyer_event_id=123',
'reserved.impression': 'https://adtech2.example/imp?buyer_event_id=123',
});
From the BSW pov the proposal by Fabian would work for Bidswitch as well for 3rd party reporting
the proposal would be to add a new automatic reserved.impression beacon that would be sent exactly at the same time as sendReportTo
Agreed that keeping the same semantics is important.
In the long run, potentially sendReportTo could be removed and replaced by the more generic beacon API
This presumes that the seller can always rely on this beacon firing -- which isn't guaranteed today by the API -- which is a fundamental change from sendReportTo().
In other words, today, we're still bound by the buyer's IFRAME triggering this call (either via header or via JavaScript), and there's no guarantee that either occurs.
We decided to visualize a bit of what Fabian suggested above and clarify that it seems there is no concern for reserved.impression similar to the one described for clicks here #826 (comment).
Therefore, we want reserved.impression to be triggered entirely independently of the DSP, as shown in the image. We also want to emphasize that the most important thing is for this event to be triggered more than once for SSP. If that’s the case, it could become a valuable billable event for the entire industry
Thank you all for chiming in on this feature request. Summarizing the why and what of the request here. Please add if I've missed anything.
Why:
Multiple entities receiving reports from the ad/auction, e.g. SSP, DSP, 3P etc. get the same event at the same time, creating consistency in use cases for those events like billing.
What:
- A new reserved event reserved.impression, which the browser sends at the navigation start of the ad iframe/fenced frames, same time as report result/reportWin pings are sent. The new event does not require any opt-in from the ad frame, since this is not new information about the frame.
- Multiple destinations per event to be supported so that 3Ps can get the reports in addition to SSP and DSP.
@ajvelasquez-privacy-sandbox do you have any more thoughts/questions to add here.
/cc @blu25
Summarizing one of the points that was discussed in the WICG PA call today.
If the event of interest here is only that the ad has started to render, then it could be an extension of reportResult, to allow multiple destinations rather than adding an automatic beacon.
/cc @JensenPaul
OK. Why not. Allowing sendReportTo with multiple destinations doesn't have the downside of having to deal with eventData from beacons. And then the different buyer & seller sendReportTo events could be synchronized by Chrome in order to not loose the event for one party.
So it is maybe the simplest option to activate this use case.
A follow up question on the sendReportTo approach: Does this use case need ARA integration?
Hello Shivani, attribution seems out of the scope of this proposal. The goal here is billing, and for this, only impressions themselves and their cost are required.