The introduction of the OpenRTB Specification in 2012 created a lingua franca spoken by constituents of the Programmatic Supply Chain. By creating a shared language and removing the need for each party to have slightly different interpretations of widely used attributes, the programmatic ecosystem was able to expand exponentially, which laid the foundation of a multi-billion dollar industry.
An attribute being codified in the OpenRTB Specification was a promise to the industry that the signal in question would not materially change. They are static by design so developers can confidently code to whatever attribute they’re looking at, knowing that it’ll remain largely the same.
Extensions introduced in the OpenRTB specification were intended to be a place to test new attributes for specific use cases without requiring full specification releases. If a quorum of implementers could show that an attribute had been adopted, it would then go into full specification support (aka mainlining). That was a great solution when there was a single, inordinately large release that only happened once a year, but the introduction of 2.x provided the opportunity to have up to monthly releases. That change in cadence for releases to the 2.x specification makes it faster to bring new signals to market, and leaves questions around when a new idea should be an extension, and when does a new attribute go straight to the mainline specification?
While relatively small, moving changes from an extension to official specification does require development time as well as coordination with partners to know who is using which attribute, and where. Often the extension and mainlined attributes are sent simultaneously to ensure parties that have not yet updated to the most recent version of the specification can use them, causing duplication and bloat in the bid stream. This also requires the demand side needing to look for the same information in two places, increasing the compute resources that may seem trivial at first but can be significant when multiplied by billions a day.
Introducing Provisional attributes!
Proposals for attributes which gain enough traction from the Programmatic Supply Chain Working Group, and quorum support from the Commit Group that would have originally become Official Extensions will now be added directly to the OpenRTB specification as Provisional Attributes, easing the adoption path for successful additions to the spec. This is intended to provide a path to test new features while not punishing a new idea for being successful in a way that does not undermine the stability of the OpenRTB specification.
Example of a provisional attribute in OpenRTB
Once introduced, new Provisional Attributes will have 12 calendar months to be implemented by 3 buy- and 3 sell-side constituents. If they meet that criteria, the provisional label will be removed and the attribute will officially be codified into the OpenRTB specification in the following release. If they do not meet that criteria within 12 months, they will be removed from the official specification and added as a community extension.
While this does significantly ease the upgrade path for future attributes, such as pod deduplication, attributes that are already implemented as extensions are still subject to the older upgrade path that is decided as the Programmatic Supply Chain group deems appropriate.
The first of Provisional Attribute, Pod Deduplication, aims to aid with competitive separation in podded bidding by giving sellers a way to tell buyers not to send certain categories of ads because there’s already one in the pod.
This is an exciting moment for the Programmatic Supply Chain Working Group to showcase the power of standards, and what can happen when they move quickly. If you have a proposal for a new attribute, or if you’d like to get involved in the discussion, please reach out!
ABOUT THE AUTHOR
Director of Programmatic, Product
IAB Tech Lab