Unlocking OpenRTB: The Ultimate Guide To Real-Time Bidding

OpenRTB Terminologies

• Publisher (Supply Side): A publisher is an entity who owns a property/site (app or website).
• Site: A property (app/website) with a dedicated ad space that is owned by a publisher.
• Supply Side Platform (SSP): An SSP is a software platform that allows publishers to sell their ad inventories across multiple demands (exchanges, advertisers, ad networks, etc) through exchanges.
• Advertiser (Demand Side): An entity that wants to purchase the publishers’ ad inventory to display their advertisements (ads).
• Demand side platform (DSP): A DSP is a software platform that allows advertisers to purchase ad inventories from multiple publishers through exchanges.
• Programmatic advertising: The automated buying and selling of digital media (ad space) between publishers and advertisers via server-to-server interactions.
• Ad Exchanges: Ad Exchanges facilitate real-time transactions of media (ads) between multiple SSPs and DSPs through open auctions.
• Bid (in advertising): The Bid is the maximum amount of money an advertiser is willing to pay to purchase an ad slot.
• Bidding (in advertising): The act of making bids on an ad inventory in an auction is called bidding.
• Bidders: The entities (advertisers, agencies, etc.) who compete in an auction to win a bid are called bidders.
• Real-time bidding (RTB): A protocol that standardizes the bidding process in real-time.
• Programmatic /Automated auction: The automated process of selling the publisher’s ad inventories to the advertiser who pays the highest through bidding.

History of OpenRTB

The Real-Time-Bidding (RTB) Project, formerly known as the OpenRTB Consortium assembled three demand side (DataXu, MediaMath, and Turn) and three supply side (Admeld, PubMatic, and The Rubicon Project) technology leaders to introduce oRTB in Nov 2010.

The idea was to develop an open industry-standard protocol for communication between the buy-side (advertisers) and sell-side (publishers) in RTB marketplaces. It aimed to simplify the connection between suppliers of publisher inventory (i.e., ad exchanges, sell-side platforms, and ad networks working with publishers) and competitive buyers of that inventory (i.e., bidders, demand-side platforms, and ad networks working with advertisers).

The first oRTB protocol was introduced in December 2010, to standardize communication between the programmatic parties for exchanging block lists (Block list project). A block list is a categorical list of websites and apps where brands or agencies choose not to display their ads, primarily due to brand safety and fraudulent concerns.

Due to the high industry adoption of version 1.0 of the OpenRTB block list, the OpenRTB project accepted the collaborative proposal of Nexage to create an API specification that specifically supported mobile advertising (OpenRTB Mobile project). The mobile subcommittee of technology leaders assembled to release OpenRTB Mobile 1.0 specification in February 2011, which focused on real-time bid request/response protocol for mobile advertising. OpenRTB version 2.6 is the latest release by IAB that supports header bidding, out-stream video, billing, and loss notification for mobile advertising.

What is OpenRTB

ORTB is a standard protocol that governs the way media is transacted between publishers and advertisers in the programmatic advertising ecosystem. Transaction of media implies the exchange of the publisher’s ad inventory with the advertiser’s advertisement (ads) through real-time auctions. This allows the advertiser's advertisement to be displayed on the publisher’s site in real time. In delivery, this means setting an API specification for companies interested in an open protocol for the automated trading of digital media across a broader range of platforms, devices, and advertising solutions.

The open protocol standardizes the language of media transactions by developing API specifications and object models across several versions of oRTB. Some of the latest specification releases are for:

• Bid request and response
• Ad formats
• Bidding techniques
• Publisher and placement types
• Win notice and Loss notice
• Geolocation, device, and other data definitions

More about them in the oRTB versions section.

These standards bring about consistency in communication when transacting media. For example, when a publisher wants to make a bid request, they must adhere to a specific communication method. The API specification designed for this purpose will require essential information, such as seller information, site URL, site category, creative standards, size and unit, etc., for buyers to make more informed bidding decisions. Every publisher who opts for the open protocol (oRTB) is expected to follow this standard when making a bid request. As a result, it ensures a uniform bid request language among all entities involved in real-time marketplaces while transacting media.

The difference between RTB and oRTB

Real-time Bidding (RTB) is the way of transacting media between buyers and sellers of the programmatic ecosystem in real-time. OpenRTB (oRTB) is the standard communication protocol that enables real-time bidding among programmatic entities.

How does the oRTB technology work

To understand how oRTB technology functions, let’s first understand how media is transacted in the real-time programmatic ecosystem.

Here's a bird's-eye view of the programmatic advertising process: Publishers aim to sell ad spaces on their sites (app/website) to advertisers in order to show an ad to the audience and generate revenue. Advertisers, on the other hand, want to display their ads on publisher sites to attract the site's audience and ultimately acquire users. This exchange of ad space and advertisements happens through real-time auctions, taking just 200 milliseconds. The highest bidder wins the opportunity to display their ad on the publisher's site. Let’s not overlook what the users gain. Users get to explore the advertisers' products or services for their own benefit while simultaneously accessing the publisher’s content. Thus, it becomes a win-win situation for all parties involved.

