VAST 4.3 and the CTV Addendum: Replacing VPAID with OMID, SIMID, and ACIF Registration

VAST error code 901 (General VPAID Error) historically accounted for up to 35% of client-side video ad drop-offs across mobile web and desktop environments, while completely disqualifying demand tags from Server-Side Ad Insertion (SSAI) pipelines on Connected TV (CTV). For over a decade, the Video Player-Ad Interface Definition (VPAID) forced video players to hand over execution control of the playback environment to an arbitrary JavaScript payload disguised as a media asset. When a demand-side platform returned a <MediaFile apiFramework="VPAID"> node, the publisher's player had to instantiate a secondary runtime, load an external script, and wait for that script to fetch, render, verify, and track the actual video stream.

That monolithic architecture collapsed under the technical constraints of native mobile applications and living-room television operating systems. Smart TV platforms such as Roku OS, Apple tvOS, Samsung Tizen, and LG webOS either lack a Document Object Model (DOM) entirely or restrict runtime script execution inside native media players. At the same time, server-side manifest manipulators cannot execute client-side JavaScript inside the cloud stitcher when assembling HTTP Live Streaming (HLS) or Dynamic Adaptive Streaming over HTTP (MPEG-DASH) streams.

To eliminate this structural bottleneck, the IAB Tech Lab VAST specifications introduced a strict architectural decoupling across VAST 4.2 and VAST 4.3, deprecating VPAID in favor of the Open Measurement Interface Definition (<AdVerifications> / OMID) for viewability and the Secure Interactive Media Interface Definition (SIMID v1.2) for interactive overlays. Building on this foundation, the VAST Addendum for CTV (finalized in July 2024) brings standardized support for the Ad Creative ID Framework (ACIF), Digital Services Act (DSA) transparency icons, and higher-resolution mezzanine file requirements tailored for large television screens. For engineering and yield teams managing high-concurrency video supply, migrating wrapper configurations and SSAI parsers to these standards is the primary mechanism for reducing playback latency and capturing premium programmatic CTV budgets.

Why VPAID Failed in Mobile and Connected TV Environments

The fundamental flaw of VPAID was its conflation of three distinct responsibilities: video playback control, ad verification measurement, and interactive user interface rendering. In a VAST 2.0 or 3.0 response utilizing VPAID, the <MediaFile> node did not point to an MP4 or HLS manifest; instead, it pointed to an executable .js application. The publisher's video player had to expose its internal playback API directly to this third-party script, allowing the ad creative to pause, resume, resize, or terminate the video element at will. Worse still, buyers routinely wrapped VPAID tags inside additional VPAID wrappers to layer third-party viewability and invalid traffic (IVT) verification scripts around the creative.

In production environments, this nested execution model created severe latency and stability failure modes:

Main-Thread Contention and Timeout Cascades: Each nested VPAID wrapper required sequential network round-trips and synchronous JavaScript evaluation on the browser's main UI thread before a single frame of video could buffer. If a verification vendor's script stalled or failed to emit the AdLoaded and AdStarted handshake events within the player's timeout window, the entire impression failed, firing a VAST 901 or 402 timeout error and leaving the publisher with an unmonetized ad slot.
Incompatibility with Non-DOM CTV Environments: Native CTV environments do not render video inside an HTML5 <video> tag backed by a full browser engine. Roku applications written in BrightScript rely on the native roVideoPlayer or SceneGraph Video node, while Apple tvOS relies on AVPlayer. Neither environment can parse or execute a JavaScript VPAID unit. Any programmatic bid response containing a VPAID payload directed at a native CTV app is automatically rejected either at the SSP filter layer or by the client device, directly depressing bid density and clearing prices.
SSAI Stitching Blindness: Server-Side Ad Insertion works by intercepting the content manifest request from the CTV device, calling the ad server and SSP auction from a cloud proxy, transcoding the winning video creative into matching bitrate segments, and splicing those segments directly into the master HLS .m3u8 or DASH .mpd playlist. Because an SSAI stitcher operates headless in the cloud, it requires direct access to a raw video file (<Mezzanine> or standard <MediaFile>). When an SSAI proxy encounters an apiFramework="VPAID" executable instead of a raw media container, it cannot extract the underlying video stream to transcode it, causing an immediate stitch failure.
Security and Sandboxing Violations: Giving third-party scripts unrestricted access to the host page or application context allowed malvertising payloads to hijack navigation, scrape user data outside privacy consent frameworks, or spoof viewability signals by manipulating DOM geometry.

