In This Article

  1. What Is OpenRTB?
  2. How Real-Time Bidding Works
  3. OpenRTB 2.5 vs 2.6 vs 3.0
  4. Bid Request Deep Dive
  5. Bid Response Structure
  6. Auction Types: First-Price vs Second-Price
  7. OpenRTB for Different Ad Formats
  8. Common Implementation Challenges
  9. The Future: OpenRTB 3.0 and Beyond

What Is OpenRTB?

OpenRTB (Open Real-Time Bidding) is an open-source communication protocol that standardizes how digital advertising inventory is bought and sold in real time. Maintained by the IAB Tech Lab (Interactive Advertising Bureau), it defines the JSON-based API through which a publisher's supply-side platform (SSP) or ad exchange communicates available ad impressions to demand-side platforms (DSPs), and how those DSPs respond with bids.

Before OpenRTB, every ad exchange used proprietary protocols. A DSP integrating with five exchanges had to build and maintain five separate adapters, each with different field names, data formats, and auction semantics. This fragmentation slowed innovation, increased integration costs, and made the ecosystem less efficient for everyone.

A Brief History

The protocol was first published in 2010 by a consortium of ad tech companies led by Right Media (Yahoo), DoubleClick (Google), and Rubicon Project. The initial goal was narrow: standardize the bid request/response contract so that real-time bidding could scale. Since then, OpenRTB has gone through multiple major revisions:

Key insight: OpenRTB doesn't define auction mechanics (first-price vs. second-price), creative rendering, or ad verification. It defines the language that buyers and sellers use to communicate. Auction rules, fraud detection, and viewability measurement are handled by adjacent standards and platform-specific logic.

How Real-Time Bidding Works

Every time a user loads a webpage or opens an app with ad inventory, a micro-auction takes place in roughly 100-150 milliseconds. Here is the sequence, step by step:

  1. User visits a publisher. The publisher's page loads, and the ad server or SDK identifies an available impression opportunity.
  2. SSP constructs a bid request. The publisher's SSP or ad exchange builds an OpenRTB bid request containing information about the impression (ad size, format, floor price), the user (device, location, consent signals), and the context (site URL, app bundle, content category).
  3. Bid request is sent to DSPs. The exchange fans out the request to multiple DSPs via server-to-server (S2S) connections, typically over HTTP POST with JSON payloads.
  4. DSP evaluates the opportunity. Each DSP receives the bid request, looks up the user in its data store, evaluates the impression against active campaigns, runs its bidding algorithm, and decides whether to bid and at what price.
  5. DSP returns a bid response. If the DSP wants to participate, it returns an OpenRTB bid response containing the bid price, creative markup (ad tag, VAST XML, native assets), and metadata.
  6. Exchange runs the auction. The exchange collects all responses, determines the winner according to its auction rules, and notifies both the winning DSP and the losing bidders (via nurl or loss notification).
  7. Ad is served. The winning creative is rendered in the publisher's ad slot.

This entire flow, from impression opportunity to ad render, must complete within the timeout window, which is typically 100-150ms for display and up to 200-250ms for video. That timeout budget must account for network latency, DSP processing time, auction computation, and creative delivery.

OpenRTB 2.5 vs 2.6 vs 3.0

Understanding the differences between OpenRTB versions is critical for implementation planning. Here is a comparison of the three versions currently in active use:

OpenRTB 2.5

The de facto production standard. The vast majority of programmatic transactions worldwide still run on OpenRTB 2.5. It defines a monolithic JSON object hierarchy rooted in the BidRequest and BidResponse objects, with inline sub-objects for Site, App, Device, User, Imp (impression), and format-specific extensions (Banner, Video, Native, Audio).

OpenRTB 2.6

Released in 2022, version 2.6 is a backward-compatible extension of 2.5. Key additions include:

OpenRTB 3.0

OpenRTB 3.0 represents a ground-up redesign of the protocol. The major architectural shifts include:

Adoption reality: As of late 2026, OpenRTB 2.5 remains dominant in production. Version 2.6 adoption is growing, especially among platforms that need supply chain transparency. OpenRTB 3.0 is in early adoption with several major exchanges running dual-stack (2.5 + 3.0) pilots. Full 3.0 migration is expected to take 3-5 years across the industry.

