What is OpenRTB?

OpenRTB is a standardized protocol from the IAB Tech Lab that enables real-time bidding (RTB) for digital advertising. It provides a common language for ad exchanges, demand-side platforms (DSPs), and supply-side platforms (SSPs) to communicate, allowing for the automated auction and sale of ad impressions in milliseconds.

The Purpose and History of OpenRTB

Before programmatic advertising became common, buying digital ad space was a manual process. It involved phone calls, emails, and insertion orders between advertisers and publishers. This system was slow, inefficient, and could not scale.

Real-time bidding (RTB) was developed to automate this process. RTB introduced the concept of auctioning off every single ad impression to the highest bidder in the time it takes a webpage to load. This was a major step forward for efficiency.

However, the early days of RTB were chaotic. Every ad exchange, DSP, and SSP created its own proprietary API and communication method. This created a technical mess, often called a “Tower of Babel” problem in the industry.

Imagine trying to connect a dozen different systems that all speak a different language. Each new integration required custom development work, which was expensive and time-consuming. This complexity limited the growth of the programmatic market.

The IAB Tech Lab, a non-profit consortium, created the OpenRTB protocol to solve this exact problem. It established a universal standard, a common language that all platforms could use to talk to each other. This dramatically reduced friction and development costs across the industry.

Think of OpenRTB as a universal power adapter for the ad tech world. It allows any DSP to plug into any SSP without needing a custom-built connection. This standardization was the key that unlocked the massive scale of today’s programmatic advertising ecosystem.

The first major version, OpenRTB 2.0, was released in 2011. Since then, the protocol has been updated several times to keep pace with technology. Later versions added support for new formats like native advertising, video, audio, and connected TV.

How OpenRTB Works: The Technical Breakdown

The entire OpenRTB process happens in the blink of an eye, typically in under 200 milliseconds. It begins the moment a user navigates to a website or opens a mobile application that contains ad space.

The publisher’s website or app makes an ad call to its ad server. The ad server then passes this request to a Supply-Side Platform (SSP). The SSP’s job is to maximize the revenue for the publisher by selling the ad impression for the highest possible price.

The SSP gathers all available information about the ad opportunity. This includes details about the website or app, the specific ad slot (its size and position), and anonymized information about the user and their device.

All of this information is carefully packaged into a structured data format called a “Bid Request”. This Bid Request is the core of the OpenRTB communication. It is a highly detailed message written in a machine-readable format, usually JSON.

The Bid Request object contains many key-value pairs that describe the impression. For example, it specifies the ad format (`imp.banner` or `imp.video`), the dimensions of the ad (`imp.banner.w` and `imp.banner.h`), and information about the user’s device (`device.geo` for location or `device.os` for operating system).

Once created, the SSP sends this Bid Request to numerous Demand-Side Platforms (DSPs) at the same time. A DSP is a platform used by advertisers to buy ad impressions. Sending the request to multiple DSPs creates a competitive auction.

Each DSP receives the Bid Request and its internal algorithms get to work. These systems analyze the request in real time to determine if the impression matches the targeting criteria of any of their active advertiser campaigns.

The DSP evaluates factors like the user’s location, the website’s content category, the time of day, and any other available data points. If the impression is a match for an advertiser, the DSP must decide how much to bid for it.

The OpenRTB Auction in Action

The auction is a rapid-fire exchange of information between the SSP and multiple DSPs. It follows a clear, standardized sequence of events defined by the OpenRTB protocol.

1. The Bid Request

As mentioned, the process starts with the SSP sending out a Bid Request. This JSON object is highly structured, containing main objects like `id` (a unique ID for the auction), `imp` (describing the impression itself), `site` or `app` (describing the publisher’s property), `device` (describing the user’s device), and `user` (describing the user with an anonymous ID).

2. The Bid Response

If a DSP wants to purchase the impression, it replies with a “Bid Response”. This response must be sent back to the SSP within a very tight deadline, often just 10-20 milliseconds. Any response that arrives too late is ignored.

The Bid Response contains the DSP’s bid. Key fields include `id` (matching the original request ID), `seatbid` (a group of bids from the DSP), and the `bid` object itself. The `bid` object contains the `price` (the bid amount in CPM) and the `adm` (the ad markup or creative tag that will be displayed if the bid wins).

3. The Auction Logic