How does oRTB Technology works

Now, let's get into the intricacies of this process and understand the role of oRTB.

When a user lands on a web page, an inbound ad request is generated by the publisher’s site. This ad request carries extensive data about the user (demographics, psychographics, behavior, and other first-party information). This request is then sent to a Real-Time Bidding (RTB) exchange as a bid request through the Supply Side Platform (SSP) for auction. Bid request in oRTB standards carries the publisher’s data (site ID, site category, site URL, ad placement information, etc.) and user data in JSON data format. Subsequently, these bid requests (since bidding will occur on the request) will be transferred to the advertisers via the Demand Side Platform (DSP) in RTB standards.

Multiple bidders participate in the auction by sharing a bid response that contains vital information such as creative attributes, image URL, and bid price (oRTB standards) with the exchange. An auction takes place within the exchange which determines the compatibility of bids based on prevailing auction rules. Ultimately, the exchange selects the winning bidder (the highest bidder) and a win notice is sent to signify a successful auction victory.

Conversely, a loss notice is sent to the other bidders, informing them that they were not successful in the bid, accompanied by the reason for the loss. The ad of the winning bidder is then displayed on the publisher's site, creating an impression. This entire process of media transaction involving real-time interaction between SSPs and DSPs is known as Real-Time Bidding.

ORTB standards are not for bid requests and responses alone. Till date, there are several oRTB protocols released, each supporting a specific function to bring consistency to the real-time bidding process. Let’s explore the different versions of oRTB and the features they support.

Bid request examples

Example 1 – Simple Banner

The basic format of a banner ad bid request is shown below with some optional parameters.

