When Native ads first began to gain adoption, they were largely considered to be customized executions due to their highly engaging and organic nature. Unlike banner ads, which consist of one fully formed asset, Native ads are primarily composed of three creative assets – headline copy, description copy and an image. OpenRTB 2.2 was very simple: a publisher would make a request which would then be met with one asset: a banner. Since multiple assets need to be assembled in order for a Native ad to be served, many have fallen for the common misconception that Native programmatic is an oxymoron. If banner ads only require one completely assembled asset, how can Native ads be compatible with real-time bidding (RTB)?

OpenRTB 2.3 and Native API Change the Game for Native Advertising

Native advertising and content distribution is so unique to any prior form of advertising that there were significant technical barriers to overcome, and industry-wide standards needed to be put in place in order to grow Native and achieve widespread adoption. When the IAB introduced OpenRTB 2.3, they also released the Native Ads API Specification, which established an optional new Native Object as part of the RTB request, that indicates if an available impression is to be a Native impression.

Significant time and resources were dedicated to building this specification, which supports the necessary communication between DSPs and SSPs to scale the delivery of Native ads in RTB environments. For the first time, a technology existed that enabled advertisers and publishers to take these deconstructed assets and assemble and deploy them in real-time.

The Native Ads API specification established two main types of inventory classification, each of which have specific IDs, which is how the DSPs and SSPs communicate:

  • 6 types of Native ad units were established (In-feed, In-Ad, Recommendation Widget, Paid Search, Promoted Listings and Custom).
  • A variety of ad unit layouts within a publisher’s website were also instituted, including Content Wall, App Wall, News Feed, Chat List, Carousel, Content Stream, Grid adjoining the content and hundreds of other Reserved for Exchange specific layouts.

This spec was designed to serve ads in a way that had never been done before, specifically standardizing Native ad units to be compatible with programmatic technologies.  If you’re not using these standards then you’re not executing Native with the most advanced technologies available, and more importantly you’re not doing it in a way that can scale.

What has the Industry Been Up to Since Then?

OpenRTB 2.3 and the Native API completely revolutionized the real-time delivery of Native ads, but this industry is constantly innovating toward better user experiences. In March 2016, the IAB released Native Ads API Specification v 1.1 as part of OpenRTB 2.4, an iteration on 2.3.  While still nascent, this latest spec provides important advancements in the classification of inventory and standardization of creative assets, enabling even greater programmatic scale for Native advertising. Here are the two main updates.

  • Establishment of Context Within Feed: Marketers and publishers create content differently for various environments. They can now provide context to the type of feed they would like each piece of content to appear in – content feeds, social feeds and product feeds.
  • Standardization of Creative Assets: As mentioned above each Native ad is comprised of 3 creative assets. New standards have been set for the headline and description in terms of copy length, and image in terms of aspect ratio and size.

But it doesn’t end there. The IAB is already working on a new and improved spec with OpenRTB 2.5, and the Bidtellect team is contributing to it alongside our industry partners. We’ll be sure to keep you updated as the Native programmatic ecosystem continues to grow and innovate!