OpenRTB 2.5

Every single impression in the TripleLift exchange is bought and sold through real-time bidding. The language that the various players in the ecosystem have settled on is called "OpenRTB." It's an open-source project and every year or so they release a new version. The latest version is OpenRTB 2.5. For native advertising (and only native advertising, for whatever reason), there's a separately-maintained sub-protocol that is released on a different cadence. In this lift letter, we discuss what's new with OpenRTB 2.5 and what that means for the industry.

LA53502LOGO.jpeg

OpenRTB primarily consists of 2 components - a bid request and a bid response. The request specifies stuff about the impression from the exchange, the response says what the bid is, what the ad payload is, etc. The sell side sends the request, the buy side responds with the bid response. Both sides need to use the same version of the protocol, more or less, to make it effective. Sometimes there is additional data that can be sent in the request that could be ignored by the buy-side if they don't know how to process it. But if there's a new ad format or other similar concept (like PMPs), then both sides need to handle it the same way. This means that adoption of new protocols sometimes takes time, because there's a bit of a chicken-and-the-egg problem. OpenRTB 2.3 was the version that introduced the native spec. Because of the general enthusiasm surrounding native, there was genuine effort to adopt it over the past 2 years. 2.4 OpenRTB 2.4 was more incremental, and also added support for audio ads. There hasn't been as compelling a case for developing to the 2.4 standard, and it has seen relatively limited adoption compared to 2.3 (at least given what I can tell).

In openRTB 2.5, several interesting things are introduced. First, there's support for historical metrics in the bid request. The details of how metrics are considered are below shown below. 

1.png

The idea is that a bid request can now include something like placement-level viewability data as measured by Moat. This should radically simplify the process of targeting high viewability placements. As discussed above, it must be supported by both buy and sell side. If the sell-side alone support it, it would just be ignored. If the buy-side alone supported targeting on metrics, it would effectively break the exchanges that hadn't upgraded - meaning the buy-side would not want to do this until they knew the sell side had. We will likely see the sell side introduce this first, to avoid being excluded from campaigns that require metric targeting, with a slow roll-out on the demand side (considering most DSPs are 2 versions behind). 

OpenRTB also introduced a concept called billing URL (burl). While there was, and remains, a win notify URL (nurl) - the nurl could be triggered whenever an auction was won, either server-to-server or client-to-server. The burl, however, provides the express functionality to defer the billing event beyond merely winning the auction and gives the exchange more clear discretion on when to bill. This, in turn, provides functionality for viewability-based billing, or billing based on a video starting or progressing to X seconds (or whatever). Of course, this delay can add significant complexity to the buy-side. DSPs would again need to support a burl concept, in addition to a nurl. This is a slightly confusing concept when combined with the metrics object above. Would the metrics be based on billed impressions or won impressions? In any event, it is clear between burl and metrics that there is a powerful push towards targeting and purchasing on viewability.

Header bidding is an increasingly important piece of the RTB ecosystem, and as a result it is now represented in the OpenRTB protocol. There is an explicit element in the bid request indicating that the impression would be transacted from an "upstream source" - meaning this lets DSPs know that the exchange is not making the primary decisioning. That upstream source can send a transaction ID. This would be like an auction ID, except it would be unified across all secondary exchanges that host that auction and theoretically enable DSPs to make the appropriate decisions based on that information (e.g. buy on only one exchange for an impression). 

2.png

 

There are other improvements in 2.5, including support for flexibly-size banner ads and additional video support - but neither are as relevant to our business.