{
  "id": "80ce30c53c16e6ede735f123ef6e32361bfc7b22", 
  "at": 1,
  "cur": [ "USD" ], 
  "imp": [ 
    {
      "id": "1",
      "bidfloor": 0.03, 
      "banner": { 
        "h": 250, "w": 300, "pos": 0 
      }
    }
  ], 
  "site": { 
  "id": "102855", 
  "cat": [ "IAB3-1" ], 
  "domain": "www.foobar.com",
  "page": "https://www.foobar.com/1234.html ", 
  "publisher": {
    "id": "8953", "name": "foobar.com",
    "cat": [ "IAB3-1" ],
    "domain": "foobar.com" 
    }
  }, 
  "device": {
    "ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.13 
    (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2", 
    "ip": "123.145.167.10" 
    }, 
  "user": { 
    "id": "55816b39711f9b5acf3b90e313ed29e51665623f" 
  } 
} 

Example 2 – Mobile

In this example, a device object represents a mobile device, while an app object represents a mobile application's request.

  {
    "id": "IxexyLDIIk",
    "at": 2,
    "bcat": ["IAB25", "IAB7-39", "IAB8-18", "IAB8-5", "IAB9-9"],
    "badv": ["apple.com", "go-text.me", "heywire.com"],
    "imp": [
      {
        "id": "1",
        "bidfloor": 0.5,
        "instl": 0,
        "tagid": "agltb3B1Yi1pbmNyDQsSBFNpdGUY7fD0FAw",
        "banner": {
          "w": 728,
          "h": 90,
          "pos": 1,
          "btype": [4],
          "battr": [14],
          "api": [3]
        }
      }
    ],
    "app": {
      "id": "agltb3B1Yi1pbmNyDAsSA0FwcBiJkfIUDA",
      "name": "Yahoo Weather",
      "cat": ["IAB15", "IAB15-10"],
      "ver": "1.0.2",
      "bundle": "12345",
      "storeurl": "https://itunes.apple.com/id628677149",
      "publisher": {
        "id": "agltb3B1Yi1pbmNyDAsSA0FwcBiJkfTUCV",
        "name": "yahoo",
        "domain": "www.yahoo.com"
      }
    },
    "device": {
      "dnt": 0,
      "ua": "Mozilla/5.0 (iPhone; CPU iPhone OS 6_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A334 Safari/7534.48.3",
      "ip": "123.145.167.189",
      "ifa": "AA000DFE74168477C70D291f574D344790E0BB11",
      "carrier": "VERIZON",
      "language": "en",
      "make": "Apple",
      "model": "iPhone",
      "os": "iOS",
      "osv": "6.1",
      "js": 1,
      "connectiontype": 3,
      "devicetype": 1,
      "geo": {
        "lat": 35.012345,
        "lon": -115.12345,
        "country": "USA",
        "metro": "803",
        "region": "CA",
        "city": "Los Angeles",
        "zip": "90049"
      }
    },
    "user": {
      "id": "ffffffd5135596709273b3a1a07e466ea2bf4fff",
      "yob": 1984,
      "gender": "M"
    }
  }

Example 3 – Video

The example shows a bid request for a video impression with two companion ad slots, one of which is expandable.

  {
    "id": "1234567893",
    "at": 2,
    "tmax": 120,
    "imp": [
      {
        "id": "1",
        "bidfloor": 0.03,
        "video": {
          "w": 640,
          "h": 480,
          "pos": 1,
          "startdelay": 0,
          "minduration": 5,
          "maxduration": 30,
          "maxextended": 30,
          "minbitrate": 300,
          "maxbitrate": 1500,
          "api": [1, 2],
          "protocols": [2, 3],
          "mimes": [
            "video/x-flv",
            "video/mp4",
            "application/x-shockwave-flash",
            "application/javascript"
          ],
          "linearity": 1,
          "boxingallowed": 1,
          "playbackmethod": [1, 3],
          "delivery": [2],
          "battr": [13, 14],
          "companionad": [
            {
              "id": "1234567893-1",
              "w": 300,
              "h": 250,
              "pos": 1,
              "battr": [13, 14],
              "expdir": [2, 4]
            },
            {
              "id": "1234567893-2",
              "w": 728,
              "h": 90,
              "pos": 1,
              "battr": [13, 14]
            }
          ],
          "companiontype": [1, 2]
        }
      }
    ],
    "site": {
      "id": "1345135123",
      "name": "Site ABCD",
      "domain": "siteabcd.com",
      "cat": ["IAB2-1", "IAB2-2"],
      "page": "https://siteabcd.com/page.htm",
      "ref": "https://referringsite.com/referringpage.htm",
      "privacypolicy": 1,
      "publisher": {
        "id": "pub12345",
        "name": "Publisher A"
      },
      "content": {
        "id": "1234567",
        "series": "All About Cars",
        "season": "2",
        "episode": 23,
        "title": "Car Show",
        "cat": ["IAB2-2"],
        "keywords": "keyword-a,keyword-b,keyword-c"
      }
    },
    "device": {
      "ip": "64.124.253.1",
      "ua": "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16",
      "os": "OS X",
      "flashver": "10.1",
      "js": 1
    },
    "user": {
      "id": "456789876567897654678987656789",
      "buyeruid": "545678765467876567898765678987654",
      "data": [
        {
          "id": "6",
          "name": "Data Provider 1",
          "segment": [
            {
              "id": "12341318394918",
              "name": "auto intenders"
            },
            {
              "id": "1234131839491234",
              "name": "auto enthusiasts"
            }
          ]
        }
      ]
    }
  }

Example courtesy: https://www.iab.com/

OpenRTB versions and their features

• Version 2.6 - Supports Connected TV (CTV) buying and selling of digital media.
• Version 2.5 - Support for header bidding, billing, and loss notifications, Video ad serving template (VAST), Flex Ads, Payment ID, tactic ID, impression metrics, out-stream video, and many more minor enhancements.
• Version 2.4 - Support for Audio ad units, SSL, video scriptability, and increased location support.
• Version 2.3 - Supports Native ad units and multiple minor enhancements.
• Version 2.2 - New enhancements for private marketplace direct deals, video, mobile, and regulatory signals.
• Version 2.1 - Revisions for IQG compliance, minor enhancements, and corrections.
• Version 2.0 - Unified specification for display, mobile, and video capabilities.
• Version 1.0 - Original Release of OpenRTB Mobile.

• Version 1.2 - Publisher Preferences API (proposed).
• Version 1.1 - Minor changes to include the real-time exchange of creative attributes.
• Version 1.0 - Original Release of OpenRTB block list specifications.

ORTB Benefits

Benefits of oRTB

• This unified protocol simplifies the interaction between all the entities of the programmatic ecosystem.
• Advertisers can easily access all inventory sources that support RTB without the need to integrate their platform with their supply-side tools.
• ORTB allows multiple bidders to bid for a single ad inventory. This subsequently can increase the value of the publisher's inventory and hence optimize yield.
• ORTB bridges the gap between advertisers and publishers across different geographies and compatibilities.
• OpenRTB provides a platform that allows players of all sizes to participate and experiment with their advertising strategies. This specifically benefits new market players.
• Saves maintenance costs for SSPs and DSPs to support integrations with multiple exchanges.
• SSPs and DSPs can implement multiple integrations without the additional cost of development for each integration.
• AdTech and MarTech solutions can make their tools more attractive and profitable by adopting ORTB standards.
• The universal language approach helps ad agencies access inventories worldwide and support global clients.

Conclusion

Today, there are numerous advanced technologies and tools available in digital advertising, such as SSPs, DSPs, ad networks, and ad servers. With the introduction of oRTB, these entities can now interact in a seamless manner making advertising more efficient between publishers and advertisers. As programmatic advertising continues to evolve, oRTB is likely to become more prevalent and play a key role in the future of digital advertising owing to its scalability, cost-effectiveness, and ability to improve efficiency.