X hits on this document

PDF document

Digital Video Ad Serving Template (VAST) - page 6 / 14





6 / 14

IAB Video Ad Serving Template (VAST)

  • 1.

    A publisher’s system (e.g. ad server, client-side video player, or other mechanism) makes an ad request to the Secondary Ad Server. The ad tag to the Secondary Ad Server may be present within a playlist, hard-coded into the player environment, returned from the ad server as a redirect, or otherwise derived. If retrieved from a Primary Ad Server, the request to the Secondary Ad Server will generally not immediately track an impression since the IAB guideline for video impression requires tracking post-buffering.

  • 2.

    The Secondary Ad Server can either respond with a Wrapper XML pointing to another Secondary Ad Sever or respond with a VAST-formatted XML document describing the ad to be shown. Both the Wrapper XML and the VAST XML are described later in this document. It will be up to the Publisher to determine business rules about the maximum number of jumps between Secondary Ad Servers that are allowed in order to optimize user experience. With each chained Secondary Ad Server the overall size of data transferred and latency will increase, so many publishers may wish to restrict the number of redirects to 2 or fewer. Optionally, the Video Player can validate business rules around the XML response and choose whether or not to display the returned ad. For example, if the player only accepts 15 second video slots and the Secondary Ad Server returns a 30 second spot, it can be thrown away and an error report generated. As discussed later in this document, ad servers may choose to adopt tagging conventions in order to reduce the likelihood of such errors.

  • 3.

    Based on the XML response, a set of tracking URLs will be requested by the Video Player for reporting purposes. Different ad servers and Video Players may support different sets of metrics and therefore different combinations of reporting.

  • 4.

    Both the Primary Ad Server and all Secondary Ad Servers must record impressions. See the Impression Tracking section of this document for more on this subject.

Impression Tracking

In order to support IAB compliant impression tracking (see: IAB Digital Video Impression Measurement Guidelines) the ad requests for video ads need to delay the impression tracking until after the video has completed buffering. However, the standard method of redirecting between ad servers using HTTP 302 responses does not allow for each ad server to communicate to the video player the proper impression URL to request.

For example, when the Video Player makes a request from a Primary Ad Server, a 302 is returned to the ad tag of the Secondary Ad Server. The Secondary Ad Server responds with XML that includes a URL for impression tracking. The Video Player requests this URL post-buffering so the Secondary Ad Server records an IAB compliant video ad impression. But how does the Primary Ad Server know when to record an impression?

There are three possible methods for overcoming this limitation:

  • 1.

    Wrap each ad server redirect response in additional XML including relevant tracking URLs (“XML Wrapper Method”).

  • 2.

    Use tag-based syntax to include impression and click tracking in the request in much the same way as rich media works today (“Rich Media Method”).

  • 3.

    Require that all Secondary Ad Servers include fields in their trafficking interfaces for the entry of a number of reporting URLs from publishers and networks (“Multiple URL Method”).

Although any of the three methods are acceptable, the VAST specification includes direct support of the XML Wrapper Method through the <wrapper> element. The XML Wrapper method is the preferred method due to its power and extensibility. It will be up to each Publisher to determine what policies are put in place to avoid excessive redirecting or large file size in XML responses.

© 2008 Interactive Advertising Bureau

  • -


Document info
Document views46
Page views46
Page last viewedSat Jan 21 18:05:00 UTC 2017