Quick reminder. A VAST response can return:
- VAST Inline response that contains all the necessary media files and tracking URIs to display and track the ad
- VAST Wrapper response. Basically, a redirect to another URL/third party ad server to serve a VAST. A VAST wrapper might as well point to another VAST wrapper, creating a chain of VAST wrappers that, ultimately, should return a VAST Inline ad
Wrappers chaining allows multiple ad servers to serve ad inventory. The idea behind this is to allow implementing ad fallback and maximize publisher revenue. However, there are some potential problems with the number of Wrapper redirects.
- Latency. Parsing each VAST Wrapper response and sending requests to the third-party VAST URI takes time.
- Tracking pixels. A video player should store all the tracking pixels contained within each VAST wrapper response and trigger them on the appropriate time during the VAST Inline Ad display. Some parties may insert multiple tracking pixels, resulting in a larger VAST response size. This also means slower delivery.
On mobile devices, publishers seriously need to take into account all this waiting time, as it might prompt visitors to leave before the content has any chance to display.
The obvious response is Yes!, video players should limit the number of Wrapper redirects. Once they reach that limit, they can take specific steps depending on the context. For example: move to the next ad from the Ad Pod, try to load the next standalone Ad, etc.
Infinite VAST redirects are not a strange occurrence either. An initial Vast Wrapper Response A might redirect to Wrapper Response B -> Wrapper Response C -> Wrapper Response D -> Wrapper Response B.
To alleviate this problem video players should limit the number of wrapper redirects and/or have a maximum wait time to reach an actual VAST Inline Ad.
The following VAST XML is a Wrapper that points to itself as a redirect URI to create an infinite VAST loop.