OpenRTB DOOH profile

The profile follows IAB Tech Lab OpenRTB 2.6 and AdCOM 1.0, and uses the OpenOOH venue taxonomy. Field names are taken from those specifications. Where we ask for more than the standard requires, the text says so.

Overview#

In this model the network is the supply side. For each screen slot it sends an OpenRTB bid request to the partner's bidder. The partner answers with a bid. The highest price wins, and the partner is billed after the creative has been played and the play has been verified.

This is different from the Bid protocol, which is the native protocol that we use today with individual bidders. The native protocol is simpler and is the default for new partners. This profile exists for platforms that already speak OpenRTB and cannot add a native integration.

Three properties set this profile apart from a web OpenRTB integration:

• Creatives are registered before the auction. A screen player must have the file on disk before the slot starts. A bid therefore cannot carry markup. It points to a creative that the partner has registered and that we have approved ahead of time. How the creative is registered is an open question, see below.
• Billing follows a verified play, not the win. The partner is billed when the billing notice (burl) fires after a verified play. The win notice (nurl) is informational.
• There is no user identity. A screen has no advertising id. device.ifa is never sent, and there is no user object.

Request profile#

The bid request is a standard OpenRTB 2.6 BidRequest with a dooh object instead of site or app.

dt and qty are the two fields that matter most for screens. A screen plays a slot at a known time, usually seconds after the auction, and a play reaches an audience whose size comes from a measurement. The multiplier we send comes from our own estimate of the passing audience. We do not claim it is a measured count of people who looked at the screen.

Response profile#

A bid response is a standard BidResponse with one seatbid and one bid per impression.

No bid is 204 with an empty body, or a BidResponse with nbr.

Billing#

The billing notice is called with GET after the player has reported a play and the report has been verified. The macros ${AUCTION_PRICE}, ${AUCTION_MULTIPLIER}, ${AUCTION_IMP_TS}, ${AUCTION_IMP_ID} and ${AUCTION_ID} are replaced with the clearing price (the bid price, because the auction is first price), the multiplier that was actually delivered, the time of the play in Unix milliseconds, the impression id and the bid request id. A win that is never played is never billed.

Open questions#

The profile is not final. These questions decide what it will look like. They are grouped as we plan to discuss them with partners.

Protocol#

Which OpenRTB version does the partner run, 2.5 or 2.6, and does it support the DOOH object, venue types and the impression multiplier? Does it use the OpenOOH taxonomy or its own? Are screens registered in advance (an inventory list or a synchronisation call), or is all screen data sent with each request? What is its response timeout, how long before the slot can a request arrive, and how long does a won ad stay valid? Where are its servers, and can they be reached from infrastructure that we host in Russia? What request rate does it expect and what throttling applies? Is there one request per slot, or are requests batched? Does it support sellers.json and schain, and how does it want the network to appear in the chain?

Auction and money#

First price or second price? Is the bid price net or gross of the partner's fee, what is the fee, and is it the same in an open auction and in a deal? Are floors supported per screen and per time of day? Is payment triggered by the win notice or by a verified play? In what currency is the settlement made, what are the payment terms, and who invoices whom? How are won slots that were not played treated?

Creatives#

Which formats are accepted: MP4 with H.264 or H.265, still images, HTML? What are the maximum file size, resolution and length? Can the address, id and checksum of a creative be delivered before the auction so that players can load it in advance? What is the approval flow? Can the network reject a creative for local rules without losing the deal? How are mismatches of length and aspect ratio handled?

Proof of play and audience#

Which proof of play does the partner accept: playback logs, camera photos, both? Does it use its own audience data or accept ours? How is the audience per play calculated? Which third-party verification is required, and from which vendors?

Reporting and billing#

How detailed is reporting (per screen, per hour, per creative), and how late can it be? How are differences between the two sides reconciled, and what difference is acceptable? Which side is the source of truth for the monthly reconciliation, and what is the dispute process?

Status#

This profile is a proposal for discussion and is not live yet. Fields and behaviour may change until version 1.0.0; from then on changes follow the Partner API rules: additive only.

{
    "id": "8f3a1c92e7b04d5a",
    "at": 1,
    "tmax": 500,
    "cur": ["USD"],
    "imp": [
        {
            "id": "1",
            "tagid": "173",
            "bidfloor": 4.5,
            "bidfloorcur": "USD",
            "exp": 30,
            "dt": 1791454530000,
            "qty": {
                "multiplier": 14.2,
                "sourcetype": 2
            },
            "video": {
                "mimes": ["video/mp4"],
                "minduration": 10,
                "maxduration": 10,
                "w": 1080,
                "h": 1920
            }
        }
    ],
    "dooh": {
        "id": "173",
        "name": "Dubai Marina Walk, west entrance",
        "venuetype": ["3", "302"],
        "venuetypetax": 1,
        "domain": "programmatic-engine.com",
        "publisher": {
            "id": "7",
            "name": "Marina network"
        }
    },
    "device": {
        "w": 1080,
        "h": 1920,
        "geo": {
            "lat": 25.0805,
            "lon": 55.1403,
            "type": 1
        }
    },
    "source": {
        "schain": {
            "ver": "1.0",
            "complete": 1,
            "nodes": [
                {
                    "asi": "programmatic-engine.com",
                    "sid": "7",
                    "hp": 1
                }
            ]
        }
    }
}

{
    "id": "8f3a1c92e7b04d5a",
    "cur": "USD",
    "seatbid": [
        {
            "seat": "agency-4411",
            "bid": [
                {
                    "id": "b-20261009-0001",
                    "impid": "1",
                    "price": 6.8,
                    "crid": "spring_2026_001",
                    "adomain": ["example.com"],
                    "dur": 10,
                    "nurl": "https://bidder.example.com/openrtb/win?id=8f3a1c92e7b04d5a&price=${AUCTION_PRICE}",
                    "burl": "https://bidder.example.com/openrtb/bill?id=8f3a1c92e7b04d5a&price=${AUCTION_PRICE}&mult=${AUCTION_MULTIPLIER}&ts=${AUCTION_IMP_TS}"
                }
            ]
        }
    ]
}