Video in waterfalls, pods and SSAI
What a server-side ad insertion stitcher such as MediaTailor receives in Epom's VAST — stable creative id, mezzanine, best file first, standard event names, advertiser and price — and how several video networks share one slot through pods, waterfalls and wrapper flags.
A companion to Video banners: what Epom writes into a video response for a server-side stitcher, and how a slot that is shared by several networks behaves. The supply-side settings — pods, pricing in the VAST answer, telling Epom which stitcher calls the tag — are on Video placements.
What a server-side ad insertion stitcher receives
On CTV a stitcher (AWS MediaTailor, Google DAI, …) transcodes the video once, caches the result and splices it into the stream. Every Local Video, External Video and Advanced Local Video(s) response is built for that:
- A stable creative id.
<Creative id="4512-a1b2c3d4">is the banner id plus a short hash of the video file. Stitchers cache their transcode under it and never expire it, so it stays the same while the file does — the ad plays straight from the cache — and changes the moment you upload a different file, so the old version never plays in its place. The first request after a new file is still skipped while the stitcher transcodes; that happens once per file. - A mezzanine file — the source a stitcher transcodes from. Videos are served as uploaded, so
it is the same file the
<MediaFile>points at:<Mezzanine>in<MediaFiles>on VAST 4.x (with its delivery, type and size from 4.1), and aMezzanineextension on 2.0 (in the ad’s<Extensions>) and 3.0 (in<CreativeExtensions>), as the IAB VAST CTV Addendum 2024 defines. Upload the best-quality file you have: the mezzanine is only as good as the upload, and the network’s maximum video file size (Preferences) caps it. - Best file first. With several media files (Advanced Local Video(s)) the highest-bitrate one comes first, and the response duration is taken from it. On a site with a publisher video spec the files the spec refuses are left out, so the best file that site accepts comes first.
- Only standard event names. MediaTailor rejects a whole response over one event name the VAST specification does not define. Epom translates the player-size events per version and leaves out what a version lacks:
| Event | 2.0 | 3.0 | 4.0 | 4.1 – 4.3 |
|---|---|---|---|---|
| Fullscreen / Exit fullscreen | fullscreen / — | fullscreen / exitFullscreen | playerExpand / playerCollapse | playerExpand / playerCollapse |
| Expand / Collapse (linear video) | expand / collapse | expand / collapse | — | — |
| Ad loaded | — | — | — | loaded |
The event settings, their conversion actions and the reports are unchanged — only the name
written into the response differs. skip and progress are sent on 2.0 as well: 2.0 is what a
tag without a version gets, and progress points often drive conversions.
- Who the ad is for, and what it pays. A stitcher that resells the slot over its own auction
needs to know whose ad it is and what it costs. From VAST 3.0 the response names the
<Advertiser>— the advertiser’s own Advertiser domain for a direct campaign, the winning bid’sadomainfor programmatic demand — and VAST 4.x adds the winning bid’s IAB categories as<Category>. The price is sent only where the placement turns on Send the publisher’s price in VAST (off by default — see Video placements): then a<Pricing model="cpm" currency="USD">carries the publisher’s net CPM for this placement, what the publisher earns, never the advertiser’s gross or a DSP’s bid. A wrapper carries the price from 4.0 only, and nothing else. A<Pricing>the demand put in its own markup is removed on every version whatever the setting, so the stitcher never sees what the buyer paid; with no net price — a creative paid by the click or the action — the response has no<Pricing>.
The ISCI / Ad-ID code travels in the same response — as UniversalAdId on 4.x and as the
Creative’s AdID plus a UniversalAdId extension on 2.0 and 3.0; see
ISCI / Ad-ID code.
Several networks in one slot: waterfalls, pods and wrapper flags
A video request returns one banner unless the placement’s Return (ads in pod) (or
maxAds on the tag) is above 1 — then the response is a numbered ad pod, and players such
as JW Player and Google IMA play every ad in it. For a waterfall across several VAST tags keep
the pod at 1 and either give the player one Epom placement per network in order, or let Epom
pick one wrapper per request by priority. The VAST 4.0 Wrapper properties (Follow
additional wrappers, Allow multiple ads, Fallback on no ads) are written into the
<Wrapper> only when the tag is requested as VAST 4.0 or later, and only steer how the player
treats that one partner’s answer. Full recipe, macros for the partner’s tag URL and how to read
fill per network: Run a pre-roll waterfall across several video networks.
Related
- Video banners — the guide
- Video banner reference — fields, saved-banner sections, ISCI, API
- Video placements — pods, pricing in the VAST answer, SSAI stitcher settings
- Run a pre-roll waterfall across several video networks
- Diagnose video ad playback failures (VAST errors)
- Video, VAST and VPAID explained
