How do I traffic one video campaign to publishers that support different VAST versions?

Keep one master creative set and traffic a separate tag per publisher requirement: a VAST 4.0 tag with CompanionAds for the publisher that supports them, and VAST 2.0 tags without companion elements for the publishers that do not. Do not send one 4.0 tag everywhere; players that only support 2.0 may reject the declared version outright.

What do I change when a publisher's player cannot run a VPAID wrapper?

Disable the VPAID requirement in the placement settings so the ad server serves plain progressive MediaFiles instead of the JavaScript VPAID unit. The video still delivers; only the interactive layer is dropped. VPAID is deprecated, so this fallback path is the long-term direction anyway.

Why does my VAST tag validate but time out in the player?

Usually wrapper depth. Each wrapper hop adds a network round trip, and players enforce both a hop limit (VAST error 302) and an overall timeout. Trace the chain hop by hop and collapse redundant hops; each intermediary should justify its round trip.

VAST scenarios: real situations, worked answers

Validation rules tell you what is wrong with a document. This page works the other direction: it starts from situations ad ops and engineering teams actually hit and walks to the correct structural answer, with the rules that would have caught the problem early.

1. Three publishers, two VAST versions, one campaign

Situation: a video launch spans three publishers. Publisher A requires VAST 4.0 with companion banners. Publishers B and C only support VAST 2.0 and no companions.

Correct approach: one master creative set, separate tags per requirement. Traffic a VAST 4.0 tag with <CompanionAds> to publisher A, and VAST 2.0 tags with no companion elements to B and C. Sending a single 4.0 tag everywhere fails: a 2.0-only player may reject the declared version attribute before it reads a single creative element, and companion markup it does not understand invites parser errors. Version-fork at the ad server, not in the creative.

Validate each fork against its own target version: the versions guide covers what each version accepts.

2. Legacy player, VPAID wrapper will not initialize

Situation: a publisher runs a legacy video player with no JavaScript VPAID support. The trafficked tag wraps the video in a VPAID unit and the publisher reports the ad never initializes.

Correct approach: change the placement settings to drop the VPAID requirement, so the ad server serves the plain progressive <MediaFile> assets directly. Video delivery continues; only the interactive layer is lost on that placement. Since VPAID is deprecated, treat this less as a workaround and more as the migration path: SIMID covers interactivity where players support it, and it degrades gracefully where they do not. The VPAID apiFramework rule flags tags still carrying the old dependency.

3. Tag validates clean, player times out anyway

Situation: the XML passes validation, yet in production the player reports no ad or logs VAST error 302.

Correct approach: count the wrapper hops. Each <VASTAdTagURI> is a network round trip, players cap the chain (commonly five hops, error 302 when exceeded), and slow intermediaries burn the overall timeout even under the cap. Trace the chain with the VAST inspector and remove hops that add no targeting or measurement value. The wrapper depth rule warns before players do.

4. CTV campaign rejected at SSAI stitch time

Situation: a CTV campaign delivers fine in browser test pages but the SSAI vendor rejects it, or quality drops visibly after stitching.

Correct approach: two usual causes. First, any JavaScript-dependent creative (VPAID) cannot execute server-side; serve plain media files on CTV placements. Second, stitchers transcode from the source you give them: without a mezzanine file, the vendor transcodes from a compressed rendition and quality suffers, and some vendors reject the tag outright. Ship VAST 4.1+ with a mezzanine for SSAI. The SSAI guide covers the full checklist.

5. Impression counts double what the ad server reports

Situation: the measurement vendor reports roughly twice the impressions the ad server logs.

Correct approach: look for the same <Impression> URL appearing more than once after the wrapper chain flattens: once in the wrapper, once in the inline ad. Compliant players fire every impression element, so a duplicated URL counts twice. Deduplicate at the ad server that builds the wrapper. See the worked duplicate-impressions example and the rule that flags it.

6. Creative plays on desktop test page, dies on HTTPS properties

Situation: the tag works in a local test harness but never renders on the publisher's site or in CTV web views.

Correct approach: check schemes. One http:// media file or tracker in an HTTPS page is mixed content: browsers block the request, players surface error 405 or fail silently, and CTV web views are stricter than desktop browsers. Serve every URL in the tag (media, impressions, tracking, click) over HTTPS. The HTTPS tracking rule catches these before launch.

Work a scenario yourself

Every scenario above shows up in real tags. Paste yours into the VAST tag validator for the rule-by-rule readout, or the VAST tag tester to fetch a live URL and preview what the player will actually do.