Third Party reporting

[mdavies-bidswitch]

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 - 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.

[pm-harshad-mane]

Using this functionality, even a publisher will be able to get details of auctions rather than depending on multiple SSP reporting.

[ajvelasquez-privacy-sandbox]

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?

[mdavies-bidswitch]

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.

[mdavies-bidswitch]

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?