TLDR; Choose oRTB for CTV Inventory
Where does Open Real-Time Bidding come from?
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.
What is Open Real-Time Bidding?
Open Real-Time Bidding (ORTB) is a standardized framework that is used for servers to communicate with each other in a common language.
How does ORTB work?
ORTB uses JSON (Javascript Object Notation) to organize all of the parameters into parent-child relationships. Parent objects can be things like App, Site, Video, User, and Device. Nested within these parent objects on the bid request side are all of the details about the user, their device, the inventory that they are currently viewing, and many other parameters that enrich the request with data that is important for buyers in their decision making algorithms. In return, the buyers send back an oRTB response that contains their bid value, creatives, and anything that the publisher will need to serve a creative if that buyer should win the auction.
Why Use it?
Two important KPIs in CTV today are eCPMs and latency. Higher eCPMs are critical for the business-side, and lower latencies are critical for the technology-side. With oRTB, both of these metrics are improved upon what they would be in a javascript or VAST tag implementation.
- 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.
- Latencies are greatly improved when oRTB is being used within a CTV environment because both technologies are built to run within a server environment—there is no need for the complex code of javascript or VAST tags. ORTB also removes any potential passbacks or redirects from the request flow, further cutting down the time that it takes to pocket valuable CPMs and avoid timeouts.
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.
