Filter Multi-Format Requests

[SyntaxNode]

This proposal is the result of a discussion of multi-format support by the Prebid Server Committee.

Summary

A multi-format request contains impressions which include more than one media type (banner, video, audio, native). Support for multi-format requests by bidders is inconsistent and publishers have difficulty determining support. This proposal allows bidders to declare support and publishers to declare a fallback plan.

Bidder Support

Prebid Server cannot determine if a bidder supports multi-format requests and need bidders to declare support. Prebid Server will add a new boolean configuration flag openrtb2.multiformat-supported for each bidder. The default value is "true" for now until a major release.

Publisher Fallback

If a multi-format request is received for a bidder in which openrtb2.multiformat-supported is false, the following algorithm will be implemented for each impression:

1. If the impression contains a preferred type (imp.ext.prebid.preferredmtype):
   1. If the bidder supports the preferred type, other types are removed for that bidder. This is the same behavior as when the bidder does not declare support for the type in their configuration. A warning is returned for each type removed (same behavior as existing media type enforcement).
   2. If the bidder does not support the preferred type, this impression is not sent to the bidder and a warning is returned.
2. If the request does not contain a preferred type:
   1. The bidder will not be called and a warning will be returned.

Rejected Ideas

We discussed the possibility of Prebid Server splitting impressions by media type. Bidders strongly oppose this behavior because it reduces their ability to enforce initiatives such as inventory efficiency. If bidders want to implement impression splitting, they can declare multiformat support and perform splitting within their adapter.

[bretg]

Overall this is an ok feature, but it could be considered 'breaking', and I'm a little skeptical that a imp.ext.prebid.preferredmtype is super useful because it's global across bidders. It seems likely that one bidder might be better at banners, another at video, and a third at native.

Rather than have publishers set a per-bidder flag, one solution is to get the bidders to make that decision on their own. So not sure I'd advocate a per-bidder request-level flag. But maybe an account-level config?

I can see the panic play out:

• PBS host company rolls out this updated of PBS
• distracted bid adapter company has ignored our communications
• when their bidder stops getting called, they finally notice
• they frantically reach out to us and their key publishers
• the publisher won't want to fall back on multiformat because all the well-behaved bidders will be fine
• the publisher may want a way to restore revenue from that bidder without changing the request, which is engineering.

I'd suggest considering:

• make this a PBS 2.0 feature so the communication is loud and clear
• if we need an override at all, make it account level config

auction:
  preferredmediatype:
     default: banner
     bidderB: video
     bidderC: native

[bretg]

Discussed in committee.

• update to support both req-level and account-level overrides per bidder.
• make the overrides global and not per-imp
• if a preferred mediatype is not specified, there's no default. The bid adapter may choke.
• discussed a bidder config that declares they support multiformat that will prevent PBS from doing this filtering.

request-level overrides

Proposed request level field ext.prebid.bidder.BIDDER.prefmtype

ext.prebid.biddercontrols: {
     bidderB: { prefmtype: video },
     bidderC: { prefmtype: native }
}

account-level overrides

auction:
  preferredmediatype:
     bidderB: video
     bidderC: native

bidder multiformat support flag

In bidder static YAML/config:

adapters:
   bidderA:
      ortb:
         multiformat_supported: true

[bretg]

One of our developers pointed out that defaulting multiformat_supported: false is a breaking change. It needs to wait for 3.0. Until then, the default needs to be multiformat_supported: true.

[bretg]

Done in PBS-Java 2.5

[bretg]

Discussed in committee. We agreed that ext.prebid.bidders is confusing since that's already used as a path for global adapter parameters.

We're changing the location of prefmtype to ext.prebid.biddercontrols.BIDDER.prefmtype.

[bretg]

Here's an example of how this feature is being used in PBS-Java today. We have a mobile app publisher who's found that several bidders do not bid well in a banner+video scenario, so they've set up this config in their "top-level stored request IDs" to hide the video part from them:

{
        ...
	"ext": {
		"prebid": {
			"biddercontrols": {
				"bmtm": {
					"prefmtype": "banner"
				},
				"grid": {
					"prefmtype": "banner"
				},
				"rise": {
					"prefmtype": "banner"
				},
				"iqzone": {
					"prefmtype": "banner"
				},
				"unruly": {
					"prefmtype": "banner"
				},
				"vrtcal": {
					"prefmtype": "banner"
				},
				"yieldmo": {
					"prefmtype": "banner"
				},
				"Displayio": {
					"prefmtype": "banner"
				},
				"conversant": {
					"prefmtype": "banner"
				},
				"cadent_aperture_mx": {
					"prefmtype": "banner"
				}
			}
		}
	}
}

[bsardo]

@bretg is this core behavior rather than module?

Also it appears this is a true/false config value. I see other values though in the docs (e.g. https://github.com/prebid/prebid.github.io/blob/1a3f650fa5fb4ac882b06abd8c2cfe79f9b206ec/dev-docs/bidders/freedomadnetwork.md?plain=1#L9). Do these other values (will-bid-on-any, will-bid-on-one, will-not-bid, etc) only serve as documentation?

@pm-shriprasad-marathe and his team are looking to implement this feature in PBS-Go.

[bretg]

Yes, it's in core in PBS-Java. Point taken that it could have been implemented as a module.

will-bid-on-any, will-bid-on-one, will-not-bid

This feature basically hides the multi-format request from the bidder -- it's only indirectly related to the bidder's self-declared support for multiformat.

i.e. if the bidder lists "will-not-bid" in the docs, it would certainly make sense to add this config. However, few bidders have admitted "will-not-bid". What they normally do is "will-bid-on-one" but they choose the 'wrong' one as perceived by the publisher.

Really, bid adapters should all be "doing the right thing" with regards to multiformat, but apparently they haven't gotten the memo. This allows pubs to make the decisions for them.