OpenRTB 3.0 and AdCOM 1.0: Why the Industry Standardized on OpenRTB 2.6 Monthly GitHub Releases

In an OpenRTB 3.0 bid request payload, the top-level openrtb envelope enforces a strict three-layer architectural boundary that decouples auction transaction mechanics from the underlying Advertising Common Object Model (AdCOM 1.0) domain objects. When the IAB Tech Lab released OpenRTB 3.0 alongside AdCOM 1.0 in late 2018, the engineering objective was unambiguous: eliminate the structural debt accumulated across OpenRTB 2.1 through 2.5, unify fragmented placement schemas, and introduce cryptographic supply chain verification at the protocol level.

Despite the architectural elegance of that separation, global programmatic exchanges, Prebid Server clusters, and tier-1 DSPs never migrated their core real-time bidding pipelines to the 3.0 wire format. Rewriting serialization engines, machine learning feature extractors, and petabyte-scale data warehouse schemas for a non-backward-compatible JSON structure proved economically and operationally unviable across infrastructure processing tens of millions of queries per second (QPS).

Rather than allowing the ecosystem to fracture permanently into proprietary extension (ext) fields inside frozen OpenRTB 2.5 payloads, the IAB Tech Lab OpenRTB working group pivoted to a pragmatic, continuous-delivery standard. Beginning with OpenRTB 2.6 and transitioning into dated monthly GitHub releases (such as v2.6-202211, v2.6-202303, and v2.6-202309+), the industry backported AdCOM 1.0 enumerations and modern commercial primitives directly into the battle-tested 2.x JSON tree.

The Architectural Ambition of OpenRTB 3.0: Separation of Transport and Domain (AdCOM)

To understand why OpenRTB 3.0 was designed as a clean-slate rewrite, engineering teams must examine the structural compromises embedded in OpenRTB 2.5. As programmatic trading expanded from desktop display banners into mobile apps, rewarded video, native feeds, and Connected TV (CTV), the 2.x specification grew by bolting disparate objects onto a flat root schema. Transaction parameters (such as imp.bidfloor, at, and tmax), media placement specifications (imp.banner, imp.video, imp.audio), and contextual signals (site, app, device, user) were tightly interleaved. Most notoriously, the Native Ads 1.x specification evolved on an independent timeline, forcing SSPs and DSPs to serialize and deserialize a double-encoded, stringified JSON payload inside imp.native.request and seatbid.bid.adm on every single auction.

OpenRTB 3.0 resolved these inconsistencies by dividing the programmatic protocol into three modular specifications:

1. The Transport Layer: Governs the network exchange mechanics, including HTTP/1.1 and HTTP/2 persistent connection pooling, gzip payload compression, TLS negotiation, and header signaling.
2. The Transaction Layer (OpenRTB 3.0 Core): Governs only the commercial auction lifecycle. It defines the Request, Item (replacing the 2.x Imp object), Deal, Response, Seatbid, and Bid objects, alongside standardized billing (burl), loss (lurl), and markup (adm) mechanics.
3. The Domain Layer (AdCOM 1.0): Defines the actual media inventory, contextual environment, and creative assets being traded. In OpenRTB 3.0, the Transaction layer references AdCOM 1.0 objects inside strongly typed sub-containers: item.spec contains an AdCOM Placement object (unifying display, native, video, and audio without stringified sub-schemas), request.context contains AdCOM DistributionChannel (Site, App, Dooh), Device, User, and Regs objects, and bid.media contains the AdCOM Ad object.

Understanding what an SSP is from a systems architecture perspective requires looking at how an exchange validates, enriches, and routes these payloads within a 100-millisecond auction window. OpenRTB 3.0 aimed to make this validation deterministic by isolating commercial rules from media taxonomy changes. In theory, the IAB Tech Lab could update an AdCOM VideoPlacement attribute or add a new CTV device enumeration without ever touching the OpenRTB 3.0 Transaction specification.

