Closed guillaume-sticky closed 6 years ago
The adapter's only responsibility is to make sure vastXml
(or vastUrl
) exists.
Video header bidding was a bit tricky due to adserver limitations... but when publishers retrieve the vast, we expect them to follow this process.
Most of the details are taken care of in by the prebid core code... but check out bidmanager.tryAddVideoBid, the videoCache, and the cust_param we add to the DFP URL if you're interested in the details.
@guillaume-sticky -- Do you plan on adding support for the "video" media-type?
@dbemiller Do I understand it well: If we support the "video" media type, giving the "vastXml" field replaces the "ad" field, as the video.js player will be able to display the video ad by itself?
@mjacobsonny I will definitively make some tests around this mediatype "video" feature to decide what will be our next step.
@guillaume-sticky Yes, that's correct
Description
Question regarding the new bidder adapter implementation for Prebid 1.0 using video ads (VAST)
Platform details
Prebid 1.0
I'm updating our bidder adapter for freewheel-ssp. As you may know we are playing video ads. I've seen there is a new parameter in the bid response: "vastXml"
seen in the documentation here: http://prebid.org/dev-docs/bidder-adapter-1.html#interpreting-the-response
it says: "XML for VAST document to be cached for later retrieval."
The question is: Is it only used to cache it? and how do we retreive it later?
Thanks for your answers.