Difference Between CSAI and SSAI (Client-Side Ad Insertion vs. Server-Side Ad Insertion)

Advertising-based monetization is a popular way for content providers to monetize their content and drive their online video revenues. Technically, there are two important ways of inserting ads into videos – CSAI (Client-Side Ad Insertion) and SSAI (Server-Side Ad Insertion).

CSAI works by making calls from the video player to an ad server that responds with the ad. On the other hand, SSAI works by inserting (or stitching) the ad media directly into the video stream, avoiding the need for making calls to a server to receive ads.

In this tutorial, let us look at how CSAI and SSAI work, the main differences, and each’s pros and cons.

Let’s go!

---

What is CSAI: Client-Side Ad Insertion

CSAI (Client-Side Ad Insertion) is the method of delivering ads to clients (desktop, mobile, CTVs, gaming consoles, etc.) where the client (video player) requests the ad server for an ad when it reaches ad-markers in the stream or in the manifest (HLS/DASH).

After receiving the client’s ad-request, the ad server returns an ad based on data collected from the client and other information (campaigns, preferences, etc.).

The video player then pauses the video, plays the ad (or group of ads), and then resumes video playback (if any). It is also the responsibility of the client to report on the ad metrics (playback, quartiles, interactives, etc.)

---

How does CSAI (Client-Side Ad Insertion) Work?

In this section, let’s take a look at how CSAI (Client-Side Ad Insertion) works. It is easily understood from the schematic below from the IAB’s VAST 4.2 specification.

Here’s how CSAI works. When the user presses play,

1. The player downloads the manifest from the CDN and begins the video playback.
2. In the case of a pre-roll ad, the ad begins to playback before the video.
3. When the video player reaches an ad-marker, it pauses the video playback and makes an API call to the ad server requesting an ad for playback.
4. Typically, the ad server will respond with a VAST XML (or VMAP, VPAID, etc.) containing information about the ad, the ad’s media, and tracking information, etc. To learn more about VAST tags, click here, and click here for the VPAID tutorial).
5. The video player uses the information received from the ad server and plays back the ad. After the ad playback, the video player continues playing the video stream.
6. Streaming platforms usually embed their video players with SDKs provided by 1st or 3rd party ad verification services. These SDKs track the position of the ad playback, completion rates, errors, etc., and report back to servers periodically with this information.

As you can see, the heavy-lifting for CSAI is at the client-side and this architecture comes with its own set of advantages and disadvantages. We’ll take a look at them when we discuss the pros/cons of SSAI and CSAI.

For now, let’s move on to SSAI and understand how it works.

---

What is SSAI: Server-Side Ad Insertion

SSAI (a.k.a Dynamic Ad Insertion or DAI) is a way of stitching an ad directly into the video that is being streamed – at the server and not the client. It is fundamentally different from how CSAI works (CSAI relies on the client doing the heavy-lifting).

SSAI has its advantages and disadvantages that we shall see in the next couple of sections.

The primary advantage of SSAI is that since the client is no longer making any server calls, it is hard for ad blocking software to block ads inserted using SSAI.

However, SSAI does have a more complicated workflow and it is hard to provide the level of personalization and interactivity as CSAI.

Let’s take a look at how SSAI works to understand more.

---

How does SSAI (Server-Side Ad Insertion) Work?

Let’s look at how SSAI (Server Side Ad Insertion) works. Here is a schematic from the IAB’s VAST 4.2 specification.

Before that, lets take a look at ad markers which are critical to the functioning of either CSAI or SSAI.

1. Before a video (or live transmission) is sent to the transcoders, the stream is decorated with baseband markers called SCTE-104 markers.
2. When the encoder compresses the video, it translates the SCTE-104 markers into SCTE-35 markers that are carried with the compressed bitstream. These markers indicate the position of ad breaks (apart from other events) in video streams.
3. The video is then packaged into HLS/DASH for ABR streaming, and the manifest locations are made known to the CMS so that the player can access them at the time of playback. The manifests also contain information about the ads that need to be played back (the position, URIs, etc.).

Now, let’s take a look at what happens when the user presses play on his device.

1. When the user presses “play” on his device, the video player will get the HLS or DASH manifest/playlist from the ad-insertion service that would have manipulated the original manifest after decorating it with ad information.
2. When the player asks for the manifest, it usually provides some information about itself (i.e., the viewer’s location, subscription-levels, etc.) to enable personalized ad-delivery.
   • Players generally provide the “X-Device-User-Agent” and “X-Device-IP” HTTP headers, as per the IAB VAST guidelines.
   • Additional data can be provided if the player is set up to do so by the SSAI vendor.
3. When the ad-insertion service is informed that an ad-marker is reached or is coming up, it contacts the Ad Decisioning server, whose job is to supply the ad for insertion.
4. The Ad Decisioning Server uses various bits of information such as the data sent from the player at the start of the playback session, ad campaigns, etc., to get an ad out of the inventory and pass it on to the Ad Insertion Server.
5. The Ad Insertion Server transcodes the ad to match the video’s bitrate ladder, packages the ad, and produces a manifest for the ad, and stitches the ad’s manifest into the video’s manifest.
6. When the player gets this refreshed manifest, it seamlessly delivers the ad as if it were delivering any other video!
7. After the ad completes, the video player continues playing the content without any interruptions or breaks.
8. Apart from this, the player can be modified to report on the ad playback to ad-tracking services. i.e., client-side reporting for server-side ad insertion.

I hope by now you’ve understood how both CSAI and SSAI work. Obviously, they have their own advantages and disadvantages. In the next section, let’s take a look at these in detail.

---

Differences between CSAI and SSAI : Pros and Cons

After understanding how CSAI and SSAI work, let’s take a look at the big differences between each of these approaches and the pros and cons as well.