Why Migration Stalled: Infrastructure Inertia at 10 Million QPS

When architectural purity collides with high-throughput distributed systems, wire-format compatibility almost always wins. Between 2019 and 2021, adoption of OpenRTB 3.0 across major sell-side platforms and tier-1 DSPs stalled near zero for four concrete engineering and economic reasons:

• Complete Wire-Level Incompatibility: OpenRTB 3.0 altered the JSON path of every single attribute in a bid request and bid response. A simple floor price check that referenced imp[0].bidfloor in OpenRTB 2.5 moved to openrtb.request.item[0].flr in OpenRTB 3.0. A video minimum duration attribute moved from imp[0].video.minduration to openrtb.request.item[0].spec.placement.video.mindur. Every C++, Go, Rust, and Java struct across thousands of DSP bidding microservices, along with every downstream Apache Parquet, Avro, and Protobuf schema in petabyte-scale data lakes, was hardcoded to 2.x field paths.
• Translation Proxy CPU and Tail-Latency Penalties: Because neither side of the market could cut over simultaneously, exchanges experimented with bidirectional translation layers that converted OpenRTB 2.5 into 3.0 for outbound DSP callouts and mapped 3.0 responses back to 2.5. At 5 million to 10 million QPS, allocating extra heap memory to construct nested openrtb.request.context and openrtb.request.item[].spec.placement trees increased garbage collection pauses and added 2 to 4 milliseconds of p99 tail latency per auction hop. In programmatic auctions governed by strict auction timeout curves, latency directly erodes bid density and publisher yield.
• Zero Incremental Revenue for Rewriting Core Parsers: For a DSP engineering organization, refactoring a bidding engine to ingest OpenRTB 3.0 purely to receive the exact same site, device, and video signals in a different JSON hierarchy generated zero incremental return on ad spend (ROAS). Engineering roadmaps prioritized privacy sandbox readiness, identity resolution, and CTV pod bidding over cosmetic schema migrations.
• The ext Object Escape Hatch: OpenRTB 2.x already contained a built-in extensibility mechanism: the ext JSON object available at every node of the tree. Whenever the industry needed a new capability between 2017 and 2021 (such as ads.txt SupplyChain schain, GDPR TCF consent strings, Extended Identifiers eids, or rewarded video signals), Prebid Server, Google Ad Manager, and participating SSPs simply injected those objects into source.ext.schain, user.ext.eids, or imp.video.ext.

By mid-2021, however, reliance on ext objects had created severe supply path optimization (SPO) friction. Different exchanges placed CTV podding fields or User-Agent Client Hints in slightly different ext namespaces, forcing DSPs to maintain dozens of brittle, exchange-specific JSON parsers.

How IAB Tech Lab Backported AdCOM Innovations into OpenRTB 2.6

Faced with universal industry consensus that the OpenRTB 2.x JSON envelope was permanent infrastructure, the IAB Tech Lab executed a decisive architectural pivot. Rather than forcing the ecosystem onto the OpenRTB 3.0 Transaction wrapper, the working group established OpenRTB 2.6 (formally ratified in early 2022) as the active development branch and began systematically backporting AdCOM 1.0 objects and enumerations directly into the 2.x hierarchy.

This compromise gave programmatic engineering teams the best of both worlds. Exchanges and DSPs kept their ultra-fast, zero-allocation JSON parsers, historical data schemas, and 2.x object paths (imp, site, app, device, user, source, regs), while immediately gaining standardized, root-level fields for modern media formats. Standardizing on our OpenRTB 2.6 infrastructure allows publishers across Web, Mobile App, and CTV to pass rich contextual, podding, and identity telemetry to tier-1 DSPs without bespoke ext translation overhead.

Structured User Agent (sua), CTV Ad Pods, DOOH, DurFloor, and Refresh Objects

Through the initial OpenRTB 2.6 release and its subsequent iterative GitHub updates (v2.6-202211, v2.6-202303, and v2.6-202309+), the IAB Tech Lab promoted the most critical programmatic capabilities from fragmented extensions into first-class 2.6 schema objects:

• Structured User-Agent (device.sua): As Chromium deprecated granular User-Agent strings in favor of Sec-CH-UA-* HTTP Client Hints, regex-based UA parsing on the buy side began failing to distinguish device models and OS versions. OpenRTB 2.6 backported the UserAgent object directly into device.sua. When a browser or WebView emits high-entropy client hints, the SSP populates sua.browsers, sua.platform, sua.mobile, sua.architecture, sua.bitness, sua.model, and sua.source (an enumeration indicating whether the data originated from low-entropy headers, high-entropy headers, or a parsed User-Agent string).
• CTV Ad Podding (imp.video and podid): In OpenRTB 2.5, signaling a multi-slot television commercial break required non-standard extensions. OpenRTB 2.6 introduced native support for fixed, dynamic, and hybrid CTV ad pods inside imp.video. Publishers now signal podid (unique identifier for the pod), podseq (position of the pod within the content stream: first, last, or mid-roll), poddur (total duration of the pod in seconds), maxseq (maximum number of ads permitted in the pod), slotinpod (guaranteed first, last, or first-or-last exclusivity), mincpmpersec (dynamic floor per second for variable-length pods), and rqddurs (an array of exact allowed creative durations).
• Duration Floors (durfloors): Historically, CTV and video publishers could only set a single flat imp.bidfloor, allowing buyers to serve a 30-second spot at the clearing price intended for a 15-second spot. Introduced in the iterative 2.6 updates, the DurFloors object inside imp.video.durfloors and imp.pmp.deals[].durfloors enables tiered floor elasticity indexed by creative length (mindur, maxdur, bidfloor), maximizing yield per second of commercial airtime.
• Digital Out-of-Home (dooh) and Impression Multipliers (imp.qty): OpenRTB 2.6 added dooh as a top-level distribution channel peer to site and app, complete with venue taxonomy (venuetype, venuetypetax) sourced from AdCOM 1.0. Paired with the Qty object (imp.qty.multiplier and imp.qty.sourcetype), SSPs can accurately represent out-of-home screens and co-viewed CTV environments where a single ad play generates multiple verified human views.
• Auto-Refresh Signaling (imp.refresh and RefSettings): Added in the v2.6-202309+ cadence, the Refresh object standardizes how web and in-app publishers declare in-view slot refreshes. By populating imp.refresh.count (the number of times the placement has already refreshed during the user session) alongside imp.refresh.refsettings (reftype indicating viewability-triggered, user-action, or timer-based refresh, and minint specifying the minimum interval in seconds), SSPs eliminate buyer guesswork and protect publisher inventory from aggressive DSP bid shading.
• AdCOM Taxonomies and SupplyChain Promotion: First-party objects like source.schain (SupplyChain), user.eids (EID), and regs.gpp (Global Privacy Platform string) moved out of ext and into the official schema, while cattax fields across bcat, site, app, and bid defaulted to AdCOM 1.0 category and creative attribute enumerations.

The following production-grade OpenRTB 2.6 JSON payload illustrates how these backported AdCOM objects coexist inside the standard 2.x request structure:

