OpenRTB 3.0 Draft

 
LiftLetters-IAB.jpg

The IAB recently released an initial draft of OpenRTB 3.0 spec (https://iabtechlab.com/wp-content/uploads/2017/09/OpenRTB-3.0-Draft-Framework-for-Public-Comment.pdf). This represents a major change for the specification. The changes are meant to solve specific challenges, including fraud (domain, location, user id, device), improved creative controls to help give publishers more control, and supply chain complexity 

OpenRTB 3.0 moves to a concept of "Offering" a set of "Items" in the bid request, and bidding on those items in the response. As a result, there is a new "Offer" object at the Request level of the bid request. The spec of the offer is below, but it can be described as enumerating the Items for sale, as well as additional information (e.g. whether this is everything for sale on a page).

image (1).png

The Item object is the actual thing being offered. This is, for example, a listing of all the ad placements being sold on one bid request. It also includes information about how one may buy that item, such as PMPs and floors - as well as preliminary support for identical impressions for things like OOH. The concepts of PMP and floor do not change materially in this version of OpenRTB.

image (2).png

The bid response, at a high level, is substantially unchanged. That said, given that Items are now being put up for Offer, the bid response includes a concept of the items that each bid correspond to (as well as a notion of requiring only winning all or part of the Items if multiple Items are up for Offer). To that end, the Bid object within Seatbid (similar concepts from previous versions), includes the relevant Item information. 

The concept of win and billing notification is given additional thought in the context of a more complex supply chain. There is movement towards client (browser) events as the basis of billable events, and there is a further concept that is still being formulated around a chain notifications - with the idea that multiple intermediaries may need to be informed about a single impression, so there should be a straightforward way to accomplish this. This has not been finalized. 

OpenRTB 3.0 also introduces a new concept called the Advertising Common Object Model (AdCOM) (https://iabtechlab.com/wp-content/uploads/2017/09/AdCOM-The-Advertising-Common-Object-Model.pdf). The idea behind AdCOM is that concepts that are useful in various specifications of OpenRTB or OpenDirect, they should be standardized. Thus the standardized components will be referenced as AdCOM objects when they appear in various OpenRTB specs - adding uniformity and predictability. This does not materially impact the contents of the protocol, as opposed to where the definitions of things live. 

Given the increasing concern around fraud on both sides (publisher and advertiser), OpenRTB has introduced the notion of a signed bid request (https://iabtechlab.com/wp-content/uploads/2017/09/OpenRTB-3.0-Draft-Signed-Requests-RFC.pdf). Bid requests will contain digital signatures (cryptographic evidence that the message is authentic) that enable the bid request's path to be trusted. This adds a publisher signature ("ps") field to the bid request that includes information about the publisher, the transaction ID, and some other fields that are encrypted by the publisher's private (secret) key. This data in the bid request can be decrypted with the publishers public key. It is proposed that a new /ads.cert file, containing that publisher's public key, be hosted on the publisher's website (in addition to ads.txt). The public key should be cached by all entities that consume it. It is not clearly specified how the signed transaction ID is passed to the exchange, but perhaps this is appended to the original ad request and passed on by the exchanges. This does mean that the publisher would be generated unique keys for each partner for each request, which is adding material complexity to the publisher's implementation. 

Another concept introduced in OpenRTB 3.0 is that of Trusted Data Partners. This seems further from being a reality, given that the proposal linked to isn't even on the IAB's website. It is instead available here: http://bokonads.com/request-for-comments-trusted-data-partners/. This requires yet another hosted file - /tdp.json - which specifies the partners that the manifest would in turn define which partners on a publisher could see bid requests, have pixels dropped and have creative assets loaded. It's a fairly complicated set of rules that are still being ironed out. 

Creative approval is another area being considered for OpenRTB 3.0. Currently exchanges and DSPs have proprietary solutions, but there is movement towards homogenization. The initial draft is available here: https://iabtechlab.com/wp-content/uploads/2017/09/IAB-Tech-Lab-Ad-Management-API-Specification.pdf. This allows both permissive (approved until not) and restrictive (rejected until approved) systems. This creates an API system where DSPs have a specified set of endpoints to upload and check the status of their creatives against the company's audit, as well as to provide a webhook to push updates back to the bidder. 

Identity is yet another area that is being considered for inclusion. This would add fields to the User object in the bid request, adding an array of "eids" (extended IDs). Each extended ID has a source and an array of Extended ID UIDs. The source is the provider, such as LiveRamp, and the Extended ID UID is the user ID itself, as well as the type of ID (e.g. cookie, IDFA, AAID, etc)

unnamed.png