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.
How Native RTB Works
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
Paid Search Units
In-Ad (IAB Standard) with native element units
Custom (can't be contained)
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 ID
Reserved for exchange formats
Reserved for exchange specific layouts
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
How the Request Would Look
The exchange would specify an array of asset objects in the request similar to the following:
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
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:
• Thumbnail Image
• Brand Name
• Brand Logo
How the Response Would Look
Those would show up in the bid response roughly as follows:
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.
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.
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.