Over the last few years, I’ve travelled to numerous trade shows (including countless NABs and IBCs) demo-ing the capabilities of server-side ad insertion. Each successive show I go to, I see more companies demo-ing SSAI (also known as DAI or dynamic ad insertion). My total count at NAB this year was 19!
It occurs to me that being able to demonstrate a modified stream at a tradeshow, where you’re just talking to a first-party ad server, is not a true representation of the realities that broadcasters face. The key to a successful SSAI (server-side ad insertion) solution is in how it scales and the complex business logic it can support. Delivering one-to-one addressability when millions of viewers are watching a major sports event is very, very different to a closed demo at IBC.
In this article I’ll discuss prefetch, a technology that is the central cog in meeting the demands of monetising major events over OTT.
Challenges of the digital environment
There are two principal requirements of any rights holder live-streaming a major event:
- To provide viewers with a reliable, seamless, high quality TV experience
- To provide advertisers with all the advantages they’ve come to expect from digital (addressability, programmatic trading, per-viewer measurement).
Achieving both in a live stream, at scale, is not easy.
When ad decisions were made a few years ago, whether for VoD or live, the broadcaster was typically inserting first-party sold ads, meaning a single call being made to an ad server (ADS) – a relatively straightforward process.
Today, where programmatic comes into play, you may still be making a call to an ADS but increasingly there may also be five, six or seven hops out to programmatic platforms. All that adds latency because of how long it takes to get a fully resolved pod of ads back. If you haven’t designed your SSAI system with that in mind, and don’t continue to develop it based on the learnings you get from working with those programmatic platforms, then what you can actually see is a drop-off in fill rates rather than an increase because the ad calls time out. Worse still, a poorly architected solution risks becoming unstable at true scale resulting in costly high-profile outages.
In a live stream you don’t have the luxury of being able to wait around before you decide what you’re going to insert into an ad break. If you’re making a first party call just to an ADS then you would expect a response back in time to enable you to fill the break. But if you’re waiting for an additional 500 milliseconds per programmatic partner then you can get to the point where the response is too late.
For example, a 70% fill-rate from your first-party ad server could drop to 30% with programmatic because of the sheer volume of ad calls that time out.
Ad server performance considerations
Typically, ad servers were designed with a VoD use case in mind, before live simulcast became commonplace. Even when a very popular show like Game Of Thrones is made available on a VoD service at the same time as it goes to air, despite the huge demand, there are limited scaling concerns for the ADS because not all viewers will have clicked pay at the exact same moment in time. Therefore they’ll go to an ad break at slightly different times and the calls to the ADS will be spread out over a longer period.
In a major live sports event scenario where you’ve got two million viewers and the ad break occurs at exactly the same time for all of them, you’re making two million ad calls to the ad server within a very, very short space of time. While that may sound like a problem the ad servers should be able to deal with, the reality is that typically they were not architected with live streaming in mind. They will either protect themselves by implementing a maximum-transactions-per-second limit to throttle requests, or will simply slowdown and timeout requests as their volume grows. If you then introduce programmatic into the mix the issues are multiplied.
Viewer experience prioritised
What this means for premium channels, where the end-user viewing experience is absolutely key, is that the broadcaster is presented with a dilemma: what to do if an ad response is incomplete. What if you’re only returned one-and-a-half minutes of ads for an ad break that’s two-and-a-half minutes long?
One solution is to serve a minute of filler slate at the end of the ad break; however that results in a degraded viewer experience. So the broadcaster will often set a business rule saying, “Okay, we’re not going to replace this break at all because we’d rather the user has a good viewing experience than an extended period of filler slate.”
As a consequence of a low fill-rate, the broadcaster actually loses all two-and-a-half minutes of the ad break which is simply not sustainable, especially if the broadcaster has paid a premium for its sports rights.
Scaling with Prefetch
Prefetch addresses this by pacing the calls made to the ad server, firstly so the ADS isn’t swamped and doesn’t slow down, and secondly so more time is allowed for all of that decisioning process to take place (absolutely critical in a programmatic world).
To implement prefetch, a close integration is required between the SSAI tech and the broadcast headend so that a lot more information is made available about the upcoming break patterns and timing. That means the SSAI provider can start to make ad calls to the ADS earlier than if you were doing “just-in-time” calls. When implemented correctly, it doesn’t have any impact on the end viewer – it simply means that the ad calls can be made earlier and allowed more time to fully resolve. The response for each viewer can then be stored ready for delivery when the ad break is signalled.
All of the stream manipulation still occurs in real time – it’s just that third-parties are allowed longer to provide the ad information the SSAI provider needs.
Expecting the unexpected
Major live events can be hugely unpredictable – it’s what makes them so engaging to the viewer, and so valuable to the advertiser.
Prefetch allows SSAI systems to “look ahead” to an upcoming ad break. Even if the exact start time and duration of the break is dependent on in-play decisions, a maximum target break length can still be determined in advance and sufficient time allowed for calls to be made to the ADS, then to a live programmatic marketplace. The SSAI platform can then dynamically adjust the break length based on the real-time automation and playout signalling, that drives the broadcast production, to deliver a personalised and true–TV experience while maximising the monetisation opportunity .
Viewer experience is one of the three central pillars of television. Monetisation is another, and I expect to see plenty of examples of both at this year’s IBC. The third is scale, and its importance must not be overlooked if broadcasters are to capitalise on the revenue opportunities of OTT.
Visit Yospace at IBC, stand 14.G14
Interested in dynamic ad insertion?
This year’s Future TV Advertising Forum focuses on DAI as a ‘hero technology’. We are also asking whether the famed brand-media-marketing machine has broken. Early conference details are here.