{
  "id": "80ce30c53c16e",
  "tmax": 120,
  "at": 1,
  "cur": ["USD"],
  "cattax": 2,
  "imp": [
    {
      "id": "1",
      "bidfloor": 14.50,
      "bidfloorcur": "USD",
      "rwdd": 0,
      "ssai": 2,
      "qty": {
        "multiplier": 1.4,
        "sourcetype": 1
      },
      "refresh": {
        "refsettings": [
          {
            "reftype": 1,
            "minint": 30
          }
        ],
        "count": 2
      },
      "video": {
        "mimes": ["video/mp4", "application/x-mpegURL"],
        "minduration": 15,
        "maxduration": 30,
        "protocols": [7, 8, 11, 12],
        "w": 1920,
        "h": 1080,
        "startdelay": 0,
        "plcmt": 1,
        "podid": "pod-midroll-01",
        "podseq": 0,
        "poddur": 90,
        "maxseq": 4,
        "slotinpod": 1,
        "mincpmpersec": 0.65,
        "durfloors": [
          { "mindur": 1, "maxdur": 15, "bidfloor": 14.50 },
          { "mindur": 16, "maxdur": 30, "bidfloor": 22.00 }
        ]
      }
    }
  ],
  "app": {
    "id": "ctv-stream-9941",
    "name": "Apex Stream CTV",
    "bundle": "com.apexstream.tv",
    "cat": ["IAB1-5"],
    "cattax": 2
  },
  "device": {
    "ip": "198.51.100.42",
    "ifa": "38400000-8cf0-11bd-b23e-10b96e40000d",
    "devicetype": 3,
    "sua": {
      "platform": { "brand": "Android", "version": ["12", "0", "0"] },
      "browsers": [{ "brand": "Chromium", "version": ["122", "0", "6261", "90"] }],
      "mobile": 0,
      "model": "Bravia 4K VH2",
      "source": 2
    }
  },
  "regs": {
    "gpp": "DBACNYA~CPXxRfAPXxRfAAfkabENB-CgAAAAAAAAAAYgAAAAAAAA~1YNN",
    "gpp_sid": [2, 7]
  }
}

Navigating IAB Tech Lab's Dated Versioning Cadence (v2.6-YYYYMM) on GitHub

Beyond backporting AdCOM objects, the most significant operational shift in OpenRTB 2.6 is how the specification itself is maintained and versioned. Under the legacy model, the industry waited years between monolithic PDF releases (OpenRTB 2.3 in 2015, 2.4 in early 2016, and 2.5 in December 2016). When regulatory changes like GDPR/CCPA or technical changes like video.plcmt arrived mid-cycle, waiting two years for a major version bump was impossible.

Today, the IAB Tech Lab manages both OpenRTB 2.x and AdCOM as living Markdown repositories on GitHub, publishing immutable monthly or bi-monthly snapshots tagged in the v2.6-YYYYMM format (v2.6-202211, v2.6-202303, v2.6-202309, and subsequent iterations). Every merge follows a strict additive-only schema evolution policy:

1. Non-Breaking Field Additions: New attributes (such as imp.refresh, imp.video.durfloors, or regs.gpp) are added as optional fields on existing objects. No existing 2.6 field is ever renamed, re-typed, or removed within the 2.x branch.
2. Single Wire Header (x-openrtb-version: 2.6): Exchanges continue to transmit x-openrtb-version: 2.6 in the HTTP request header regardless of which monthly v2.6-YYYYMM GitHub snapshot they have implemented. Because JSON parsers in Go (encoding/json) and Java (Jackson configured with DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES disabled) silently ignore unrecognized keys, an SSP can deploy v2.6-202309+ fields to all outbound endpoints immediately without breaking DSPs still parsing the baseline 2022 schema.
3. Synchronized AdCOM Enumerations: List enumerations (such as updated video placement subtypes in video.plcmt, new VAST 4.3 API frameworks, or updated privacy regulation flags) are maintained in the AdCOM repository and directly referenced by the monthly OpenRTB 2.6 releases.

For AdOps architects and programmatic engineering teams, this dated GitHub release model requires a disciplined quarterly schema synchronization workflow. Rather than treating OpenRTB 2.6 as a static checkbox, exchange and publisher engineering teams should audit their Prebid.js 11.x, Prebid Server, and GAM integration pipelines against the latest v2.6-YYYYMM GitHub tag every quarter. Specifically, verify that video placements populate updated video.plcmt values alongside legacy placement integers, migrate proprietary ext refresh and podding parameters into standard imp.refresh and imp.video.durfloors nodes, and ensure device.sua is forwarded from client-side headers through server-side adapters to maximize DSP bid density and clearing prices.