In any digital content industry, standards must be defined in order to protect advertisers – and ultimately the entire industry – against bad data practices. Advertisers can continue to pay and benefit publishers only if the industry, as a whole, agrees on a set of metrics with which data or stats can be measured.
In the podcasting space, paid advertising is still in its infancy, and there are complications to consider. Take for instance the fact that content is often consumed through apps the publisher doesn’t have control over. For example, podcast listening apps (sometimes called “podcatchers”) allow users to subscribe to podcasts, which are then downloaded and consumed offline. However, in these cases, the only thing the publisher sees in his or her stats is a downloaded episode (either manually or automatically), but not whether or not it was listened to.
At Spreaker we are in the unique position of being able to control the platform end-to-end: we have both a publishing platform and a listening application. This allows us to deliver precise information to our publishers, like whether or not their audience has actually listened to their episodes, and if so, when and how. We call this “on-platform” consumption, and we report this data in our stats as “plays.”
However, being an open service, we give our publishers a couple of tools to help distribute their content to a variety of other platforms:
- The RSS feed, which contains episode links and metadata
- Individual download links to single episode mp3s
Our podcasters use these powerful tools to share their content to iTunes, Twitter, and other sites, though consumption through them gets counted as “downloads.” In other words, these tools are just links posted on the Internet. While we at Spreaker can see that most incoming media file requests come from human-operated apps, others come from pieces of software that work automatically.
And there’s yet another complication; even legit apps that “stream” podcasts make multiple requests for the same file. The Apple Podcast app, for example, makes lots of requests, even for small episode bits, in order to prevent users from using too much bandwidth. However, that results in tens, sometimes hundreds of requests for a single episode file by the same user.
The essential problem we have to solve is defining what constitutes as a “download.”
How many downloads of the same episode by the same user should we count if they happen in a single day?
Does it make sense to note that an episode has been listened to 10 times if it was always listened to by the same person? And, by the way, how do you define a unique listener when all you have is an IP address and some technical data?
The IAB has done a terrific job of answering these questions, and has published a detailed guideline that all podcast hosting providers are required to follow. Spreaker is moving in this direction, and we’ve recently published our own document describing the type of filtering we’re applying in order to remove duplicates (an up-to-date version can always be found here).
Recently, we’ve made a few changes in the way we filter these duplicates that may have affected your audience analytics. First of all, we assure you that nothing has changed on the listener side; you have exactly the same number of listeners today that you had yesterday. What has changed is that for some of you, this figure may be lower than expected. This is because we’re now applying IAB’s recommendations in order to make sure that what we report as a “download” has the exact meaning as what is required by industry standards.
Every vendor knows the ecosystem is continuously changing, with new apps constantly emerging with different request patterns. We’ll be updating our filtering system and making changes along the way that will ensure your data is as close as possible to what’s actually going on with your listeners, so that you can get the paid advertising you’re looking for.