Glossary term

CSAI (Client-Side Ad Insertion)

What Is CSAI?

CSAI (Client-Side Ad Insertion) is a method of delivering video ads. Here, the video player on the viewer’s device is responsible for requesting, loading, and playing the ads.

In CSAI, ads are not part of the original video stream; they are inserted dynamically during playback.

This ad delivery method is mostly used for

• YouTube-style web video players
• Mobile apps using Google IMA or similar SDKs
• Ad-supported VOD platforms (AVOD)
• Interactive or skippable ad experiences
• Programmatic ad delivery in real time

How CSAI Works

Step 1: Starting simple, the user hits play on a video.

Step 2: The video player checks the timeline and identifies ad cue points (e.g., pre-roll, mid-roll, post-roll).

Step 3: At each cue point, the player sends a request to an Ad Server, typically using the VAST or VMAP protocol.

Step 4: The ad server returns one or more ad creatives (video files and tracking URLs).

Step 5: The player plays the ad(s), tracks interactions, and then resumes or starts the main video content.

Key Components of CSAI

Here are the main parts of the CSAI pipeline.

1. Video Player

The video player is the core of CSAI. It manages both the content and the ad playback. The video player responds to cue points, handles stream switching, and maintains synchronization between the ad experience and the main video content.

The Video Player is Responsible for

• Ad Cue Management: Pause main content at pre-roll, mid-roll, or post-roll breakpoints.
• Creative Playback: Load and play ad videos with full control (play, pause, stop, volume, seek-locking).
• Media Compatibility: Must support standard video formats (MP4, WebM, etc.).
• UI Integration: Display skip buttons, countdown timers, companion ads, or overlays.
• Event Dispatching: Emit events (e.g., adStarted, adComplete, adError) to the rest of the app.

Video Player Examples

HTML5-based players (e.g., Video.js, Shaka Player)

Native mobile players (Android ExoPlayer, iOS AVPlayer)

Smart TV SDKs (e.g., Tizen, Roku SceneGraph)

2. Ad Server

The ad server handles ad decisioning — selecting which ad(s) to serve in response to a request from the player, based on factors like user location, device, and campaign rules.

The Ad Server Provides:

• VAST XML: A standardized format describing ad creatives, tracking URLs, clickthroughs, durations, and more.
• VMAP (if applicable): Describes multiple ad breaks for longer videos or live streams.
• Wrapper Responses: Can redirect to another ad server for bidding, waterfalling, or mediation.

The Ad Server Role in Steps

1. Selects ads based on targeting criteria.

2. Manages pacing, frequency capping, and campaign delivery.

3. Tracks reporting via beacon responses.

4. Supports fallback creatives or alternate tags if the primary ad fails.

Ad Server Examples

Google Ad Manager, FreeWheel, SpotX, and SpringServe

3. Ad SDK (Optional but Recommended)

The Ad SDK simplifies CSAI implementation by abstracting away ad loading, rendering, tracking, and error handling logic. It acts as a layer between the player and the ad server.

Ad SDK Responsibilities:

• Loads and reads the ad instructions from VAST or VMAP files.
• Picks ad files that work best for the device (based on quality or size).
• Plays the ad and prevents users from skipping or interacting unless allowed.
• Sends tracking signals when the ad starts, finishes, or reaches key points.
• Shows ad controls like skip buttons, timers, or mute options.
• Manages backup ads and handles problems if an ad fails to load.

Why is the ad SDK optional?

Advanced streaming platforms mainly implement their own ad logic directly. Also, for custom players or platforms without SDK support, you may need to build an ad SDK manually.

Ad SDK Examples

Google IMA SDK (Web, iOS, Android)

FreeWheel MRM SDK
Roku’s Ad Framework in SceneGraph

4. Ad Tracking Beacons

Beacons are URLs provided in the VAST XML that must be triggered at specific points during ad playback to notify the ad server (and advertisers) of key events.

Key Events Tracked:

• Impression: When the ad begins rendering
• Start: Ad playback begins
• First Quartile: 25% complete
• Midpoint: 50% complete
• Third Quartile: 75% complete
• Complete: 100% watched
• ClickThrough: Viewer clicks the ad
• Error: Playback fails due to a technical issue (code is included)

How Ad Tracking Beacons Work:

Step 1: Player or SDK performs a GET request to each beacon URL at the correct moment.
Step 2: Beacons often contain macros like [TIMESTAMP], [CONTENT_ID], and [PLAYER_WIDTH], which must be resolved before the call.
Step 3: Ad verification vendors (such as Moat, IAS, and DoubleVerify) may also insert third-party tracking pixels.

