There’s an updated standard in town: OpenRTB 2.3. The latest version incorporates guidelines for native advertising creative within a real-time bidding environment, accounting for metadata like headline, content URL, description text and images.
The standard should mean more native advertising will flow through more exchanges with fewer hiccups, right? Well, not exactly. AdExchanger asked industry experts:
How will OpenRTB 2.3 change the native ecosystem?
Click below or scroll down to read their responses.
- Neal Richter, chief scientist, Rubicon Project and co-chair of OpenRTB
- Rob Griffin, EVP, global head of digital, Havas Media Group
- Curt Larson, VP for product, Sharethrough
- Justin Choi, CEO of Nativo
- Eric Berry, CEO of TripleLift
Neal Richter, chief scientist, Rubicon Project and co-chair of OpenRTB
“The new native spec is a big step forward for OpenRTB and the programmatic ecosystem. … Much of the demand [in mobile] is banner ads adapted to mobile inventory unit sizes. Native ads in mobile are essentially new ad formats that adapt to the mobile environment’s look and feel. The result is better ads, better engagement and better results for both the advertiser and the developer. … Standardization brings scale. With the new potential for revenue, more app developers will enter the market. Mobile monetization via native ads is underdeveloped today and a key direction is to expand the reach into the programmatic world. … Finally, by standardizing the process and removing the need for the integration of multiple SDKs, mobile apps will render more quickly and will be less likely to crash, thus delivering an optimal user experience.”
Rob Griffin, EVP, global head of digital, Havas Media Group
“The big payoff is clarifying what is “real” native. Some native opportunities are just standard rich media ads in the guise of content while others are truly unique opportunities integrated into the actual publisher’s content with new ad formats. So hopefully having a native designation from the 2.3 proposal will help with this. The goal is to create greater granularity and clarification when bidding, which is important for native. It’s also important to be able to designate and define mobile optimized sites, which is another part of 2.3. I also like the idea of having test mode for modeling bid scenarios. But I do wonder the negative impact of a price race to the bottom and [a lack of] new customized formats if the sole goal is scale.”
Curt Larson, VP for product, Sharethrough
“Now that native has matured as a concept and the programmatic standard is finalized, there will be a tremendous acceleration of native investment overall and programmatic in particular, with programmatic ability a standard part of the equation for all major native platforms by 2016. Programmatic workarounds and non-standard workflows will soon be replaced by the official standard. One of the most immediate impacts of OpenRTB 2.3 will be felt on mobile. Mobile has the potential to receive the majority of native RTB impressions, due to the fact that supply often outstrips demand for native inventory on the mobile web.”
“The standard is going to open the floodgates to feed-based monetization, but it will be the evolution of banners rather than the evolution of native. …. Most advertising is going to move to the feed, and it will start with the mid-tail to long-tail publishers adopting click-out native executions. We haven’t seen much interest from the premium guys, because it effectively creates a trade-off between user engagement and revenue. Eventually, as more monetization moves into the feed, all publishers will have to evaluate how they’re maximizing revenue there. We’re not so naive to expect that every publisher is going to remain with “true native.” Easier and more standardized paths to scaling native can be a good thing for the industry, provided stakeholders don’t lose sight of the user. Native is ultimately about content and content is about engagement, not interruption.”
“The OpenRTB 2.3 native spec merely provides a language clarifying how to specify an image or a caption and responding with assets. It doesn’t address the fundamental challenges of native at scale. The spec doesn’t define what kind of assets people should be using. The buy side will have to assemble a large set of assets for each exchange, or do a custom build for each exchange, instead of providing for a single, common set of assets. There’s complexity in figuring out in real time what they’re asking for. Each exchange is going to come up its own specification, and then each different DSP is going to have to build a custom native adapter for each different exchange. So while OpenRTB 2.3 provides language for custom adapters, there’s still a need for a custom adapter.
OpenRTB 2.3 is a specification for requesting certain assets, and responding with certain assets. The problem is that it’s not predictable: The exchange could theoretically define any arbitrary bid request that a bidder might not be capable of understanding. Our OpenRTB 2.2 extension provided a very simple, predictable protocol for buying native. We do expect people will migrate to 2.3 in the future, but only when there is more certainty around the protocol.”