When publishers connect their inventory to a modern CTV monetization platform, stripping legacy VPAID demand at the OpenRTB bid request level is mandatory. By signaling explicit support for OMID (7) and SIMID (9) in the imp.video.api array of an OpenRTB 2.6 request while omitting VPAID (1 and 2), supply-side platforms protect player stability and force DSPs to route clean, stitchable VAST 4.2 and 4.3 responses.

Separation of Concerns in VAST 4.2 and 4.3: Verification vs. Interactivity vs. Playback

To permanently resolve the failure modes of executable media files, VAST 4.x enforces a strict separation of concerns. Under VAST 4.2 and VAST 4.3, the video player retains exclusive ownership of the media playback lifecycle. A <MediaFile> node is restricted strictly to raw video streams (such as progressive MP4, WebM, HLS, or DASH) and a high-quality <Mezzanine> source file for server-side transcoding. No executable code is permitted inside the media delivery node.

Verification and interactivity are extracted into dedicated, sandboxed sibling nodes within the <InLine> or <Wrapper> structure. Third-party viewability and fraud measurement scripts are isolated inside the <AdVerifications> node, governed by the Open Measurement (OMID) standard. Interactive user experiences, such as shoppable carousels, dynamic overlays, or trivia prompts, are isolated inside the <InteractiveCreativeFile> node, governed by SIMID v1.2.

Architectural refactoring diagram replacing a tangled legacy VPAID box with isolated glass modules for 4K Mezzanine media, Open Measurement verification, and SIMID interactive overlays.

This decoupled architecture transforms how video ad pods are assembled and executed across both client-side and server-side pipelines. Because the video file is immediately accessible in the XML tree without executing JavaScript, the player or SSAI stitcher can begin pre-buffering or transcoding the video stream in parallel while the verification and interactive scripts initialize asynchronously in restricted sandboxes. If a verification vendor's server experiences high latency or an interactive overlay script throws a runtime exception, the video player simply fires a non-fatal diagnostic tracking beacon and plays the video ad uninterrupted, preserving publisher yield and user experience.

Implementing the Node for Open Measurement (OMID)

The <AdVerifications> element replaces the verification use case of VPAID by pairing declarative XML metadata with the IAB Tech Lab Open Measurement SDK (OM SDK) integrated natively into the publisher's web player, mobile app (iOS/Android), or CTV application (tvOS, Roku, Tizen, webOS). Instead of allowing a third-party vendor to inspect the screen directly or wrap the video player, the host application's OM SDK collects geometry, volume, playback state, and obstruction signals, then transmits those immutable measurements to the verification scripts loaded inside a restricted, DOM-less execution context.

In a VAST 4.3 payload, each <Verification> node identifies the measurement vendor via the vendor attribute, declares the verification script URL inside <JavaScriptResource apiFramework="omid" browserOptional="true">, and passes campaign-specific configuration strings inside <VerificationParameters>. It also includes a dedicated <TrackingEvents> block for the verificationNotExecuted event, which triggers if the player cannot run the script and passes the [REASON] macro (1 for verification resource rejected, 2 for verification not supported, or 3 for resource load error).

