CSAI vs SSAI: Get the Best Bang For Your Buck

When considering a monetisation strategy, it makes sense to carefully weigh your options. You may already have heard about Client-Side and Server-Side Ad Insertion. But what are they, and where does each strategy shine?

Going Big Screen_ Bringing Video to LG WebOS (2)


In a CSAI-flow, advertisements are managed and added on the end-user’s device. From a delivery point-of-view, content and ads are separated; the player plays content and advertisements independent of each other. The player will switch between the two as needed. Client-Side Ad Insertion is specified via the IAB (Interactive Advertising Bureau) standards:

  • VAST (ad metadata)
  • VMAP (ad timing)
  • VPAID/SIMID (interactive ads) and
  • OMID (viewability measurements)

A compliant player supports all ad solutions that adhere to these standards, making it easier to switch to another provider. CSAI-systems with a different flow can then be added on an individual basis. Alternative implementations, for instance Google IMA, can also be added in parallel.

CSAI vs SSAI: What are the differences?

Figure 1 - Client-Side Ad Insertion Diagram


In an SSAI-flow, advertisements are directly stitched to the streaming manifest on the server side at the last moment. The content and advertisements are closer related to each other, allowing smoother playback and transitions. This way of working is comparable with traditional linear television. The main difference between broadcast advertising and SSAI is that the latter allows advertisements to be targeted towards individual end-users.


Figure 2 - Server-Side Ad Insertion Diagram

Server-Side Ad Insertion is only partly standardised. SCTE-35 markers are a popular technique to signal the encoder and packager where ads are allowed to be inserted. It was, however, never intended to be used towards streaming clients. As a result, SCTE-35 is often only used to inform SSAI providers where ads should be placed. How they place those ads, and how they provide the relevant metadata for tracking ad progress, is not standardised. This metadata is needed to build a CSAI-like experience: showing a click-through, giving an indication about duration and current time. Some common strategies include: 

  • Fetching metadata from the SSAI provider’s backend 
  • Adding timed cues via ID3/EMSG 
  • Parsing custom tags from the streaming manifest 
  • Integrating with a proprietary library 

A video-player pre-integrated with multiple SSAI vendors improves the inter operability between all of them.

It depends

Generally speaking, SSAI is a bit more expensive and complex to set-up and use compared to CSAI. This is due to the tighter integration between content and advertisements and the increased complexity overall. These additional costs have to be subtracted from the Cost Per Mille (CPM) pay-out. The higher cost of SSAI, however, can be easily countered by the fact that it provides a much higher fill-rate.

"Ad blockers have primarily been optimised to block CSAI ads, but are not sophisticated enough to detect SSAI ads and block them."

CSAI ads are not always able to play due to ad blockers, errors happening on the client side, time outs for loading an ad, errors in VPAID ads et cetera. In practice, ad providers typically only promise a fill-rate ranging between 25 and 55%. In the case of SSAI, ad-blockers may block the integration libraries or the origin of the ad provider, but in that case the end-user would not be able to watch the content in the first place.

In conclusion, SSAI may be more expensive than CSAI, but also
results in much more ad impressions.
Ad blockers may be less
effective against this type of advertising.


Both technologies have both their strengths and challenges. Client-Side Ad Insertion is relatively easy to set up, but comes with challenges of its own.

Transitioning between content and ads

Switching between content and ads is relatively easy for CSAI ads, because most platforms allow the use of multiple decoders at the same time. A player could then load the content in one video element and preload the advertisement in another one.


Figure 3 - CSAI without Ad Preloading


Figure 4 - CSAI with Ad Preloading

In practice, it is slightly more complicated. Real-world environments are complex and diverse. For instance, it is not possible to use two different decoders at the same time for platforms such as Tizen and webOS without halting the other one. On the iPhone's iOS, it is not possible to work with two video elements in full screen mode, because transitions between the two are visual to the user. In such a case, a virtual full screen (stretching just the browser size) may be the only option. Alternatively, the same video element can be reused to play content and ads. This comes with a little cost in delay, as it is possible to preload the advertisement. Using one video element is also useful because it allows Airplay sessions to pick up the CSAI ad as well. That being said, it is important to note that these are just some examples out of many others. 

SSAI ads are played like regular content, so they are less impacted by platform limitations. In practice, most SSAI providers do not reencode and re-timestamp the ads, which means the video decoder needs a reset in between. For HLS, this means a player needs to support discontinuities, while an MPEG-DASH player must support multi-period manifests.

Playing video advertisements during live-streams

In video-on-demand use-cases, it is easy to indicate when a CSAI video advertisement should play. For live streams, it is slightly more complicated for a variety of reasons: 

  1. VMAP has been mainly designed with VoD use-cases in mind, leaving much room for interpretation with regards to signaling an ad opportunity in a live-stream. 

  2. It is unclear whether content missed by playing an ad should be skipped after resuming, or picked up at the same time. It is preferable to skip the missed content and stay at the live point of the stream, but this comes at the cost of missing a bit of content.
    SSAI vs CSAI visual-04
    Figure 5 - CSAI Linear Advertisement on Live Stream
  3. Main content is paused during ad playback, making it challenging to get timed metadata from the live stream while playing ads.
    For live-streams and CSAI, we recommend using banner advertisements as it does not interrupt the content. For live streams, it is a better choice to use SSAI overall, because it is easier to indicate when an ad should start and end using SCTE-35 markers. These markers can also be used for CSAI, but it is a less common practice.
Interactive advertisement

Interactive advertising allows direct engagement between the advertiser and the end-user, as it can deliver a more interesting, dynamic ad experience. 

Traditionally, CSAI has been stronger on this front, due to the VPAID specification. Up until 2019, there was no SSAI-counterpart for the popular CSAI-specification. With the release of VAST 4.2 and SIMID/OMID as the successors of VPAID, this shortcoming is now solved, as SIMID is compatible with Server-side ads. 

The old VPAID specification was designed around the premise that third party JavaScript-logic should take control over ad playback. The player would be able to control the ad via generic instructions such as play, pause, stop, would be able to read the status out and receive events for updates. The advertisement would implement its own playback and the player could only hope everything would run smoothly. If an unexpected crash occurred, the ad would be stalled. 

SIMID reverses the roles and puts the player back in charge of ad playback. The player will keep the SIMID-frame updated about the status of the advertisement (current time, duration…), so the interactive layer stays in sync with the ad. 

"The change in design through SIMID allows the player to reuse the same interactive layer for both CSAI and SSAI ads."

The key factor to look out for is adoption: SIMID is relatively young and still needs to find its place in the market. Google DFP already started supporting this specification via its Google IMA-library.

Canvas or WebAudio

APIs such as canvas and WebAudio are not always considered when using Client-Side Ad Insertion approach. This is partly due to vendor limitations. For instance, Google IMA, the most dominant framework, renders its own ads in an iframe. This makes it impossible to connect these APIs. 

These APis are, however, perfectly usable for Server-side Ad Insertion, except when DRM is used. This opens the way for new, creative applications. For instance, canvas can allow additional pixel manipulation to apply filters on the video, or WebAudio can normalise audio peaks, making it easier to keep the volume between content and ads consistent. 


Both Client-Side Ad Insertion and Server-Side Ad Insertion have their advantages and disadvantages. CSAI is generally easier to set-up, but comes with a generally lower fill-rate due to ad blockers and platform limitations.

EZDRM blog banner (11)

SSAI is a bit more complex to set up, and slightly more expensive, but it provides an overall smoother experience. If you like to know more about what might be the best solution for your project or use case, do not hesitate to reach out to one of our experts.

Any questions left? Contact our THEO experts.

Subscribe by email