Bid Request Deep Dive

The bid request is the cornerstone of OpenRTB. It carries everything a DSP needs to evaluate an impression opportunity. Here is the top-level structure (OpenRTB 2.5):

{
  "id": "req-abc-12345",
  "at": 1,
  "tmax": 120,
  "wseat": ["seat-42", "seat-99"],
  "bseat": [],
  "imp": [{
    "id": "imp-1",
    "instl": 0,
    "tagid": "header-banner-728x90",
    "bidfloor": 0.50,
    "bidfloorcur": "USD",
    "banner": {
      "w": 728,
      "h": 90,
      "pos": 1,
      "mimes": ["image/jpeg", "image/png"],
      "battr": [8, 9, 10]
    },
    "ext": {
      "prebid": { /* Prebid Server extensions */ }
    }
  }],
  "site": {
    "id": "site-9876",
    "domain": "example.com",
    "page": "https://example.com/news/article-123",
    "cat": ["IAB1", "IAB9"],
    "publisher": {
      "id": "pub-001",
      "name": "Example Publisher"
    }
  },
  "device": {
    "ua": "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0...)",
    "geo": {
      "lat": 37.7749,
      "lon": -122.4194,
      "country": "US",
      "region": "CA",
      "city": "San Francisco"
    },
    "devicetype": 1,
    "ifa": "38400000-8cf0-11bd-b23e-10b96e40000d",
    "os": "iOS",
    "osv": "17.0",
    "ip": "192.0.2.1"
  },
  "user": {
    "id": "user-hash-xyz",
    "buyeruid": "dsp1-user-abc",
    "yob": 1990,
    "gender": "M",
    "ext": {
      "consent": "CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA",
      "eids": [{
        "source": "uidapi.com",
        "uids": [{ "id": "UID2-value" }]
      }]
    }
  },
  "regs": {
    "ext": {
      "gdpr": 1,
      "us_privacy": "1YNN"
    }
  }
}

Key Fields Explained

imp (Impression Array): Each element represents one ad placement available for bidding. The banner, video, audio, or native sub-object specifies the format. The bidfloor and bidfloorcur fields declare the minimum acceptable price and currency. Multiple impressions can appear in a single request (multi-imp requests), which is common in header bidding scenarios.

device: Describes the user's device including user agent, device type (mobile, tablet, CTV, desktop), operating system, screen dimensions, and hardware identifiers. The ifa field carries the advertising ID (IDFA on iOS, GAID on Android), which is critical for user-level targeting and frequency capping.

user: Contains user-level data including exchange-level user ID, buyer-specific user ID (set via cookie sync or UID mapping), demographic signals, and identity extension objects (eids) for post-cookie identity solutions.

site / app: One of these objects describes the context. For web, site includes the domain, page URL, content category, and publisher info. For mobile apps, app replaces site and includes the app bundle ID, store URL, and app name.

regs: Regulatory signals. The gdpr flag indicates whether the user is in a GDPR-regulated region, and us_privacy carries the CCPA opt-out signal. The user.ext.consent field carries the full IAB TCF v2 consent string.

Bid Response Structure

When a DSP decides to bid on an impression, it returns a bid response. The response follows a nested structure: BidResponse → SeatBid[] → Bid[]. The SeatBid layer exists because a single DSP may bid on behalf of multiple "seats" (advertisers or buying entities).

{
  "id": "req-abc-12345",
  "seatbid": [{
    "seat": "seat-42",
    "group": 0,
    "bid": [{
      "id": "bid-001",
      "impid": "imp-1",
      "price": 2.75,
      "nurl": "https://dsp.example.com/win?price=${AUCTION_PRICE}",
      "adm": "<div>...creative markup...</div>",
      "adid": "creative-555",
      "adomain": ["advertiser.com"],
      "cat": ["IAB2"],
      "dealid": "deal-xyz",
      "w": 728,
      "h": 90,
      "attr": [6],
      "ext": {
        "prebid": {
          "type": "banner"
        }
      }
    }]
  }],
  "bidid": "response-abc",
  "cur": "USD"
}

