CTV ad servers and SSAI: how ads are delivered to streaming TV

What is an ad server?

An ad server is the system that receives the result of an ad auction and actually delivers the ad creative to the viewer. It sits between the SSP (which ran the auction) and the viewer's device (which displays the ad). The ad server's job is to:

• Receive the winning bid and the associated creative from the DSP
• Deliver the creative to the viewer's screen at the right moment
• Fire tracking events (impression, quartile completions, completion) at the correct times
• Report delivery metrics back to both the publisher and the advertiser

There are two types of ad server relevant to CTV: publisher-side ad servers (which manage the publisher's inventory and delivery) and advertiser-side campaign ad servers (which track the advertiser's campaign performance independently).

Publisher ad servers in India CTV

Google Ad Manager (GAM) is the dominant publisher ad server in India CTV. Most streaming platforms in India use GAM to manage their ad inventory, run their programmatic auctions (via GAM's built-in SSP functionality), and route winning ads to delivery. JioCinema and several other platforms build their ad serving infrastructure on GAM, giving Google structural visibility into India's CTV ad ecosystem.

FreeWheel (owned by Comcast) is a video-specialist ad server used by some premium publishers who want a platform built specifically for long-form video and streaming, rather than a general-purpose ad serving system like GAM.

Advertiser campaign ad servers

On the advertiser side, campaign ad servers like Campaign Manager 360 (Google's CM360) track impressions, clicks, video completion events, and conversions across all placements in a campaign. They provide the advertiser with an independent measurement record — separate from what the publisher and DSP report — which is used for reconciliation and cross-publisher campaign management.

Client-side ad insertion (CSAI)

Client-side ad insertion (CSAI) is the original method of delivering ads to video players. In CSAI, the video player on the viewer's device makes the ad request and plays the ad directly:

1. The video player detects that an ad break is coming
2. The player sends an ad request to the publisher's ad server
3. The ad server returns a VAST response pointing to the winning ad creative
4. The player fetches the ad creative from the DSP's or publisher's CDN
5. The player pauses content and plays the ad
6. After the ad, the player resumes content

Advantages of CSAI

• Third-party measurement: Because the ad request is made from the viewer's device, third-party verification vendors (DoubleVerify, IAS) can fire their own tracking pixels alongside the VAST events. This enables independent brand safety, viewability, and invalid traffic measurement.
• Standard VAST compatibility: CSAI follows the standard VAST specification straightforwardly. Ad tech tools that handle VAST work out of the box with CSAI.
• Flexibility: Publishers can swap ad creative in real time at the device level. Ad serving logic (frequency capping, competitive separation) can be enforced on the device.

Disadvantages of CSAI for CTV

• Buffering: When the player stops content to fetch the ad from a different CDN, viewers often see a blank screen or buffering spinner. On connected TVs, this is a poor viewing experience compared to the seamless linear TV model viewers are used to.
• Ad blocking: Client-side requests can be intercepted by ad blockers or modified DNS settings. On CTV devices this is less common than on desktops, but it is possible on some platforms (e.g., Pi-hole setups on home networks).
• Complexity: Managing ad delivery on heterogeneous CTV device types (Android TV, Tizen, webOS, Roku) with different video player implementations is harder with CSAI than with SSAI, which abstracts device differences at the server level.

Server-side ad insertion (SSAI)

Server-side ad insertion (SSAI) solves the buffering and blocking problems of CSAI by moving ad insertion from the viewer's device to a server in the cloud. With SSAI, the ad is stitched into the video stream before it ever reaches the viewer's device.

How SSAI works

1. The viewer requests the stream: When a viewer opens a streaming app and starts watching, they request a video stream from the publisher's CDN.
2. The SSAI server intercepts: Instead of receiving the content directly, the request is routed through the publisher's SSAI server (a manifest manipulation server).
3. The ad is resolved: The SSAI server calls the publisher's ad server, retrieves the winning ad creative from the DSP, and stitches it into the video stream at the correct break point. The ad is transcoded to match the bitrate and resolution of the content stream.
4. A single stream is delivered: The viewer's device receives one continuous video stream containing both content and ads, indistinguishable at the technical level. There is no separate ad request from the device and no buffering between content and ad.
5. Tracking fires server-side: The SSAI server fires VAST tracking pixels (impression, quartile events, completion) on behalf of the viewer's device as the ad plays.

Advantages of SSAI for CTV

• Seamless viewing experience: No buffering, no blank screens between content and ad. The ad plays as smoothly as the content. This is the linear TV experience that CTV viewers expect.
• Ad blocking resistance: Because the ad is part of the main stream, there is no separate ad request to block. Device-level ad blocking does not work against SSAI.
• Device abstraction: The SSAI server handles ad insertion logic once, in the cloud, regardless of what type of CTV device the viewer is using. Publishers do not need to implement different CSAI logic for every device SDK.
• Competitive separation: The SSAI server can enforce rules like not showing two competing brands back-to-back across a full ad pod, which is difficult to enforce in a CSAI environment where each impression is auctioned independently.

Disadvantages of SSAI

• Third-party measurement limitations: Because the ad is delivered as part of the main stream, third-party pixels cannot be fired from the viewer's device. Verification vendors must either integrate with the SSAI server directly or rely on server-to-server tracking. Not all SSAI implementations support all third-party vendors.
• Infrastructure cost: Running an SSAI server at scale requires significant infrastructure investment. It is not viable for small publishers.
• Debugging complexity: When an ad does not play correctly in an SSAI environment, diagnosing the problem is harder than in CSAI because the issue could be at the content manifest layer, the SSAI stitching layer, the ad server, or the CDN.

VAST: the standard connecting everything

VAST (Video Ad Serving Template) is the IAB Tech Lab standard that defines how video ads are requested, delivered, and tracked. Both CSAI and SSAI use VAST — it is the language that ad servers speak to DSPs and creative stores.

A VAST response is an XML document that contains:

• A pointer to the video creative file (the actual MP4 or HLS stream of the ad)
• Tracking URLs for impression, quartile events (25%, 50%, 75%, 100% completion), and click
• Skip offset (if the ad is skippable and after how many seconds)
• Companion ad specifications (if there are accompanying display banners)

VAST wrappers are used when the ad server calls a secondary ad server before returning the creative — common in programmatic where the SSP calls the DSP's ad server, which returns a VAST wrapper pointing to a further VAST response. Deeply nested wrappers (wrapper chains) are a source of latency and tracking discrepancies in CTV campaigns.

The India context: why SSAI dominates and what it means for buyers

JioCinema and Disney+ Hotstar — the two largest India CTV publishers by viewing volume — both use SSAI for their premium inventory. This has direct consequences for advertisers:

• Limited third-party verification: Standard DoubleVerify or IAS tags cannot fire directly from the viewer's device on JioCinema or Hotstar because the ad is delivered server-side. Measurement relies on platform-reported data or SSAI-compatible measurement integrations that the publisher must explicitly enable.
• Impression discrepancies: DSP-counted impressions and platform-counted impressions will not match exactly. In India CTV, discrepancies of 5–15% between DSP and platform counts are standard and expected. Buyers need to understand which count to use as the billing source and build this into reconciliation processes.
• Viewability is not independently measurable: Standard viewability measurement (confirming the ad was visible on screen for a minimum duration) requires a tag running on the device. In SSAI environments, this is not possible without publisher cooperation. Viewability metrics for India CTV campaigns are generally platform-reported, not independently verified.
• Fewer ad format risks: Because JioCinema and Hotstar use SSAI, ad buffering is minimal and the viewing experience is high-quality. The advertiser benefit is that CTV ads in India deliver a genuinely TV-like experience to viewers.