<AdVerifications>
  <Verification vendor="ias.com-omid">
    <JavaScriptResource apiFramework="omid" browserOptional="true">
      <![CDATA[https://static.adsafeprotected.com/vans-adapter-omid.js]]>
    </JavaScriptResource>
    <VerificationParameters>
      <![CDATA[advId=98412&campId=449102&chanId=ctv_ssai_01&pubId=skyboosts]]>
    </VerificationParameters>
    <TrackingEvents>
      <Tracking event="verificationNotExecuted">
        <![CDATA[https://pixel.adsafeprotected.com/mon?reason=[REASON]&advId=98412]]>
      </Tracking>
    </TrackingEvents>
  </Verification>
</AdVerifications>

For publishers prioritizing OMID measurement and brand safety, the browserOptional="true" attribute on <JavaScriptResource> is particularly critical in CTV and mobile app environments. It signals to the native OM SDK that the verification script does not depend on browser DOM APIs (window or document) and can be executed safely inside a lightweight headless JavaScriptCore or V8 isolate managed by the native application or Google IMA/PAL SDK.

Secure Interactive Media Interface Definition (SIMID v1.2) Sandboxing

While OMID handles passive measurement, interactive ad formats require a visual surface and bidirectional communication with the video player. SIMID v1.2 replaces the interactive capabilities of VPAID by rendering interactive HTML5 creatives inside a cross-origin, sandboxed <iframe> (or native webview overlay) positioned over the video player. Unlike VPAID, a SIMID creative has zero direct access to the video element, the publisher's page DOM, or the underlying media stream.

In VAST 4.2 and 4.3, interactive assets are declared within the <Linear> block using the <InteractiveCreativeFile> node. The node specifies apiFramework="SIMID" and uses the variableDuration="true" attribute if user engagement with the overlay can extend the duration of the ad slot beyond the length of the underlying video file.

<Linear>
  <Duration>00:00:30</Duration>
  <MediaFiles>
    <MediaFile delivery="progressive" type="video/mp4" width="1920" height="1080" bitrate="8000" codec="H.264">
      <![CDATA[https://cdn.skyboosts.com/creatives/1080p_spot.mp4]]>
    </MediaFile>
  </MediaFiles>
  <InteractiveCreativeFiles>
    <InteractiveCreativeFile type="text/html" apiFramework="SIMID" variableDuration="true">
      <![CDATA[https://interactive.skyboosts.com/simid/v1.2/qr-overlay.html?cmp=8831]]>
    </InteractiveCreativeFile>
  </InteractiveCreativeFiles>
</Linear>

All communication between the publisher's video player and the SIMID creative occurs exclusively via asynchronous W3C postMessage JSON payloads following a strict request-acknowledge state machine. When the player initializes the SIMID session, it sends a SIMID:Player:init message containing environment capabilities, video dimensions, and navigation telemetry (such as D-pad remote control availability on CTV). If a viewer clicks an interactive element or scans an on-screen product carousel using their TV remote, the creative cannot pause the video directly; it must emit a SIMID:Creative:requestPause message, which the publisher's player evaluates against its own pod policies before granting via a resolve callback or rejecting via a reject callback. When executing advanced CTV video ad formats, this asynchronous message bus guarantees that a malfunctioning interactive overlay can be torn down immediately by the player via SIMID:Player:adStopped without crashing the playback session.

The IAB VAST Addendum for CTV (2024): High-Resolution Mezzanine Specs, ACIF Support, and DSA Icons

Although VAST 4.2 and 4.3 solved the VPAID problem, the rapid scaling of programmatic Connected TV exposed new operational gaps in ad pod deduplication, European regulatory compliance, and visual quality on ultra-high-definition screens. In July 2024, the IAB Tech Lab finalized the VAST Addendum for CTV, updating the specification with three targeted structural enhancements designed specifically for living-room television delivery and SSAI architectures.

The first enhancement addresses high-resolution <Mezzanine> requirements for large TV screens. Early VAST 4.x specifications defined mezzanine file guidelines during an era dominated by mobile and desktop viewports, often permitting lower bitrates and 720p or basic 1080p source files. On 65-inch and 85-inch 4K Ultra HD television panels, transcoding an under-spec mezzanine file inside an SSAI stitcher produces visible macroblocking, banding, and audio-video sync drift against broadcast-grade streaming content. The 2024 CTV Addendum updates the <Mezzanine> node specifications to accommodate full HD (1920x1080) and 4K UHD (3840x2160) source files with elevated bitrate floors, explicit color space consistency, and standardized codec profiles (such as H.264 High Profile and HEVC/H.265). By ingesting a pristine, high-bitrate mezzanine asset, SSAI platforms can generate an Adaptive Bitrate (ABR) ladder that seamlessly matches the frame rate (29.97fps, 50fps, or 59.94fps) and audio loudness (LKFS/LUFS) of the surrounding CTV stream.

The second enhancement introduces explicit support for the Ad Creative ID Framework (ACIF) via the <UniversalAdId> node. One of the most persistent failure modes in programmatic CTV is ad pod collision: when an SSAI stitcher fills a 90-second commercial break by running parallel auctions across multiple SSPs and DSPs, the same brand's creative (or two competing automotive brands) frequently wins adjacent slots in the same pod because each DSP assigns a proprietary, uncoordinated creative ID. The 2024 CTV Addendum standardizes how registered ACIF identifiers are declared inside the <UniversalAdId idRegistry="acif.org"> node, linking every transcoded variant back to a single verified registry record containing standardized brand, industry category, duration, and audio/video fingerprint metadata.

The third enhancement extends the <Icons> node to support European Union Digital Services Act (DSA) transparency requirements on Connected TV interfaces. Under Article 26 of the DSA, publishers and ad platforms serving audiences in the EU must display real-time transparency disclosures identifying that the content is an advertisement, naming the natural or legal person on whose behalf the ad is presented, and disclosing the main parameters used to target the recipient. Because CTV environments lack a mouse cursor or standard browser chrome to click traditional AdChoices icons, the CTV Addendum standardizes <Icon program="DSA"> payloads that allow CTV players to render remote-navigable regulatory overlays or scannable QR codes on the 10-foot UI, firing standardized <IconViewTracking> and <IconClickTracking> beacons when invoked.

<InLine>
  <AdSystem version="4.3">Sky Boosts_SSP</AdSystem>
  <AdTitle>Premium_Automotive_Q4_4K</AdTitle>
  <Creatives>
    <Creative id="cr_99201" adId="SB_88412">
      <Linear>
        <Duration>00:00:30</Duration>
        <UniversalAdId idRegistry="acif.org">ACIF-2024-9948102-A8F2</UniversalAdId>
        <MediaFiles>
          <Mezzanine delivery="progressive" type="video/mp4" width="3840" height="2160" codec="HEVC" fileSize="184549376">
            <![CDATA[https://cdn.skyboosts.com/mezzanine/auto_q4_uhd_source.mp4]]>
          </Mezzanine>
        </MediaFiles>
        <Icons>
          <Icon program="DSA" width="120" height="40" xPosition="right" yPosition="top" duration="00:00:10" apiFramework="SIMID">
            <StaticResource creativeType="image/png">
              <![CDATA[https://cdn.skyboosts.com/dsa/ad-info-badge-ctv.png]]>
            </StaticResource>
            <IconClicks>
              <IconClickTracking>
                <![CDATA[https://track.skyboosts.com/dsa/click?ad=cr_99201]]>
              </IconClickTracking>
            </IconClicks>
            <IconViewTracking>
              <![CDATA[https://track.skyboosts.com/dsa/view?ad=cr_99201]]>
            </IconViewTracking>
          </Icon>
        </Icons>
      </Linear>
    </Creative>
  </Creatives>
</InLine>

Maintaining Backward Compatibility via the VAST 2.x/3.x Addendum

While sell-side infrastructure, Google Ad Manager (GAM 360), and modern SSAI stitchers fully support VAST 4.2 and 4.3, buy-side migration across global DSPs and agency ad servers remains uneven. A substantial percentage of programmatic video demand is still trafficked inside legacy VAST 2.0 and VAST 3.0 XML schemas that lack native schema definitions for <AdVerifications> or <UniversalAdId> at the root <InLine> or <Linear> level. If an SSP or video player strictly rejects VAST 2.0/3.0 tags, the publisher sacrifices significant auction pressure; conversely, if the DSP attempts to deliver OMID verification in a VAST 2.0 tag using a legacy VPAID wrapper, the impression will fail on CTV and mobile.

To bridge this gap without requiring a full schema upgrade on legacy buy-side ad servers, the IAB Tech Lab published the VAST 2.x/3.x Addendum alongside the core VAST 4.x specifications. This backward-compatibility specification allows DSPs and verification vendors to backport VAST 4.x <AdVerifications> and <UniversalAdId> nodes directly into a VAST 2.0 or 3.0 response by encapsulating them inside the standard <Extensions> block.

<VAST version="3.0">
  <Ad id="legacy_compat_7721">
    <InLine>
      <AdSystem>Tier1_DSP</AdSystem>
      <AdTitle>Legacy_VAST3_With_OMID_And_ACIF</AdTitle>
      <Extensions>
        <Extension type="AdVerifications">
          <AdVerifications>
            <Verification vendor="doubleverify.com-omid">
              <JavaScriptResource apiFramework="omid" browserOptional="true">
                <![CDATA[https://cdn.doubleverify.com/dv-omid-verification.js]]>
              </JavaScriptResource>
              <VerificationParameters>
                <![CDATA[ctx=119482&cmp=DV_CTV_8821]]>
              </VerificationParameters>
            </Verification>
          </AdVerifications>
        </Extension>
        <Extension type="UniversalAdId">
          <UniversalAdId idRegistry="acif.org">ACIF-2024-7731904-B2C1</UniversalAdId>
        </Extension>
      </Extensions>
    </InLine>
  </Ad>
</VAST>

For AdOps architects and video engineering teams, supporting this transitional state requires three concrete implementation steps across your monetization stack:

Enforce Dual-Path XML Parsing in Client Players and SSAI Stitchers: Configure your VAST parser to inspect both the native VAST 4.x <InLine><AdVerifications> path and the fallback VAST 2.0/3.0 <InLine><Extensions><Extension type="AdVerifications"><AdVerifications> path. Likewise, extract ACIF creative IDs from both <Linear><UniversalAdId> and <Extensions><Extension type="UniversalAdId"> before executing pod deduplication and competitive separation logic.
Audit OpenRTB 2.6 Bid Requests for Explicit API and Protocol Arrays: Ensure your SSP adapter and Prebid Server video modules populate imp.video.protocols with [2, 3, 5, 6, 7, 8, 11, 12, 13, 14] (spanning VAST 2.0 through VAST 4.3 and their respective wrappers) while strictly constraining imp.video.api to [7, 9] (OMID-1 and SIMID 1.2) on CTV and mobile inventory. Never pass 1 (VPAID 1.0) or 2 (VPAID 2.0) on SSAI or native app requests.
Validate Wrapper Depth and Mezzanine Ingestion Thresholds: In Google Ad Manager and your SSAI transcoder, set a hard maximum VAST wrapper depth of 3 hops to keep total XML resolution latency under 600ms, and configure your stitcher's ingestion filter to cache transcoded HLS/DASH segments keyed by the UniversalAdId (acif.org) value. By keying the transcode cache to the registered ACIF ID rather than the ephemeral DSP creative URL, your SSAI pipeline eliminates redundant mezzanine transcoding across SSPs and guarantees zero first-impression frame drops.