Prebid is best known as the open-source way publishers run header bidding for display ads. It handles video too, and for publishers with video placements it can be one of the most effective ways to bring competitive demand to every impression. Video bidding works a little differently from display, though, and the details matter.
A quick refresher on header bidding
In a header bidding setup, the page asks several demand partners for bids at the same time, before the ad server makes its decision. The highest bids are then passed to the ad server, which compares them with other demand, such as direct campaigns or Google demand, and picks a winner.
The result is more competition for each impression than a waterfall, where partners are asked one after another.
What is different about video
The bid includes a VAST response
For a display ad, a winning bid comes with creative markup the page can render. For video, the bid comes with a VAST response, or a link to one, that the video player will follow. That means Prebid, the ad server and the player need to agree on how the winning VAST reaches the player.
Caching
Because VAST responses can be large and players request ads at slightly different moments, Prebid video setups usually cache the winning VAST and pass a short reference to the ad server and the player. Getting caching right avoids ads that expire before they play.
Context: in-player or outstream
Prebid distinguishes between two contexts:
- In-player (instream): the ad runs inside a video player alongside content, before, during or between clips.
- Outstream: there is no content video. The ad appears in its own unit on the page, typically in the article.
The context affects which demand partners bid, what they are willing to pay and which rules apply. Buyers value in-player inventory differently from outstream, so declaring it accurately matters.
Player details in the request
Video bid requests should describe the player: its size, whether it starts muted, whether ads are skippable, which protocols and file types it supports and where it sits on the page. The more accurate the description, the better buyers can bid, and the fewer mismatched creatives you receive.
Client-side or server-side
Prebid.js runs the auction in the reader’s browser. Prebid Server runs it on a server and returns the results. The trade-offs:
- Prebid.js gives partners direct access to browser signals but adds requests to the page.
- Prebid Server keeps the page lighter and suits environments like apps and connected TV, where there is no browser.
Many publishers use both, choosing per partner.
Setting it up well
A few practical points we see publishers get wrong:
- Set sensible timeouts. Video players need an ad quickly. Long auctions delay playback and lose viewers.
- Use price granularity that fits video. Video bids tend to sit in a different range from display. Price buckets designed for banners can throw away value.
- Keep the chain short. Each extra wrapper between the bid and the creative adds delay and risk.
- Filter creatives. Check file sizes, durations and formats before they reach the player.
- Watch fill and timeouts per partner. A partner that often times out costs you more than it earns.
Where Prebid fits with an ad server
Prebid produces bids; an ad server decides which ad plays, taking into account direct campaigns, deals, other programmatic demand and the publisher’s rules. In our setup, every format runs through the Vortex ad server, and Prebid.js, Prebid Server, OpenRTB, Google Ad Manager and Amazon TAM can all be connected to it. Our ad server page shows how those pieces fit together.
Header bidding for video takes a little more care than display, but the principle is the same: more qualified competition for every impression, with the publisher in control of the rules.