The SSP collects all the Bid Responses that arrive on time. It then runs an auction to determine the winner. Most programmatic auctions use a “second-price auction” model.

In a second-price auction, the highest bidder wins. However, the winner does not pay the price they bid. Instead, they pay the price of the second-highest bid, plus a small increment (like one cent). This model encourages bidders to bid their true maximum value for the impression.

4. The Win Notification

Once the SSP determines the winner, it sends a Win Notification to the winning DSP. This message informs the DSP that its bid won the auction and at what price (the clearing price). The SSP also sends the winning ad creative (`adm`) from the Bid Response back to the user’s browser or app.

5. Rendering and Tracking

The user’s device receives the ad creative and renders the ad in the designated ad slot. At the same time, tracking pixels included in the ad creative will fire. These pixels send data back to the DSP and other platforms to confirm that the ad was successfully delivered (an impression) and to track any subsequent clicks or conversions.

OpenRTB in Practice: Three Real-World Scenarios

Understanding the protocol is one thing, but seeing how its proper implementation affects business outcomes is another. Here are three distinct scenarios where a deep understanding of OpenRTB was critical.

Case Study A: The E-commerce Brand Losing Bids

An online shoe retailer was using a DSP for its retargeting campaigns. They were bidding aggressively to win back past website visitors, but their auction win rate was below 5%. Their campaign ROI was negative because they could not reach their most valuable audience.

An investigation into their DSP’s logs revealed a simple but critical error. Their outgoing Bid Responses were often missing the `crid` (creative ID) field. This field is a unique identifier for the specific ad creative being used in the bid.

Many SSPs have strict rules and will automatically reject any bid that does not include a valid `crid`. They do this for auditing, reporting, and brand safety scanning. The retailer’s ad creatives were not correctly registered within their DSP, so the ID was never sent.

The solution involved the ad operations team meticulously registering every ad creative in the DSP’s system. They then ensured that their bidding logic always populated the `crid` in the Bid Response. They also adopted a dynamic creative system that automatically generated and registered creatives.

After this fix, their win rate for retargeting auctions jumped from 5% to over 40%. This allowed them to effectively reach past visitors, leading to a 25% increase in conversions from their programmatic ads. The campaign became profitable almost overnight.

Case Study B: The B2B SaaS Company with Wasted Spend

A B2B software company was targeting high-level executives for their expensive enterprise product. Despite setting up targeting for business professionals, they found their budget was being rapidly spent on mobile gaming apps and gossip websites. Lead quality was extremely low, and their cost per acquisition was unsustainable.

A deep dive into the incoming Bid Requests showed the problem clearly. Their DSP was bidding on a massive volume of requests from irrelevant properties because its filtering was too basic. It was not correctly parsing the IAB content category fields (`site.cat` and `app.cat`) in the requests.

The DSP was treating all traffic as equal, ignoring the rich contextual data available within the OpenRTB protocol. This meant bids intended for a financial news site were being placed on a mobile game.

The solution was to build a more sophisticated targeting strategy within the DSP. The team created a specific inclusion list for IAB categories directly related to business, technology, and finance (e.g., `IAB1`, `IAB13-2`). They also created a large blocklist for categories like casual games (`IAB9-30`) and entertainment.

The result was immediate. Their ad spend on irrelevant inventory fell by over 70%. While their total number of impressions decreased, the quality of clicks and form-fills improved dramatically. Their cost per qualified lead was cut in half within the first month.

Case Study C: The Publisher with Low Ad Revenue

A popular gardening blog with a loyal following was struggling with low ad revenue. Their fill rate was high, meaning the ad slots were almost always filled. However, the average price they received for their inventory (their CPM) was consistently low.

An audit of their SSP configuration revealed they were sending out very generic Bid Requests. The requests included basic information like the ad size and URL, but nothing else. They were not passing any of their valuable first-party audience data or specific article context.

To a DSP, their traffic looked generic and undifferentiated from any other website. Advertisers were not willing to bid high prices because they could not be sure who they were reaching. The publisher was leaving a huge amount of money on the table.

To fix this, the publisher integrated their data management platform (DMP) with their SSP. This allowed them to enrich their outbound Bid Requests with valuable signals. They began passing audience segment IDs (e.g., `user.data`) to identify groups like “organic gardening enthusiasts” or “vegetable growers”.

