← All posts

SSAI vs. CSAI: Which Is Better for SIMID Interactive Ads?

·

Every video ad in a stream gets there one of two ways. Either the viewer's player fetches the ad and plays it, or a server stitches the ad into the video before it reaches the player. These are client-side ad insertion (CSAI) and server-side ad insertion (SSAI), and the choice between them shapes almost everything about how an ad looks, plays and gets measured.

It also shapes what interactive ads can do. SIMID, the IAB Tech Lab standard for interactive video ads, works with both, but not in the same way. Here is how the two approaches compare, and which one is the better fit for SIMID.

Client-side ad insertion (CSAI)

With CSAI, the player does the work. When it reaches an ad break, it requests an ad from the ad server, receives a VAST response, picks a media file that suits the device, pauses the content, plays the ad and then switches back. It fires the tracking URLs itself as the ad plays.

Strengths:

  • The player knows everything about the ad. It has the full VAST response, including any interactive component, and it controls ad playback directly.
  • Measurement is straightforward. Impressions and quartiles are reported from the viewer's device, which is what industry measurement guidelines prefer.
  • Interactivity is natural. The player can load an interactive layer, pause the ad when the creative asks, and extend the ad while a viewer explores.

Weaknesses:

  • Visible seams. Switching from content to ad and back can mean buffering, a blank screen or a jump in quality.
  • Ad blockers. Because ad requests come from the device, they can be blocked.
  • Device dependence. Every device needs a capable player and ad SDK, which is hard across the long tail of smart TVs and streaming devices.

Server-side ad insertion (SSAI)

With SSAI, a stitching server does the work. It requests the ad, transcodes the ad's video to match the content's encoding, and splices it into the stream. The player receives one continuous stream and may not even know an ad is playing. We covered what it takes to serve ads this way in Why Serving Video Ads for SSAI Is Harder Than It Looks.

Strengths:

  • Seamless playback. Content and ads flow together like broadcast TV, without buffering at the break.
  • Resistant to ad blocking. The ad is part of the stream itself.
  • Works on almost any device. A device only has to play a video stream, which is why SSAI is so widely used in connected TV and live streaming.

Weaknesses:

  • Tracking is harder. The server often fires tracking on the viewer's behalf and must pass along device details to avoid looking like invalid traffic.
  • New creatives are delayed. Ads have to be transcoded before they can be stitched, so a creative's first requests are often skipped.
  • The player is out of the loop. Unless the stitching service tells it, the player does not know where ads start and end, or that an ad has an interactive component.

Where SIMID fits in

SIMID separates the ad's video from its interactive layer. The player always plays the media; the interactive creative runs in a sandboxed iframe on top and talks to the player through a defined set of messages. That separation is exactly what makes SIMID possible with SSAI, which VPAID never was: VPAID ads controlled their own video, and in a stitched stream there is no separate ad video to control.

But "possible" is not the same as "equal." The SIMID specification is candid about what changes in a stitched or live stream.

What SIMID can do with CSAI

With client-side insertion, a SIMID ad gets the full feature set:

  • The player has the interactive file from the VAST response and loads it in step with the ad.
  • The creative can ask the player to pause the ad while a viewer explores, and ask to extend the ad's duration.
  • Ads that depend on pausing can declare it with VAST's variableDuration="true" attribute, and the player knows whether it can honor that before it plays the ad.

What changes with SSAI

With server-side insertion, the ad's video is baked into a stream that keeps moving:

  • The player has to be told about the ad. The stitching service needs to signal where each ad starts and pass along the interactive file, so the player can load the creative at the right moment. The SIMID specification notes that in SSAI the player must compute the ad's timing from its position in the stream.
  • Pausing and extending may not be possible. In the specification's words, in SSAI and live streams "the player may not be able to pause the media, shorten ad, or extend user ad experience." The player signals this with variableDurationAllowed set to false, and the creative must not request a pause or a duration change. If a creative asks anyway, the player rejects it and the ad plays on uninterrupted.
  • Some ads cannot run at all. An ad marked variableDuration="true" is only playable where the player can pause it. If it cannot, the specification says the player must not render that ad.
  • Some devices are left out either way. SIMID needs a device that can show an HTML layer over video. Some TV sets and streaming boxes cannot, regardless of how the ad is inserted.

So which is better for SIMID?

CSAI gives SIMID the most room. The player has the ad, controls its playback and can say yes when a creative asks to pause or extend. Interactive experiences that let viewers browse for as long as they like work best here.

SSAI is where much of the audience is. Connected TV and live streaming rely heavily on server-side insertion, and SIMID is the interactive standard that can work there at all. The trade-off is that the experience has to fit inside the ad's fixed running time, and the player and stitching service have to cooperate to deliver it.

In practice, the right answer is not to pick one. It is to design interactive ads that work in both:

  1. Do not depend on pausing. Build the core experience so it delivers value within the ad's normal duration. Treat a pause or extension, where the player allows it, as a bonus rather than a requirement.
  2. Use variableDuration="true" only when it is essential, knowing it rules the ad out wherever the player cannot pause, including much of SSAI and live inventory.
  3. Make the video stand on its own. Some players and devices will show only the video, so it should work as a complete ad without the interactive layer.
  4. Carry the experience to the phone. A QR code on screen gives viewers a way to interact on any device and any insertion method, including the TVs that cannot run SIMID. We wrote about why in The Value of QR Codes.
  5. Test with the stitching providers you buy through, since how they pass interactive files and ad timing to the player varies.

That is the approach VideoStorm takes: interactive experiences that let viewers choose, explore and buy wherever the player allows it, and QR codes through ScanStorm and ForeCaster that bring the same experience to the viewer's phone wherever it does not.

Want interactive video ads that work across CSAI, SSAI and every screen in between? Get in touch.

← All posts