Critical Response Fields

price: The bid price in CPM (cost per mille, i.e., per thousand impressions). In a first-price auction, this is the exact amount the buyer will pay if they win. In a second-price auction, the buyer pays the second-highest bid plus a minimal increment.

adm: The ad markup. For display ads, this is typically HTML/JavaScript. For video, it contains a VAST XML tag. For native, it's a JSON object with native asset specifications. Some exchanges support nurl (win notification URL) instead of inline markup, where the exchange fetches the creative after the auction concludes.

nurl: The win notification URL. When the bid wins, the exchange fires this URL, optionally substituting ${AUCTION_PRICE} with the actual clearing price. This allows the DSP to log the win and serve the creative dynamically.

adomain: The advertiser domain(s). Exchanges use this for competitive separation (preventing competing advertisers from appearing in the same ad slot) and for publisher block lists.

Auction Types: First-Price vs Second-Price

OpenRTB's at field in the bid request specifies the auction type, though in practice, most exchanges override this with their own rules.

Second-Price Auction (at=2)

The traditional RTB auction model, derived from Vickrey auction theory. The highest bidder wins but pays the second-highest bid plus $0.01. This was the dominant model in early programmatic because it incentivizes truthful bidding: your optimal strategy is to bid your true valuation of the impression, since overpaying is protected by the second-price mechanism.

First-Price Auction (at=1)

Starting around 2018-2019, major exchanges (Google Ad Manager, PubMatic, Xandr, and others) transitioned to first-price auctions. The winner pays exactly what they bid. This shift was driven by header bidding, which fragmented the auction across multiple exchanges running parallel second-price auctions, creating inefficiencies and "bid jamming" where intermediaries could manipulate clearing prices.

In a first-price auction, DSPs must implement bid shading algorithms to avoid overpaying. Bid shading uses historical auction data, win rates, and competitive density to estimate the optimal bid price — just enough to win without paying more than necessary. A typical bid shading model might reduce the raw bid by 15-40% depending on the impression's competitive profile.

Unified first-price auction: Google's move to a unified first-price auction in 2019 was a watershed moment. By eliminating the "last-look" advantage that second-price mechanics gave to Google's own demand, it leveled the playing field for all bidders. Today, first-price auctions are the industry standard for open exchange transactions.

Bid Shading Mechanics

A bid shading algorithm typically considers: historical clearing prices for similar inventory (domain, geo, device, format), the number of competing bidders (estimated from win rate data), the buyer's campaign urgency (pacing and budget depletion rate), and floor price proximity. The goal is to find the "efficient bid" that maximizes win rate while minimizing cost per win.

OpenRTB for Different Ad Formats

OpenRTB is format-agnostic at the request level. The impression object (imp) includes format-specific sub-objects that describe the creative requirements.

Display (Banner)

The simplest format. The imp.banner object specifies dimensions (w, h), allowed MIME types, blocked creative attributes (e.g., battr: [8,9,10] blocks expanding, audio, and survey interstitials), and position. The creative is typically returned as inline HTML in the adm field.

Video (VAST/VPAID)

Video impressions use the imp.video object, which specifies:

The bid response for video typically contains a VAST XML tag in the adm field. The VAST tag defines the media file URL, tracking events (impression, start, first quartile, midpoint, third quartile, complete), and optional companion banners. VPAID (Video Player-Ad Interface Definition) extends VAST with an interactive JavaScript layer, though its usage is declining in favor of SIMID (Secure Interactive Media Interface Definition) and OMID (Open Measurement Interface Definition).

Native

Native ads use the imp.native object with a JSON request field following the Native Ads API specification. The request defines required and optional assets: title (with character limits), image assets (main image, icon, with dimension constraints), data assets (description, CTA text, sponsor name, rating, price, etc.). The bid response returns a matching adm JSON with asset values.

Audio

Audio impressions use imp.audio, which specifies MIME types, protocols (DAAST 1.0+), minimum and maximum ad duration, and feed type (music, podcast, radio, etc.). Audio ads are served as VAST or DAAST tags with audio media files.

