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!
As the digital advertising ecosystem has become increasingly crowded with multiple devices and formats, marketers must have the right strategies in place to drive optimal value for each campaign. To maximize the efficiency of direct response strategies, breaking campaigns out by product (in-ad, rec widget, in-feed) and device (desktop, mobile, tablet) can create better efficiencies that will help achieve campaign goals.
The overarching factor in setting up your campaign is setting up a pricing structure that will, in the end, back into the eCPC or eCPA expected by the advertiser. Dynamic pricing allows a campaign manager to bid higher/lower on inventory. Dynamic pricing allows for various pricing structures by device, product, creative, site, etc. – whatever works best in hitting goal. If certain premium inventory on desktop can be won at $3 while mobile inventory can be won at $.50 then a dynamic strategy will be implemented in order to obtain price efficiency. In the end the only requirement from the client side is to not exceed their contracted dynamic cost per click (CPC) or CPM.
You could, for example, price In-Feed higher than In-Ad or RecWidget if you know the former will perform to goal at a higher rate while also garnering more supply. If you are bidding on In-Feed at a $3CPC, and your CTR is .10%, then you will back into an average RPM on a placement of $3. A $3RPM will beat out any bid that is lower and allow you to win more inventory compared to an In-Feed campaign running on a $2CPC with a 10% CTR (equaling a $2RPM).
When setting up a dynamic campaign at a granular level there are typically two ways to come to a conclusion on what product and device break-out provides the best efficiencies. The first way is to prospect: to open the campaign to all products and devices with run of network contextual targeting to isolate placements that achieve the eCPA goal. This strategy is usually used when there are no historical learnings with regard to the advertiser, vertical and/or conversion goal.
However when there are historical learnings, the second strategy is to run only certain products and devices. For example, if you are running a campaign that is based on form completions, you will most likely find that mobile can work as well as desktop in terms of garnering conversions at a low spend ratio. On the other hand, campaigns with conversion goals that require actions further down the funnel, such as booking a hotel, usually perform best on desktop. With this type of historical learning, you can set up pre-optimizations to achieve best performance.
To maximize dynamic pricing, various strategies are employed to back into a client’s goal. There are three major avenues:
- Prospecting: This is implemented when a campaign first launches. This campaign will be priced extremely low relative to the other methods and is meant to cast a wide net on an entire network. The idea is to identify pockets of inventory that can perform to goal. Subsequently, these performing sites and/or placements will be shifted into the proven campaign.
- Proven Targeting: The most efficient method is to set up a proven or a whitelisted campaign, in which only sites and placements which have exceeded an advertiser’s KPI benchmarks are included in the campaign. The proven campaign is usually implemented from the learnings of a prospecting initiative. It is implemented at a higher price relative to the other strategies, allowing the campaign to win more impressions and clicks on inventory that is backing into the client’s goal.
- Contextual Targeting: This is another strategy that is typically used when an advertiser has strict branding guidelines in addition to a conversion goal. In this case, sites that perform best are plucked from the contextual campaigns and placed on a proven site list. This proven contextual site list campaign is priced higher in order to max out delivery in an attempt to back into goal.
To learn more about how you can maximize dynamic pricing for your campaigns, reach out to a member of the Bidtellect team through our website to get started!