Additional Plugin Points to Support ORTB-PAA Adapters to Make Translation Easy/Error-Free

[thegreatfatzby]

Industry Use of ORTB in PAA

ORTB is the lingua franca of digital advertising, and not surprisingly we're discussing using it to pass signals around the Private Auction. For instance, using the standardized-and-widely-used ORTB BidRequest in the auctionConfig.auctionSignals, and BidResponse in the ad portion of the generateBid response, would seem to make sense and is being discussed in IAB groups.

ORTB to PAA Translation

One thing that is interesting about this is the need to translate reliably between models, as both ORTB and PAA have structures and fields they need for various reasons, some of which overlap. As examples for a simple banner request:

• ORTB: the BidRequest will have a imp.banner.format object that specifies the size of the tag (multiple, but ignore that for now).
• PAA:requestedSizes will shortly become PAAs way of knowing about requested size of the tag.
• ORTB: if there's a bid (there can be multiple, ignore for now) the BidResponse will have a SeatBid.bid.price value.
• PAA: there is a bid element of the response from generateBid.

Divergence in these would be bad.

To be very clear, I'm not talking about feature divergence, i.e. the above "ignore for nows" about multiple sizes per tag and multiple bids per impression. That is challenging and (I believe) driving that to 0 as much as possible will aid the success of PAA and PPA more broadly. I'm talking specifically about a case where there ends up being a difference in the scalar value between bid.price in the ORTB response and the bid value in the top level of the object coming back from generateBid.

It is certainly true that we, as software people, can write code to not do that. However, the more decentralized this code, the more likely there will be errors, and this gets even more true as this spec/system and the signals that can be passed in grow more sophisticated and complex.

Adapter Pattern Directionally

This seems like a classic case for an adapter pattern, wherein multiple things can be adapted to a single internal representation needed by the PAA framework. In this case the internal representation would be the internal stuff in Chromium space, and the two adapters would be the current auctionConfig --> internal and then ORTB --> internal.

However, making the internal representation part of a public contract is likely a bad idea for both sides, so being able to keep auctionConfig as the contract and adapting to that seems the right direction. Also, since auctionConfig will contain other non-overlapping "contracts", we still need access to that.

Solution

So to formally propose something I'll ask for:

• Two new hooks for auctionConfig and generateBid response adaption.
• Those hooks take a function that takes in a blob and outputs the auctionConfig or generateBid response. To allow for the non-overlapping parts, it will be merged in by top level key.
• Those functions are not owned by Chromium (although having them available inside could be nice for performance and ease of use in the case of widely standardized things).
• How to implement exactly: dunno exactly, maybe use the existing functions and have a adapter field on the auctionConfig that the framework would take, run, and then merge onto the auctionConfig, same in the generateBid response.

[patmmccann]

Prebid.js is writing as much as it can of an ortb2 request object to auctionSignals when a config passes through its hands. Expect this to increase over time. For example, publishers don't usually write the bcats to the prebid config, but we're going to start encouraging / enabling it.

See prebid/Prebid.js#10649. I suspect sellers will continue to embrace putting the ortb2 object in a predictable place in auctionSignals and there is no need to change the API to support this.