Table of Contents

• RTB vs ORTB
• Real-Time Bidding - RTB
• Open Real-Time Bidding - ORTB
  • ORTB Evolution
• Pros and cons of RTB
• Discrepancies on RTB
• RTB with EXADS (SSP)
• RTB with EXADS (DSP)
• Conclusion

Real-Time Bidding, or RTB came to the scene before Open Real-Time Bidding, or ORTB was introduced. Its adoption changed the advertising industry and became one of the most important ways of buying and selling ads. One thing that was missing was a standard that could be used by everyone to make the whole process easier.  RTB and ORTB complement each other and in this article, we try to explain how it all works. We will touch on some of the key points of both RTB and ORTB that will explain how they are revolutionizing the digital advertising industry.

RTB vs ORTB

First, let’s start by explaining what RTB and ORTB mean:

Real Time Bidding or RTB is a process of buying and selling ad impressions through real-time auctions.

Open Real Time Bidding on the other hand is a protocol or a specification of API on how to implement RTB. ORTB specification started as a pilot project between a couple of SSPs and DSPs, and after successful adoption, it became the IAB (Interactive Advertising Bureau) standard maintained by the ORTB community. More about the standard can be found in the ORTB Official documentation.

Real-Time Bidding - RTB

RTB is a subcategory of programmatic media buying. Some other subcategories are listed below and their benefits can be seen right away:

• Private Marketplace - only selected advertisers, usually based on an invite or registration basis.
• Programmatic Guaranteed - advertisers can reserve a guaranteed amount of traffic, and publishers are guaranteed that their spots will be covered.
• Preferred Deals - advertisers get priority access to specific traffic at a negotiated price.
• Programmatic Direct/Automated Guaranteed - allows advertisers to buy reserved traffic directly from publishers using programmatic technology.
• RTB - buying and selling of impressions open to anyone.

The difference between programmatic and traditional media buying is that the former is possible with just a set of tools and software, while the latter is run by people through all the steps of the process from initial contact to price negotiation. Programmatic has a huge advantage here, being cheaper and faster. 

Where RTB benefits among other programmatic media buying, is its availability to everyone, which means an even faster up-and-running process.

RTB can be used to buy or sell as little as a single impression, and scale for that number to be in the billions. The whole process, from initiating a bid request call in the user browser to the advertiser bidding on the impression and returning the ad happens within milliseconds. The industry standard is between 100ms to 300ms, including both computation time and RTT (Round Trip Time). Its scalability, availability, and speed make it one of the top technologies used in modern-day advertising.

Because Round-Trip Time can drastically increase depending on the site visitor’s browser, ad exchange, and advertiser location, it is recommended that RTB requests are configured by location and contain as much context as possible. So, having the ad server located in North America, while the RTB partner has their servers in Asia, and the end user is in Europe, will end up with considerable network round-trip latencies. This leads to a degraded ad serving experience, many times ending in an increased amount of timeouts for the RTB process.

Two of the most important (and thus mandatory) elements of RTB are IP address and location. 

Another important factor for RTB, and for the integration process to be fast and smooth, is to carefully review existing documentation about requests and responses when developing it. This development is necessary so partners have a communication contract in place to both interpret a request and send back a response. The most relevant and important standard in the industry is the OpenRTB standard, which describes the request and response structures and enables systems to work together. 

Open Real-Time Bidding

ORTB is a specification that aims to provide standards for communication between RTB parties, such as SSPs and ad exchanges or ad exchanges and DSPs. Following those recommendations, it helps prepare both parties on what to expect and consider it as a common language between two machines. Since the specification is quite vast and not every single feature may be fully supported by both sides, there are usually some modifications required, thus ORTB is not necessarily plug-and-play, but it aims to be. 

In an ideal scenario, all the features of ORTB will be fully implemented and machines will be able to communicate in the same manner as two people speaking English do. Not having some features on either side is like two people misunderstanding each other due to being non-native English speakers or being native English speakers but simply not understanding each other due to different accents.

ORTB Evolution

Here is a quick overview of ORTB’s evolution and features added over time:

Bid requests and bid responses, being the backbone of the whole process, have a vital role in successful auctions. 

• ORTB bid requests require HTTP protocol using the POST request method (due to the large payload being sent) with the defined JSON structure.
• The response should return one of the following:
• 200 OK - valid bid response, win notification, billing notification, etc
• 204 No Content - valid request indicating NO BID (although there are other options, this one is preferable due to minimal bandwidth usage)
• 400 Bad Request - invalid request, a bid request containing malformed or corrupt payload

Any other HTTP codes can be supported but they should be documented, for example:

• 408 Timeout - if RTB timeout exceeds due to RTT + auction time
• 429 Too Many requests - in case the other party decides to apply a QPS (queries per second) limitation

Some other things to consider as part of ORTB configurations are:

• Keep-Alive header - HTTP Persistent Connections as it helps reduce connection management overhead
• HTTP vs HTTPS - depending on the content and compliance, some parties require HTTPS although HTTP offers some performance due to TCP handshake management 
• Compressed requests/responses - using tools such as gzip to minimize bandwidth usage
• ORTB header version (e.g.: x-openrtb-version: 2.5)

The main bid request consists of the following sections:

• id - unique ID of the bid request, sent by SSP and ad exchange replies with the same id, in case of ad exchange to DSP communication, DSP should reply with the same id
• at -  auction type, where 1 = First Price, 2 = Second Price
• imp - details about the list of impressions offered
• site - details of publishers’ site 
• app - details of publishers’ app
• device - details of publishers’s device
• user - details of the user of the device; the advertising audience
• tmax - timeout
• ext - placeholder for exchange-specific extensions to OpenRTB
• bxxx - blacklisting specific things, such as categories, advertisers
• wxxx - whitelisting specific things, such as languages, or advertisers

