An introduction to server-side ad insertion: how it works and how it can be used with mesh network delivery

Lumen Application Delivery Team
Lumen Engineering Blog
6 min readJan 27, 2022

Advertising is crucial to businesses and the video industry is no exception. For broadcasters and content publishers, targeting each individual with accurate and personalized advertising has been a dream for years. Fortunately, OTT media has opened up new doors towards service — and ad — customization.

At least, that is, if it is not stopped by an ad-blocker. Ad blocking has been a thorn in the side of content providers trying to monetize OTT video content: whereas providers are getting better at targeting viewers, those same users are getting better at avoiding ads. Today, more than 42%[i] of internet users globally use an ad-blocker. Yet, broadcasters and content publishers need monetization to be able to deliver sought-after content to users.

As part of our mission to help broadcasters deliver video more effectively and scale profitably, we at Lumen have worked to fully support client-side, dynamic and server-side ad-insertion workflows in our delivery product suite.

This article will delve into server-side ad insertion, a not-so-new technology that has taken center stage for its capacity to balance personalized viewing experience with predictable ad revenue. We will talk about how it works, along with the advantages and challenges it involves. We will also address how peer-to-peer technologies work with server-side ad insertion.

What is SSAI?

Server-side ad insertion (SSAI), also referred to as “ad stitching” is an advertising solution based on combining video content and ads into the same stream at the server level. A unique manifest and single stream arrive at the consumer device, therefore mitigating the threat of ad blocking and offering a TV-like experience to users. However, unlike classic television, SSAI enables providers to stitch targeted ads into a stream based on the individual user watching the content (in which case it is often referred to as DAI, “dynamic ad insertion”). Because of its ability to circumvent ad blockers and deliver personalized ads, it is estimated that 45% of OTT advertisements[ii] today are served using SSAI.

How does it work?

After encoding and packaging the video, file chunks are described by a streaming manifest (order of chunks, size, etc.). Without server-side ad insertion, every user gets the same manifest and content. But in the SSAI model, the call to the ad server is made upstream of the video being delivered to the user. This involves modifying the original manifest and inserting video file chunks of the ads served to each specific viewer.

Whether from a live ingest or an on-demand ingest, the video content includes ad break markers — often (but not always) based on the SCTE-35 standard (Digital Program Insertion Cueing Message for Cable) that indicates the start and duration of the ad break. These ad triggers allow the packager to indicate where ads should appear in the stream and to forward this information to the manifest.

For live television broadcasting, the ad markers are placed at the beginning and end of “official” ad breaks. When dealing with VOD content, the way ads are inserted is more flexible: the beginning of the ad is fixed but the duration of the ad break can depend on the ad sequence that will be shown to each specific viewer.

Either way, when the ad stitching server detects an ad marker in the original manifest an ad request is sent to the ad decision server. Then the original manifest is modified and ad file chunks are inserted in the stream. This stream is sent to the player, resulting in what we call ad stitching, or SSAI.

What are the pros and cons of SSAI?

Because ads cannot be identified as coming from an ad-serving URL, SSAI is more resilient to ad blockers. Server-side ad stitching can also avoid some of the quality pitfalls seen with client-side ad insertion, including black screens and buffering when the main content stops and the ad loads. On the broadcaster side, it can also simplify one’s workflow if serving to a variety of devices, especially for those such as smart TVs in which custom client-side ad-serving and measurement development can be cumbersome.

However, the complexity is not necessarily eliminated, but simply shifted upstream. With live content, the length of time to be filled with an ad is fixed and the same for all viewers, which must be taken into account by the ad server. Similarly, ads may not originally be encoded in the same resolutions or have the same frame rate as the original video stream, meaning they more often than not must be transcoded into the right ABR formats.

Today, SSAI vendors across the board handle these classic complexities. However, SSAI does not entirely remove the need for client-side development. First, the player must be able to handle this combined ad and content manifest; in practice this means reading MPEG-DASH streams with multiple periods or discontinuity tags if serving HLS. Players must also be able to correctly interpret ad markers, a process which is not necessarily standardized or native across all end-user platforms. Moreover, broadcasters may want to disable certain user interface components such as seeking during ad breaks or may want to implement client-side QoS measurements for ad breaks, both of which may require specific development on the player side.

Lastly, SSAI also has implications for other parts of broadcasters’ video workflows. For example, if using DRM, they will need ad support for both HLS and DASH and a DRM provider that supports multiple DRM systems. If using a multi-CDN setup, server-side ad serving can also complexify deployment.

Despite the challenges involved in using SSAI, this solution is seen as key to ensuring sustainable ad revenue. SSAI vendors are developing more and more sophisticated solutions that handle more types of use cases, and conversations have begun around standardization of ad measurement and markers.

What about compatibility with peer-to-peer solutions?

As server-side ad insertion becomes more and more important to broadcasters across the world, Lumen has worked to help ensure that its content delivery solutions are compatible with SSAI — particularly our client-side peer-to-peer solution.

Our Mesh Delivery technology works by determining the best source for the content on a segment-by segment basis. We have a complete view of the manifest and can determine which segments correspond to ads and which ones correspond to the main video content and can handle each accordingly.

One of the most common questions we get is how we handle ads that differ from one user to the next. Working directly at the manifest level allows us to identify each video segment as unique, correctly sourcing the content from the CDN or the right mesh network of peers. For ad segments, we can either suspend peer-to-peer delivery for the duration of the ad or we can do peer-to-peer delivery on identical ads, depending on the use case.

While some customization may be necessary depending on a specific case, we have worked with providers such as Amazon, Brightcove and Yospace to make sure our products work well together.

If you would like to try Lumen peer-to-peer delivery on your SSAI streams, contact us below to get started with a free trial*.

*Offer limited to configurations, compatible systems and usage limitations including maximum data volumes set out by Lumen. Offer available for a limited time to qualifying business customers for new service. Service and offer may not be available everywhere. Lumen may change, cancel or substitute offers and services or vary them by service area at its sole discretion, without notice. Offer may not be combined with other offers. Credit approval and deposit may be required. Additional restrictions, terms and conditions may apply.

This content is provided for informational purposes only and may require additional research and substantiation by the end user. In addition, the information is provided “as is” without any warranty or condition of any kind, either express or implied. Use of this information is at the end user’s own risk. Lumen does not warrant that the information will meet the end user’s requirements or that the implementation or usage of this information will result in the desired outcome of the end user. This document represents Lumen’s products and offerings as of the date of issue. Services not available everywhere. Business customers only. Lumen may change or cancel products and services or substitute similar products and services at its sole discretion without notice. ©2022 Lumen. All Rights Reserved.

[i] https://www.hootsuite.com/pages/digital-trends-2021–2021 Report — p74

[ii] https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Report-Streaming-Monetization-in-2020-140860.aspx

--

--