There was an unexpected error authorizing you. Please try again.

So, You’d like to Propose a Change to OpenRTB/AdCOM…

So, You’d like to Propose a Change to OpenRTB/AdCOM…

Sam Tingleff and Jennifer Derke

flickr: volvob12b

 

Like a monarch butterfly, new proposals to the OpenRTB standard do not begin life as a beautiful, fully formed creature.

 

In this post we hope to first clarify some of the misconceptions which we’ve seen about the standardization process and to better set expectations for new contributors in the OpenRTB Working Group.

 

First, to be super clear, as of OpenRTB 3.0, the specification has evolved into two distinct components: “AdCOM”, which provides a reusable object model for advertising, and “OpenRTB” which provides a transactional wrapper around AdCOM for the purpose of real time bidding. Other transactional models like OpenDirect make use of AdCOM as well.

 

In most cases, new proposals relevant to OpenRTB are likely to really be AdCOM proposals, however many people may continue to use the terms interchangeably as we will in this post.

 

Second, both specifications are no substitute for business development. It is expected that new features achieve some level of commercial success prior to becoming part of the standard.

 

As broadly adopted standards go, OpenRTB tends to move fairly quickly. However, in the trade off between moving quickly and suffering from an excess of unused bloat, or moving slowly on a smaller, more focused base, the OpenRTB group has generally tended towards being slow to adopt new fields or features.

 

At a minimum, in most situations a new proposal should have at least one integration – between an exchange and a Demand Side Platform (DSP) – live and transacting via an extension. This is a low bar! It is expected that proposed additions or changes to the standard are championed by these active participants, all of whom wish to scale up their tremendous innovation with multiple other parties.

 

In many cases it may be helpful to have these extensions be public, in case others are simultaneously seeking to solve the same problem. To facilitate these interactions, proposals can be submitted in the public-facing OpenRTB github repository as a pull request. Contributors are responsible for “marketing” the proposal to other would-be implementers – the #general channel on our OpenRTB slack is a great place to start.

 

The OpenRTB standard changes through the efforts of a large community of contributors and collaborators, with governance from a smaller Commit Group of individuals with a long history of contributions. Proposals come from any part of the larger community, improve through the process of community feedback, and are endorsed and actually brought into the standard through the commit group.

 

The typical lifecycle of a proposal is approximately the following.

 

  1. Two counterparties (Party 1 and Party 2) agree on a problem, brainstorm solutions and come up with a rough draft of a solution;
  2. Party 1 writes up an extension object and shares draft documentation with Party 2;
  3. Party 2 provides feedback and perhaps revisions are made;
  4. Both parties develop to this extension object;
  5. Production releases occur on both sides and production use ramps up between these two parties;
  6. Success occurs! Party 1 and Party 2 both wish to tell the world about this new extension and scale up the solution throughout their businesses;
  7. Party 1 and Party 2 collaborate on a more formal proposed change to the OpenRTB specification, perhaps involving individuals from other organizations;
  8. The proposal is presented to the full OpenRTB working group, which contributes critical peer review and (hopefully) voices of support;
  9. Then, either of the two actions may occur to facilitate publication of the new OpenRTB spec feature;
    1. The change is published within the OpenRTB github repository as an extension, which allows for continued incubation.
    2. The change is included in an OpenRTB minor version release, which goes through a 60-day public comment period;
      1. The minor version release is officially released.
  10. Once the proposal reaches this stage of publishing, it is up to the industry to complete the lifecycle of a proposal by adopting the new feature.

flickr: volvob12b

 

To participate in the OpenRTB working group, contact us any time at techlab@iabtechlab.com.