Search form

What is Server-Side Ad Insertion (SSAI)?

What is Server-Side Ad Insertion (SSAI)?

Introduction to Server-Side Ad Insertion in Streaming Video

For broadcasters and video content providers, an inherent tension exists between the need to deliver a premium viewing experience – complete with start-over and time-shifted TV functionality – and to monetize streaming video offerings and services. The challenge of monetizing over-the-top (OTT) video content will only continue to grow as viewership on connected devices increases.

To optimize streaming video revenue opportunities, advertisers are increasingly seeking ways to match the interests of individual consumers with ads, and deliver them in a non-disruptive way.

Ad personalization reduces the consumer desire to employ ad blockers, and creates a mutually beneficial streaming experience for video providers and audiences. Beyond the relevance of topical interests, ad personalization can also connect with individual viewers in ways that are emotionally relevant to them, sparking changes in thinking as well as in purchasing.

While the opportunities to capitalize on ad personalization and ad insertion grow, the question for broadcasters, pay TV operators, content programmers and all video providers is, what is the best way to meet the needs of the video business and the viewing audience?

The solution needs to balance monetization requirements with the ability to provide a high-quality viewing experience for subscribers – a balance that server-side ad insertion can consistently maintain.

What is Server-Side Ad Insertion?

Server-side ad insertion is a combination of manifest manipulation, ad server communication, and ad bitrate and resolution normalization, all of which happens on the server-side before presenting a manifest to clients. Server-side ad insertion may also be referred to as dynamic ad insertion, or ad stitching.

By whatever name it is known, server-side ad insertion is difficult to get right for numerous reasons:

  • Server-side ad insertion requires a highly scalable origination service
  • Personalized manifests are not cacheable
  • Reporting and custom player behavior requires clients to know an ad has been played
  • Different ad standards (VAST, MAP), ad servers, origin servers, and player environments complicate server-side ad insertion workflows

To cope with fluctuations in demand for just-in-time server-side ad insertion, a highly scalable architecture is required – particularly for broadcasters that must deal with the sharp peaks in demand that breaking news, sports events and popular TV series bring. Cloud-based video processing with a server-side ad insertion integration is one way broadcasters can scale to meet audience demand.

When events are underway, the number of concurrent viewers can vary greatly and unpredictably. For example, viewership for a closely played game may remain steady for much of the contest, then surge by hundreds of thousands of new viewers during the last few minutes.

The key to managing viewer variances is in encoding and packaging that can be virtualized for rapid deployment and hosted in a cloud infrastructure for quick auto-scaling.

Because dedicated single path hardware encoders and packagers lack flexibility, the practical solution is to spin up instances of cloud-based video processing as they are needed. The cloud is uniquely well suited to creating millions of individually tailored manifests of content and advertising for live-streamed events.

So Server-Side Ad Insertion is Complicated. What’s Wrong with Client-Side Ad Insertion?

While client-side ad insertion is a common solution for ad personalization and targeting, it has technological hurdles that can be difficult to overcome in certain situations, particularly, live broadcasts such as sports, events, and news:

  • Client-side ad insertion is subject to high network latency and shifts in video quality due to changes in codec, resolution and bitrate
  • There is no elegant solution capable of handling seamless live streaming
  • Requires code changes across multiple platforms and devices
  • As the use of ad-blocking software grows, ad fill rates on desktop and mobile web environments shrink

In addition to its technological limitations, client-side ad insertion can also have a noticeably negative effect on the viewer experience:

If you thought buffering made users angry, just see what happens when the page crashes after they sit through the pre-roll, forcing them to reload the page and watch the pre-roll again. Client-side advertising requires a lot of per-platform code, especially when the user is watching video through an app. This doesn’t just mean higher development costs for the one implementing the page or app; it also means a fragile playback experience for the user. A 100% server-side ad solution is far less complex to build and manage, and is also less likely to crash. “How Server-Side Ad Insertion is Making Online Ads More User-Friendly”
StreamingMedia.com

How Does Cloud-Based Ad Insertion Work?

The general processing flow for cloud-based ad insertion is as follows:

Server Side Ad Insertion Diagram

Server-Side Ad Insertion Infrastructure

  1. A player sends a request for live or video-on-demand (VOD) HLS content from the content distribution network (CDN). The CDN is configured to use ad insertion services as the origin for manifests, rather than the content origin. Each request includes parameters from the player about the viewer, so manifests are unique for that request.
  2. The ad insertion service pulls the fully formed template manifest from the content origin server. This manifest includes ad markers so that the ad insertion service knows where to perform an ad insertion or ad replacement.
  3. When an ad marker is seen, the ad insertion service sends a request to the ad decision server (ADS), including the player parameters from the content request and the duration of the ad break.
  4. The ADS provides a VAST or VMAP response that includes the ads to be played back, based on viewer information gathered from the parameters that the ad insertion service passed through, current ad campaigns, and ad tracking URLs to report ad playback to.
  5. The ad insertion service manipulates the manifest to include the URLs for the appropriate ads from the VAST or VMAP response.
  6. The ad insertion service provides the fully customized manifest to the requesting player via the CDN (the CDN cannot cache this response as it is unique to the player).
  7. As playback progresses, either the ad insertion service or the video player reports how much of an ad is played. Using server-side reporting, the service sends ad viewing reports to the ad tracking URL directly, with no input required from you.
  8. As the player requests ad segments throughout content playback, if the ad is not already transcoded in a format that matches the video content, the ad insertion service transcodes the ad at the time of the ad segment request. If an ad is not already transcoded, the service doesn't present it for playback at the first request.