OpenRTB 2.6 DOOH Bid Stream: A Technical Deep Dive

With 60,000+ DOOH screens under contract and 10,629+ screens actively onboarded, Trillboards processes massive volumes of transactional data every second.

For enterprise CTOs, VP of Engineering, and Head of Ad Operations, understanding the underlying programmatic advertising technical architecture is non-negotiable.

Digital Out-of-Home (DOOH) has fundamentally transformed from a static, direct-sales medium into a highly structured, scalable programmatic ecosystem.

This evolution is largely driven by the release of the OpenRTB 2.6 standard, which introduced native support for the unique nuances of physical screens in the real world.

This technical deep dive explores the anatomy of an OpenRTB 2.6 request, the mechanics of the DOOH bid stream, and the critical infrastructure required to operate a next-generation Supply-Side Platform (SSP).

---

The Evolution of Programmatic Architecture in DOOH

Historically, applying digital programmatic standards to DOOH was like fitting a square peg into a round hole.

Protocols designed for one-to-one web browsers failed to account for physical venue contexts, multi-viewer impression multipliers, and offline caching.

According to the IAB Tech Lab, OpenRTB 2.6 decoupled its enumerated lists to point directly to the AdCOM 1.0 companion specification.

This architectural shift allows for monthly, non-breaking schema updates and faster technical adoption across the ecosystem.

Overcoming Legacy Protocol Limitations

Before OpenRTB 2.6, SSPs and DSPs relied on custom extensions to pass DOOH-specific data.

This fragmentation led to massive discrepancies in impression counting and billing.

DSPs often misinterpreted DOOH bid requests as standard mobile video, leading to invalid bids and high latency.

How OpenRTB 2.6 Solves DOOH Nuances

The introduction of OpenRTB 2.6 standardized the communication between SSPs and DSPs for physical screens.

It established authoritative objects for venue types, audience multipliers, and device physical characteristics.

By leveraging this standard, platforms like Trillboards can offer an API-first digital signage API that translates local CMS telemetry into standardized programmatic bid requests.

---

Deep Dive: Anatomy of the OpenRTB 2.6 Request Object

To understand the DOOH bid stream, we must inspect the JSON payload transmitted from the SSP to the DSP during a real-time auction.

Below is a representative OpenRTB 2.6 bid request generated by the Trillboards SSP.

The JSON Payload Structure

The following payload illustrates a standard video ad request for a digital signage screen.

{
  "id": "trill_req_8f9a2b1c4d5e",
  "imp": [
    {
      "id": "1",
      "video": {
        "mimes": ["video/mp4"],
        "minduration": 5,
        "maxduration": 15,
        "w": 1920,
        "h": 1080,
        "protocols": [2, 3, 7, 8],
        "placement": 5,
        "plcmt": 4,
        "api": [7]
      },
      "dooh": {
        "venuetype": ["1"],
        "venuetypeid": 23,
        "pub": {
          "id": "pub_9942",
          "name": "Urban Transit Network"
        }
      },
      "qty": {
        "multiplier": 14.5,
        "sourcetype": 1,
        "vendor": "Trillboards Audience Insights"
      },
      "bidfloor": 12.50,
      "bidfloorcur": "USD"
    }
  ],
  "device": {
    "ua": "Trillboards-SDK/1.4.2 (Linux; Android 10)",
    "ip": "192.0.2.1",
    "geo": {
      "lat": 40.7128,
      "lon": -74.0060,
      "type": 2,
      "accuracy": 10
    },
    "make": "BrightSign",
    "model": "XT1144",
    "os": "Linux",
    "hwv": "1.0"
  },
  "source": {
    "ext": {
      "schain": {
        "ver": "1.0",
        "complete": 1,
        "nodes": [
          {
            "asi": "trillboards.com",
            "sid": "pub_9942",
            "hp": 1
          }
        ]
      }
    }
  }
}

The Dedicated dooh Object

A core component of this architecture is the dedicated dooh object.

As documented by programmatic exchanges like Verve Group and BidSwitch, this object captures spatial and environmental context.

It maps physical screens to the OpenOOH Venue Taxonomy using fields like venuetypeid.

Currently, Trillboards maps inventory across 38 venue categories under the IAB OpenOOH taxonomy.

The Qty Object and Impression Multipliers

Crucially, because DOOH is a "one-to-many" medium, OpenRTB 2.6 implements the Qty object.

Within this object, the multiplier attribute (often referred to in legacy specs as impmultiply) enables DSPs to calculate billable media costs based on real-time audience impression multipliers.

