A Complete Guide To OpenRTB 2.3 Making Sense Of Programmatic Native Advertising
Table Of Contents Introduction How Native RTB Works Native Requests Section 4.1 of Native Ads Spec Section 4.2 of Native Ads Spec Native Response Section 5 of Native Ads Spec Creative Approval Preparing For 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 Spec and OpenRTB Dynamic Native Ads Spec 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.
OpenRTB 2.3 Changes The Game With Support For Native Native changes the flow of RTB to include all the metadata (headline, thumbnail, etc.) that the publisher side technology will assemble into the native ad. 1 User visits site, making ad impression available 2 SSP sends bid request on behalf of publisher site 3 Native Standard DSPs respond with metadata and bids on behalf of advertisers DSPs respond with bids including ad tags I Bid $18 I Bid $25 I Bid $20 4 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} See behind the scenes of Pepsi's new video Promoted by Native SSP assembles native ad with real-time templating to fit into the design and layout of the site or app See behind the scenes of Pepsi s new video Promoted by
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 specific 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 - 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 alreadystandardized 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 Example For The Request 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 Description up to 400 characters Promoted by Brand Name
How The Request Would Look 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.
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 Thumbnail Image Headline Brand Name Description Brand Logo
How The Response Would Look 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. 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.