The future of better audio ad experiences is now.
HLS Interstitial solves longstanding issues around ad content delivery.
Every audio publisher is ultimately looking to do three things to keep their business humming:
Create an excellent experience for their listeners, with a seamless integration of show content and relevant advertising;
Orchestrate that experience easily;
Measure ad performance accurately and efficiently – from delivery to time spent listening – so publishers know they’re providing that great experience, and getting the ad revenue they’re due.
Yet, as any of those publishers will tell you, getting there isn’t always so easy.
While proponents of traditional server-side and client-side audio ad insertion constantly “battle” over which method is better, both are inefficient to some degree and make achieving the above goals really complex. They attempt to do things that they weren’t built to do, like count ad impressions. They require different technical skill sets to manage. They can slow down ad delivery. The list goes on.
HLS Interstitial is a cheaper, more efficient alternative for audio ad insertion, eliminating a lot of “noise in the pipes” of traditional server/client-side functionality. Let me explain a bit more.
Server-side v. client-side injection
Server-side ad injection requires a specialized audio streaming server. More than just delivering audio content (broadcasting audio received from an encoder to connected listeners), it needs to personalize each stream it delivers – customizing ads for listener preferences, geo location, and more. Moreover, because audio ads don’t all have the same duration, the audio content may be different from listener-to-listener.
And the streaming server is on the hook for more than just that.
Audio ads need to fit perfectly into a defined placeholder, and the transition from the regular content stream to ads always needs to be perfect. Listening time needs to be measured for each ad and plays need to be accurately reported. The streaming server in this case becomes the gatekeeper of revenue – a role it should never play. Bugs become inevitable, putting the publisher-advertiser relationship on tricky ground.
None of the above is anything that an audio streaming server was built to do.
With client-side ad injection, the player has the responsibility to identify where audio ads get placed, implement the VAST protocol to communicate with an ad server or SSP, call the ads, play the ads, and report back what was played.
But VAST, as many know, is complex and most of the time requires custom integration with every SSP. Moreover, in this case, now it’s the audio player’s turn to become the gatekeeper of revenue – a role it’s just as ill-suited to play as a streaming server. Imagine if there’s a bug in which ads are reported as 100% played even if the listener stopped the player before an ad break.
Other requirements, like implementing a more sophisticated buffer management system (to store a stream received from the server while the ads are played, then resume the main content), add to the complexity.
Replacement v. Insertion
Both the server and client-side should support both types of audio ad injection – replacement and insertion.
With the former, the ads should replace part of the original content when the segment that needs to be replaced is more or less the same duration as the ads. Insertion, on the other hand, is used when the segment to be replaced is very short, often as little as 100 milliseconds. This method is obviously more complicated for the server side when the audio content is live streamed, while replacement is more challenging for the client side.
Both methods add additional complexity to client and server-side implementations.
How HLS Interstitial works in a nutshell
HTTP Live Streaming (HLS) is a newer and more advanced protocol for delivering live and on-demand audio content to audiences. It’s based on successive calls to a media playlist that contains URLs to small audio files (chunks). The player should request the media playlist at a constant interval and play the audio chunks in order.
HLS Interstitial introduces the capability that a Media Playlist will contain a URL to another playlist that contains additional audio chunks with content like ads. This feature makes it easier to deliver content like mid-roll ads or other audio content that’s not part of the original playlist.
Events to alternative content from an ad server or SSP can be triggered at any time. The content is delivered seamlessly within the listener experience.
HLS Interstitial includes both insertion and replacement functionality. Technically, it does this just by playing with the X-RESUME-OFFSET option, which describes when the player should get back to the original content.
The official Apple AVPlayer fully supports HLS Interstitial (this is the main player used on iPhone). Other major HLS third-party players also already have this on their roadmap.
More detail about the HLS Interstitial protocol support can be found in the official Apple documentation here: https://developer.apple.com/streaming/GettingStartedWithHLSInterstitials.pdf
A more efficient process for audio ads
A streaming server shouldn’t have to address server-side ad insertion/replacement. The HLS Interstitial protocol means the client player no longer has to implement VAST. It delegates impression reporting, listening duration and other measurement to the SSP or ad server, which are frankly the only systems that should handle this functionality.
This is equally about versatility. If you’re a large publisher and all you need is to host your own streaming server without ad Insertion capabilities, you can just integrate with a third party SSP or ad server for interstitial content. Likewise, if you already have a streaming server to deliver your content, you can access monetization capabilities without any change to your infrastructure.
We’re excited to tell you more about how we’re integrating HLS Interstitial into our offering at SoundStack, and how it can help you create better ad experiences for both you and your listeners.
To learn more, reach out to us.
Photo by Vitaly Gariev on Unsplash