Server-Side Ad Insertion: Have a Good DAI
In today's over-the-top (OTT) world, ad-supported OTT video is irrevocably siphoning viewership from traditional broadcast television viewing. The shift from broadcast to unicast formats allows advertisers to target audiences with more precision, splicing potentially highly targeted ads into each viewer's video stream. Targeting can make ads more relevant and hence raises the value of an ad view. There are two primary approaches to splicing targeted advertisements into an OTT video stream: client-side and server-side.
In client-side ad insertion (CSAI), an ad-decision request is made by the viewer's playback client, which then downloads the ads and splices them into the stream at a designated location (the "ad opportunity" or "avail") in the stream. In server-side ad insertion (SSAI), the ad decision is made in the network and the ad is spliced into the stream before sending it to the client.
In the case of SSAI, a component called a "manifest manipulator" (MM) creates the spliced streams for each client. It makes the ad-decision requests on behalf of each client, fetches the ads, and inserts them seamlessly into each viewer's stream.
The measurement of ad views, or impressions, makes use of “beacons.” These are notifications sent to an analytics aggregation server declaring that an ad has been partially or completely viewed. The beacon (containing the aggregation server location) is returned with the ad decision. There are frequently many beacons per ad, corresponding to all the entities that participated in the ad decision process. It is not uncommon for each ad to include many 10s of beacons: there are typically 6 beacons representing an “impression” and the quartiles of ad playback (start, first quarter through complete playback), each sent to multiple ad decision partners in the ecosystem.
With CSAI, the beacons must be triggered at the client. With SSAI, the beacons may be triggered on the server-side, or they may be sent to the client for triggering from the client when the ad has played.
Both CSAI and SSAI have strengths and weaknesses, and each has enjoyed a period of popularity. At their debut, the initial industry opinion was that client-side beaconing (CSAI) was more accurate: it could report on what the client played, rather than what the client requested. The worry with SSAI and server-side reporting was that clients viewing a stream containing ad opportunities may have received an ad decision for playback and triggered the associated beacons, but by the time the ad arrived for playback, the viewer might have tuned out; so beacons were sent, but no ad was viewed. But there are easy ways to mitigate this issue. Ultimately server-side ad insertion brings a slew of other benefits that makes it the better choice, outweighing this one concern.
The Benefits of SSAI
In contrast to CSAI, SSAI always delivers a high quality of experience. Ads are spliced into the stream seamlessly with no buffering and with frame-accurate placement. In fact, with SSAI the client isn't aware that it's playing an ad, and when beaconing is done on the server side, the client is as thin as possible. This gives service providers the opportunity to avoid client/vendor lock-in and save on client and client-version upgrade and management costs.
Upgrades to the service, such as the ability to send different types of beacons, can be managed at a single point: the server side. A service can even be transitioned to include new capabilities overnight for all users at once.
However, it's SSAI's resistance to fraud that may be its most compelling characteristic. Blocking viewing of ads on the client side is relatively straightforward—it works the same way ad blockers work with web pages. With SSAI however, it is difficult, and potentially impossible, to do.
Most importantly, the SSAI service provider is a single audit point and a service entity. This is not the case with a cloud of beacon-sending clients that can't be verified or audited. Client-side beacons can be spoofed. The prevalence of click-fraud on the internet is a forewarning of what can happen with OTT ad-supported video when impression reporting is done on the client side. With SSAI, OTT ecosystem players can avoid many of the fraud issues their predecessors faced with web-based ad insertion, helping them to increase advertiser confidence and spend rates
Client-side beacon advocates may argue that there are ways to overcome these deficiencies. But the reality is that all of these mitigations require amalgamating data from various ecosystem entities—the content origination system, the service provider, the ad insertion system, etc. The business hurdles to aggregating this highly sensitive data from different entities with different interests are impossible to overcome in practice.
SSAI can also address some of CSAI's other beaconing issues. For example, it's reasonable to aggregate beacons on the server side and meter them out over time, avoiding large peaks of triggered beacons and reducing infrastructure costs. This kind of metering is difficult, if not impossible, to do on the client side, which can be turned off at any time.
SSAI can also offer other attractive, forward-looking options such as making multiple ad decision requests in parallel, selecting an optimal response. This type of logic can easily be upgraded at the server, but it's almost impossible to manage on the client side.
Lastly, the same SSAI infrastructure can be used to deliver targeted alternative content, during a sports blackout or as a result of geographic restrictions. Alternative content delivered to different regions (or even users) can be managed in the same way as ads. It is selected per user and spliced on the server side seamlessly. Doing this on the client side is not a secure option.
The Drawbacks of CSAI
CSAI's first weakness is that it requires a "thick" client. The client must be able to make ad decision requests, store and manage ads, fire impression beacons, and splice the ads into the video streams. Each of these is a complex process, and in unison, they make the client a heavy component that is typically proprietary and deeply intertwined with the service. A video service provider that uses CSAI, becomes essentially married to the client-vendor for life.
CSAI's second weakness is managing the upgrading and versioning of such a client across a range of consumer devices running on different chipsets and different operating systems. This is an expensive and complex proposition.
Thirdly, downloading and storing ads on the client uses more streaming bandwidth, which can degrade the quality of the viewed video content when ads are downloaded simultaneously with playback.
Lastly, seamless splicing of video is not trivial, especially if ads are represented in a non-streaming format, as is normally the case. Client-side beaconing creates a quagmire of issues. It is not uncommon for every ad to include up to 100 different beacons. This results in a large computational burden on the client and an even worse burden on the analytics aggregation server which must accumulate beacons simultaneously from every viewer of the stream. With popular linear streams in which large audiences all view ads at the same time, the beacon ingestion load requires expensive infrastructure which, ironically, sits idle most of the time while no ads are being watched.
Conclusion
The reality is that in many situations, SSAI is the only option. Some devices, for example some smart TVs, are designed to only run thin clients, and they are not amenable to rapid software upgrades due to long and complex testing cycles. In these situations, SSAI is preferable.
Some may argue that although CSAI reporting could be suppressed, that this is a far-fetched scenario. But the Carrier IQ debacle—the outrage-driven bankruptcy of a company whose software was used to send cell phone user-report beacons—is worth a review.
Although different players in the end-to-end ecosystem have different interests and consequently different opinions about the strengths and weaknesses of SSAI, the end-goal is shared: to monetize video. With the need to use thin clients in large market sectors, SSAI becomes the preferred option. Given server-side ad insertion's fraud-resistance, accuracy, safety, and reliability, and the necessity to use thin-clients in large market sectors, it has become the best option.
[Editor's note: This is a vendor-contributed article from Wurl. Streaming Media accepts vendor bylines based solely on their value to our readers.]
Related Articles
SeaChange Senior Director, Advanced Advertising Scott Apgar explains why OTT ad insertion isn't ramping up more quickly in this clip from his presentation at Streaming Media East 2019.
02 Oct 2019
Streaming Media's Tim Siglin and fuboTV CTO Geir Magnusson discuss SSAI and ad personalization on the show floor at Streaming Media East 2019.
24 May 2019