OpenRTB 3.0 was designed to overhaul the programmatic advertising landscape by enhancing trust and transparency as the supply chain grew more complex. But, several years post-launch, it's still not widely adopted. To find out why, let's examine its goals, why adoption so far has been limited, and what we’re likely to see next.
What is Open RTB 3.0?
In September 2017, the IAB Tech Lab released the framework for OpenRTB 3.0, the latest iteration of its OpenRTB protocol.
Originally created in 2010, the goal of the specification is to establish a standardized, simplified code of conduct for operating in the programmatic auction environment. Technical specifications were made available in July of the following year.
OpenRTB 3.0 was hailed by the IAB as the biggest overhaul of the framework since its inception. It aimed to address various issues that had developed as the ecosystem for the automated buying and selling of ads had become more complex and cumbersome. Key among the objectives were to restore trust and transparency through better security, reduced ad fraud, faster bid processing, and improved ad quality.
Evolving challenges
Anyone familiar with the industry knows that programmatic has become increasingly complicated, with more players and competencies introduced, and an increasingly privacy-focused regulatory backdrop adding another layer to navigate.
Fraud is an ever-present issue. The expanded supply chain is more unwieldy as ad impressions have limited visibility and are hard to trace and validate. They pass through multiple publishers, exchanges, ad networks, demand side platforms (DSPs), and advertisers, complicating oversight. And the more hops between platforms, the more chance there is for malicious interference.
While the IAB’s Ads.txt (released in May 2017) made measurable inroads into tackling ad fraud with a checklist of pre-approved exchanges, it only applied to domain fraud. Widely used tactics such as location fraud, device fraud, and domain spoofing, for example, did not fall under its protective umbrella.
The widespread adoption of header bidding threw another wrench into the works of the RTB auction. Regarded as mainstream since 2016, header bidding put publishers back in the driving seat by giving them visibility of partners and their performance, thereby helping them boost their revenue. But publishers offering inventory to multiple exchanges at the same time led to huge increases in the number of bid requests that platforms needed to process, putting them under significant strain and slowing down the bidding process. Additionally, the process of delivering ad creatives from the buy-side to the sell-side complicated the pre-approval publishers need to ensure essential brand safety.
OpenRTB 3.0 was developed to introduce the much-needed changes required for this continually evolving programmatic landscape.
New RTB standards
OpenRTB 3.0 introduced extra safeguards to Ads.txt with Ads.cert. This enabled publishers, plus each link in the supply chain, to stamp every ad impression with an authenticated and encrypted signature to show the buyer that it hadn’t been tampered with. (Fraudsters often change how the impression is described – such as the domain where the ad will appear - leading buyers to purchase it under false pretenses.)
In addition, with AdCOM 1.0 (Advertising Common Object Model), OpenRTB 3.0 took on other programmatic business challenges. This included introducing new protocols for supply and demand partners to use for the approval and rejection of creatives to improve ad quality.
Version 3.0 also tackled the problem of bid request overload in the programmatic system by cutting down on the amount of duplicated code that had crept into the process. Previously, an ad exchange selling different types of inventory for a publisher (such as open exchange, programmatic guaranteed, and over-the-top video) would need separate specifications for each inventory category. But these specs would contain unnecessary duplications – publisher IDs and content categories, for example, are the same regardless of ad type. OpenRTB 3.0 restructured the specifications to remove repeats, thereby reducing traffic volumes and related latency issues.
However, despite its industry-benefiting credentials, to date, OpenRTB 3.0 has received a lukewarm reception.
(S)low adoption
The scale of the upgrade to OpenRTB 3.0 cannot be over-stated—it’s a big overhaul.
It’s also not backward-compatible with older versions of the framework, so any organization implementing it needs to deploy significant resources to rewrite the underlying code. This has deterred many players from getting on board.
Around the time of its launch, there were also updates to the existing OpenRTB 2.5 specifications. These started to address some of the weaknesses in the older iterations of the protocol and were deemed more urgent (and straightforward) to implement. Meanwhile, although Ads.cert didn’t get off the ground, supply chain security was reviewed with an increased focus on authorization, identity and transparency standards including Ads.txt, Apps-ads.txt, Sellers.json, and Supply-chain.
Outside the OpenRTB world, the ongoing drive for consumer privacy was dialed up with various new US regulations and updates to the EU GDPR, while Chrome announced its plans to depreciate the third-party cookie and Apple removed its IFA identifier. These all contributed to taking the focus off the development and take-up of the new 3.0 specification.
So... what now?
It's worth noting that some of the OpenRTB 3.0 specification, such as AdCOM 1.0, has been adopted. However, it seems unlikely that the framework will be used as it was originally planned.
In part, this is down to the industry’s ongoing evolution. It’s also because the IAB Tech Lab addressed many of the challenges 3.0 had been developed to resolve with changes to OpenRTB 2.5 and, as noted above, an increased focus on the supply chain.
In addition, it developed what is commonly referred to as the 2.x platform. This incorporates the key OpenRTB 3.0 elements that the industry wanted to work on, but made them compatible with existing OpenRTB architecture. Unlike version 2.5, which was planned as a one-off upgrade, 2.x is designed to be updated regularly (with new modules such as ad podding, digital out-of-home/DOOH, and Google Privacy Sandbox adaptions some of the many new releases). This flexible approach is more closely aligned to the changing needs of the industry.
And additional standards are introduced as the sector continues to shift. OpenRTB 2.6 for example, with its focus on connected TV (CTV), has been available since mid-2022.
Working with BidSwitch
BidSwitch will always run on the latest version of the OpenRTB protocol, as part of our remit is to enable partners to trade seamlessly—even if they are running on different editions of the framework. As such, we developed full support for OpenRTB 3.0 when it first came out and provide detailed technical specifications for clients that do want to develop it on their side.
As an IAB Tech Lab participant, BidSwitch also contributes to industry discussions around the ongoing development of the specifications.
To discuss your OpenRTB requirements, get in touch with the BidSwitch team today.