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. Based on the data each user provides, the right ad can be shown at the right time.
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, 35 to 40% 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, Streamroot has worked to support client-side, dynamic and server-side ad-insertion workflows. 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 38% of OTT advertisements 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 extremely 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, as Realeyes CEO David Hassoun recently reminded us.
Despite the complexity involved in using SSAI, this solution is seen as key to guaranteeing sustainable ad revenue and is therefore gaining traction. SSAI vendors are developing more and more sophisticated solutions that handle all 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, Streamroot has worked to ensure that its solutions are compatible with SSAI.
Streamroot’s peer-to-peer CDN technologies work by determining the best possible 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.
Once 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 Streamroot 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 your use case.
While some customization may be necessary depending on your specific case, we are happy to have worked with providers such as Amazon, Verizon, Brightcove and Yospace to make sure our products work well together.
Non-exhaustive list of providers for which Streamroot offers broad or partial SSAI support.
If you would like to try Streamroot peer-to-peer delivery on your SSAI streams, contact us below to get started with a free trial.