By James Wilhite, Director of Product @Publica
What is it?
Before oRTB (Open Real-Time-Bidding) came along, server-to-server connections were very custom and time consuming. Partners on either side of the server connections had to make sure that the parameters that they felt were most important were being sent correctly, and their naming conventions had to be normalized. For example, something as simple as the app store URL could be known as storeurl, appstoreurl, appurl, or anything else that an engineer could come up with that made sense to them. If a publisher named the object storeurl, they would tell that to their SSP and, in turn, the SSP would map that object to whatever they had it named as in their system.
Why Use it?
- ECPMs are lifted because oRTB sends in dynamic bids via the bid response. These dynamic bids then compete in the auction at their true value instead of being slotted in as a value CPM to compete at a static price.
ORTB is the fastest way to scale in a CTV environment. Once the servers are set up to communicate with each other, there isn’t any maintenance needed to keep them running. In stark contrast to a VAST tag integration, you won’t need to regularly reorder your demand stack, and you won’t run into issues with missing macros or typos in your ever-expanding list of query params.
How can I learn more?
The version of oRTB that currently has the most adoption is version 2.5. For those who want to dive into what can be sent via oRTB, the spec for version 2.5 can be found on IAB’s website. It really isn’t as daunting as it first appears, and all of the information regarding data that can be sent can be found in section 3 of the document.
If your company is already using oRTB, try to get your hands on a sample bid request and use the spec to see which parameters are being sent to your partners. Often it takes both the business-side and the tech-side working together to implement oRTB in the most efficient manner while optimizing for more demand.