Digital Out-of-Home (DOOH)

DOOH is one of the fastest-growing segments for OpenRTB. The device object is extended with screen-level attributes: physical dimensions (in centimeters), screen resolution, location (latitude/longitude of the physical screen), and venue type. The impression may include playback scheduling (loop-based or triggered), and the creative is typically a video file or image sequence optimized for large-format display.

Common Implementation Challenges

Latency Budgeting

The 100-150ms timeout is unforgiving. A DSP must parse the bid request, perform user lookup (database or cache query), evaluate dozens or hundreds of eligible campaigns, run the bidding model, construct the response, and transmit it back. Each step adds milliseconds. Common strategies include:

Fraud Detection

Invalid traffic (IVT) remains a persistent challenge. Bid requests may originate from bots, device farms, spoofed domains, or manipulated SDKs. DSPs must implement multi-layered fraud detection:

Viewability

An ad that is served but never seen by a human is wasted spend. The IAB defines a viewable impression as one where at least 50% of the creative's pixels are visible in the viewport for at least 1 continuous second (display) or 2 continuous seconds (video). OpenRTB itself doesn't carry viewability data, but SSPs often pass predicted viewability scores in the imp.ext field, and third-party verification vendors (DoubleVerify, Integral Ad Science, Moat) measure actual viewability post-serve.

Privacy and Consent

With GDPR, CCPA, LGPD (Brazil), and the deprecation of third-party cookies, OpenRTB implementations must carefully handle consent signals. The regs object carries jurisdiction-level flags, while the user.ext.consent field carries the IAB TCF v2 consent string. DSPs must parse these strings to determine which purposes and vendors have consent, and adjust their data processing accordingly. Misuse of personal data without valid consent exposes both buyer and seller to regulatory penalties.

Creative Review and Quality

Exchanges must review creatives before they can serve. This creates a cold-start problem for new campaigns. Most exchanges implement a two-phase review: automated scanning (malware detection, ad policy compliance, file size checks) followed by manual review for flagged creatives. OpenRTB's cat (creative category) and attr (creative attributes) fields help exchanges pre-filter creatives without full review.

The Future: OpenRTB 3.0 and Beyond

OpenRTB 3.0 is the most significant evolution in the protocol's history. While adoption is still early, its architectural improvements address fundamental limitations of the 2.x series:

Performance at Scale

At the scale of modern programmatic (billions of bid requests per day across major exchanges), JSON parsing becomes a bottleneck. Protobuf serialization produces payloads that are 3-10x smaller and parse 5-20x faster than equivalent JSON. For a DSP processing millions of requests per second, this translates to substantial infrastructure cost savings and reduced latency.

Supply Chain Authentication

ads.cert, the digital signature standard integrated into OpenRTB 3.0, provides cryptographic proof that a bid request originated from an authorized seller and was not modified in transit. This directly addresses domain spoofing and unauthorized reselling, which remain significant fraud vectors in the 2.5 ecosystem. Each hop in the supply chain signs the request, creating a verifiable audit trail.

AdCOM: A Unified Object Model

The Advertising Common Object Model (AdCOM) separates reusable advertising objects (placements, media definitions, user data structures) from the transaction protocol. This means the same Placement object can be used in an OpenRTB bid request, a direct-sold ad management API call, or a creative quality review tool. AdCOM eliminates the redundancy and inconsistency that accumulated across OpenRTB 2.x versions.

What Comes Next

Migration advice: If you're building new ad tech infrastructure today, design for OpenRTB 2.5 compatibility but architect your data models to align with AdCOM principles. This positions you for a smoother 3.0 migration when your exchange partners are ready. Abstract the protocol layer so you can swap JSON for protobuf without rewriting your bidding logic.

Getting Started

If you're implementing OpenRTB for the first time, start with the IAB Tech Lab's official specification and reference implementations. Key open-source tools include Google's OpenRTB library (Java/C++/Python), Prebid Server (Go/Java) for header bidding, and various testing tools like the IAB's OpenRTB Validation Suite. Test thoroughly against edge cases: empty impressions, missing device data, malformed consent strings, and timeout scenarios.