Proposal for Prebid Video Module

[karimMourra]

Type of issue

Proposal to implement a Feature

Description

In order to make bidding on video easier for publishers, we would like to introduce a video module allowing Prebid to register with Video Players. Each Video Player would own and maintain a video submodule. The main module ensures that the submodule specified by the publisher is used, and acts as a standardized interface and bridge between Prebid and each submodule.

The video submodules in turn act as a bridge to the video player. They are responsible for ensuring the video is rendered and obtaining the oRTB video params. Said oRTB params would then be added to the bid request or made available when requested by a bid adapter.

This new feature would ease publisher pain points when integrating with Prebid, notably:

• ad scheduling orchestration: since Video Players are configured with ad schedules, the video submodule can request bids on behalf of the publisher, simplifying the coordination for the publisher.
• oRTB video param retrieval and integrity: the publisher can rely on the video submodule to populate the oRTB video params, and would be guaranteed to have the right information since the video player is the source of truth.
• video rendering: the publisher no longer needs to own and maintain the integration between Prebid and the video player.

Project management

JW Player is willing to own the development of the Core Video Module, as well as the development of its player submodule, in collaboration with the Prebid community. Submodules for other video players can be developed by members of the community as well as the maintainers of the players.

Technical Details

Suggested Prebid API changes:

• ability to specify a video submodule in the prebid config
  • i.e. setConfig({videoModule: {args}})
  • prebid instance would use the same video player for all video ad units

Sample Video Module Config interface:

var videoModule = {
          providerCode: 'videoJS',
          player: playerInstance,
          playerId: 'mediaPlayer',
          role: ['auction', 'rendering', 'enrichment']
  };
pbjs.setConfig( { videoModule } );

Definitions:

• VideoModule: Config object used to signal that a Video Adapter should be used and configure the video integration.
  • VideoModule.code: unique identifier of the Video Adapter. (required)
  • VideoModule.player: reference to the Video Player (optional)
  • VideoModule.playerId: the HTML element id of the player (optional- to be used in the case where player load happens after Prebid configuration).
  • VideoModule.role: list of roles the video module can play:
    • enrichment: The module obtains the oRTB video Params and makes them available to bid Adapters.
    • rendering: the player renders the ad creative
    • auction: the player controls the auction scheduling. It can request bids when it reaches an ad break.

Prebid Implementation requirements:

• the ability to modify bid requests and/or ad units, on behalf of the publisher
  • required to add the video params to the bids and/or ad units
• the ability to modify the prebid config, on behalf of the publisher
  • required when the Video Module controls the auction, and the publisher configures Prebid via the Player’s API.
• the ability to import dfpAdServerVideo
  • required when the Video Module renders the creative using the Google IMA SDK
• ability to register for event callbacks via onEvent API
  • required when the Video Module controls the auction
• possibly the ability to call addAdUnits API
  • required when the Video Module controls the auction, and the publisher configures the bid adapters via the Player’s API.
• ability to call the requestBids API
  • required when the Video Module controls the auction, to request the bids before an ad break
• ability to call the getHighestCpmBids API
  • required when the Video Module controls the auction, to determine a winner

[Asafsham]

@bretg @mike-chowla
I think it can be very similar to the real time data module in term of structure and design (plus a lot of the limitation that we already have today for the RTD modules). If you want, my committee along with JW can help with the dev.

Plus, my humble opinion - I think it's a great idea. There's something unintuitive and sometimes complicated when connecting video players with prebid, organising it and allowing players to connect using their own submodules makes a lot of sense and would save publishers' dev time.

[dshore]

@Asafsham

If you want, my committee along with JW can help with the dev.

Thx for the support!

[bretg]

This seems like a promising idea in general. My initial feedback is that things need to be done "in the Prebid Way", at least in 4.X.

• Bid adapters must read their video params from AdUnit.mediaTypes.video.params. There are a number of ways this module could write to that object, but you'll need to define what happens on overlap.
• Auction integration needs to be done via the bidsBackHandler
• Bid caching and GDPR need to be considered
• You're welcome to define new events like VIDEO_IMPRESSION, VIDEO_COMPLETE, etc.

[muuki88]

Hi,

Thanks for this proposal ❤️ I'm not too familiar with video so I have some questions how this proposal relates to

• fallback renderer for outstream ads. Is the rendering role a similar feature?
• outstream in general. Is this proposal only related to in instream, or both?
• https://github.com/prebid/prebid-outstream

Thanks in advance,
Muki

[karimMourra]

Hi @muuki88 , the idea is to support both instream and outstream. I was not familiar with prebid-outstream, thanks for sharing! I will take a look, ideally we would reuse it in the Video Module

[ocm-peter]

Hello all,

This sounds really promising and am really looking forward to this.

Adding my 2 cents:

the ability to modify bid requests and/or ad units, on behalf of the publisher
required to add the video params to the bids and/or ad units

use the utils.getGptSlotInfoForAdUnitCode() function, to support publishers that use GAM ad unit paths in
the prebid adUnits configuration, rather ad unit ids.

Most, if not all, bidder adapters assume that the bid.adUnitCode going into the video player
is the actual div id that the player should render. That is not the case on all situations.
I've been hacking into prebid adapters for days now to make our hb outstream solution work.

I have tried more clean solutions like pre bid request hooks to alter the video ad unit code to the div id
before bid requesting or just after, but not all bidder adapters seemed to work with that solution.

In general, from my experience working with prebid outstream, there seems to be a lot of stuff to be
standarized and a bidder/publisher protocol to be created.

More than happy to help on your venture @karimMourra!

[karimMourra]

Hi @ocm-peter thanks for the feedback and help! Much appreciated!
Could you please help me understand your use case with GAM ad unit paths? do you have any examples or demo pages using outstream and GAM ad unit paths ? At JW Player we deal mostly with instream ads, and though we support outstream, we haven't dealt with this use case.
In the case of instream, the idea of each ad unit being associated to a different div is not ideal because they could all render in the same player, which would be embedded in the same div throughout its lifecycle.
Since we want this solution to work for both instream and outstream, it would be great for us to collaborate and standardize as much as possible.

[gglas]

@karimMourra how's progress coming here?

[karimMourra]

Hi @gglas we are finalizing our formal proposal which can be found at https://docs.google.com/document/d/112HPpxlWpyrrV8Y611kEQRnDMaG1DjYhVkbQf6Dgl0s/edit?usp=sharing

[karimMourra]

Hi all, the final proposal can be found at https://docs.google.com/document/d/1sueL8EXnD-DViTIEBNayAzNNrYocdHtmEl7433g0f5I/edit?usp=sharing
cc @gglas

[patmmccann]

@karimMourra does this still address #5696 ?

[karimMourra]

@patmmccann there are limitations because of what information the IMA SDK surfaces. We can determine when the ad impression came from a bid, but not when an ad error came from a bid