How does DOOH work in OpenRTB?

A third distribution channel

Every OpenRTB bid request answers the question "where is this ad going to run?" with exactly one object. For two decades that meant site or app. The 2.6-202211 snapshot added a third: dooh, for screens in physical space, from airport panels to retail displays to roadside billboards.

The three are mutually exclusive. Sending both app and doohleaves a bidder with no defensible way to price the impression, which is why RTBlint treats it as an error rather than a warning.

The dooh object

Note what is missing: no page, no bundle, no user identity worth speaking of. A DOOH request describes a place, not a person, which is why it is one of the few programmatic channels that is structurally low-signal for privacy purposes.

The part that surprises bidders: imp.qty

Web and app assume one impression per ad. DOOH does not: one play on a screen in an arrivals hall is seen by whoever is standing there. OpenRTB models that with the Qty object on the impression.

"imp": [{
  "id": "1",
  "banner": { "w": 1080, "h": 1920, "pos": 7 },
  "qty": {
    "multiplier": 42.0,
    "sourcetype": 1,
    "vendor": "geopath.org"
  }
}]

multiplier is required and is a float: it is the number of impressions this one play represents, and it can be below 1 for a screen with low expected audience. sourcetype is recommended and names the class of measurement behind the number, using the AdCOM DOOH Multiplier Measurement Source Types list. vendor is required when sourcetype indicates a third-party measurement vendor.

Because the price on a bid is still a CPM, the multiplier is what turns a bid into a cost per play. And because the delivered audience may differ from the estimate at auction time, the notice URLs carry ${AUCTION_MULTIPLIER}, which expands to the total quantity of impressions actually won. See the macro reference.

What else changes for a bidder

• Device. device.devicetype 8 marks an out-of-home device, and device.geo is the fixed position of the screen. There is no ifa, no user agent worth parsing, and no meaningful user.eids.
• Creative. Screens are frequently portrait and very large, so banner.w and h land far outside display norms. Video DOOH is usually short, muted, and non-skippable, which constrains video.maxduration, playbackmethod, and skip.
• No clicks. There is nothing to click, so performance measurement runs on exposure and attribution rather than click-through, and imp.clickbrowser is meaningless.
• Timeouts. Screen loops are scheduled in advance, so DOOH tmax values are often more generous than web display.

Check a DOOH request

The DOOH example payload is a complete, valid request with a venue type and a quantity multiplier, and it opens directly in the tester. The most common failures on real DOOH traffic are a missing qty.multiplier, a venuetype string that does not exist in the taxonomy named by venuetypetax, and requests that still send site or app alongside dooh from a pre-2.6 code path.

Sources

• OpenRTB 2.6: DOOH (3.2.32), Qty (3.2.31), Imp (3.2.4)
• OpenRTB 2.6-202211 release notes
• AdCOM 1.0: DOOH Venue Taxonomies, DOOH Multiplier Measurement Source Types, Device Types