Client-Side Ad Insertion (CSAI) and VAST/VPAID/SIMID

Why This Matters

If you sell ads against video, the second-largest engineering choice your monetisation roadmap will make — right after SSAI vs CSAI itself — is which interactive-ad layer to support, because that choice quietly determines which advertisers will accept your inventory at all. VPAID was the de facto interactive standard for a decade and shipped malware in production; SIMID replaces it with a sandboxed iframe; OMID measures viewability without granting the creative any access to the page. A product manager who reads this article will leave knowing why a "VPAID JS" line item from an agency in 2026 is grounds to reject the campaign, why the IMA SDK is the default on the open web and why the open-source videojs-contrib-ads plugin still ships against the same VAST contract, and why "we want VPAID interactive" from a sales rep usually means "we want SIMID interactive and the sales rep is two years behind". An engineer will leave with the VAST 4.3 XML surface area, the SIMID 1.1 message catalogue, the OMID 1.5 verification flow, the ad-pod sequencing rules, and the seven production bugs (wrapper-depth timeouts, blank frames at the splice, IFA-leak claims, OM SDK script-load failures, ad-id mismatch, cookie-consent collisions, and the "looks fine in QA, breaks in production" frame-rate mismatch) that block launch the week before launch.

This article is the seventh piece of the nine-article Block 9 (Operations, DRM, Ads, and QoE) inside Fora Soft's Video Streaming Learn corpus. Read SSAI in depth for the server-side alternative this article positions against, QoE metrics that every dashboard should show for how ad performance is folded into the same metrics layer the engineering team already runs, and streaming cost economics for the unit-economics view that justifies — or kills — a CSAI deployment.

What CSAI Actually Is

Before the protocols, the architecture. Client-Side Ad Insertion is the practice of having the video player — running in a browser, a smart-TV native app, or a mobile app — own every step of the ad lifecycle except the auction. The content stream and the ad stream are two separate sources. When the player reaches an ad break, it pauses the content video element, calls an ad decision server (ADS), downloads the response, picks a creative, layers a second video element (or re-sources the same one), plays the ad, fires the tracking beacons, and only then resumes content. Every device that runs CSAI must ship the same heavy lifting: a VAST parser, an HTTP client with cookie jar, a video element capable of mid-play source changes, a UI overlay that draws the skip and click-through buttons, an event firer that emits ten or more tracking pixels per impression, and increasingly an OMID-compliant verification runner.

The contrast with Server-Side Ad Insertion (SSAI) — covered in our SSAI deep dive — is sharp. In SSAI the origin rewrites every viewer's manifest so content and ad segments live in the same continuous byte stream and the player never knows it played an ad. In CSAI the player knows it played an ad because the player is the one playing it. That single architectural difference dictates everything downstream: where the ad-blocker can intercept, where the impression is counted, who pays the CDN bill for the creative, who is responsible if the ad fails to load, and which device classes can run the integration at all.

The 2026 numbers explain the priorities. Global ad-blocker adoption reached 29.5% of internet users in early 2026 — roughly 1.77 billion people — with around 31.5% of users aged 16–64 saying they use a blocker at least sometimes. Vendor test-bed studies of CSAI against modern blockers report 95% blocking success on Windows desktops and 74% on Mac desktops; published case studies put the resulting revenue loss at 15–30% of expected CSAI inventory, with fill rates dropping to 70–85% because of timeouts and creative-load errors. Meanwhile US connected-TV (CTV) ad spend, where SSAI dominates because the devices cannot run a heavy ad SDK, was forecast at 38 billion US dollars for 2026 and 42 billion for 2027 by major industry trackers. CSAI did not die — it kept the open web, where ad blockers can be partly mitigated, where JavaScript SDKs run freely, and where the kind of interactivity a SIMID creative wants is actually possible. It lost the living room.

Figure 1. CSAI versus SSAI architecture. In CSAI the player makes the ad call and runs the ad creative locally; in SSAI the manifest manipulator at the origin does the same work and the player just plays segments. The placement of the ad call is the single line that determines every downstream trade-off.

The VAST Contract: What Every Ad Server Sends

Every CSAI integration ultimately reduces to one document: a VAST XML response. VAST — Video Ad Serving Template — is published and maintained by the IAB Tech Lab and has been the universal ad-server-to-player handshake since version 1.0 in 2008. The current version is VAST 4.3, released December 2022, with the latest editorial update published 18 July 2024; the XSD schema is mirrored at github.com/InteractiveAdvertisingBureau/vast and the spec PDF lives at iabtechlab.com/wp-content/uploads/2022/09/VAST_4.3.pdf.

A VAST response is one of two shapes:

