An update to the IAB standard for buying and selling native ads at scale was recently released for public comment. The spec, known as Native 1.1, is an extension of a larger update to the OpenRTB 2.3 protocol, soon to be 2.4, that in 2015 ushered in an era of standardization for native advertising: programmatic native.
I’m confident in saying the release of the Native 1.1 extension marks a major advancement for the native ad market and is specifically designed to enable broader growth of programmatic native.
While OpenRTB 2.3 was a landmark achievement to write a protocol to enable the highly standardized world of Real-Time Bidding to be compatible with native ads (which were once considered to be solely custom ad executions), as explained here, there is still a lot of ground to make up to unlock the true potential of programmatic native advertising, and 1.1 is a major step on that road.
These updates stand to make 2016 the year that native ads become a core element of the RTB landscape.
The Shortcomings Of Native 1.0
OpenRTB 2.3 added an entirely new object to the standard for native, and the Native 1.0 spec defined what can go in that native object: rather than image references for banners and video references for pre-roll, the native object includes the actual metadata for the ad — things like headline, description, thumbnail, and brand name.
The evolution from fixed ad serving to component-based ad serving is the fundamental breakthrough that allows native ads to be integrated to the RTB workflow.
The Native 1.0 spec created a generic framework by which a supply source (SSP/exchange) can request the specific items needed as part of the ad, such as thumbnail size and headline lengths. A demand source (DSP/bidder) is then required to respond with assets that match the specifications of the supply source.
This was a good generic framework, but the challenge has been that no one specified what those assets should look like. Each supply source was free to define their own standards for things like image size, aspect ratio, headline length, brand name length and more.
As you can imagine, this created challenges for the demand side. As a demand platform, how can you be prepared to respond with any given thumbnail size? While there might be a way to resize thumbnails to fit, how do you resize a headline if the supply source requests a shorter headline than you have — truncating a headline doesn’t cut it.
For display, Demand Side Platforms know that if you have a few common sizes, you’re set for most inventory. With native inventory, the lack of standardization has lead to missed opportunities or mis-rendered ads.
To make matters worse, some supply sources have yet to create their own standards, leaving it to each publisher to set requirements. This means every request from every supply source can be different.
The second major challenge with the 1.0 specification was in how native ad unit types were defined. The Native 1.0 spec followed the nomenclature of the Native Advertising Playbook, which has since been updated with the In-Feed Deep Dive.
When applied to the native spec, the classifications of the original playbook created confusion on the DSP side in terms of classifying inventory due to the commingling of context and layout concepts and some overlapping or unclear definitions. In many cases, inventory is being purchased by named supply source, in the lack of standard classifications, hampering scalability.
Native 1.1 Brings Specificity and Structure To Programmatic Native
The new OpenRTB Native 1.1 Extension, now out for public comment before being released officially in winter, continues to allow support for the original standard, but has added a new means of classifying inventory and will eventually deprecate the old method.
Native inventory is now classified in two ways:
1. Context
What type of content surrounds the ad unit? There are three primary classifications, according to the IAB Deep Dive On In-Feed Ad Units: content feeds, social feeds and product feeds. Each primary classification has sub-classifications.
2. Placement Type
What is the design of the ad unit being purchased? This list aligns similarly to the original playbook but in a streamlined fashion:
• In the feed of content
• In the atomic unit of the content, i.e. on an article page or single image page
• Outside the core content, i.e. in the ads section on the right rail or as a banner-style placement near the content
• Recommendation widget, most commonly presented below the article content
These new classifications should enable native to scale more broadly as DSPs can represent inventory by context and placement type, rather than needing to separately represent each supply source.
With nomenclature taken care of, fixing the asset requirements was also a top priority with Native 1.1. Given the free range of early native standards, agreeing on a tighter standard wasn’t easy, and obviously will result in some platforms needing to make changes, but it’s a necessary step on the way.
The Road To Native Standardization
To begin the process of standardization, the IAB working group inventoried the current asset requirements of all the native supply sources we could find, including social platforms like Facebook and Twitter, and the largest programmatic native ad platforms like Sharethrough, Google, Yahoo! and MoPub.
This gave us a picture of the current world, and in some areas clear patterns emerged in terms of how various fields were being used and some differing interpretations of the standard.
Through numerous working sessions with key industry representatives, we figured out a set of recommendations for the primary asset types.
While supply sources are still free to deviate from the standard, there will be an incentive for all supply sources to follow the standards in order to expose themselves to as much demand as possible.
Going forward, DSPs can be confident that if they support these asset types they will be able to bid on most native supply.
Below are the specific standards that were agreed upon:
How Images Are Handled In OpenRTB 2.4
How Text Elements Are Handled In OpenRTB 2.4
2016: Native Programmatic Comes Of Age
Taken together, the changes to inventory classification and asset requirements, along with other minor bug fixes and enhancements to the spec, should enable the type of rapid scaling of native programmatic we anticipate for 2016 and we encourage the ecosystem to adopt these standards as quickly as possible.
Standardizing on sizes enabled display to scale programmatically, and we’ve now done the same for native.
While we’ve been talking about programmatic native for a couple years now, scale is still small and often proprietary. In 2016, that will all change.
An update to the IAB standard for buying and selling native ads at scale was recently released for public comment. The spec, known as Native 1.1, is an extension of a larger update to the OpenRTB 2.3 protocol, soon to be 2.4, that in 2015 ushered in an era of standardization for native advertising: programmatic native.
I’m confident in saying the release of the Native 1.1 extension marks a major advancement for the native ad market and is specifically designed to enable broader growth of programmatic native.
While OpenRTB 2.3 was a landmark achievement to write a protocol to enable the highly standardized world of Real-Time Bidding to be compatible with native ads (which were once considered to be solely custom ad executions), as explained here, there is still a lot of ground to make up to unlock the true potential of programmatic native advertising, and 1.1 is a major step on that road.
These updates stand to make 2016 the year that native ads become a core element of the RTB landscape.
The Shortcomings Of Native 1.0
OpenRTB 2.3 added an entirely new object to the standard for native, and the Native 1.0 spec defined what can go in that native object: rather than image references for banners and video references for pre-roll, the native object includes the actual metadata for the ad — things like headline, description, thumbnail, and brand name.
The evolution from fixed ad serving to component-based ad serving is the fundamental breakthrough that allows native ads to be integrated to the RTB workflow.
The Native 1.0 spec created a generic framework by which a supply source (SSP/exchange) can request the specific items needed as part of the ad, such as thumbnail size and headline lengths. A demand source (DSP/bidder) is then required to respond with assets that match the specifications of the supply source.
This was a good generic framework, but the challenge has been that no one specified what those assets should look like. Each supply source was free to define their own standards for things like image size, aspect ratio, headline length, brand name length and more.
As you can imagine, this created challenges for the demand side. As a demand platform, how can you be prepared to respond with any given thumbnail size? While there might be a way to resize thumbnails to fit, how do you resize a headline if the supply source requests a shorter headline than you have — truncating a headline doesn’t cut it.
For display, Demand Side Platforms know that if you have a few common sizes, you’re set for most inventory. With native inventory, the lack of standardization has lead to missed opportunities or mis-rendered ads.
To make matters worse, some supply sources have yet to create their own standards, leaving it to each publisher to set requirements. This means every request from every supply source can be different.
The second major challenge with the 1.0 specification was in how native ad unit types were defined. The Native 1.0 spec followed the nomenclature of the Native Advertising Playbook, which has since been updated with the In-Feed Deep Dive.
When applied to the native spec, the classifications of the original playbook created confusion on the DSP side in terms of classifying inventory due to the commingling of context and layout concepts and some overlapping or unclear definitions. In many cases, inventory is being purchased by named supply source, in the lack of standard classifications, hampering scalability.
Native 1.1 Brings Specificity and Structure To Programmatic Native
The new OpenRTB Native 1.1 Extension, now out for public comment before being released officially in winter, continues to allow support for the original standard, but has added a new means of classifying inventory and will eventually deprecate the old method.
Native inventory is now classified in two ways:
1. Context
What type of content surrounds the ad unit? There are three primary classifications, according to the IAB Deep Dive On In-Feed Ad Units: content feeds, social feeds and product feeds. Each primary classification has sub-classifications.
2. Placement Type
What is the design of the ad unit being purchased? This list aligns similarly to the original playbook but in a streamlined fashion:
• In the feed of content
• In the atomic unit of the content, i.e. on an article page or single image page
• Outside the core content, i.e. in the ads section on the right rail or as a banner-style placement near the content
• Recommendation widget, most commonly presented below the article content
These new classifications should enable native to scale more broadly as DSPs can represent inventory by context and placement type, rather than needing to separately represent each supply source.
With nomenclature taken care of, fixing the asset requirements was also a top priority with Native 1.1. Given the free range of early native standards, agreeing on a tighter standard wasn’t easy, and obviously will result in some platforms needing to make changes, but it’s a necessary step on the way.
The Road To Native Standardization
To begin the process of standardization, the IAB working group inventoried the current asset requirements of all the native supply sources we could find, including social platforms like Facebook and Twitter, and the largest programmatic native ad platforms like Sharethrough, Google, Yahoo! and MoPub.
This gave us a picture of the current world, and in some areas clear patterns emerged in terms of how various fields were being used and some differing interpretations of the standard.
Through numerous working sessions with key industry representatives, we figured out a set of recommendations for the primary asset types.
While supply sources are still free to deviate from the standard, there will be an incentive for all supply sources to follow the standards in order to expose themselves to as much demand as possible.
Going forward, DSPs can be confident that if they support these asset types they will be able to bid on most native supply.
Below are the specific standards that were agreed upon:
How Images Are Handled In OpenRTB 2.4
How Text Elements Are Handled In OpenRTB 2.4
2016: Native Programmatic Comes Of Age
Taken together, the changes to inventory classification and asset requirements, along with other minor bug fixes and enhancements to the spec, should enable the type of rapid scaling of native programmatic we anticipate for 2016 and we encourage the ecosystem to adopt these standards as quickly as possible.
Standardizing on sizes enabled display to scale programmatically, and we’ve now done the same for native.
While we’ve been talking about programmatic native for a couple years now, scale is still small and often proprietary. In 2016, that will all change.
Behind Headlines: 180 Seconds in Ad Tech is a short 3-minute podcast exploring the news in the digital advertising industry. Ad tech is a fast-growing industry with many updates happening daily. As it can be hard for most to keep up with the latest news, the Sharethrough team wanted to create an audio series compiling notable mentions each week.
An update to the IAB standard for buying and selling native ads at scale was recently released for public comment. The spec, known as Native 1.1, is an extension of a larger update to the OpenRTB 2.3 protocol, soon to be 2.4, that in 2015 ushered in an era of standardization for native advertising: programmatic native.
I’m confident in saying the release of the Native 1.1 extension marks a major advancement for the native ad market and is specifically designed to enable broader growth of programmatic native.
While OpenRTB 2.3 was a landmark achievement to write a protocol to enable the highly standardized world of Real-Time Bidding to be compatible with native ads (which were once considered to be solely custom ad executions), as explained here, there is still a lot of ground to make up to unlock the true potential of programmatic native advertising, and 1.1 is a major step on that road.
These updates stand to make 2016 the year that native ads become a core element of the RTB landscape.
The Shortcomings Of Native 1.0
OpenRTB 2.3 added an entirely new object to the standard for native, and the Native 1.0 spec defined what can go in that native object: rather than image references for banners and video references for pre-roll, the native object includes the actual metadata for the ad — things like headline, description, thumbnail, and brand name.
The evolution from fixed ad serving to component-based ad serving is the fundamental breakthrough that allows native ads to be integrated to the RTB workflow.
The Native 1.0 spec created a generic framework by which a supply source (SSP/exchange) can request the specific items needed as part of the ad, such as thumbnail size and headline lengths. A demand source (DSP/bidder) is then required to respond with assets that match the specifications of the supply source.
This was a good generic framework, but the challenge has been that no one specified what those assets should look like. Each supply source was free to define their own standards for things like image size, aspect ratio, headline length, brand name length and more.
As you can imagine, this created challenges for the demand side. As a demand platform, how can you be prepared to respond with any given thumbnail size? While there might be a way to resize thumbnails to fit, how do you resize a headline if the supply source requests a shorter headline than you have — truncating a headline doesn’t cut it.
For display, Demand Side Platforms know that if you have a few common sizes, you’re set for most inventory. With native inventory, the lack of standardization has lead to missed opportunities or mis-rendered ads.
To make matters worse, some supply sources have yet to create their own standards, leaving it to each publisher to set requirements. This means every request from every supply source can be different.
The second major challenge with the 1.0 specification was in how native ad unit types were defined. The Native 1.0 spec followed the nomenclature of the Native Advertising Playbook, which has since been updated with the In-Feed Deep Dive.
When applied to the native spec, the classifications of the original playbook created confusion on the DSP side in terms of classifying inventory due to the commingling of context and layout concepts and some overlapping or unclear definitions. In many cases, inventory is being purchased by named supply source, in the lack of standard classifications, hampering scalability.
Native 1.1 Brings Specificity and Structure To Programmatic Native
The new OpenRTB Native 1.1 Extension, now out for public comment before being released officially in winter, continues to allow support for the original standard, but has added a new means of classifying inventory and will eventually deprecate the old method.
Native inventory is now classified in two ways:
1. Context
What type of content surrounds the ad unit? There are three primary classifications, according to the IAB Deep Dive On In-Feed Ad Units: content feeds, social feeds and product feeds. Each primary classification has sub-classifications.
2. Placement Type
What is the design of the ad unit being purchased? This list aligns similarly to the original playbook but in a streamlined fashion:
• In the feed of content
• In the atomic unit of the content, i.e. on an article page or single image page
• Outside the core content, i.e. in the ads section on the right rail or as a banner-style placement near the content
• Recommendation widget, most commonly presented below the article content
These new classifications should enable native to scale more broadly as DSPs can represent inventory by context and placement type, rather than needing to separately represent each supply source.
With nomenclature taken care of, fixing the asset requirements was also a top priority with Native 1.1. Given the free range of early native standards, agreeing on a tighter standard wasn’t easy, and obviously will result in some platforms needing to make changes, but it’s a necessary step on the way.
The Road To Native Standardization
To begin the process of standardization, the IAB working group inventoried the current asset requirements of all the native supply sources we could find, including social platforms like Facebook and Twitter, and the largest programmatic native ad platforms like Sharethrough, Google, Yahoo! and MoPub.
This gave us a picture of the current world, and in some areas clear patterns emerged in terms of how various fields were being used and some differing interpretations of the standard.
Through numerous working sessions with key industry representatives, we figured out a set of recommendations for the primary asset types.
While supply sources are still free to deviate from the standard, there will be an incentive for all supply sources to follow the standards in order to expose themselves to as much demand as possible.
Going forward, DSPs can be confident that if they support these asset types they will be able to bid on most native supply.
Below are the specific standards that were agreed upon:
How Images Are Handled In OpenRTB 2.4
How Text Elements Are Handled In OpenRTB 2.4
2016: Native Programmatic Comes Of Age
Taken together, the changes to inventory classification and asset requirements, along with other minor bug fixes and enhancements to the spec, should enable the type of rapid scaling of native programmatic we anticipate for 2016 and we encourage the ecosystem to adopt these standards as quickly as possible.
Standardizing on sizes enabled display to scale programmatically, and we’ve now done the same for native.
While we’ve been talking about programmatic native for a couple years now, scale is still small and often proprietary. In 2016, that will all change.
Founded in 2015, Calibrate is a yearly conference for new engineering managers hosted by seasoned engineering managers. The experience level of the speakers ranges from newcomers all the way through senior engineering leaders with over twenty years of experience in the field. Each speaker is greatly concerned about the craft of engineering management. Organized and hosted by Sharethrough, it was conducted yearly in September, from 2015-2019 in San Francisco, California.
Stay Up-to-Date—
Subscribe to our newsletter and receive cutting-edge digital advertising insights, including our weekly Behind Headlines episodes, delivered right to your inbox.
.png)
