Is HLS video better for consumption stats?
When you enable HLS video in your podcast hosting company, the Apple Podcasts app doesn’t download the video (or the audio component) in one part any more - it downloads little chunks instead. One of the benefits of that is, we’re told, that it’s much easier to know how much of an episode is actually consumed: because it’s only downloading those parts.
The downside with normal downloads are that they aren’t always played. Most people believe that anywhere from 10% to 20% of all downloads are never played. (In 2021, we calculated the true figure was about 13%). This is fine: it’s been costed in to every ad sale, and most advertisers will judge success based on results anyway.
But, with HLS, because the download is broken up into little chunks, we should know how long someone watched - and, if they skip bits, we should know that, too, right?
But, does HLS actually offer better understanding of a user’s behaviour?
Tests in a web browser suggests that it does: but it’s still all a little opaque.
Our test
In a test, we started playing a piece of Apple Podcasts HLS video; and stopped that playback after ten seconds. So, we should have seen just ten seconds downloaded, right? Not really - in that ten seconds, irrespective of the podcast hosting service used, we saw more than 60 seconds of content being downloaded when we just played ten seconds. It temporarily buffers enough content in the browser to ensure smooth playback. (The amount that is buffered can be discovered in the browser, but is, by default, up to your browser - whatever it thinks is a sensible amount to buffer, based on a number of different things.)
When we played just ten seconds of the episode, has it downloaded enough content for 60 seconds of playback? That’s the IAB definition of a “download”, and the answer is - yes.
But - is this a “play”?
Is it a play?
Is it a “play” according to Apple Podcasts Connect? The answer is: yes. A “play” in Apple Podcasts is literally someone pressing the play button. If you listen for longer than 0 seconds, then that’s a play.
But wait: it isn’t a play at all. Apple Podcasts Connect doesn’t measure any plays from the Apple Podcasts website or from embedded players: it only measures the iOS app, iTunes on Windows, or HomePod (and only from versions released since 2017). So any play you get on the Apple Podcasts website won’t appear as a play in Apple Podcasts Connect.
Would this be a play according to Spotify? No. Spotify needs 30 seconds of playback for it to be a play.
Would it be a play according to YouTube? No. YouTube doesn’t actually document what they think a “play” is, but it’s generally believed that, above a certain number of plays, YouTube needs 30 seconds of playback for it to count.
Is it a play according to the upcoming AMP specification? We don’t know, because we don’t know the details of the specification yet, other than “30 seconds of content played”. If that’s measured client-side (i.e. comes from the player knowing what you listened to), then it isn’t a play, because we only listened to ten seconds. But if that’s measured server-side (by looking at the downloads of the chunks) then it is a play, because more than 30 seconds were requested. But, we also know that all those downloads happened in just ten seconds, so perhaps the specification will take the time of download into account.
Is it a play according to a podcast hosting company? They can only measure server-side, looking at the download of the chunks. So perhaps they can look at the time of the downloads of the chunks as well.
But there again, Apple Podcasts still lets you auto-download episodes. With HLS, an auto-download would grab all the chunks as quickly as possible; while a “streaming” play would only grab the first 60 seconds as quickly as possible, and then grab additional chunks when they’re needed.
Can we tell if someone skips?
If I were to skip thirty seconds, would it be possible to tell?
Yes, if we’re measuring within the Apple, Spotify or YouTube apps: because presumably the app knows when someone hits the skip button.
But would a podcast hosting company know if someone skipped? Based on our tests, they would if a listener skipped more than 70 seconds, because the player will probably only hold 60 seconds or so in cache.
But if they only skipped 30 seconds, the only giveaway would be to, again, measure of the time of the download of the chunks as well. If, suddenly, a user is downloading more chunks than you’d expect, then there’s been some skipping going on.
Does HLS fix podcast measurement?
For podcast listeners (or viewers) watching while “streaming”, there’s no doubt that HLS gives clearer statistics than a download alone. But it’s not perfect.
In order to have full podcast measurement, the right way would be consistent instrumentation in every podcast app, and for each of those apps to report back to the podcast publisher. That is unlikely to happen - some podcast app developers have already indicated they will not do this - and is inconsistent with an open podcast ecosystem.
If we base everything on those apps that do report instrumentation, we need to ensure that they are all reporting the exact same thing. Press “play/pause/play” three times on both Spotify and Apple, and the total of plays on Spotify would be 1 while the total plays on Apple would be 3 in the app (or zero on the web).
A careful technical specification, requiring podcast hosts to time downloads of individual chunks, is certainly possible: but that may be quite technically complex for podcast hosts to deal with. We currently don’t have a specification like this.
So, does HLS fix everything? Not by itself, we’d suggest.
