Products
Resources
Other
OpenRTB and the History of Programmatic. How The Standard Became a Mirror of the Interactive Advertising Development
April 13, 2026
OpenRTB is considered to be the technical basis of programmatics. But its evolution speaks not only about the development of the protocol, but about the development of the market itself. The way OpenRTB has changed shows how the programmer has gone from unifying the RTB auction to a more complex system of standards and platform implementations
The Standard in Which the Market is Visible
OpenRTB (or oRTB) is usually described as a technical programming framework: the bid request and bid response format, without which SSP, DSP and exchanges would not be able to trade inventory normally.
If you look at the protocol not as a set of fields, but as a history of decisions made by the industry, more becomes clear. The evolution of the standard clearly reads the history of interactive advertising: from an attempt to unify the digital auction in 2010-2012 to a more comprehensive system that takes into account smart TV, supply chain transparency and the specifics of individual markets.
Therefore, the standard looks uneven. He doesn't have a beautiful linear biography, where each subsequent version simply and painlessly replaces the previous one. On the contrary, the history of the standard is full of side branches, parallel logics and solutions that are explained not by versioning, but by the structure of the industry itself. For example, the coexistence of OpenRTB 3.0, introduced as a new architectural line in 2018, and OpenRTB 2.6, which became an almost important update of the 2.x branch already in 2021-2022.
If you look at the protocol not as a set of fields, but as a history of decisions made by the industry, more becomes clear. The evolution of the standard clearly reads the history of interactive advertising: from an attempt to unify the digital auction in 2010-2012 to a more comprehensive system that takes into account smart TV, supply chain transparency and the specifics of individual markets.
Therefore, the standard looks uneven. He doesn't have a beautiful linear biography, where each subsequent version simply and painlessly replaces the previous one. On the contrary, the history of the standard is full of side branches, parallel logics and solutions that are explained not by versioning, but by the structure of the industry itself. For example, the coexistence of OpenRTB 3.0, introduced as a new architectural line in 2018, and OpenRTB 2.6, which became an almost important update of the 2.x branch already in 2021-2022.
Why was oRTB Needed at All
When RTB (the standard for real-time advertising bidding protocol) was just gaining weight, the market had a rather mundane problem: participants lacked a common data exchange language. The RTB Project, from which OpenRTB grew, came together in November 2010. The first mobile specification was released in February 2011, the unified OpenRTB 2.0 in June 2011, and in January 2012, OpenRTB was adopted as the IAB (Interactive Advertising Bureau) standard with release 2.1.
These dates show the original function of the standard. It appeared not as an “ideal programmer's model”, but as a way to reduce the chaos of integrations in a market that was beginning to grow out of its architecture. At the time of the project's launch, the programmer occupied only a small part of the display market. In other words, OpenRTB was created not as an add-on to a mature ecosystem, but as an infrastructure framework for an environment that was growing rapidly and needed compatibility.
These dates show the original function of the standard. It appeared not as an “ideal programmer's model”, but as a way to reduce the chaos of integrations in a market that was beginning to grow out of its architecture. At the time of the project's launch, the programmer occupied only a small part of the display market. In other words, OpenRTB was created not as an add-on to a mature ecosystem, but as an infrastructure framework for an environment that was growing rapidly and needed compatibility.
Growing Up Together
At an early stage, programmatic was primarily about display advertising. Then the market quickly began to include mobile, video, and later native segments.
The OpenRTB 2.x branch can be read as the main line of growing up of a classic programmer. The characteristic milestones are quite substantial: in January 2015, OpenRTB 2.2 strengthened private transactions for premium inventory (PMP) and signals for non-human traffic; in June 2015, version 2.3 added support for native advertising; in December 2016, OpenRTB 2.4 brought audio objects, skippability, and SSL support. In September 2017, OpenRTB 2.5 consolidated its mature phase with the introduction of header bidding, updated video signaling, and historical metrics.
Thus, oRTB did not grow abstractly, but along with the market. In a couple of years, the industry has needed a language for buying display inventory. Then — for mobile and video. Then we'll work with native formats, more complex videos, and a mature auction infrastructure that preserves backward compatibility.
The OpenRTB 2.x branch can be read as the main line of growing up of a classic programmer. The characteristic milestones are quite substantial: in January 2015, OpenRTB 2.2 strengthened private transactions for premium inventory (PMP) and signals for non-human traffic; in June 2015, version 2.3 added support for native advertising; in December 2016, OpenRTB 2.4 brought audio objects, skippability, and SSL support. In September 2017, OpenRTB 2.5 consolidated its mature phase with the introduction of header bidding, updated video signaling, and historical metrics.
Thus, oRTB did not grow abstractly, but along with the market. In a couple of years, the industry has needed a language for buying display inventory. Then — for mobile and video. Then we'll work with native formats, more complex videos, and a mature auction infrastructure that preserves backward compatibility.
One Protocol is Not Enough
By about 2017-2018, when OpenRTB had already grown to the mature 2.5 branch, it was still responsible for the auction exchange, but the market began to demand transparency of chains and the need for a common object model.
So in 2018, oRTB 3.0 and the first AdCOM appeared — common object models and a common dictionary of enumerations. In other words, the market has grown from a single protocol into an ecosystem of specifications. This is not a bureaucratic complication, but a reflection of the fact that the digital advertising industry itself has become much more complex: it is no longer enough for it to quickly trade inventory, it needs to do it in a coordinated, transparent and verifiable manner.
So in 2018, oRTB 3.0 and the first AdCOM appeared — common object models and a common dictionary of enumerations. In other words, the market has grown from a single protocol into an ecosystem of specifications. This is not a bureaucratic complication, but a reflection of the fact that the digital advertising industry itself has become much more complex: it is no longer enough for it to quickly trade inventory, it needs to do it in a coordinated, transparent and verifiable manner.
Architecture vs. Implementation
Two forces almost always collide in advertising technology.
The first is architectural. It pulls the industry towards a clean, consistent and modern model. Remove common objects, make the standard slimmer, increase transparency, and reduce the number of implicit interpretations.
The second is production. It reminds that the market already has working integrations, accumulated code, contracts, SSP and DSP infrastructure, and a huge amount of inventory that needs to be sold not in the future, but now.
A simple but important thing follows from this: standards in interactive advertising are not developing according to academic logic, where the new version completely replaces the old one. More often than not, a new architecture appears before the market is ready to live massively inside it. Until that happens, the industry takes individual elements from the new model and integrates them into the old production branch.
OpenRTB 3.0 was an architectural step forward. But the IAB Tech Lab itself later admitted that OpenRTB 3.0 was not widely adopted across the ecosystem, while AdCOM elements and related sheets were widely used in the world of OpenRTB 2.x.
The first is architectural. It pulls the industry towards a clean, consistent and modern model. Remove common objects, make the standard slimmer, increase transparency, and reduce the number of implicit interpretations.
The second is production. It reminds that the market already has working integrations, accumulated code, contracts, SSP and DSP infrastructure, and a huge amount of inventory that needs to be sold not in the future, but now.
A simple but important thing follows from this: standards in interactive advertising are not developing according to academic logic, where the new version completely replaces the old one. More often than not, a new architecture appears before the market is ready to live massively inside it. Until that happens, the industry takes individual elements from the new model and integrates them into the old production branch.
OpenRTB 3.0 was an architectural step forward. But the IAB Tech Lab itself later admitted that OpenRTB 3.0 was not widely adopted across the ecosystem, while AdCOM elements and related sheets were widely used in the world of OpenRTB 2.x.
The Grand Return of the TV
oRTB 2.6 is important not only as a “live sequel” to 2.x. In 2021-2022, the foreign advertising market has already become seriously interested in Smart TV. In a classic web auction, the market thinks of a separate display. On a Smart TV, this is no longer enough: here you need to describe the sequence of ad blocks, the length of the ad block, and the more complex content context taken into account by oRTB 2.6.
That is, 2.6 should be understood not as a random tail of the old branch, but as a practical response to the new inventory environment. The paradox of "3.0 earlier, 2.6 later" is therefore not really a paradox. This is a common form of life in a mature technology market, where the architectural future and the manufacturing present are moving at different speeds.
Despite the widespread interest in advertising on Smart TV in Eastern Europe, the market has still not fully switched to the latest version of the standard, as oRTB 2.6 also supports backward compatibility with older versions of the standard. But UMG implemented oRTB 2.6 in it's products.
That is, 2.6 should be understood not as a random tail of the old branch, but as a practical response to the new inventory environment. The paradox of "3.0 earlier, 2.6 later" is therefore not really a paradox. This is a common form of life in a mature technology market, where the architectural future and the manufacturing present are moving at different speeds.
Despite the widespread interest in advertising on Smart TV in Eastern Europe, the market has still not fully switched to the latest version of the standard, as oRTB 2.6 also supports backward compatibility with older versions of the standard. But UMG implemented oRTB 2.6 in it's products.
The Standard as a Guide
Putting this whole story together, OpenRTB turns out to be useful not only as a technical base for RTB auctions. It works as a stress map within the industry. In 2010-2012, it reflects the need for unification. In 2015-2017, the market grew towards mobile, video and native advertising. In 2018, the transition from a single protocol to a more complex ecosystem of standards with oRTB 3.0 and AdCOM 1.0. In 2021-2023, the return of application updates to the 2.x branch through 2.6 and CTV focus. And in local markets, there is also the imposition of a global standard on a specific platform and regulatory environment.
Therefore, the history of OpenRTB does not add up to a beautiful line of versions. But that's exactly what makes it valuable. It shows that programmatic is developing not as a pure engineering system, but as a compromise market — between a universal standard, real implementation, new types of inventory and the rules of specific jurisdictions. And if you look at OpenRTB that way, then the dates in this story are needed not for the sake of a calendar, but for the sake of understanding when the market changed and why the standard changed with it.
Therefore, the history of OpenRTB does not add up to a beautiful line of versions. But that's exactly what makes it valuable. It shows that programmatic is developing not as a pure engineering system, but as a compromise market — between a universal standard, real implementation, new types of inventory and the rules of specific jurisdictions. And if you look at OpenRTB that way, then the dates in this story are needed not for the sake of a calendar, but for the sake of understanding when the market changed and why the standard changed with it.