A Complete Guide To OpenRTB 2.3

Making Sense Of Programmatic Native Advertising

Table Of ContentsIntroductionHow Native RTB WorksNative Requests

Section 4.1 of Native Ads SpecSection 4.2 of Native Ads Spec

Native ResponseSection 5 of Native Ads Spec

Creative ApprovalPreparing For Programmatic Native

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 Spec and OpenRTB Dynamic Native Ads Spec provide a common language so developers can support the scaling of native ads.

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.

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.

Introduction

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.

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

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

What Else Is New?

User visits site, making ad impression available

2

1

DSPs respond with bids

including ad tags

Standard

Native SSP receives metadata

and selects the winning bid

SSP receives ad tag with banner,

rich media, or video asset to

display on site

From OpenRTB 2.3 specs:

Headline {title}Content URL {clk}Description Text {data}Thumbnail {img}Brand Logo {img}Brand Name {data}

DSPs respond with

metadata and bids on

behalf of advertisers

Native

Native SSP assembles

native ad with real-time

templating to fit into the

design and layout of the

site or app

SSP sends bid request on behalf of publisher site

OpenRTB 2.3 Changes The Game With Support For NativeNative changes the flow of RTB to include all the metadata (headline, thumbnail,

etc.) that the publisher side technology will assemble into the native ad.

3

4

Promoted by

See behind the scenesof Pepsi's new video

Promoted by

See behind the scenes of Pepsi’s new video

I Bid $18

I Bid $25

I Bid $20

Understanding The Native RequestSection 4.1 of Native Ads Spec

The Native ObjectThe 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 RequestOn 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.

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 specific formats

Native Object Requires Ad Unit And Layout

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

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:

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

What About The In-Feed Unit?

Ad Unit Layouts

Section 4.1 of Native Ads Spec

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.

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 - 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 auxiliary info like ratings, brand name, etc.• extension - you’ll see extension objects on most OpenRTB objects, allowing

exchanges and bidders to add additional custom items

Let’s look at an example: say an exchange wants the following items with a bid:

• Headline• Thumbnail image• Brand name• Brand logo• Description

Headline up to 140 characters

Promoted by Brand Name

Description up to 400 characters

Getting Started With The Request

Assets For The Request

Example For The Request

The exchange would specify an array of asset objects in the request similar to the following (in the real request this is provided in JSON, but here we are using a shorthand bullet notation for readability):

• asset 1 (headline)• req:1 [indicating this is required]• title: len:140 [indicating the bidder should provide a title, up to length 140]

• asset 2 (thumbnail)• req:1• img: wmin:1000, hmin:750, type:3 [indicating that an image should be specified

with minimum width 1000 and minimum height 750, and of type 3; in this case no maximums are specified; ‘type 3’ is referenced in a reference table, and corresponds to a thumbnail]

• asset 3 (brand name)• req:1• data: type:1, len:40 [type 1 means it’s the brand name, and a max of 40

characters]• asset 4 (brand logo)

• req: 0 [indicating this is NOT required]• img: wmin:48, hmin:48, type:2 [indicating an image for brand logo, type 2]

• asset 5 (description)• req: 0• data: type:2, len:400 [type 2 means description, and a max of 400 characters]

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.

How The Request Would Look

Understanding The Native ResponseSection 5 of Native Ads Spec

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

Headline

Brand Name

Brand Logo

Description

Thumbnail Image

Getting Started With The Response

Sharethrough Example

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.

Those would show up in the bid response roughly as follows:• asset 1 (headline)

• req:1 [indicating this is required - in this case that the bidder requires it to be shown in the ad]

• title: text: “Watch this awesome thing happen that involves my brand”• asset 2 (thumbnail)

• req:1• img: url: “http://www.mybrand.com/ads/thumbnail1.png” [a url to the image for the

thumbnail]• asset 3 (brand name)

• req:1• data: value: “My brandname”

• asset 4 (brand logo)• req: 0 [indicating this is NOT required to be shown in the ad]• img: url: “http://www.mybrand.com/ads/brandlogo1.png”

• asset 5 (description)• req: 0• data: value: “Watch this story of amazing heartwarming people engaging with each

other around my brand.”

How The Response Would Look

Creative ApprovalIAB, 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 NativeThe 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.