TV consumption is making a clear migration from broadcast and classic managed IPTV platforms to over-the-top (OTT) delivery. This occurs in both live linear channels as well as with catch-up content, defined as video on demand (VOD) assets of recently aired content played out to consumers while capturing the TV audience. From a business model standpoint, early premium OTT services were based primarily on subscription VOD models (SVOD) and therefore ad-free content. Meanwhile, early online video platforms, generally defined as short-form content like YouTube, relied primarily on pre-roll advertisements. They have done so primarily within the context of dedicated applications (YouTube, Vevo, etc.), which originate the advertising and content from the same server and can coordinate the playback. Newer live linear Pay TV Lite services, supported by mix of subscription and ad supported revenues, are just taking off as a meaningful component of the Pay TV landscape. They grew nearly 50% in 2016 to US$1.1 billion and are expected to grow at a 44% annual growth rate through 2021 to represent US$6.8 billion in subscription revenues.
In the Pay TV domain and modern syndicated content, the majority of services today rely on client-side advertising insertion. In brief, the client device stops playing back the content, sends out a Video Ad Serving Template (VAST) request, gets a response, loads the asset, and then restarts playing back the content.
Client-side ad insertion puts the burden of communication and coordination on mobile devices, which have the wrong characteristics for these tasks—they are performance and memory-limited, battery-starved, and have long latencies and strained connectivity to network resources. From a more comprehensive perspective, problems with client-side ad insertion include:
- Ad blockers: Ad blockers index ad routers and ad server sites and prevent calls to those IP addresses (in a way similar to security software preventing sites that host malware), preventing the ability of the client to playback the ad content. Most clients treat this as an “ad failure” and go back into the content playback, although app-based services can detect this and ask consumers to whitelist their sites or block the subsidized content.
- Latency and performance: Going from playback of one asset to another can cause problems such as stitching issues, resolution changes, loss of playback buffer, etc., which negatively impact the viewing experience. Further, the latency of typical mobile networks and increase in transactions from a mobile device increases device battery consumption, decreases network efficiency, and increases latency-related problems. For example, a typical ad insertion may require a call to an ad router, one to two ad servers, and then the ad asset itself. Round-trip cellular latencies are on the order of 100 ms in most 4G networks; removing three ad-related calls can reduce start time by 300 ms, which is noticeable to users and has a direct subscriber impact.
- Development considerations: Implementing client-side ad insertion requires developers to use many SDKs on the client devices; porting these to every platform, achieving common functionalities across all supported devices, and managing the versioning of these across platforms is complicated.
These challenges are causing many broadcasters to move to a next-generation technology: server-side advertising insertion (SSAI). SSAI implementations move the complexity from every client and SDK to the server side. They improve each of the problems listed above, in brief:
- Ad blockers are resolved because the advertisement is proxied from the same content server, so it is impossible to tell by the IP address where the content ends and the advertisement begins.
- Latency and performance are moved from the device at the edge of the network to “cloud-to-cloud” data transfers that occur at data centers with significantly more connectivity. In addition, the ability of the server to cache content and unify the playback experience (for example, transcoding or transrating ads to match the content and network conditions) can further improve the experience.
- From a development standpoint, developers still like to implement some client-side signaling for quality of service (QoS) and analytics perspective, and they must have some trick modes or other capability to prevent fast forwarding through ads, etc. However, generally, the number of SDKs implemented in an application can be reduced from seven to ten down to three to four in typical premium video services.
Ad blocking is not a uniform problem—Digiday published data (http://digiday.com/publishers/global-state-of-ad-blocking/) showing how ad blocking is today greater on desktop devices than mobile devices, is done by men more than women, and is done by younger audiences more than older audiences. There is significant regional variation, with Poland being the highest (38%), Germany and the US with strong levels of ad blocking (~25%), lower levels in the UK (21%), and the lowest in Japan (10%). Server-side ad insertion can help overcome many of the challenges of client-side technology, simultaneously improving quality and increasing ad impressions. For instance, Elemental Technologies enabled Ooyala to implement server-side ad insertion with the Ooyala Pulse ad server for customers to improve video service monetization.
Now is the time to take a detailed look at how client-side ad insertion technology is degrading your subscriber/viewer experience and how ad blocking is impacting your service monetization. Subscriber expectations for video continue to grow, and the bar for expected video quality is slowly rising—server-side ad insertion is one tool that can help increase quality of service and improve viewer experience. Now is also a good time to prevent ad blocking as it occurs at lower levels on mobile devices than desktop devices, while mobile devices are driving an increasing amount of viewing. Moves taken today toward server-side ad insertion can help keep your video service ahead of the curve and grow, from a monetization standpoint, faster than would otherwise be possible.
