rtblintAlpha

Guides

VAST and OpenRTB: how video ad creatives are delivered

VAST and OpenRTB are both IAB Tech Lab specs, they both show up in a video ad, and they are constantly confused. They do different jobs: OpenRTB runs the auction that decides which ad plays; VAST describes what that ad is and how the player should fetch and track it. This guide draws the boundary and shows exactly where they connect.

Two specs, two jobs

  • OpenRTB is the real-time auction protocol: the bid request describing a video opportunity and the bid response naming a winner. It is JSON, exchanged between an exchange and bidders.
  • VAST (Video Ad Serving Template) is the creative-delivery format: an XML document a video player reads to know where the media file lives, how long it runs, what is clickable, and which tracking events to fire. It is consumed by the player, not the exchange.

OpenRTB decides the winner in milliseconds; VAST plays out over the seconds the ad is on screen. Different layers, different consumers.

Where they meet: bid.adm

The connection point is the winning bid's markup. For a video impression (mtype 2), the ad markup a bidder returns in bid.adm is typically a VAST XML document, or the bidder returns a nurl that resolves to one. The exchange passes that VAST to the player, which takes over from there.

OpenRTB bid request   imp.video { ... }        "here is a video slot"
OpenRTB bid response  bid.adm = <VAST> ... </VAST>   "here is the winning ad"
      |
      v  exchange hands the VAST to the player
Video player          parses VAST, fetches media, fires trackers

So VAST rides inside an OpenRTB field. The auction envelope is OpenRTB; the payload for a video win is VAST. See how adm works in adm vs nurl.

How the request constrains the creative

The Video object in the bid request tells bidders what kind of VAST is acceptable before they ever bid. The fields that matter most for compatibility:

  • protocols: which VAST versions and wrapper modes the player supports. A bidder returning VAST 4 markup to a player that only listed VAST 2 will fail to render.
  • mimes: acceptable media file formats.
  • api: supported API frameworks (for interactive video such as VPAID or the newer SIMID and OMID measurement).
  • minduration / maxduration: the allowed ad length, which the VAST creative must fit.
  • plcmt: the placement type, which affects what creative is appropriate. See placement vs plcmt.

A bid whose VAST violates the constraints the request advertised is a rendering failure waiting to happen, and it does not announce itself in the JSON.

Wrappers and the redirect chain

VAST can be inline (the ad and its media in one document) or a wrapper that redirects to another VAST document, chaining through ad servers before reaching the final creative. That chain lives entirely on the VAST side, after the OpenRTB auction is over, but it is where a lot of video latency and error originates. OpenRTB's job ends when the winning adm is delivered; what happens inside the VAST is a separate problem with its own tooling.

Two validations, two layers

Because the layers are separate, so is their validation. rtblint checks the OpenRTB side: that imp.video is well formed, that protocols, api, and durations are sane, and that the bid response envelope is valid. Whether the VAST document inside adm is itself valid is a distinct check, handled by a VAST validator, not an OpenRTB one. Validate the auction envelope in the tester; validate the VAST separately.

Sources