UPDATE: A Guide To OpenRTB 2.4 And Native 1.1, The New IAB Standards Fueling Programmatic Native

Introduction

OpenRTB 2.3, a collection of advertising recommendations from the Interactive Advertising Bureau, sets a standard for how native ads can be bought and sold through a real-time auction. With new support for native advertising, the OpenRTB 2.3 API and OpenRTB Dynamic Native Ads API provide a common language so developers can support the scaling of native ads.

In this guide you’ll understand what the new specs mean for your ads. From the bid requirements to the assets needed to automate native placements and updates to the call and response process, you’ll be able to take advantage of the new guidelines in no time.

The key difference between Real-Time-Bidding (RTB) standardization for native ads and display ads comes down to one word: metadata.

With banners, all that was needed was a single file. With native, the ad unit itself is composed of multiple elements that must be transferred through the bid request and bid response.The headline, thumbnail image, brand name, brand logo, and description must all be considered by publisher and advertiser alike. Not every publication will require every piece of metadata, nor will every advertiser have every element in a native ad. At minimum, both parties should optimize for the basics – headline, thumbnail, and description – and consider how brand assets fit into the mix. It may seem like a more complex process, but it frees up advertisers from relying on their designers and does not require extra work for publishers using modern ad technology.

Where It All Began

Don’t let the dot fool you – OpenRTB 2.3 is no incremental update. Since the standard was set in 2011, OpenRTB continues to update alongside the ever-evolving digital ad industry and the technology behind it.

A New Standard For Native To Scale

The support for native advertising in OpenRTB 2.3 is the most significant change since OpenRTB 2.0, which unified display, mobile, and video. This ushers in a new era for native, and will likely result in a flurry of activity and new liquidity as native ads scale.

OpenRTB 2.3 principally extends OpenRTB 2.2 by adding a new object, Native, that sits next to the existing Banner and Video objects. When there are only two top-level objects, adding a third is a pretty big deal. The new Native Object was built from the ground up to support the types of data that need to be exchanged to transact a native ad.

What Else Is New?

For the most part, the rest of OpenRTB is the same. Targeting and optimization, which now work for native, still work banner and video.



Understanding The Native Request

Section 4.1 of Native Ads Spec

Native Object Requires Ad Unit and Layout

The Native Object

The Native Object defines an available native placement and must be included directly in the impression object in order to be passed through the bidstream.

The Native Request

On the request side, the Native Object describes the unit being put up for auction - the elements (such as thumbnail, brand name, brand logo, etc), and the general type (from among the six IAB categories), etc.

In the native request, we are principally concerned with two things: describing the native unit that’s being bid on and describing what the publisher needs to render the ad.

There are two principal ways to describe the native inventory: Ad Unit ID and Layout ID. This method of specifying ad design can be confusing and will likely evolve in future versions of the spec. SSPs and DSPs now communicate using these IDs. Whether you're a DSP or a SSP you’ll need to think about how your ad will look. First, select the type of ad you show on your site from the ad unit table. Next, select the desired layout.

The ad unit comes from the IAB Native Advertising Playbook definition of the 6 types of native:

