Bypassing adblocking software with Server-Side Ad Insertion and increase ad revenues by up to 25%.
For the past five years, there’s been a massive improvement and growth pattern in online video advertising towards an encoding or server-side approach to inserting ads, also known as Server-Side Ad Insertion (SSAI) to bypass adblocking software. In contrast to the traditional client-side techniques, like VAST and VPAID, which stitch together the ad content and non-ad content on the client-side, server-side ad insertion intercalates ads on a CMS level. The benefit of applying SSAI is that the client receives a continuous stream arriving from a single source which creates a broadcast-like transition between ads and content.
The concept of inserting ads on the server-side is also aiming to improve video service monetization, as traditional ad-blocking software is no longer able to bypass playback of ad content. As of today, ad-blockers are used by about 27% of users and therefore have a significant negative impact on ad-driven businesses.
The disadvantages of Client-Side Ad Insertion
Monetizing content via client-side ad insertion (CSAI) is a common tactic in today’s online video streaming industry. There are a number of standards used including VAST 3.0, VPAID 2.0, IMA, VMAP, to name just a few. Depending on the level of interactivity required, one can choose the standard that fit’s the targeted use-case best. All the specifications listed above are well supported in Bitmovin’s Adaptive Streaming Player and are described in the related tutorial, setting up Ads with our player is easy to do.
Nowadays most commonly used standards share one major disadvantage: They can be detected and blocked by the client. Although ad providers have come a long way in skillfully disguising ad content, the ongoing race between them and the manufacturer of ad-blockers has given content publishers many sleepless nights. From their perspective, every unplayed ad corresponds to a potential loss of ad-driven revenue.
The use of ad-blocking software has grown steadily in recent times and it is no longer limited to a small number of “geeks”. More and more average internet users are adopting ad-blocking technology and this is a big threat to ad-driven businesses. The common strategy of detecting blocked ad content and asking consumers to whitelist certain sites relies on the goodwill of users and is far from a satisfactory solution.
Besides the blocking issue, there are other shortcomings when ads are ‘stitched’ to the content at the client-side. Changing the source from the content videos to ad clips leads in most cases to resolution changes and a loss of the playback buffer and therefore a decrease in quality of experience. Although the named disadvantages can be overcome by using efficient pre-buffering strategies, at least to a certain extent, latency-related problems, due to additional calls to (multiple) ad routers and then the ad asset itself, will still be present.
Also from a development point of view, CSAI increases effort and expenses. It is not uncommon to make use of ad SDKs, like Google’s IMA SDK, which has to be integrated and tested on every target platform. Achieving common functionalities across all devices can be costly and managing the different versions across platforms increases complexity.
In summary, it can be said, that CSAI approaches come with major disadvantages, which makes the Server-Side alternative even more attractive.
Server-Side Ad Insertion
The general concept behind SSAI, as already indicated by the name, is stitching together the content and ad clips on the server side during the encoding phase. This is in contrast to CSAI, where the client application handles the ad insertion. As the ads are part of the content video stream itself and proxied from the same server/CDN, there is no obvious indication to the client that the video content has been replaced by an ad. For traditional ad-blocking software, it will be impossible to detect and prevent playback of the ad clips.
As ads and content video are one continuous stream, latency problems and rough transitions between ads and content will be avoided. From a developer’s perspective (speaking only about the playout application), handling advertising scenarios will be much easier, as only ad tracking has to be covered by the client. Of course, there are many optimizations available to further enhance the viewer’s experience, such as disabling seeking or trick modes. In general, SSAI tends to move complexity from the client to the server/encoding side. Clearly, this step introduces new challenges for encoding systems, as addressed later on. (Download the Server-Side Ad Insertion Datasheet)
How are Ads Inserted Into the Content?
As stated in SSAI scenarios, advertisement clips are stitched to the content video itself. The below figure shows an overview of the involved components and their interaction.
The content video is fed into the encoder either from a content store or a live ingest. The ad break markers—e.g., inband SCTE-35 triggers or programmatically inserted triggers via the API—are recognized by the encoder, and the information is forwarded to the manifest service. The encoded segments are then written to storage or to a CDN directly, and stored alongside the ad content.
When a client starts a streaming session, the manifest file is requested from the content storage or CDN. The request contains personalized custom data about the viewer and is forwarded to the manifest service. Based on this information, gathered from cross-site tracking and other personalization techniques, the manifest service creates the appropriate playlist (including ad content) for the specific streaming session.
Once playback starts and an ad break is reached, the ad content is presented to the viewer in a smooth and transition-free manner. Using signaling mechanisms, like ID3 tags in HLS, or EMSG data and MPD Events in case of MPEG-DASH, ad-related reports (e.g., ad started information, 10% played, etc.) will be sent to tracking servers from the player.
Bitmovin’s SSAI Solution
Bitmovin enables SSAI, using Bitmovin’s Cloud Encoding System and Bitmovin’s Adaptive Streaming Player in combination with third-party ad providers, in an end-to-end scenario. For video delivery, both MPEG-DASH and HLS, as well as progressive download, can be used, as shown in the below demonstration. The content video is interrupted by a short mid-roll ad sequence, starting at around 30 seconds.
As it can be seen, ad assets are presented with Bitmovin’s Adaptive Streaming Player in the same way as the video content itself to ensure smooth and transition-free playback. Therefore user experience will be improved and thus engagement will be increased.
To signal ads to the encoder, ad markers can either be set using inband techniques like SCTE-35 triggers or via a RESTful API. For ad tracking, inband as well as out of band events are detected by Bitmovin’s Adaptive Streaming Player and can be sent to tracking servers.
SSAI: A Solution for Everything?
Looking at live scenarios, it is obvious that the demand for SSAI will vary over time. To cope with these fluctuations, a highly scalable architecture that handles just-in-time ad insertion is required. As manifests must be created according to the inputs (around personalization) from ad providers, a virtualized solution (hosted either in cloud infrastructure or in a managed on-premise setup) capable of immediate auto-scaling will be needed.
Nowadays commonly used ad standards are built on the concept of inserting ad clips into content video purely on the client-side. So-called, Client-Side Ad Insertion does not seem to meet the requirements of online video streaming anymore and especially the increasing number of blocked ads is a major disadvantage. A novel approach, called Server-Side Ad Insertion, or SSAI promises to overcome these issues and even increase user experience and engagement of viewers. Download the Server-Side Ad Insertion Datasheet
Request a demo