Pros of CSAI

1. CSAI provides a lot of options for dynamic, rich-media ad experiences using VPAID (deprecated) and SIMID. Publishers and Advertisers can create rich experiences (like surveys, click-throughs, overlays, etc.) using traditional client-side ad serving technologies.
2. Rich tracking and metrics: It is quite easy to set up very detailed tracking in the case of CSAI. Using the VAST XML, players can report on the quartiles of completion, clicks, click-throughs, etc. providing a lot of data for ad-tracking services.
3. Highly-personalized ads: using a plethora of data sources and information, highly personalized ads can be served using CSAI technology.

Cons of CSAI

1. Latency: the life of CSAI starts with the player requesting an ad-server for an ad and then waiting for that ad to be delivered. This inherently induces latency and can frustrate the viewer.
2. Buffering: inherently, the ad is served from a different origin than the video in the CSAI paradigm. If the ad-server is not well-tuned and the video player does not request the correct bitstream (if the ad was transcoded into multiple variants), then the ad can start buffering which will surely frustrate the end-user.
3. Ad Blockers: it is common to see ad-blocking technology in browsers preventing ad playback causing a loss of revenue for the publishers and advertisers. The player has to make explicit API calls to ad servers, pause video playback, and start ad playback. Using this information, ad blocking technology can easily block ad playback.
4. Heavy on the client: Because the client has to treat an ad differently from a video, the work of the client increases and so does the size of its code-base. If you add tracking code to such clients, then the size increases even more. Furthermore, ad tech vendors have to also support a wide range of clients (HTML5, Android, iOS, Roku, gaming consoles, etc.) to ensure that their customers can get revenue from all their platforms.
5. Variable video quality between content and ads.: since the ad inventory is not necessarily matched with the content in terms of bitrates, and resolutions, it is possible that the quality of the ad and the video can differ causing a poor user experience.

Pros of SSAI

1. Broadcast-like ad experience: SSAI claims to provide a “broadcast-like experience” for consumers by stitching the ad directly into the video stream. By avoiding API calls to ad-servers, there is a reduction in the latency before the ad starts and continuity in the video quality between the ad and content. SSAI can also adapt to varying bandwidth conditions and provide a smooth playback experience.
2. Protection against adblocking: With SSAI, the ads are inserted at the server-side and not at the client-side. This makes it difficult for ad-blockers to interrupt the ad-insertion process.
3. Easier on the client: Since SSAI takes care of ad-insertion at the server and stitches the ad into the content, it is easier to support SSAI in devices where it can be hard to insert code. However, this statement should be taken with a grain of salt, because you are still restricted by the platform’s native players and what you can use there. You’ll have to pick and choose your streaming protocol (HLS, MPEG-DASH, MSS) and the DRM (FairPlay, PlayReady, or Widevine) to deliver to SmartTVs, Gaming Consoles, etc. Here is an interesting fact-sheet from NorginMedia that talks about the support matrices across a large range of platforms.

Cons of SSAI

1. SSAI ad-measurement is problematic: There is a growing consensus that it is not enough to take the word of an SSAI vendor that an ad was stitched into the stream – there needs to be independent, client-side verification of this. But, of late, there have been efforts to provide SDKs and clients designed to detect their SSAI ads.
2. Spoofing in SSAI: As discussed before, the end-devices usually send the “X-Device-User-Agent” and “X-Device-IP” HTTP headers to the ad-servers as per the IAB VAST guidelines. Anyone can set up servers and spoof this information to mimic a large set of end-devices requesting ads. This is the basis of a widespread fraud where publishers were made to believe that their ads were requested and played millions of times on CTVs, but the ad requests were just from dummy servers. Read more about this here.
3. A lower degree of personalization compared to CSAI: If an SSAI vendor wants to provide per-customer personalized manifests for a publisher with a large user-base, then it is a massive drain on their resources because the SSAI workflow includes transcoding, packaging, and manifest manipulation.
4. Can require custom work on players: SSAI vendors typically need a way to disable any playback controls when an SSAI ad is being displayed to the user. Without this, a user can easily skip past an ad (as is possible with typical video content). Conversely, if the publisher wants an option to skip ads, then a mechanism must be built to tell the player that it is playing an ad and not the video.
5. Manifest caching problems: because the personalization is done on the server-side, the per-user manifests cannot be cached and shared amongst all the users. This is not an efficient use of caching services!
6. Complex backend: SSAI, as we know, requires transcoders, packagers, and manifest manipulation services, in addition to ad+video delivery infrastructure, making them complex to design and maintain. The further difficulty is that all these components need to be independently scalable to different degrees to account for service surges.
7. Inability to serve rich-media ads: The difficulty in serving VPAID using SSAI can prevent publishers from moving over to SSAI as their only solution. Even if it can be achieved, it further complicates the client-side implementation, negating some of the benefits of going to SSAI. However, it is reported that SIMID is supported by SSAI – so let’s see when what happens when SIMID is adopted widely.

---

So, should I choose CSAI or SSAI?

Both CSAI and SSAI have their pros and cons and have their place in ad-serving technology for OTT. There is no argument about that!

However, if one was worried about sticking to CSAI or moving to SSAI, I feel the first thing they should do is engage with an ad-tracking service (independent, 3rd party) and get hold of fundamental data on how their ads are performing –

• Is there a lot of latency, buffering?
• What are the fill-rates?
• Where are most of the errors coming from?
• What is the cost of maintaining CSAI on all the devices we support?
• What are the completion-rates of the ads? Do people continue watching the content after the ad?
• Are my marketing campaigns dependent on interactivity?
• And so on.

Getting concrete, unbiased, raw data will help a publisher make the right decision whether to use CSAI or SSAI. Such data-driven decisions will positively impact revenue and, most importantly, the user experience!