Coming Soon: A Programmatic Native Standard That Will Change The Industry

curt-larsonData-Driven Thinking" is written by members of the media community and contains fresh ideas on the digital revolution in media.

Today’s column is written by Curt Larson, vice president of product at Sharethrough.

In late 2013 Facebook kicked off the merger of native advertising and real-time bidding with the introduction of FBX and its exchange ads. To accommodate the social giant, major demand-side platforms (DSP) backed FBX by adding support for creative metadata, such as headlines, thumbnails and the like.

Seeing the success of FBX, web publishers and ad tech companies began hypothesizing about how they could bring the same native RTB capabilities to sites and applications outside of Facebook.

Those murmurs have become louder over the past two years. Now we are at a point where the worlds of native ads and RTB will merge with the upcoming release of a new standard called OpenRTB 2.3.

The launch of OpenRTB 2.3 is an inflection point for the native industry that will unleash a flood of new development on both the supply and demand sides as they build support for it.

The standard puts the final nail in the coffin in terms of scale. It also challenges the industry to avoid some of the programmatic pitfalls for display, namely a race to the bottom and a reputation for low-quality remnant inventory. None of these traits are inherent in programmatic.

Display's answer to these issues has principally been private exchanges, but that's not the only path and isn’t necessarily the best. All parts of the native ad ecosystem have a vested interest in maintaining quality while not forcing everyone to strike private exchange agreements.

The New Native Standard

Currently in public review at the IAB and scheduled for ratification sometime in the next few months, OpenRTB 2.3 will be the first RTB spec to provide a clear programmatic standard for native. It principally extends prior RTB standards by adding native to existing banner and video rules. That new native object was built from the ground up to support the types of data that needs to be exchanged to transact a native ad.

On the request side, the native object describes the unit being put up for auction, in terms of elements, such as thumbnail, brand name or logo and native type, as determined by the IAB’s Six Core Types.

On the response side, we see the single biggest distinction from banner responses in that all metadata, including headline and brand logo, must be included with the response. In banner responses, you typically just provide a pointer to a piece of code that is thrown on the page by the browser; the DSP doesn't need any knowledge of the content. But for native responses, just like for FBX, the DSP must be cognizant of the creative’s individual elements and metadata.

This new standard will put native at programmatic parity with the display and video industries. And while that parity answers questions related to scale, it also opens up new issues.

Moving Mobile Forward

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.

This delta is largely caused by the lack of programmatic buying standards. The added benefit for buyers in this scenario is that when Open RTB 2.3 plugs into mobile native inventory, it will open up one of the highest-impact mobile inventory channels to programmatic buying, rather than following desktop’s history of initially making lower-quality inventory available.

The major DMPs, whose data is used prominently in programmatic targeting, have all added support for mobile over the past few years, and although data density may be lower than desktop, the same targeting abilities advertisers are used to on desktop are available on mobile.

The Quality Issue

There is genuine worry that RTB will reduce the premium nature of native ads. This is obviously a concern for any publisher that is considering opening up its coveted native placements to RTB demand sources, which for display have often resulted in lower quality.

Due to their integration and visual similarity to organic content, publishers are focusing on the quality of creatives in native ad placements to avoid denigrating the user experience with low-quality advertisements directly within their content feeds.

Because RTB is a technology for transacting, many hope brand advertisers will be just as willing to distribute their high-quality brand advertising as low-quality DR advertising. Yet despite a brand’s willingness to use programmatic for their most premium content, it will also be up to publishers to make sure they have advanced controls to dictate what forms of creative and types of buyers they accept for their native ad inventory.

Looking Ahead

One principal difference in native is the requirement that all data about the creative must be included in the bid. Thus, DSPs must have the interface and capability to ingest, edit and transact in creative metadata. This will be the principal change on the demand side. Some DSPs did some of this work when they built support for FBX.

On the supply side, the changes are more extensive since the entire technology stack for delivering metadata into publisher sites is different. Technology that assembles the components in real time based on the publisher site design, for example, is quite different from the technology that puts an image in an iframe. Numerous new native supply-side platforms already support dynamic templating for native, though, so the solutions are available.

In a nutshell, we have publisher-side solutions, a standard and the beginning of needed changes on the DSP side. It’s almost time for us to start connecting the dots.

Follow Sharethrough (@sharethrough) and AdExchanger (@adexchanger) on Twitter.


Add a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>