Why are ad tracking beacons important?

These signals enable advertisers to validate delivery, engagement, and billing. Missed beacons = lost revenue or impression discrepancy.

CSAI vs SSAI

We already know that CSAI is an ad delivery method, but it is not the only one. SSAI (Server-Side Ad Insertion) is another effective ad delivery method that was developed after CSAI to enhance playback and prevent ad blocking.

What Is SSAI?

SSAI (Server-Side Ad Insertion) is an ad delivery technology that stitches the ads directly into the video stream on the server before it's delivered to the viewer.

SSAI creates a single stream that combines both content and ads, resulting in smoother playback and increased resistance to ad blockers.

CSAI and SSAI Comparison

Technical Background:

CSAI (Client-Side Ad Insertion) inserts ads at the player level.

The video player detects ad cue points, requests ads from the ad server (via VAST/VMAP), and plays them separately from the main content. This means that ad tracking and interactivity are handled entirely by the client. CSAI’s approach requires SDK integration, platform-specific logic, and is vulnerable to ad blockers and playback interruptions.

SSAI (Server-Side Ad Insertion) stitches ads into the content stream on the server before delivery.

The player receives a single video stream with ads already embedded. The server handles ad selection, manifest manipulation (for HLS or DASH), and encoding if needed. It delivers a smoother playback experience and bypasses most ad blockers, but limits real-time tracking and client-side interactivity.

Ad Delivery in Monetization:

CSAI supports precise tracking (impressions, clicks, quartiles) and enables advanced monetization strategies like interactive ads, companion banners, frequency capping, and audience targeting. Therefore, it’s ideal for advertisers needing detailed reporting and real-time personalization, especially in browser and mobile app environments.

SSAI provides more stable ad delivery with fewer skipped ads, thanks to its resistance to ad blockers and reduced ad load failures. It maximizes ad fill on devices where SDK support is limited, such as smart TVs and set-top boxes. However, it relies on server-side tracking, which is less granular and often delayed or incomplete.

Overview

CSAI is essential for real-time ad decisioning, advanced tracking, and interactivity—especially for web and mobile apps. SSAI is the best for seamless playback, ad-block resistance, and broad device compatibility—especially for OTT, CTV, and FAST platforms.

Benefits of CSAI

Advanced Ad Tracking Tracks impressions, clicks, quartile completions, mute/unmute events, etc.

Real-Time Personalization Allows for user-specific targeting and ad selection during playback.

Dynamic Ad Logic Supports frequency capping, sequential ads, companion banners, and skippable ads.

Easier Server Setup The server only needs to deliver content; the client manages ads.

Flexible Monetization Works well for both on-demand and live content where precise targeting is key.

Choose CSAI…

• When fine-grained ad analytics are critical (e.g., advertisers need proof of engagement)
• When content is played in environments where ad blockers are not a concern
• For platforms that already support VAST, VMAP, and VPAID
• In use cases where ad interactivity (skip, click, CTA overlays) is required

Limitations of CSAI

Regardless of its ability to deliver a personalized experience, CSAI has drawbacks both for the content provider and the end-user.

1. Ad Blocker Vulnerability: Ad requests and playback are visible to blockers, leading to skipped ads.

2. Disrupted Playback: Switching between content and ad streams (from one video player to another) can cause buffering or black screens.

3. Device Fragmentation: Requires platform-specific SDKs or code (e.g., web, iOS, Android, Roku).

4. Complex Frontend Integration: Developers must manage ad logic, error handling, and UI consistency to ensure a seamless user experience.

5. Lower Fill Rates on Some Platforms: If players fail to load ads correctly, impressions may be lost.

CSAI in Modern OTT Services

Despite the fact that SSAI takes the dominance, CSAI continues to play an important role for modern OTT platforms, especially in environments where real-time ad decisioning, detailed analytics, and user interactivity are critical.

In web-based and mobile OTT apps, CSAI enables the video player to dynamically request and render ads during playback.

It supports advanced features such as frequency capping, sequential ad logic, interactive creatives (via VPAID), and real-time bidding (RTB). This makes CSAI ideal for personalized ad experiences based on viewer behavior, location, and device type.

However, CSAI also faces limitations in OTT environments where device fragmentation is high (e.g., smart TVs, set-top boxes). Each device may require different SDKs and custom integrations, and ad blockers can interfere with client-side ad requests, reducing fill rates.

To overcome these issues, many modern OTT services adopt hybrid models (server-guided ad insertion)—using CSAI for web and mobile, and SSAI for connected TV and FAST channels—combining the strengths of both methods to optimize monetization and playback quality across platforms.