Ad Unit ID Description
1 Paid Search Units
2 Recommendation Widgets
3 Promoted Listings
4 In-Ad (IAB Standard) with native element units
5 Custom (can't be contained)
500+ Reserved for exchange formats

What about the in-feed unit?

You’ll note that the ‘feed unit’ type has been removed, versus what was defined in the playbook, the logic being that it’s really a layout (see below).

The layout on the other hand was developed by the group working on the native ad spec, and includes the following options:

Ad Unit Layouts

Layout ID Description
1 Content Wall
2 App Wall
3 News Feed
4 Chat List
5 Carousel
6 Content Stream
7 Grid adjoining the content
500+ Reserved for exchange specific layouts

Section 4.1 of Native Ads Spec

Getting Started with the Request

Our next task in the native bid request is to describe the type of assets that need to be included in the bid response. For example, many publishers need a headline, thumbnail, and brand name. Some may also want a brand logo, app rating, and other metadata. The Open RTB 2.3 native spec allows the requester (publisher) to define which fields are available and which are required, along with their specific requirements, such as the character length of a headline.

Assets for the Request

Technically, the request is done by providing an array of assets in the bid request. This array of assets is then returned in the response. The fields in the bid request are concerned with specifying the available assets, which are required, and the allowed attributes, whereas on the response the bidder provides the actual assets, and can similarly specify whether they require those assets to be in the ad.

In this array of assets, each item specifies a type of resource it’s requesting:

  • title - the headline of the ad
  • image (img) - can be used for a variety of images, principally the thumbnail
  • video - if a video can be shown, this allows it to be specified (utilizing the already-standardized VAST protocol)
  • data - used for auxillary info like ratings, brand name, etc
  • ext - you’ll see extension objects on most OpenRTB objects, allowing exchanges and bidders to add additional custom items

Example for the Request

So let’s look at an example. Let’s say an exchange wants the following things with a bid:

  • Headline - up to 140 characters
  • Thumbnail image
  • Brand name
  • Brand logo
  • description

How the Request Would Look

The exchange would specify an array of asset objects in the request similar to the following:

[
  {
    id: 1, # Headline
    req: 1, # Required
    title: {
      len: 140 # Length
    }
  },
  {
    id: 2, # Thumbnail Image
    req: 1,
    img: {
      wmin: 1000,
      hmin: 750,
      type: 3
    }
  },
  {
    id: 3, # Brand Name
    req: 1,
    data: {
      type: 1,
      len: 40
    }
  },
  {
    id: 4, # Brand Logo
    req: 0, # Not Required
    img: {
      wmin: 48,
      hmin: 48,
      type: 2
    }
  },
  {
    id: 5, # Description
    req: 0,
    data: {
      type: 2,
      len: 400
    }
  }
]

This is one specific example, but hopefully you can see how there is great flexibility in this structure to support different types of native ads with different field needs. We’ll see how this gets reflected back in the response below.


Understanding the Native Response

Section 5 of Native Ads Spec

Getting Started with the Response

Native responses differ fundamentally from display responses in that all the data about the ad must be returned with the response. In display, only an image or a pointer to assets must be returned; in fact, in some cases, the DSP doesn’t even know the content at the time of the bid — it is only assembled at render time. For native, all this info must be present in the bid response. The bid response echoes the request in structure. Recall in our example above that the exchange requested the following assets:

  • Headline
  • Thumbnail Image
  • Brand Name
  • Brand Logo
  • Description

Sharethrough Example

How the Response Would Look

Those would show up in the bid response roughly as follows:

[
  { # Headline
    id: 1 # Headline
    req: 1, # Required
    title: {
      text: "Watch this awesome thing happen that involves my brand"
    }
  },
  {
    id: 2 # Thumbnail Image
    req: 1,
    img: {
      url: "http://www.mybrand.com/ads/thumbnail1.png"
    }
  },
  {
    id: 3 # Brand Name
    req: 1,
    data: {
      value: " My Brand Name"
    }
  },
  {
    id: 4 # Brand Logo
    req: 0, # Not Required
    img: {
      url: "http://www.mybrand.com/ads/brandlogo.png"
    }
  },
  {
    id: 5 # Description
    req: 0,
    data: {
      value: "Watch this story of amazing heartwarming people engaging with each other around my brand."
    }
  }
]

As you can see in the response, we provide the values requested in the request object. Logical enough. The concept of required is flipped now we mean that as the bidder we require this element to be in the ad. We’d expect our bid to be declined if the supplier is unable to show that element in the ad.

For Engineers

One thing that might be a little confusing is that in the response, you no longer say whether this is an image, of what type, etc. That match is done purely based on ID - so if you sent a request for asset #5 of type image, etc., then the returned asset #5 will be assumed to be for that. There is no need to specify those other details in the response.


Creative Approval

IAB, which creates the OpenRTB spec, hasn’t included anything about creative approvals, but it’s likely that ad exchanges will implement their own procedures. This is especially important for native ads because the content tends to inherit aspects of a publication’s voice, so a keen eye is kept on quality. Supply sources should be sure to implement a creative approval service and provide strong controls to account for this. We could easily see a standard for this process in a future iteration of OpenRTB.


Preparing for Programmatic Native

The principal difference in native is providing all the data about the creative 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. Luckily, some DSPs have done the work already in supporting FBX.

On the supply side, the changes are more extensive since the entire technology stack for delivering metadata into the publisher site is different: technology to assemble the components in real-time based on the publisher site design is quite different from the technology to put an image in an iframe. Many new native SSPs already support dynamic templating for native, so the solutions are there.

So we have publisher-side solutions, we have a standard, and we have at least a start on the changes needed on the DSP side. Time to start connecting the dots.


Download Guide