// Publishers — CTV ad tech

VAST, VPAID, OMID, SSAI and CSAI in plain words

CTV monetization drowns in acronyms, but the concepts are simple: a standard for describing video ads, a standard for interactivity, a standard for measurement, and two places where ads can be inserted — in the player or in the stream. This page explains each one, shows what an integration actually looks like, and lists the mistakes that cost publishers money.

How connection works

01.Apply

Register as a publisher and choose your inventory type: CTV app, FAST channel or web video.

02.Inventory review

We check verification files, audience quality and measurement hygiene before any commercial terms.

03.Individual terms

Revenue model, payment schedule and reporting granularity are agreed with you in writing.

04.Demand connected

Ad demand is connected through the integration route that fits your stack: SDK, VAST, SSAI or S2S.

VAST: the ad description language

VAST (Video Ad Serving Template) is the industry-standard XML format in which an ad server answers the question 'what ad should I play?'. A VAST response contains the video file URLs, tracking events (impression, start, quartiles, completion), click-through destination and error callbacks. Your player requests a VAST tag at each ad break, parses the XML, plays the video and fires the tracking beacons. Almost everything in CTV monetization is built on this exchange.

VPAID and OMID: interactivity and measurement

VPAID was an older standard that let ads run their own code for interactivity and measurement — powerful but heavy, and largely abandoned on TV platforms for performance and security reasons. OMID (Open Measurement Interface Definition) is its modern replacement for measurement: a standard interface that lets verification vendors measure viewability and completion inside the player without custom code per vendor. For a publisher, supporting OMID means more demand, because measured inventory is what brand buyers are allowed to buy.

CSAI: ads inserted by the player

Client-side ad insertion means the video player on the device pauses content, calls the ad server, plays the ad and returns to content. CSAI is precise and interactive — every beacon fires from the device, and click or remote actions work naturally. The costs are complexity: the player must handle VAST parsing, errors, timeouts and smooth transitions, on every device generation you support. CSAI is the natural fit for on-demand (AVOD) apps.

SSAI: ads stitched into the stream

Server-side ad insertion moves the work to the cloud: an SSAI service takes your content stream, asks the ad server for ads personalized per household, and stitches the ad video into the stream itself. The device plays one continuous stream — no client ad logic, no blocking, uniform behavior across every platform. This is why SSAI is the standard for FAST channels and live content. The trade-off: measurement must be handled deliberately, because the player no longer knows where ads are — beacons are fired from the server or via a lightweight client SDK, and buyers scrutinize SSAI measurement for spoofing.

What an integration looks like

A typical CSAI integration is: configure ad break positions in your player, point them at a VAST tag, test that every tracking event fires, ship. A typical SSAI integration is: mark ad breaks in your stream with SCTE-35 cues, configure the SSAI service with your ad server's endpoint, verify per-household measurement on real devices, ship. In both cases the publisher's side is measured in days of engineering, not months — the long pole is always certification and demand approval, not the code.

Typical mistakes that cost revenue

The recurring failures we see in CTV integrations: VAST wrappers nested too deep, so players time out before reaching the media file; missing error beacons, which hides failures from both you and the buyer; quartile events fired in the wrong order; ad requests without proper device and app identifiers, which makes inventory unverifiable and unsellable; SSAI without client-side measurement confirmation; and pods that repeat the same creative. Every one of these reads as low-quality inventory to a buyer's verification stack — and low-quality means low price or no fill.

FAQ

Q.Is VAST a piece of software?

No — VAST is a document format, an XML schema. An ad server produces VAST documents; your player or SSAI service consumes them. When someone says 'VAST tag' they mean the URL that returns such a document.

Q.Should new integrations still use VPAID?

No. VPAID is effectively deprecated in CTV: TV platforms restrict or reject executable ad code. Use OMID for measurement and platform-native mechanisms for interactivity such as QR overlays.

Q.CSAI or SSAI for a new CTV app?

On-demand library: CSAI is simpler and fully measurable. Live or FAST stream: SSAI is the practical standard. Many publishers end up running both in one app — CSAI for VOD, SSAI for linear.

Q.What is a VAST wrapper?

A VAST response that redirects to another ad server instead of containing a video file. Chains of wrappers are normal in programmatic, but each hop adds latency and failure risk — keep chains short and timeouts generous.

Q.Why do buyers care about OMID support?

OMID lets independent verification vendors measure your inventory. Without it, large brand campaigns simply cannot buy you — their contracts require third-party measurement.

Q.How do I test my VAST integration?

Play your ad breaks on real devices while capturing network traffic, and confirm that impression, start, each quartile and completion events fire in order. Then test failure paths: empty responses, timeouts, malformed XML.

Q.Does SSAI work on every platform?

Yes — that is its main advantage. Because ads are stitched into the stream, the device only plays video. The platform-specific part is measurement: how beacons are confirmed from the client side.

Q.Which route does Mobadly support?

Integration routes are confirmed during onboarding and depend on your platform and stream architecture — SDK, VAST tag, SSAI and server-to-server are the options we evaluate. Terms are agreed individually.

Become a publisher

Quick application

Application received. We'll contact you within 24 hours.