Digital Out Of Home (DOOH) Support

[SyntaxNode]

Overview

OpenRTB 2.6-202211 introduced a new top level object for DOOH inventory alongside the existing App and Site objects. The Prebid DOOH Taskforce has requested for Prebid Server to add support.

OpenRTB Model Updates

The following new fields were added to the OpenRTB 2.x specification to support DOOH. Prebid Server must update its internal to add:

• New Object: request.dooh
• New Object: imp.qty
• New Field: imp.dt (timestamp when the item is estimated to be fulfilled)

Prebid Server Code Changes

• Adjust validation logic to verify that only one of app, dooh, and site are provided.
• Allow bidders to specify in their configuration if they support media types for a new dooh capability.
• Filter unsupported dooh impressions before calling a bidder, extending existing opt-in logic for app and site.
• Add a new dooh channel type and auto populate to dooh when the value is not provided by a publisher.
• When searching for the account id, check dooh.publisher in addition to app and site.
• Add support for dooh in the video endpoint data model. This endpoint is planned to be deprecated, but its strange IMHO to implement DOOH support everyone but here.
• First Party Data should be expanded to include dooh following the same rules as exist today for app and site.
• Extend existing metrics to dooh inventory. In PBS-Go this includea:
  • requests with new label requests_without_cookie
  • request_time_seconds with new label requests_without_cookie
  • requests_without_cookie with new label requests_without_cookie

Adapter Code Changes

None required. Adapters already opt-in to which inventory types they support. Adding DOOH as an option will not require a code change until the adapter makes a choice to add support.

[bretg]

Updated PBS First Party Doc to cover DOOH

[minaguib]

Confirming after a few meetings I've started preparing code and PR to deliver the above.

[bretg]

We've started porting the Go PR to Java and have some questions. Maybe @SyntaxNode can route these?

This feature pushes us to deal again with the lovely site/app incompatibility problem. We dealt with this in First Party Data processing. There are several places where site/app/dooh could end up conflicting:

1. the original ORTB request could contain multiple
2. the stored request could add a conflict
3. bidder-specific FPD (ext.prebid.bidderconfig.ortb2) could add a conflict

Are all of these scenarios covered, and are they all draconian Kill-The-Request or do we pick one over another?

Also, seems like PBS should automatically set ext.prebid.channel to "dooh" of that's the only one of the 3 objects present. Is that a thing?

[SyntaxNode]

Maybe @SyntaxNode can route these?

👍

Are all of these scenarios covered, and are they all draconian Kill-The-Request or do we pick one over another?

A bid request is invalid if more than one of site/app/dooh is specified, regardless of it coming direct from a publisher or being the result of a stored request or First Party Data merge.

I wouldn't characterize this approach negatively as "draconian". These objects describe the context/location of where the ad appears and it makes no sense for more than one to apply. The OpenRTB 2.6 spec is abundantly clear that "only one applies to a given bid request".

Also, seems like PBS should automatically set ext.prebid.channel to "dooh" of that's the only one of the 3 objects present. Is that a thing?

It's not a thing, but is a good callout. Let's make it a thing.

[bretg]

Turns out I'd already updated the FPD doc with DOOH describing the "draconian" approach. BTW - we're good with dragons.

Let's make it a thing.

Cool.

[simontrasler]

Note the DOOH contract is as follows -- will that be covered here?

• The request contains a qty object with a multiplier.
• All prices in the request and the bid response are for a single person CPM (i.e., non-multiplied).
• The bidder is charged the multiplied amount -- e.g., if the request has a multiplier of 5, and the winning bid clears at $1, that bidder is charged $5.
• The macro ${AUCTION_PRICE} is replaced by the single-person price ($1 in this example), and ${AUCTION_MULTIPLIER} in the bidder's ad markup/pixels is replaced with the multiplier value (5 in this example), and the bidder is expected to use that in order to track what they have spent.

If a bidder accepts requests with the dooh object, this signals they accept the contract.

[bretg]

Thanks @simontrasler . I'll let @minaguib and @SyntaxNode tackle in more detail, but my thinking is that the basic open source Prebid Server request/response signaling is ok as implemented. If any PBS host company wants to actually utilize DOOH, there are analytics and finance requirements they'll have to meet.

@minaguib - the fact that bid adapters will have to resolve their own ORTB macros should be part of the documentation you were planning to write.

[bretg]

@SyntaxNode - our team is testing the ported DOOH changes and pointed out that the metrics definition in the original request above is hard to understand and perhaps not in sync with what got implemented.

Extend existing metrics to dooh inventory. In PBS-Go this includes:
- requests with new label requests_without_cookie
- request_time_seconds with new label requests_without_cookie.  // maybe this should be request_time_seconds_without_cookie?
- requests_without_cookie with new label requests_without_cookie                 // this seems not very useful?

Besides these questions, I'm told that we see in the code is just these:

"account.${accountId}.requests.type.openrtb2-dooh"
"adapter.generic.requests.type.openrtb2-dooh"

[SyntaxNode]

Implemented in PBS-Go 2.0 with exception of:

• First Party Data
• Populating the DOOH channel type.

[bretg]

Done in PBS-Java.

Includes FPD and DOOH channel. However, there's interim behavior where it's not rejecting site+app+dooh objects. That will be addressed in 3.0 because at this point it's a breaking change.