This prevents DSPs from incorrectly inflating the raw CPM bid price for a single screen playout.

Key Insight: If a screen has an impression multiplier of 14.5, a DSP bidding a $10.00 CPM is effectively paying $0.145 for that single ad play. The Qty object standardizes this math across all programmatic buyers.

---

Real-Time Audience Intelligence in the Bid Stream

Passing static venue data is no longer sufficient for premium programmatic monetization.

DSPs demand dynamic audience intelligence to optimize their bidding algorithms.

Integrating IAB Audience Taxonomy

Trillboards enriches the bid stream with real-time audience telemetry.

Our platform currently supports 1,558 IAB Audience Taxonomy 1.1 nodes (segtax=4) directly within the OpenRTB requests.

Over the past 60 days alone, we have seen 675 IAB audience segments observed in live impressions across our network.

Sensing-Enabled Hardware

For advanced publishers utilizing computer vision and edge-AI, audience data becomes highly deterministic.

Currently, there are 82 sensing-enabled screens emitting segtax=600 audience signals during peak windows on the Trillboards network.

This deterministic data is passed to DSPs via the user.data array in the OpenRTB request, allowing buyers to target specific demographics currently standing in front of the screen.

---

Bridging CMS and SSP via Digital Signage API

Technically, this programmatic advertising technical architecture relies on RESTful digital signage APIs to bridge local Content Management Systems (CMS) with cloud-based SSPs.

Signage players dynamically request, cache, and inject programmatic video ads into local playlists.

The Trillboards Partner SDK

Building your own SSP can easily incur $500K+ in development costs.

Trillboards provides this infrastructure-as-a-service via our Partner SDK (@trillboards/ads-sdk).

This SDK supports TypeScript, React, React Native, Flutter, CTV, and server-side integrations.

Webhook-Driven Event Architecture

Modern digital signage networks require real-time observability.

Trillboards utilizes a webhook-driven event architecture to manage device status, impressions, payouts, and audience spikes.

Our OpenAPI spec (accessible via Swagger UI at /developer/docs) offers three API tiers:

1. Basic: 200 requests/min.
2. Developer: 1K requests/min, including venue intelligence.
3. Enterprise: 5K requests/min, raw data exports, and strict SLAs.

This API-first approach is ideal for networks like VapeTM utilizing smart vending machines with digital displays and advertising screens to generate programmatic yield.

---

VAST Tag Validation and OM SDK Verification

When a DSP wins an auction, it responds with an ad markup payload, typically formatted as a Video Ad Serving Template (VAST).

To ensure flawless delivery, developers must utilize rigorous VAST tag validation.

The Importance of Validation

Authoritative tools like the IAB Tech Lab VAST Tag Validator verify that incoming VAST 4.x templates correctly parse AdVerification nodes.

Validation ensures that interactive, non-compatible elements (such as skippability) are stripped before playout occurs on the physical screen.

To date, Trillboards has performed 89,155 creative-level classifications across 23 IAB Content Taxonomy top-level categories, combining brand-safety and categorization checks.

Open Measurement Interface Definition (OMID)

Brand advertisers demand MRC-compliant ad verification.

Trillboards integrates the OM SDK (Open Measurement SDK) to execute OMID scripts embedded within VAST tags.

This allows third-party measurement vendors (like DoubleVerify or Integral Ad Science) to independently verify viewability and fraud metrics on DOOH inventory.

---

Supply Chain Transparency and Brand Safety

Fraud prevention is a critical pillar of programmatic advertising technical architecture.

Buyers will not bid on DOOH inventory that lacks verifiable supply chain transparency.

The 14-Check Validation Runbook

To protect our exchange, Trillboards executes a proprietary 14-check OpenRTB 2.6 supply-chain validation runbook on every request.

This runbook validates:

• ads.txt / app-ads.txt: Ensuring the publisher has authorized Trillboards to sell the inventory.
• sellers.json: Verifying the identity of the publisher within the Trillboards SSP.
• SupplyChain Object (schain): Tracing the exact path of the impression from the physical screen to the DSP.

By enforcing these checks, we ensure that DSPs bidding on Trillboards inventory are completely protected from domain spoofing and IVT (Invalid Traffic).

---

The Trillboards Architecture: Next-Gen SSP

Trillboards is engineered as a next-generation SSP and free ad server specifically for DOOH and digital signage publishers.

Unlike legacy systems that act purely as a CMS, Trillboards is the revenue layer.

Multi-Demand VAST Waterfall

