The Challenges of Server Side Ad Insertion and Why They’re Worth It
Today it’s more important than ever that broadcasters and publishers are able to deliver and monetize content across every device type. It’s equally important that these content providers meet the expectations of their audiences – a linear TV experience. This is where server side ad insertion (SSAI) has a compelling value proposition and there’s an interest in understanding how it works.
Server side ad insertion (SSAI), also referred to as dynamic ad insertion (DAI) or ad stitching, is the process of combining content and ads into a single stream of video before delivering it to the player. This eliminates buffering and circumvents ad blocking. Without SSAI, ads are inserted client-side (CSAI) using logic within a player or SDK to call an ad server like Doubleclick, SpotX or AppNexus etc. SSAI eliminates that call so ad blockers are unable to detect and block third-party domains. Eliminating that call also eliminates buffering and delays between the content and the ads, creating a smooth, linear TV-like experience.
SSAI systems work in one of two ways, manifest manipulation and ad-creative ingest. The more common method is manifest manipulation, which involves writing out a manifest, or playlist, for the stream that includes video stream segments from different sources – the content source and the ad service. In this model the content service makes the ad request, parses the response from the ad server, and then writes out the stream manifest to include segments from the content service and directly from the ad service.
This approach has the advantage of being simpler to implement and is quicker to do, however the stream segments from the various sources can be encoded slightly differently, and these differences can trip up the decoder on some devices. These services try to make up for differences by inserting what is called a discontinuity – a marker to indicate the decoder should be reset. But some players only take this to mean the timeline should be reset, not all the encoding parameters. For example the content video may have a different set of audio tracks from the ad creative, or it may have a different key frame interval. These differences sometimes lead to the player not knowing how to proceed and interrupting playback.
The other approach, ad-creative ingest, has the content service make the ad request, parse the response, and then actually download and process, or ingest, the linear video creative. By ingesting the ad creative just as it would any other video content, the SSAI service can control the quality of the output. In particular it can do things such as normalize the audio – so the ad doesn’t seem much louder than the content – as well as make sure the whole video – content and ads – has the same encoding parameters throughout – for maximum compatibility with players and devices. This method even has the ability to work with devices that do not support discontinuities.
The SSAI stream delivery service makes the ad request on behalf of the client in either case. One common concern is that the ad service needs to know the request is not fraudulent. Since all requests come from the same IP address range, and frequently from those assigned to well-known public clouds, these requests can be hard to distinguish. One way to handle this is for the SSAI service to pass the client context to the ad service, specifically the device user agent and requesting IP address.
The exact way this is done currently varies between services, but for instance, Brightcove uses HTTP headers borrowed from HTTP proxy services — X-Forwarded-For and X-Device-User-Agent. The more heavyweight IAB AdCom spec, governing how ad requests are trafficked by OpenRTB services, is an alternative way to send client context.
The applications for SSAI span far beyond better user experience and defeating ad blockers. Since SSAI ads are “stitched” into the content, they play out just like any other portion of the video and do not require special player or device logic, and therefore they work everywhere that streaming video works. It allows broadcasters and publishers to monetize across all device types, notably the consoles and TVs that are driving the growth in OTT viewing but that may not have client-side hooks to request and handle ads and analytics.
At Brightcove, the expansion of connected living room viewing among their customers’ audiences has been a driver of growth in their usage of SSAI. Brightcove shared data with me that shows that the customer base which has adopted SSAI has increased usage by 75% over the course of the last six months which you can interpret to be a positive signal of its efficacy. Sometimes Brightcove suggests a hybrid ad delivery (SSAI + CSAI) approach that looks like this:
Although web-based ad delivery methods are absent in these environments, advertisers’ expectation to deliver on web-based ad metrics still persists, which presents the first challenge of SSAI. The current generation of OTT video and connected TV applications have evolved from web video; videos that play in a web page. The video ad stack that has grown up for web video is largely based on how display ads work (non-video image-based ads for web sites). A non-video website typically contains a mixture of text, images, and interactive content. All of these elements are loaded by the web browser, sometimes from different servers, and rendered together. Certain web browser technologies, specifically browser cookies and the ability to execute JavaScript, have become essential to how ads are loaded and rendered in the page. These elements make it possible to do things like ad targeting (and retargeting) and executing proprietary verification scripts that are downloaded with the ad units called VPAID scripts.
Targeting users is still possible without cookies using device IFAs (identifiers for advertisers), unique identifiers and even IP addresses. In a post-GDPR world, where cooking users becomes very difficult or perhaps impossible, these new identifiers may even be the future of audience targeting. However, without these legacy web browser capabilities, one thing that reigns true is that VPAID is non-existent in these app-based environments. This has been the main objection of SSAI, as traditional web video advertisers are not able to buy off of the VPAID metrics they’re familiar with, including viewability.
Ensuring that ads are seen is important, however it should be less of a concern for these premium, non-web environments. There’s less risk of user abandonment – toggling between browsers or channel surfing. The video is also less likely to compete for screen real estate with the player taking up most, if not all, of the screen. There’s also much greater trust between buyers and sellers for this inventory type, and the majority of transactions on this premium inventory take place in private marketplaces. Being able to serve ads on this premium inventory and ensure they’re being delivered by mitigating ad blockers should alleviate the concerns of any skeptical advertiser.
Why It’s Worth It. The ability to reach OTT connected devices and avoid ad blockers far outweighs the manageable challenges of targeting and measurement, the impact of which continues to be reduced. SSAI improves user experience, protects revenue and expands reach through an easy and proven integration path. Broadcasters, publishers, and advertisers alike have come to expect digital targeting and measurement with a linear TV experience and SSAI is filling that need and will continue to be iterated upon to address any remaining gaps.