SSAI (server-side ad insertion, also called ad stitching or dynamic ad insertion) merges ads into the video stream on the server before delivery. The device receives one continuous manifest with ads already spliced in, instead of the player pausing content to fetch and render ads itself. It is the dominant delivery method for CTV and live streaming.

What is the difference between SSAI and CSAI?

In CSAI (client-side ad insertion) the player on the device fetches the VAST tag, loads the ad media, renders it, and fires tracking itself. In SSAI a server does all of that: it fetches and unwraps the VAST, transcodes the creative to match the stream, splices it into the manifest, and fires or delegates the beacons. CSAI gives better measurement fidelity; SSAI gives broadcast-smooth transitions and resists ad blocking.

Why does CTV use SSAI?

Three reasons: seamless broadcast-like transitions with no buffering wheel between content and ad, uniform delivery across hundreds of device types with weak or inconsistent player SDKs, and resistance to ad blocking since the ad is indistinguishable from content at the network level. Live sports adds a fourth: ad decisioning must keep up with a live manifest, which only a server can do reliably.

How does SSAI work with VAST?

The stitcher is the VAST client. It requests the ad tag at break time, unwraps wrapper chains server-side, selects or transcodes a media file (ideally from the Mezzanine element), rewrites the stream manifest, and handles tracking either by firing beacons server-side with forwarded device headers or by passing tracking metadata to the device player.

SSAI: Server-Side Ad Insertion

SSAI (server-side ad insertion, also called ad stitching or dynamic ad insertion) is the delivery model in which ads are merged into the video stream on the server, before anything reaches the viewer. The device plays one continuous stream with the ads already inside it. There is no separate ad request from the player, no player-side ad rendering, and at the network level, no visible boundary between content and ad.

SSAI is the dominant delivery model for CTV and live streaming, which makes the stitcher the most important VAST client most tags will ever meet.

How the stitcher pipeline works

Break reached. The content manifest (HLS or DASH) reaches an ad break, defined by markers in the stream or a VMAP schedule.
Ad decisioning. The stitcher calls the ad server or SSP with the break context and receives a VAST response.
Server-side unwrap. Wrapper chains are resolved in the data center under tight time budgets; the device never walks a redirect chain.
Transcode and normalize. The creative is converted to match the content stream's bitrate ladder, resolution, and codec profile, ideally from the tag's Mezzanine source rather than a compressed rendition.
Manifest manipulation. Ad segments are spliced into the manifest so the player fetches them like any other piece of content.
Tracking. Either the server fires impression and quartile beacons on the device's behalf (server-side beaconing) or the device player fires them from metadata the stitcher passes down (client-side beaconing). Hybrid setups split the two.

SSAI vs CSAI

Dimension	CSAI (client-side)	SSAI (server-side)
Who fetches and renders the ad	The player on the device	A stitching server
Content-to-ad transition	Player switches sources; buffering possible	Seamless; one continuous stream
Ad blocking	Blockable at the network level	Effectively unblockable
Device SDK requirements	Capable player SDK on every device	Minimal; the device just plays video
Measurement fidelity	High; events reflect actual playback	Depends on beaconing mode and header forwarding
Interactivity (SIMID) and OMID verification	Supported where the SDK supports it	Requires client-side integration; server alone cannot run it
Live streams at scale	Strains the device and the ad server	Built for it
Typical home	Web and mobile in-app video	CTV, FAST channels, live sports

What SSAI changes about your VAST

The tag format is identical; the consumer is different, and it has different needs. Four requirements follow:

Macros must be expanded by the stitcher. The VAST 4.1 macro set ([TIMESTAMP], [CACHEBUSTING], [IFA], and the rest) is expanded by whoever fires the beacon. In SSAI that is the server, and unexpanded literal brackets in tracker URLs are the most common stitch-time defect.
Beacons need forwarded device context. Server-fired impressions come from data-center IPs with server user agents. IAB guidance requires forwarding X-Forwarded-For and X-Device-User-Agent so measurement can attribute the beacon to a real device instead of flagging it as invalid traffic.
A Mezzanine source should be present. Stitchers transcode; a mastering-quality source is what keeps the ad looking like the content it interrupts.
Client-side layers need a client. OMID verification and SIMID interactivity execute on the device. A pure server-side path carries those elements but cannot run them; if the buy depends on them, the delivery path needs a device-side integration.

The failure modes behind these requirements, and what they cost, are covered in SSAI rewrites your VAST: what breaks at stitch time and the revenue math of broken VAST.

Where validation fits

Because the stitcher re-processes every tag, validation belongs at three points: when a creative is onboarded (before it enters the stitcher's cache), in CI for the systems that assemble tags, and against the served output the stitcher actually produces. vastlint validates the structure, macros, media file set, and version coherence that stitch-time processing depends on.

Validate a tag before it enters an SSAI pipeline.Open the VAST tag validator →

SSAI: Server-Side Ad Insertion

How the stitcher pipeline works

SSAI vs CSAI

What SSAI changes about your VAST

Where validation fits

Further reading