The recent release of the OpenRTB 2.3 real-time-bidding protocol is one of the biggest milestones for Programmatic Native Advertising. The new version of OpenRTB introduces several enhancements, but it's most notable for supporting native inventory. This allows sellers to request native ads, and buyers to bid using native ad formats.
StackAdapt is currently integrated with over 10 native ad supply partners through OpenRTB, many utilizing OpenRTB 2.3.
What we like about OpenRTB's native support
1. It's flexible
The term "native" has been thrown around to describe numerous different ad formats (such as promoted listings, recommendation widgets, custom responsive units) that can be placed on different parts of content (such as in-feed, content wall, content stream). In OpenRTB 2.3, indicating the layout and ad unit type in the bid request supports these various types.
Each native ad format also consists of different assets. For example, recommendation widgets consist of a heading and a small image, while in-feed units consist of a heading, body text, and images that can vary from large to small. Data asset types in the bid response can be used to indicate these various forms of assets and their values.
Another key feature is the indication of minimum width and height support of image objects. Since there are no IAB standards of image sizes, each native ad placement can have a unique image size, and the buyer has to know if they have an image that can correspond to this placement.
2. It's being adopted
Several native ad technology companies, including StackAdapt and many of its partners, have upgraded their integration to OpenRTB 2.3 since its release. Previously, each company would have it's own custom integration based off OpenRTB 2.1/2.2. This would result in longer integration queues as each customization had to be handled on the technology end.
In addition, native ad networks that were previously not OpenRTB compatible are starting to develop real-time-bidding capabilities.
This is not to say that OpenRTB 2.3 is perfect, and there are still customizations to the protocol that StackAdapt has built to satisfy the needs of different integration partners.
How OpenRTB native support can be improved
1. Support for native video
OpenRTB 2.3 ships with its own native video support. However, it's not very usable, as it requires the video to be in VAST format. VAST is most suited in the pre-roll environment, where a 30 second video ad is displayed before the content video is played.
With VAST, it means that video hosted on YouTube, Vimeo, or other external platforms cannot be promoted, and requires the buyer to host the video itself. Typical VAST players also do not support play, pause, and replay capabilities. This doesn't make sense for native video, which are always stand-alone videos.
We prefer to pass video through an iFrame URL. Within this iFrame, we can support any type of video format without the supply partner needing to make changes on their end. The downside is the lack of security and control that the supply partner has. In this case, a more dynamic approach to pass different video types and their corresponding URLs (such as YouTube), similarly to data asset types, would be a practical solution. In this case the supply partner would need to support each type of video player on their end individually.
2. Support for multiple assets and images
This is more debatable, but in our experience, we have faced challenges due to different supply partners allowing or blocking different assets. Instead of having the buyer and supply depend on a separate API to understand which assets or images are allowed, it would be easier for the buyer to pass different combinations of assets or images, and for the seller to block certain combinations if needed.
Yang Han, Co-founder/CTO