In brief, the key difference between OpenRTB and header bidding is that the former still implies a somewhat traditional, waterfall auction system; and the latter implies the simultaneous bidding on publishers’ inventory prior to making a call to their ad server.
What is Real-time Bidding?
First, let’s cover the basics. The notion of real-time bidding (RTB) actually means bidding on publishers’ inventory in real time, where the winning bidder gets to display the ad on a particular ad placement. And the indispensable aspect of the real-time bidding process is waterfalling, i.e. prioritizing the bidders in the auction based on the offered price, then passing the inventory to successive auctions, until the impressions are filled.
In this respect, a common drawback of waterfalling for publishers implies the potential loss of revenue, due to lower/no focus on the real-time impression value. At the same time, from the advertiser’s perspective, this frequently means limiting their access to publishers’ premium inventory in case of the first bid loss, leaving them with scarce choices for their ad display.
On a greater scale, real-time bidding introduces middlemen to the ad sale process, where SSPs generally handle the auction on a publisher’s side, and DSPs do the same on the advertisers’ side. This may result in the lower transparency of the entire programmatic ad supply chain, hence making it more prone to ad fraud, which leads to poorer business results for each player in the system.
What is OpenRTB?
Unlike the real-time bidding itself, OpenRTB doesn’t introduce an entirely new ad buy-sell system, instead offering somewhat a unified standard for the auction configuration and setup.
Contrarily to some of the proprietary RTB-related tech, OpenRTB is an open-source ad serving protocol, aimed at streamlining the programmatic ad buying process in a variety of ways. One of the later versions (oRTB 2.6), for instance, supports header bidding on each stage of the waterfall, which should improve the publishers’ overall revenue potential.
Meanwhile, the OpenRTB 3.0 specification provides the more advanced ad fraud protection techniques, and has been refactored to take benefit from IAB Tech Lab’s Advertising Common Object Model (AdCOM) and Ad Management API, hence helping to achieve greater interoperability across the programmatic ad ecosystem.
In spite of its obvious pros, one of the existing pitfalls of OpenRTB is that the protocol keeps the waterfalling in the core of the auction process, aiming to streamline some of its aspects instead.
More importantly, the lack of adoption of the newer oRTB versions by the industry players essentially stalls the innovation in the programmatic ad market.
What is Header Bidding?
In brief, header bidding is an ad serving protocol, which implies the simultaneous bidding on inventory by all players on the Demand side prior to making a call to a publisher’s ad server.
Quite obviously, the key difference between header bidding and RTB is that this protocol does NOT imply any waterfalling, which implies the relatively more straight-forward implementation on the publisher’s digital properties (via adding a piece of JS code in the webpage header).
In this respect, some of the most apparent advantages of header bidding lie in the more streamlined integration (using open-source solutions, like prebid.js) and its overall cost effectiveness.
At the same time, the implementation process is rather complex, and may lead to page latency issues, if not handled properly on all ends.
Which is better: RTB (using OpenRTB) or header bidding?
On the one hand, enabling a publisher’s SSP to handle the programmatic ad auction setup may seem an easier way to take.
On the other hand, however, working with a top-quality video header bidding solution (with prebid.js support) can actually allow streamlining the video ad integration process, while also opening a path to achieving the more ambitious ad revenue goals. This is, actually, why header bidding is currently considered a preferred protocol for online ad transactions.