By providing this extra context directly within the OpenRTB request, they gave DSPs the confidence to bid much higher. An advertiser looking for organic gardeners would now pay a premium for that specific impression. The publisher’s average CPMs increased by over 60%, leading to a substantial lift in total ad revenue.

The Financial Impact of OpenRTB Done Right

OpenRTB is more than just a technical specification; it is a direct driver of financial performance. Its correct implementation determines revenue for publishers and return on investment for advertisers. Minor configuration details can have a major financial impact.

For advertisers, the core financial concept is efficiency. An improperly configured integration leads to wasted ad spend. Every dollar spent on an impression that has no chance of converting is a dollar lost. This is not just about fraud, but also about relevance.

Imagine a campaign with a $100,000 budget. If 20% of bids are sent to the wrong geographic location or for the wrong device type because of poor Bid Request parsing, that is $20,000 spent with a near-zero chance of success.

A well-tuned system ensures that the budget is concentrated only on the most valuable and relevant impressions. This focus increases the campaign’s effective reach and directly lowers the cost per acquisition (CPA), maximizing the return on ad spend (ROAS).

For publishers, the financial equation revolves around yield optimization. A publisher’s ad revenue is a function of their inventory’s fill rate multiplied by the average CPM they receive. OpenRTB directly influences the CPM.

As seen in the case study, failing to enrich Bid Requests with valuable first-party data is a costly mistake. A generic, non-contextual impression might receive a base CPM of $1.00. It is a commodity.

The same impression, when enriched with data identifying the user as a high-intent buyer, might attract bids of $5.00 or more from multiple advertisers. Over millions of impressions, this difference between generic and premium translates into significant revenue growth.

Auction dynamics also play a role. Latency is a hidden cost. If an SSP’s or DSP’s systems are slow, they can miss auction deadlines. For publishers, this means a lost opportunity to sell an impression. For advertisers, it means a lost opportunity to reach a target customer.

Strategic Nuance: Myths and Advanced Tactics

To truly succeed with OpenRTB, one must move beyond the basics. Understanding the protocol’s subtleties and debunking common myths can provide a significant competitive advantage in the programmatic marketplace.

Myth vs. Reality

Myth: OpenRTB is the same thing as “programmatic advertising”.
Reality: OpenRTB is a specific protocol used for real-time bidding, which is a major part of programmatic advertising. However, the term “programmatic” also includes other automated buying methods that do not use an RTB auction, such as Programmatic Direct or automated guaranteed deals.

Myth: The highest monetary bid always wins the auction.
Reality: While price is the primary factor, it is not the only one. SSPs and exchanges often have other rules that can override the highest bid. For instance, a private marketplace deal might give one buyer priority, or a creative might be blocked for violating a publisher’s brand safety rules, disqualifying the bid regardless of price.

Myth: All data found in an OpenRTB Bid Request is accurate and reliable.
Reality: Data quality can vary significantly from one source to another. While many premium publishers provide clean, valuable data, the open exchange can also contain traffic with inaccurate location data, misrepresented site categories, or even fraudulent signals. Verifying and validating data is a constant challenge.

Advanced OpenRTB Tactics

Go Beyond Standard Targeting: Basic advertisers filter by location and device type. Advanced teams build bidding models that analyze less common OpenRTB fields to find an edge. For example, they might target users on a Wi-Fi connection (`device.connectiontype = 2`) for large video ads or analyze the `source.pchain` (PaymentChain) object to verify supply path transparency.

Master Private Marketplace Deals: Do not limit your strategy to the open auction. Use the `pmp` (private marketplace) object and `dealid` field in your bidding. This allows you to participate in private auctions with premium publishers, giving you first-look access to high-quality inventory before it is offered to the general market.

Analyze Bid Loss Reasons: Winning is great, but learning from losses is powerful. Many SSPs can provide feedback on why a bid lost via bid loss codes. Analyzing these codes (e.g., “bid was below price floor”, “creative blocked by publisher”) gives you actionable intelligence to adjust your bidding strategy, pricing, and creative assets, creating a valuable feedback loop for optimization.

Abisola

Meet Abisola! As the content manager at ClickPatrol, she’s the go-to expert on all things fake traffic. From bot clicks to ad fraud, Abisola knows how to spot, stop, and educate others about the sneaky tactics that inflate numbers but don’t bring real results.

View all posts by Abisola (Abisola)