• InLine — a complete ad. Carries the media file URL(s), the duration, the tracking beacons, the click-through, optional companion banners, and (in 4.x) the block that lists OMID verification scripts.
• Wrapper — a redirect. Names a downstream VAST URL the player should fetch instead. Wrappers can chain (publisher's ad server → SSP → DSP → creative origin); IAB's recommendation is that players abort after a wrapper depth of five, and the player's parser MUST count.

A typical 4.3 InLine for a 30-second linear ad has eight to twelve top-level elements: Ad, InLine, AdSystem, AdTitle, Impression, AdServingId (mandatory in 4.x), Creatives (which wraps one or more Creative/Linear blocks), MediaFiles (one entry per encoding ladder rung), TrackingEvents, VideoClicks, AdVerifications, and Extensions. Linear ads — the pre-roll, mid-roll, post-roll spots — live inside Linear; non-linear overlays live inside NonLinear; banner companions live inside CompanionAds.

Three changes in VAST 4.x are worth memorising because every vendor blog references them and every ad server's tester reports against them:

1. Mezzanine separation. VAST 4.0 split the creative into a high-bitrate mezzanine MP4 () the SSAI service can transcode against, and a delivery-ready block the CSAI player picks from. The mezzanine is the source of truth; the media files are the client-ready ladder rungs.
2. UniversalAdId. The element carries an ad-system-issued identifier that travels with the creative across every wrapper hop, so downstream measurement can de-duplicate the same ad served through ten different SSPs.
3. AdVerifications and OMID. From 4.1 onwards the canonical way to attach a third-party verification script is the block — a list of entries naming the script URL, the vendor key, the access mode (LIMITED, DOMAIN, CREATIVE, FULL), and the verification parameters. The player's OMID-compliant runner loads each script and pipes the standardised viewability events to it. Before 4.1 verification rode in ; some legacy servers still emit that shape and well-behaved players handle both.

<?xml version="1.0" encoding="UTF-8"?>
<VAST xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:noNamespaceSchemaLocation="vast.xsd" version="4.3">
  <Ad id="3201" sequence="1" conditionalAd="false">
    <InLine>
      <AdSystem version="4.0">FS-AdServer</AdSystem>
      <AdTitle>Brand X — Pre-roll 30s</AdTitle>
      <AdServingId>a7f4b09c-1c83-4a8c-9c75-7b1f0e1f0a2b</AdServingId>
      <Impression id="imp-1">https://imp.example.com/i?ad=3201</Impression>
      <Creatives>
        <Creative id="cr-1" sequence="1" adId="3201">
          <UniversalAdId idRegistry="ad-id.org">BRX-30S-2026</UniversalAdId>
          <Linear>
            <Duration>00:00:30</Duration>
            <TrackingEvents>
              <Tracking event="start">https://t.example.com/s</Tracking>
              <Tracking event="firstQuartile">https://t.example.com/q1</Tracking>
              <Tracking event="midpoint">https://t.example.com/m</Tracking>
              <Tracking event="thirdQuartile">https://t.example.com/q3</Tracking>
              <Tracking event="complete">https://t.example.com/c</Tracking>
              <Tracking event="skip">https://t.example.com/sk</Tracking>
            </TrackingEvents>
            <VideoClicks>
              <ClickThrough id="ct-1">https://brandx.example.com/lp</ClickThrough>
              <ClickTracking>https://t.example.com/ct</ClickTracking>
            </VideoClicks>
            <MediaFiles>
              <Mezzanine delivery="progressive" type="video/mp4"
                         width="1920" height="1080">https://cdn.example.com/mez/3201.mp4</Mezzanine>
              <MediaFile delivery="progressive" type="video/mp4" bitrate="3500"
                         width="1280" height="720" codec="avc1.4d4028" scalable="true"
                         maintainAspectRatio="true">https://cdn.example.com/mf/3201-720p.mp4</MediaFile>
              <MediaFile delivery="progressive" type="video/mp4" bitrate="1500"
                         width="854" height="480" codec="avc1.4d401f" scalable="true"
                         maintainAspectRatio="true">https://cdn.example.com/mf/3201-480p.mp4</MediaFile>
            </MediaFiles>
          </Linear>
        </Creative>
      </Creatives>
      <AdVerifications>
        <Verification vendor="omid-vendor.example.com-omsdk">
          <JavaScriptResource apiFramework="omid" browserOptional="false">
            https://verify.example.com/omid.js
          </JavaScriptResource>
          <VerificationParameters><![CDATA[opts=track,view]]></VerificationParameters>
        </Verification>
      </AdVerifications>
    </InLine>
  </Ad>
</VAST>

Read the snippet carefully: the player has everything it needs to play the ad, fire ten tracking beacons, register a click-through, and run a third-party viewability script — without re-contacting the ad server. That is the contract.

Ad Pods and Wrappers

A real CSAI integration almost never plays one ad per break. Connected-TV ad breaks routinely run a pod of three to six consecutive spots; broadcast-grade live streams can pod eight. VAST encodes pods by setting a sequence attribute on each element inside the same VAST response — sequence="1", sequence="2", and so on — and the player plays them back in order without an inter-ad reload. VAST 4.2 added explicit guidance for OTT/CTV ad pods, where four-or-more-spot mid-rolls are the norm and the player must handle pre-roll-into-pod transitions without dropping a frame.

Wrappers are the other side of the same coin. A wrapper is an element containing (not ) and a pointing at the next VAST URL. Each wrapper hop is a network round trip; each round trip is a potential timeout. The IAB-suggested player default is to abort after five wrapper hops, and to time out an individual hop at five seconds — though every commercial player exposes both numbers as configuration. Wrapper-depth failures are the second most common VAST error (code 302 in the IAB error-code list) after media-file load failures (code 303). Production CSAI integrations log the wrapper depth on every play and alert when the p95 crosses three; once it crosses four you are paying for ad-server work the user will never see.

Figure 2. The anatomy of a VAST 4.3 InLine response. Every CSAI player ships a parser that walks these blocks in this order; every ad server ships an emitter that writes them. The contract is universal.

The Player's Job: A Frame-Accurate Walkthrough

To understand CSAI is to understand the player's state machine during a single ad break. Below is the canonical sequence for a pre-roll on the open web; mid-rolls add one wrinkle (the content video must pause at a known frame), post-rolls drop one (no content resumption). Numbers in parentheses are typical wall-clock budgets you should hold yourself to in production.

1. t = 0 — User clicks Play. The player initialises the content video element with preload="none" to avoid wasting bandwidth on the content while the ad runs.
2. t = 0 — Ad request fires. The player builds the ad-tag URL from the publisher's macros (page URL, page category, IFA / GAID / GPID for identifier-supported environments, content metadata, custom key-values) and issues an HTTPS GET. Target: response in ≤ 300 ms on the open web; ≤ 600 ms on CTV.
3. t = 300 ms — VAST response arrives. The player parses the XML. If the response is a Wrapper, the player fetches the next hop. If the chain depth exceeds the configured maximum, the player records error 302, fires the error beacons, and either falls back to a backup ad-tag or moves to content.
4. t = 600 ms — Media file selection. The player walks , picks the highest-bitrate rung that fits the viewport, current bandwidth, and codec capability. CTV players often hard-bias toward 1080p H.264 progressive MP4 because their adaptive logic is limited.
5. t = 600 ms — OMID session start. If is present, the player loads each verification script through the OM SDK runner, registers the video element as the ad session's measurement target, and emits sessionStart.
6. t = 800 ms — Media file fetch begins. The player issues a range request for the first byte range of the chosen MP4. The TCP / TLS handshakes for the creative origin add another 200–400 ms on the first ad of the session.
7. t = 1500 ms — canplay event. The player has enough buffered to start playback. It calls play() on the ad video element and surfaces the skip-after-N-seconds UI overlay if the campaign allows skipping.
8. t = 1500 ms — impression and start beacons fire. Order matters: Impression URL fires first (the auction-winning beacon), then the start tracking event. Most ad servers will not bill if Impression does not arrive within 30 seconds of the ad-tag request.
9. t = 9000 ms (30% mark) — firstQuartile fires.
10. t = 15000 ms (50% mark) — midpoint fires.
11. t = 22500 ms (75% mark) — thirdQuartile fires.
12. t = 30000 ms (100% mark) — complete fires. The ad video element is paused and the player either advances to the next ad in the pod (back to step 4 with the next element) or resumes content.
13. t = 30000 ms — sessionFinish. The OMID runner closes the verification session; the player tears down the ad video element and re-displays the content video element.
14. Total ad-load latency budget — 1500 ms is the right number on the open web for a single-ad pre-roll. CTV players routinely hit 2500–4000 ms, which is the single largest contributor to abandonment on FAST channels.

Two of those steps deserve their own paragraph because they are where every CSAI integration fails first.

Step 7 — the gap between canplay and play(). A web video element that has only its first byte range buffered will frequently canplay and then immediately stall once playback begins. Defensive players hold off on play() until canplaythrough has fired or until buffered.end(0) - currentTime > 2. Without this discipline, viewers see the ad start and then stall for one to three seconds, which the OMID playerStateChange event will faithfully report as "buffering during playback" — a metric that lowers the inventory's MRC viewability score. Step 12 — the splice back to content. The single most common visible bug in CSAI is a brief black frame between the ad's last frame and the content's first frame. The cause is always the same: the player tears down the ad element, calls load() on the content element, and play()s the content before the content's first frame has decoded. Defensive players keep the content element warm in the background (paused but with a buffered first segment), so the transition is a play() not a load() — a one-frame swap not a re-decode.

VPAID: The Standard That Shouldn't Have Survived 2019

To understand why CSAI looks the way it does today, you have to understand the standard that the industry just spent ten years trying to bury. VPAID — Video Player-Ad Interface Definition — was first published by the IAB in 2008 alongside VAST 1.0 and last revised as VPAID 2.0 in 2012. Its purpose was simple: let an ad creative run arbitrary JavaScript inside the publisher's player so the creative could be interactive (quizzes, mini-games, expandable overlays, viewer-controlled cameras) and so the creative's vendor could measure viewability on its own terms.

The mechanism: the VAST block can advertise a apiFramework="VPAID" attribute, in which case the resource is not a video file at all — it is a JavaScript bundle that the player loads, hands a reference to the player API, and trusts to do the right thing. The bundle returns a creative object that exposes initAd, startAd, stopAd, pauseAd, resumeAd, getAdSkippableState, and a handful of event listeners. The bundle then draws the ad onto a canvas, plays the video frames, fires the impressions, optionally renders interactive UI, and tells the player when it is done.

That architecture had three problems the industry could not engineer around.

1. Security. A VPAID bundle is third-party JavaScript loaded into the publisher's page with full access to everything the publisher can access. AdExchanger reported in 2017 on a security firm finding VPAID specs manipulated to deliver malware; the pattern was simple — a malicious DSP would bid into an inventory pool, win the bid, ship a VPAID creative whose JavaScript redirected the page to an exploit kit, and disappear before the next ad-server audit. For a CTV app owner letting a VPAID tag run was, in one researcher's phrase, "like handing over the keys to the house".
2. Performance. A VPAID creative is, by definition, a single JavaScript thread that has to render video on a canvas, fire beacons, and run arbitrary creative-vendor code, all on the main thread. CPU spikes during VPAID ads were the default; ad startup times of three to six seconds were normal; mobile-web abandonment rates on VPAID inventory were measurably worse than on inline VAST.
3. CTV impossibility. Smart TVs, Rokus, Fire TV Sticks, and Chromecasts run resource-constrained JavaScript runtimes — some run no JavaScript at all in the player path. VPAID's design assumes a full browser; on CTV, half the VPAID bundles in circulation fail to initialise.

Google's Ad Manager publicly announced it would stop accepting VPAID on its own video inventory in 2020, migrating to SIMID instead. IAB Tech Lab's own VPAID page now classifies the spec as deprecated and notes that VAST 4.x has removed VPAID support entirely. As of 2026, sending a VPAID creative to a modern player is approximately the same gesture as sending a Flash SWF — the receiving end may or may not still handle it, the auctions will not pay for it, and the security teams will block it. If a sales rep quotes you a "VPAID JS line item" in 2026, treat it the same way you would treat a Flash quote: politely redirect to SIMID.

SIMID: VPAID's Replacement, Done Right

SIMID — Secure Interactive Media Interface Definition — is IAB Tech Lab's purpose-built replacement for VPAID. The first public draft opened for comment in April 2019; SIMID 1.0 was published shortly after; SIMID 1.1 added nonlinear-ad support and the expand/collapse messages; SIMID 1.2, opened for public comment 8 September 2022 alongside VAST 4.3 and ratified shortly thereafter, added responsive-ad sizing (the spec lets a creative declare -1 to mean "I don't know my final size"), squeeze-back support (the L-shaped layout where content shrinks into a corner and the rest of the screen becomes ad), and a security tightening that requires the player to issue cryptographically secure session identifiers.

The architectural difference from VPAID is the whole point. A SIMID creative runs in a sandboxed iframe, not in the player's JavaScript context. The player and the creative communicate exclusively through a defined postMessage API; the creative cannot read cookies, cannot touch the DOM outside its iframe, cannot start network requests outside its allow-list, and cannot crash the player by throwing an uncaught exception. The player owns the video; SIMID owns the interactive overlay.

The message catalogue is small. The player sends Player:init, Player:startCreative, Player:adStopped, Player:adSkipped, Player:resize, and a handful of state-change messages. The creative sends Creative:resize, Creative:requestSkip, Creative:reportTracking, Creative:fatalError, Creative:requestExpand, Creative:requestCollapse, and Creative:requestPlayResume. Every message is JSON, every message carries a session ID and a monotonic message number, and every message has a documented timeout. A SIMID-compliant player has roughly 600 lines of integration code; a VPAID-compliant player needed 3,000.

The VAST integration is clean: a creative advertises itself with apiFramework="SIMID" inside a or block, the player loads it in an iframe with sandbox="allow-scripts allow-same-origin" (or stricter), and the handshake begins. The Google IMA SDK for HTML5, Android, and iOS has shipped client-side SIMID support since 2020 — the Android DAI SDK added it in version 3.21.0 — and modern open-source players (hls.js + videojs-contrib-ads, Shaka Player, JW Player, THEOplayer, Bitmovin Player) all read SIMID from VAST 4.x responses.

The practical upshot for 2026: if your ad campaign needs interactivity (a quiz, a product carousel, an L-shaped squeeze-back, a viewer-controlled angle on a sports highlight), SIMID is how you ship it. VPAID is grounds to fail QA.

OMID: Measurement Carved Off From Interactivity

The third standard in the CSAI stack is OMID — the Open Measurement Interface Definition — and the SDK that implements it, the OM SDK, both maintained by IAB Tech Lab. OMID exists because the industry recognised that "interactivity" (the VPAID-then-SIMID problem) and "viewability measurement" (was this ad actually visible on the user's screen?) had been bundled together in VPAID for no good architectural reason and should be unbundled.

OMID's job is precise. It defines a JavaScript-and-native API that a viewability vendor (Moat, IAS, DoubleVerify, Nielsen, Comscore, and so on) implements on the verification side, that a player or app implements on the measurement side, and that a VAST response wires together via the block. When the player creates an ad session, the OM SDK runner instantiates each declared verification script inside a sandboxed context, registers the player's video element as the measurement target, and pipes a standardised event stream — impressionOccurred, loaded, start, firstQuartile, midpoint, thirdQuartile, complete, pause, resume, bufferStart, bufferFinish, skipped, volumeChange, playerStateChange, geometryChange — to the verification script. The script does its math (was the player on screen? was the volume above zero? was the video paused for less than two seconds?) and reports its findings to the vendor's own backend.

Three OMID details matter for a CSAI engineer.

1. OMID 1.5 is the current spec as of 2025 ratification (the IAB Compliance API at complianceomsdkapi.iabtechlab.com/compliance lists certified partners; the most recent ratification list was updated in March 2026). OMID 1.5 added improved ad-session classification (adSessionType: "html", "native", "javascript"), audio session support, and the friendly-obstruction registration API that lets the player tell the SDK that its own controls (play / pause / skip / fullscreen) are not occlusions and should not lower the viewability score.
2. Access modes are negotiated. The element advertises an accessMode of LIMITED, DOMAIN, CREATIVE, or FULL. LIMITED is the default and the safest: the verification script runs but cannot see the publisher page. CREATIVE is the strictest sandbox: the script can talk to the creative but not the publisher. FULL (rare, requires direct publisher relationship) gives the script access to the full page. Every player must enforce the requested access mode or treat the verification as invalid.
3. Friendly obstructions are not optional.** A player whose UI controls overlap the video element will see its viewability scores cut in half by every major MRC-accredited vendor unless those controls are registered as friendly obstructions. The IMA SDK exposes the API; the open-source players ship a helper; integrators forget about it routinely and discover the bug only after the first month of campaign reports comes in. Do not let your CSAI launch ship without this.

Figure 3. The evolution from VPAID to the modern three-layer stack. VAST carries the contract, SIMID handles interactivity inside a sandboxed iframe, OMID handles viewability measurement through a parallel verification API. VPAID is the deprecated common ancestor that put all three in one JavaScript context.

How a CSAI Ad Actually Reaches a Player: Direct, Programmatic, Header Bidding

VAST is the contract; how the ad-tag URL gets populated with a winning ad is a different question, and the answer changed in 2017 with the rise of video header bidding. There are three patterns a CSAI integration must support in 2026.

Direct-Sold Inventory

The publisher sells an impression directly to an advertiser. The ad-tag URL points at the publisher's primary ad server (Google Ad Manager, Magnite Ad Server, Equativ, FreeWheel for the CTV-flavoured deployments). The ad server picks the winning creative from its own line items, returns VAST, and the player plays it. Latency: 100–300 ms on the open web. Reliability: highest in the stack — one network hop, one decision engine, no auction.

Programmatic via Open RTB

The impression goes through a real-time auction. The publisher's ad server, on receiving the ad request, fires an OpenRTB auction (the IAB Tech Lab spec — OpenRTB 2.6 added video-pod fields in 2022 and is the current baseline in 2026) to its configured SSPs, which in turn solicit bids from DSPs. The auction completes within roughly 100 ms, the winning DSP returns a VAST URL, and the ad server wraps that URL in a VAST Wrapper response. The player parses the wrapper, fetches the winning DSP's VAST, and plays. Latency: 400–800 ms. Reliability: medium — three or four hops, multiple parties, every layer can time out.

Video Header Bidding (Prebid.js / Prebid Server)

The publisher decides not to defer the auction to the primary ad server alone. Before the ad-tag URL is built, a header-bidding wrapper (Prebid.js running in the page or Prebid Server running in the cloud) runs its own parallel auction across a fixed set of demand partners; the winning bid's CPM and creative URL are stuffed into the ad-tag URL as a hb_pb (Prebid price bucket) and hb_uuid (Prebid cache key) parameter, and only then is the ad call to the primary ad server made. The primary ad server sees the header-bid price as a competing line item against its direct-sold and SSP-mediated demand. Latency: 800–1500 ms — the most expensive of the three because two auctions run instead of one — but yield uplift on premium video inventory has been published consistently in the 15–35% range since 2019, which is why it dominates premium publishing.

Three implementation rules cover most of the production pain. Run header-bidding auctions in parallel, never in series, with a 1500 ms timeout — a missed bid is better than a missed user. Use Prebid Server (cloud) over Prebid.js (browser) on CTV apps where the client CPU is constrained. Always pass the winning Prebid bid into the primary ad server, not directly into the player, so the publisher's existing direct-sold line items still get a chance to win. If you skip the third rule, you will quietly cannibalise the highest-CPM inventory you sell — a mistake every publisher who pulled Prebid into a video stack has made at least once.

The IMA SDK and the Open-Source Alternatives

In production CSAI deployments today, four implementations cover roughly 95% of the integrations.

Google IMA SDK — the dominant choice on the open web and mobile. Free, distributed for HTML5, Android, iOS, tvOS, Roku, and Cast. The HTML5 SDK is at version 3.726.0 (2026); it ships a full VAST 4.x parser, SIMID support since 2020, OMID 1.5 integration, ad-pod sequencing, companion-ad rendering, and a tight integration with Google Ad Manager. The trade: every IMA-served ad request is observable by Google. Most publishers accept that trade because the alternative is to write a VAST parser themselves.

videojs-contrib-ads + videojs-ima (open-source web) — the canonical Video.js ad stack. The contrib-ads plugin handles the player state machine (pause content, layer ad element, fire events, resume content); videojs-ima wraps the IMA SDK so that publishers can run Google Ad Manager auctions inside a Video.js-driven site. The combination is what most independent media publishers ship; it is the open-web sibling of the IMA-direct approach.

Shaka Player + custom ad layer — Shaka does not ship native ad support but exposes the right primitives (text-track-style cue insertion, mid-play source switching). Publishers who run Shaka because they need DASH-first delivery typically layer their own minimal CSAI on top — a VAST parser, an Ad overlay, an IMA SDK hookup — and ship a single integration. Shaka 4.x added experimental ad-related APIs in 2024 but the contract is still "bring your own".

hls.js + custom or IMA layer — analogous to Shaka, on the HLS side. hls.js' rich event surface and the ability to drive a second video element from JS make custom CSAI integration roughly a one-engineer-week project.

A note for product managers: the difference between these four shows up at exactly two metrics — the percentage of ad requests that complete the impression beacon and the percentage of those impressions that pass MRC viewability. The IMA SDK is the leader on both because every other implementation is, at some level, a careful reimplementation of what IMA already does. If your engineering team's first instinct on a CSAI launch is "let's write our own ad layer", redirect them toward IMA unless you have a specific reason — a privacy mandate, a CTV target IMA does not support, a control point the SDK does not expose — to go custom.

Comparative Table: CSAI vs SSAI vs SGAI in 2026

A single comparison table captures the trade-offs your monetisation team will fight about. It is biased toward 2026 reality: SSAI runs the living room, CSAI runs the open web, SGAI sits between them.

Criterion	CSAI	SSAI	SGAI
Where the ad call happens	In the player	At the origin / manifest manipulator	At the origin; player executes the ad
Ad-blocker resistance	Low (15–30% revenue loss; 95% block success on Win desktop)	High (block must defeat the manifest itself)	High (manifest signal; client fetch on a publisher domain)
Device coverage	Open web, mobile, web TV; SDKs on CTV with constraints	Universal — works wherever a manifest plays	Modern players that implement the ad-marker handshake (DASH-IF v3.0 SGAI, Roku Ad Decisioning, others)
Interactivity	Native — SIMID layer runs as iframe overlay	Hard — needs SCTE-35 + player hooks + extra layer	Native — client side runs the ad creative
Personalisation	High — every ad request is unique to the session	High — every manifest is per-session	High — every ad-marker fetch is per-session
Latency added per break	1.5–4.0 s for first pod ad	0.5–1.5 s after the live latency budget itself	1.0–2.5 s — between CSAI and SSAI
Server cost per concurrent stream	Low (player does the work)	High (manifest manipulator + ad conditioning + ad-impression beacons)	Medium — server does the picking, client does the playback
Measurement accuracy	High (player owns event firing; OMID native)	Medium (server fires beacons; OMID still needs player hooks)	High (player fires events as in CSAI)
Standards maturity in 2026	Very mature (VAST 4.3, SIMID 1.2, OMID 1.5)	Mature (VAST 4.3, SCTE-35 2023r1, IAB SDK for SSAI ad reporting)	Emerging (DASH-IF SGAI guideline 2023, vendor pilots through 2024–2025)

| Fora Soft heuristic | If you can use SIMID on your audience's devices, use CSAI. If you cannot, use SSAI. If you can use neither cleanly, the new SGAI middle is worth a 12-month pilot. |

Common mistake — running CSAI on a CTV target without an SDK fallback. The single most painful CSAI failure mode in 2026 is launching a Smart TV app (Tizen, webOS, Vidaa, Roku) without first verifying that the IMA SDK or a vendor equivalent (Magnite, FreeWheel, AWS Elemental MediaTailor's CSAI client) actually ships for that device class. The publisher's web team builds the integration against IMA HTML5, the CTV team tries to port it, the SDK does not exist for Tizen 8.0, the publisher ends up writing a custom VAST parser at the last minute, and the launch slips by three months. The fix is to pick the ad-SDK matrix before you pick the player matrix. Treat the SDK availability table as the foundational constraint, not an integration detail.

Figure 4. The CSAI ad-load latency budget for a single pre-roll on the open web, broken into its seven sub-budgets. The single largest savings opportunity is the wrapper-chain depth: shaving one hop saves 200–400 ms.

Where Fora Soft Fits In

Fora Soft has shipped CSAI integrations into video-streaming, OTT, e-learning, and telemedicine products since the original IMA SDK released. The recurring pattern across those projects: the ad layer is never the hardest engineering problem — the alignment between the ad layer and the QoE dashboard is. A team can land a clean VAST 4.3 parser in two weeks; it can land a clean OMID integration in three; it will still spend the next quarter explaining to the analytics team why the CSAI impression count differs from the OM SDK's measured impressions by two percent, and which one is right (the ad server's is what billing uses; the OM SDK's is what the MRC audit uses). The work we sell is the second part — wiring the ad layer's event surface into the same pipeline that already collects QoE metrics and analytics, so the product team has one truth instead of three. Our verticals where this work has shipped are video streaming, OTT/IPTV, e-learning, telemedicine, conferencing, and AR/VR; the most common deployment shape is hls.js or Shaka on the open web plus a native CTV app behind an SSAI fallback for the device classes the IMA SDK does not reach.

The 2026 Decision Tree: When CSAI Is Still the Right Answer

CSAI is not the past. It is the present for the open web and a meaningful slice of mobile. The question is when to pick it over SSAI for a new product. The tree below is the one we actually walk with clients in 2026.

Figure 5. The 2026 decision tree for CSAI vs SSAI vs SGAI. The single most determinant question is the device-class mix — if more than 30% of expected views come from CTV, default to SSAI unless an SGAI pilot is feasible.

Branch 1 — Device class. If more than 30% of expected views come from CTV (Roku, Fire TV, Tizen, webOS, Vidaa, Android TV) or the publisher already targets these explicitly, default to SSAI. The IMA SDK is the only ad SDK with credible CTV coverage, and even IMA's coverage on Vidaa and on Tizen 8.0 has gaps in early 2026. If less than 10% of views come from CTV, default to CSAI. If between 10% and 30%, run a side-by-side pilot.

Branch 2 — Ad-blocker exposure. If your audience is heavily desktop-Windows and skews technical (developer-tools sites, gamer audiences, finance-news desktops), ad-blocker rates can hit 50–70% of sessions. At that exposure CSAI loses 30–50% of inventory by impression and SSAI is the right answer even on the open web. If your audience is mobile-Android-and-iOS heavy (where ad-blocker adoption is lower because of platform constraints), CSAI still works well.

Branch 3 — Interactivity. If the ad product roadmap requires interactive creatives (quizzes, expandable banners, shoppable ads, viewer-controlled experiences), CSAI is the only path that runs SIMID cleanly. SSAI can run interactive ads but only via a hybrid where the SSAI stream plays linearly and a client-side SIMID overlay is layered on top — at which point you have two ad layers to debug and the architectural simplicity SSAI bought you is gone.

Branch 4 — Measurement requirements. If your advertisers require MRC-certified viewability vendors (which most enterprise advertisers do as of 2026), both paths support OMID. CSAI's OMID story is more mature; SSAI's OMID story requires either a SGAI hybrid or the server-side IAB SDK for SSAI Ad Reporting (which still requires player-side event hooks to be useful).

Branch 5 — Engineering capacity. If the team has fewer than two full-time backend engineers available for a six-month ad stack build, CSAI is the only realistic path — most of the complexity lives in libraries (IMA, contrib-ads) you do not have to build. SSAI requires you to either ship a manifest manipulator (a high-investment build) or pay a vendor (Yospace, AWS Elemental MediaTailor, Broadpeak BkS400, Mux Stitch, Bitmovin Streams) per concurrent stream. The vendor route is the right choice for most launches; the in-house route is the right choice only when the publisher's economics depend on margin per ad break and the publisher operates at FAST-channel scale.

If you finish all five branches and the answer is "we should do CSAI", the download at the end of this article — the CSAI Integration Checklist — is the seven-page artefact our team uses to keep the launch on rails.

What to Read Next

• Server-Side Ad Insertion (SSAI) in Depth — the architecture this article positions against.
• QoE Metrics That Every Dashboard Should Show — where the ad layer's event surface gets correlated with the player's quality metrics.
• Streaming Cost Economics — the unit-economics view that justifies (or kills) a CSAI launch.

CTA Block

• Talk to a streaming engineer — book a 30-minute scoping call.
• See our case studies — OTT, FAST, e-learning, and surveillance projects that ship CSAI today.
• Download the CSAI Integration Checklist — the one-page A4 reference our team uses to keep launches on rails.

References

1. IAB Tech Lab — Video Ad Serving Template (VAST) 4.3, released December 2022, latest editorial update 18 July 2024. PDF at iabtechlab.com/wp-content/uploads/2022/09/VAST_4.3.pdf. XSD at github.com/InteractiveAdvertisingBureau/vast. Primary standard for every CSAI integration; cited for VAST anatomy, wrapper limits, ad pods, mezzanine separation, UniversalAdId, AdVerifications block.
2. IAB Tech Lab — Secure Interactive Media Interface Definition (SIMID) 1.2, public-comment release 8 September 2022, ratified 2023. Spec at interactiveadvertisingbureau.github.io/SIMID/ and standards page at iabtechlab.com/standards/simid/. Cited for message catalogue, sandboxed-iframe architecture, responsive-size signalling, cryptographic session IDs.
3. IAB Tech Lab — Open Measurement Interface Definition (OMID) and Open Measurement SDK, OMID 1.5 ratified 2025; compliance API at complianceomsdkapi.iabtechlab.com/compliance last updated March 2026. Standards page at iabtechlab.com/standards/open-measurement-sdk/. Cited for verification access modes, friendly-obstruction registration, ad-session classification.
4. IAB Tech Lab — Video Player-Ad Interface Definition (VPAID) 2.0, original spec January 2012, formally deprecated in VAST 4.0 (2016) and absent from VAST 4.3. Standards-old page at iabtechlab.com/standards-old/video-player-ad-interface-definition-vpaid/. Cited for VPAID architecture and the reasons for its deprecation.
5. IAB Tech Lab — Digital Video Multiple Ad Playlist (VMAP) 1.0.1, published July 2012, current. Standards-old page at iabtechlab.com/standards-old/video-multiple-ad-playlist-vmap/. Cited for ad-break timing and the where/when of pod placement.
6. IAB Tech Lab — OpenRTB 2.6 specification, ratified 2022, current baseline in 2026. Cited for the auction layer that sits behind a VAST Wrapper and the video-pod fields added in 2.6.
7. Google Developers — IMA SDK for HTML5 client-side guide and release notes, HTML5 SDK 3.726.0 (2026). Set-up at developers.google.com/interactive-media-ads/docs/sdks/html5/client-side/get-started; release notes at developers.google.com/interactive-media-ads/docs/sdks/html5/client-side/release-notes. First-party engineering source; ranked tier 3 (deployer with co-author status) and overridden in the rare conflict with the IAB spec text, none of which arose for this article.
8. AdExchanger — "Publishers Rejoice: VPAID Is Out And SIMID Is In", 2019, plus follow-up coverage 2020–2022 of Google Ad Manager deprecating VPAID. Cited as the industry-wide narrative source on the VPAID-to-SIMID transition.
9. Backlinko — Ad Blocker Usage and Demographic Statistics 2026, January 2026 update. backlinko.com/ad-blockers-users. Cited for the 29.5% adoption figure, 1.77 billion users, and 31.5% of 16-64-year-olds — the numbers that drive the CSAI vs SSAI economics.
10. Streaming Learning Center — "CSAI vs SSAI in Video Ad Insertion: A Comprehensive Guide", 2024–2025 update. streaminglearningcenter.com/articles/csai-vs-ssai-in-video-ad-insertion. Cited for the 95%-on-Windows, 74%-on-Mac ad-blocker success-rate test-bed numbers and the 15–30% CSAI revenue-loss range.
11. StackAdapt and MNTN — 2026 CTV Statistics reports. Cited for US CTV ad-spend projections (38 billion USD 2026, 42 billion USD 2027) and the FAST 55% YoY growth figure.
12. Prebid.org — Prebid.js Video Overview for Header Bidding, current as of 2026. docs.prebid.org/prebid-video/video-overview.html. Cited for header-bidding architecture and the 15–35% premium-inventory yield uplift range.
13. DASH-IF — Server-Guided Ad Insertion (SGAI) Implementation Guideline, October 2023 release, current in 2026. Cited for the SGAI middle position in the trade-off table and the decision-tree branch.
14. Wowza, Broadpeak, Bitmovin, Dolby OptiView, Yospace engineering blogs (multiple 2024–2026 posts on CSAI/SSAI/SGAI comparisons). Cited as tier-4 deployment references; consulted for the comparative table and the latency budget but overridden by the IAB specs and the Google docs where they disagreed.