Our platform operates a sophisticated multi-demand-source VAST waterfall.

This waterfall integrates Google Ad Manager (GAM), HiveStack, Vidverto, and our own OpenRTB exchange.

The system utilizes a second-price auction engine to maximize yield for the publisher while maintaining low latency.

The Business Model: Free Ad Server & Transparent Revenue Split

Competitors in the digital signage space often charge $5 to $45 per screen per month just for CMS software.

Trillboards provides a completely free ad server—publishers pay $0/screen/month.

The platform monetizes exclusively through ad demand, not publisher fees.

Programmatic ad revenue is split 60/40 in the publisher's favor: the venue/publisher keeps 60%, Trillboards keeps 40%.

This alignment ensures that Trillboards only succeeds when our publishers succeed, making it the perfect infrastructure for networks, as JUUCE demonstrates with their portable phone charger rental kiosks with digital signage in stadiums and high-traffic venues.

---

Benchmarks and Best Practices for Implementation

For engineering teams integrating with a digital signage API, performance is critical.

DOOH environments often suffer from intermittent internet connectivity, requiring robust caching strategies.

Latency Optimization in the DOOH Bid Stream

In standard web RTB, auctions must conclude within 100-200 milliseconds.

In DOOH, the request is often made minutes or hours before the actual playout, a process known as "prefetching."

Best Practices for Prefetching:

• Implement local caching of VAST XML payloads on the media player.
• Download heavy MP4 video assets to local storage during off-peak hours.
• Fire the impression beacon (the <Impression> URL in the VAST tag) only when the first frame of the video renders on the physical screen.

Handling Offline Playouts

If a screen loses internet connection, it must continue to play cached content.

However, programmatic rules dictate that impressions must be reported in near-real-time to prevent fraud.

Trillboards' SDK handles this by queuing offline impression beacons and transmitting them with a timestamp once connectivity is restored, ensuring publishers still get paid for verified offline playouts.

---

Conclusion: The Future is API-First

The transition to OpenRTB 2.6 has unlocked unprecedented scale for programmatic DOOH.

By decoupling taxonomies and standardizing the DOOH bid stream, the industry has paved the way for massive enterprise adoption.

For CTOs and architects, leveraging an API-first platform like Trillboards eliminates the massive capital expenditure of building a proprietary SSP.

With our free ad server, OM SDK integration, and strict 60/40 revenue split, Trillboards provides the definitive programmatic infrastructure for the next generation of digital signage networks.

Ready to monetize your network? Explore our developer documentation and integrate the Trillboards SDK today.

---

Frequently Asked Questions

What is OpenRTB 2.6 and why is it important for DOOH?

OpenRTB 2.6 is a programmatic bidding protocol updated by the IAB Tech Lab. It is critical for DOOH because it introduces specific objects (like dooh and qty) that allow DSPs to bid accurately on physical screens and multi-viewer impressions.

How does the Qty object work in the DOOH bid stream?

The Qty object contains an impression multiplier. If a screen has 10 viewers, the multiplier is 10. This allows a DSP to bid a standard CPM, which the exchange then multiplies by 10 to calculate the final media cost, preventing artificially inflated CPMs.

What is VAST tag validation?

VAST tag validation is the process of inspecting incoming XML ad payloads to ensure they meet technical requirements. It verifies that the video formatting is correct, strips out incompatible interactive elements, and ensures OM SDK tracking scripts are properly formatted.

How much does Trillboards charge for its ad server?

Trillboards is a completely free ad server. Publishers pay $0 per screen per month. The platform monetizes through ad demand, and programmatic ad revenue is split 60/40 in the publisher's favor (the venue keeps 60%, Trillboards keeps 40%).

What is the OpenOOH Venue Taxonomy?

The OpenOOH Venue Taxonomy is a standardized list of physical location types (e.g., Gyms, Malls, Transit Stations). Trillboards maps its inventory across 38 venue categories to give DSPs precise context on where an ad is playing.

How does Trillboards handle ad verification?

Trillboards integrates the OM SDK (Open Measurement) for MRC-compliant ad verification. This allows third-party vendors to execute OMID scripts within the VAST tag to verify viewability and detect invalid traffic (IVT).

Can I integrate Trillboards into my existing CMS?

Yes. Trillboards offers a Partner SDK (@trillboards/ads-sdk) that acts as programmatic infrastructure-as-a-service. It supports TypeScript, React, React Native, and server-side integrations, allowing you to add programmatic monetization to any existing digital signage CMS.