Each of the above sections consists of objects with more details. 

Example:

{
    "id": "80ce30c53c16e6ede735f123ef6e32361bfc7b22",
    "at": 1,
    "cur": [
        "USD"
    ],
    "imp": [
        {
            "id": "1",
            "bidfloor": 0.03,
            "banner": {
                "w": 300,
                "h": 250,
                "pos": 0
            }
        }
    ],
    "site": {
        "id": "102855",
        "cat": [
            "IAB3-1"
        ],
        "domain": "www.foobar.com",
        "page": "http://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"
    }
}

 

Once we have a winner at the auction, a response similar to the one below is returned:

• id - ID of the bid request to which this is a response
• seatbid - array of seatbid objects; 1+ required if a bid is to be made
• cur - bid currency using ISO-4217 alpha codes
• seatbid.bid.id - bidder generated bid ID to assist with logging/tracking
• seatbid.bid.impid - id of the Imp object in the related bid request
• seatbid.bid.price - bid price
• seatbid.bid.adm - markup of actual ad
• seatbid.bid.nurl - win notification URL (doesn’t mean the ad was delivered or viewed)
• seatbid.bid.burl - billing notification URL (ad is considered to be delivered, viewed, billable) 
• seatbid.bid.iurl - used for image compliance/quality checking
• seatbid.bid.adomain - advertiser domain
• seatbid.bid.cid - campaign id
• seatbid.bid.crid - creative id

Example:

{
    "id": "80ce30c53c16e6ede735f123ef6e32361bfc7b22",
    "cur": "USD",
    "seatbid": [
        {
            "seat": "512",
            "bid": [
                {
                    "id": "123",
                    "impid": "974090632",
                    "price": 1.43,
                    "adm": "<HTML>...</HTML>",
                    "nurl": "http://adserver.com/winnotice?impid=102",
	        "burl": "http://adserver.com/billingnotice?impid=102",
                    "iurl": "http://adserver.com/pathtosampleimage",
                    "adomain": [
                        "advertiserdomain.com"
                    ],
                    "ext": {
                        "btype": 1
                    },
                    "cid": "campaign111",
                    "crid": "creative112",
                    "w": 300,
                    "h": 250
                }
            ]
        }
    ]
}

 

Figure 1. Request sequence (taken from official ORTB documentation)

Pros and cons of RTB 

On top of the benefits that programmatic and RTB bring, there are some pros and cons for each party involved:

SSP Pros:

• exposed to more demand = maximizing revenue and fill rate 

SSP Cons:

• more complex compliance 
• no guarantee of ad coverage 

DSP Pros:

• better targeting due to "standardized" request and flexible context  

DSP Cons: 

• less control over where their content will show 

Discrepancies on RTB

Since the auction happens between different systems it is expected that there will be some discrepancies. The main reason for this is that one part is done server side (bid requests) while the other part is done on the client side (impression and other events tracking). Taking that into account up to 5% is expected, and 5-10% is likely but it should be looked into, more than 10%, and especially more than 15% requires investigation and a better understanding of why it is happening and how to mitigate it.

JavaScript errors on the client side could prevent calling some URLs such as impression, click, or other events trackers that happen in users’ browsers.

Slow network speed/loss of network connection could prevent delivering the ad to the client after being requested or making an event tracking call after being delivered.

The user left the page / is redirected automatically before it gets the chance to render the ad or even deliver the ad even though this happens in milliseconds it is still very much possible.

Viewability feature as the publisher might not consider or trigger an impression event if the ad is just partly visible.

AdBlockers can have the biggest impact on discrepancies; there are different things that ad blockers do to block the ads. Usually, they will try to block the whole requests for ads, but if the request for an ad goes through and a response is sent back, wins can be counted. The ad blocker can then prevent showing delivered ads based on CSS classes or tags, and, in that could cause discrepancies between winning ads and impressions.

RTB with EXADS (SSP)

In the below examples, we will show how simple it is to integrate RTB with EXADS using ORTB protocol.

First, you need to have a publisher account with an EXADS-powered network. Once you approve your account you can continue with the steps below

The second step is to register an SSP and create an RTB zone. When creating the zone you need to select one of the RTB options. For this example, we will use RTB Banner Supply format which supports multiple sizes, 300x250, 300x100, etc.

The next step is to add some information about your zone, such as name, category, and most importantly RTB Partner. There are multiple options but we will use ORTB v2.5 for this example.

Once you save your preferences you will get a url like below. That URL is an API for RTB that you need to share with your publisher. With that URL, you can share our publisher documentation to make the whole integration process simpler. Documentation can be found here EXADS ORTB documentation.

RTB with EXADS (DSP)

In this example, we will show how to integrate EXADS with DSP. Once you create an advertiser account with EXADS, what you need to do is: create a campaign, set the Campaign type: Exchange, and select Partner to OpenRTB v2.5. Once that’s done you can move to the Ads tab.

On the Ads tab you need to add the RTB endpoint provided by your partner and that is it, you are ready to buy RTB traffic using the ORTB protocol.

Conclusion

This article aims to give you a better insight into RTB and ORTB, why they were introduced, and what issues they aim to solve. It also shows how to integrate an SSP and a DSP with EXADS. As long as your clients can conform to the ORTB standard, integration should be pretty straightforward and painless. As already said, it’s not plug-and-play but if both parties use the same ORTB standard effort should be minimal. If you want to find out more about the solutions available from EXADS, contact us today!