Add Video Reach adapter

[VideoReach]

Type of change

• Bugfix
• Feature
• New bidder adapter
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Does this change affect user-facing APIs or examples documented on http://prebid.org?
• Other

Description of change

Add Video Reach adapter

• test parameters for validating bids

{
  bidder: 'videoreach',
  params: {
    TagId: 'MS8OW'
  }
}

Be sure to test the integration with your adserver using the Hello World sample page.

• hello@videoreach.de
• official adapter submission

For any changes that affect user-facing APIs or example code documented on http://prebid.org, please provide:

• Add Video Reach Bidder doc prebid.github.io#1273

Other information

[robertrmartinez]

Looking now

[robertrmartinez]

I would like to clear up some of my confusion.

It seems as if videoreach is a pure video demand exchange?

But you are never sending back bidResponse.mediaType == video

Instead you pass nothing which defaults it to banner.

If a publisher wishes to use videoreach with other video demand partners this will cause problems.

Prebid requires that the full VAST XML, or a videoCacheKey is passed in the bidResponse object for any video demand.

Thus when constructing the Client Side caching it is able to store the VAST XML for future fetching.

For video Reach is looks like you return script tag which loads some javascript which then will pick out your VAST XML.

This will not work with many video prebid integrations that publishers have.

The recommendation is to:

1. Have your adserver either:
   A: Return the full vastxml, which then Prebid will cache it for you
   OR
   B: Return the vastxml URL which will point to the VAST XML.
   OR
   C: Return the vastUrl as well as the videoCacheKey to be retrieved from.

========================================================================
FOR A:
- You would alter your bidAdapter to return this full vastXML in the bidResponse.vastXml
- This would indicate to Prebid Core that this VAST XML needs to be cached and thus it would call the Prebid Cache server which the publisher had defined in

 - Then, when prebid picks the winning video bid or however the publisher sets it up, it now hows the URL for the cached XML alongwith each bid containing its unique UUID to retrieve the VAST xml from the cache.

Exampel bid adapter using this: https://github.com/prebid/Prebid.js/blob/master/modules/pubmaticBidAdapter.js#L940

========================================================================

FOR B:
- If you are storing your Vast XML on the server side and it is retrievable, then you can simply pass along two values:
- bidResponse.vastUrl: full url to retrieve the vast from
- bidResponse.vastImpUrl: an impression url which is used when wrapping the vastUrl into a prebid cache Vast URL before caching it client side.
Example bid Adapter using this: https://github.com/prebid/Prebid.js/blob/master/modules/appnexusBidAdapter.js#L375

========================================================================

For C:
- If you do not want prebid to cache for you, then you then you can pass along a few more values in order to flag it to not be cached:

 - `bidResponse.vastUrl`: full url to retrieve the vast from
 - `bidResponse.videoCacheKey`: a unique identifier for each cache to retrieve it from.

Example bid adapter using this approach:
https://github.com/prebid/Prebid.js/blob/master/modules/rubiconBidAdapter.js#L467

Please note that When constructing DoubleClick calls, prebid sends the following KVPs when VIDEO is the mediaType:

{
     hb_uuid: //unique identifier to for each cached object
     hb_cache_host: // the hostname of the URL where this vast xml is cached
     hb_cache_path: // the path for the URL
}

When these three things are combined it should form a full URL which points to the cached url.
Example: https://github.com/prebid/Prebid.js/blob/master/modules/rubiconBidAdapter.js#L473

[robertrmartinez]

Please see comments.

Also please provide clarity on the expectation of how videoReach will be used in conjunction with other Video Demand partners if you really want to always count your bid response as banner

[robertrmartinez]

Also, your Bid Request Server seems to not add port numbers in when adding the Access-Control-Allow-Origin header based on the Origin request header

This would make it hard for anyone testing locally with your adapter, not a blocker though, just wanted to let you know if you had not noticed yet.

[VideoReach]

Hi Robert,

thank you for your helpful information.

We made following changes:

• Access-Control-Allow-Origin add Port
• getUserSyncs with GDPR
• We removed video from supportedMediaTypes (maybe we'll add it in future versions)

Thanks!

[robertrmartinez]

@VideoReach

Taking a look now.

Thanks.

[robertrmartinez]

@VideoReach Thanks for updating.

I still have a question regarding your example parameters and how to actually render your ads?

It seems as though your ad server is loading some JS which eventually looks like it is trying to get a VAST Url, or maybe some sort of vast player?

How will you be having bidders work with your adapter?

Do you plan on them not using the usual pbjs.renderAd to render your ad?
Is there extra configuration needed by the publisher to work with your adapter?

[VideoReach]

@robertrmartinez Thanks for checking!

It seems as though your ad server is loading some JS which eventually looks like it is trying to get a VAST Url, or maybe some sort of vast player?

Right, we load our own player (when won), which is loading the winning VAST.

Do you plan on them not using the usual pbjs.renderAd to render your ad?

So far this is not planned.

Is there extra configuration needed by the publisher to work with your adapter?

No, we just set the HTML selector (in out ad server). The publisher only need to use the provided TagId. Our JS knows where to place the ad - in the example the selector element is: #TextContent

[robertrmartinez]

LGTM

Thanks for answering my questions.