How we all can help podcasts thrive (but nothing’s quite that easy…)

Serial Podcast by Casey Feisler

Podcasts continue to grab the media’s attention, but the economics behind them are as hard as ever. I’ve got a proposal on how that could be fixed, but it needs vision and support from major industry players too. Why should I or content creators care, and why should developers bother?

Digital audio has continued to attract a lot of attention of late. From Serial, to services such as NPR One, audio is continuing to fight its corner in a crowded digital landscape. It’s easy to see why too, as our lives get increasingly busier everyday the core qualities that lead me personally to a lifetime passion for radio broadcasting are equally as applicable to all forms of audio content irrespective of delivery method; the can be enjoyed anywhere and usually whilst doing other activites — be it walking, driving or even exercising.

Technology giants are seemingly aware too. Most recently Google added podcasts in to its Play Music application which is pre-installed on a huge number of Android devices. Many believe this will have a similar effect to when Apple included Podcasts in iTunes and then later pre-installed a specific Podcast app on to iPhones a couple of years ago.

So, awareness and accessibility of podcasts is improving. But, as a content creator, can you be sure if anyone is out there, listening? An article in the New York Times recently argued that Apple have actually held the medium back somewhat with their opaque management of listing and placement in the Podcast section of iTunes. But, more importantly, it touched on the issue of analytics and metrics.

When you subscribe to a podcast, depending on how the software you use operates it may “stream” the file and play it as it grabs it from a remote computer or download the audio for later. The latter is the “traditional” way a podcast client would work, downloading an episode whilst you have a Wi-Fi or mobile data connection so you can listen later whilst offline (maybe on an underground train service or driving in a remote part of the world, or originally even on a device that doesn’t have a direct data connection itself.) This is often combined with the capability to subscribe to a podcast so the process is automated, which might mean a user subscribes and then forgets about the show for a few days, a couple of weeks, months, or indeed — forever. If you’re a semi-regular Podcast listener, take a look at your app now. How many unplayed episodes do you have? Are you really going to listen to all of them? There lies a problem.

The only metric a creator has to judge performance of their podcast is measuring activity on the content they serve from their own computers - the episode audio file themselves and the document that describe the show and lists the audio files which your app routinely checks for new content. Because of all the different ways your client might grab that audio, the download figures for the audio aren’t particularly helpful. Those downloads might represent a listen, but they might equally represent a user that’s listened to one episode and then each week after their client has continued to download them and… well, you know how it is, you’re busy, it’s stuck in a flurry of Messenger notifications. (It’s OK. We’re human.)

So if you’re a content creator wanting to concentrate on your podcast, the chances are at some point it needs to begin contributing back financially to give it the attention it deserves. To do that you either need advertising or sponsorship on board and, without the meteoric coverage that a podcast such as Serial can achieve, that’s pretty difficult when you can’t even say if one or 1,000,000 people listened — and even then if your made up audience figures heard all thirty minutes or left after sixty seconds.

The technology problem here is actually pretty trivial to solve. Earlier this week Omny Studio, a company which provides services to audio content creators, picked up on the same NYT article and announced they would integrate analytics in to their own player. This means listeners to podcasts hosted through Omny and listened to via their own player can now track listening starts, stops (and, therefore, durations). You can work out exactly how many heard your podcast, what bits they heard and even begin to see things like when a large portion of audience drop out due to a particular piece of content. As a technology, it’s relatively simple, but the data it gives content creators is crucial.

There are, however, two issues. Firstly, because the tracking only works via Omny’s own player — which is most commonly embedded in to a Podcasts own website — it may not be where most of your audience listen. Indeed, I believe part of the success of Podcasts is the fact that it’s an open standard which allows people to choose their preferred app or location to consume the audio. Most likely, a listener will default to whichever podcast app came pre-loaded on their phone and curate a list of things they want to listen all in one place to so they can flick between shows easily. I would hedge my bets few podcasts, if any, see most of the traffic via their own web presence.

This is a little unfair to Omny, who don’t specifically provide a podcast service, but more a way to get audio content online be that embeds, podcasts, on social network etc. They also acknowledge the issues with the current implementation and see it is a starting point, the next challenge being to get the technology built in to the large scale app players. Omny don’t specifically mention if this would just be their own technology (which might be a significant challenge to get the likes of Google or Apple to adopt) or an open technology.

Which lead me to wonder if an open solution has already been proposed.

So far, I’ve not discovered anything, so I had a go at designing one myself. If you’re technically inclined, at the end of this article I put forward an idea on how this could be acheived.

Regardless, an open standard still has a tricky path to getting adopted; why would developers build this in to their apps? One interesting argument is that if they implement this technology in such a way that they offload the reporting aspect to their own servers, they effectively become a bridge with a steady stream of information all about the podcasts being consumed by their users. That data could come first to them, before they forward it on to the podcaster themselves. This is equally lucrative information for the app developers as well as the content creators. But why would they forward it on?

Ultimately the podcast “ecosystem” needs to works to work to a mutually beneficial arrangement. The podcast apps aren’t successful without great content and great content can’t continue to be made for free. So I believe, partly in the interests of playing fair, it would be beneficial for both parties to assist each other.

Which brings me back to the second identifed issue. If podcasters and client developers don’t work on this together, it’s probable that the likes of Google will do the same as Omny and implement some form of analytics in to their own podcast offering. If they do, it’s likely Apple will at some point also join them. Then as a podcaster you have 2, 3, 4 or more sources of statistics distributed in different silos — which means aggregation, competing methodologies, and a slowly increasing pile of headaches to deal with.

Alternatively I propose an open standard which still allows any developer to still do their own thing but built upon a common foundation to give everyone a level playing field.

To conclude, the very things that brought me in to the world of broadcasting are common with digital audio delivery in podcasts. They present the next exciting chapter in crafting entertaining, engaging and thought provoking audio content for audiences small and large. I want to see this thrive, but to do that it needs to be sustainable. The technology is the easy bit, but it needs widespread adoption. If you’ve enjoyed this, please do share it to others you think may be interested and I’d love to receive feedback on the feasability of this endeavour.

And if you’re interested on how the technology might work, read on.

When I first thought about the problem from a technology point of view, it immediately struck me that a similar technique already exists and is widely adopted not for podcasts but for blogs. There is an interoperable standard known as pingbacks implemented by most major blogging platforms. The concept is that if you share the URL of a blog post on another system that implements pingbacks, it “pings back” to the original author’s system to say “Hello, I’m over at this location and have just shared your article”. It’s a form of attribution and gives the author awareness of where else their content is out in the world. You’ve most likely seen this in action on a blog post where, in the comments, a list of URLs shows other articles that mention the article you’ve just read.

Taking this inspiration, what if the RSS feed for a podcast included an element that specified an HTTP(S) URL. This URL can be stored by the client and used to report listening sessions back to the original source. For example, in the RSS feed:

<rss version=”2.0">
 <channel>
 <title>My Podcast</title>
 <link>http://andybee.com</link>
 <description>Lively discussion and topical banter</description>
 <pingback>http://andybee.com/podcasts/pingback</pingback>
 <item>
 <title>Monkey Tennis</title>
 <guid isPermaLink=”true”>http://andybee.com/podcasts/monkey-tennis.mp3</guid>
 <description>Smell my cheese</description>
 <pubDate>Thu, 26 May 2016 12:12:45 BST</pubDate>
 <enclosure length=”1037273" url=”http://andybee.com/podcasts/monkey-tennis.mp3" type=”audio/mpeg”/>
 </item>

The URL http://andybee.com/podcasts/pingback being a simple script that accepts an HTTP POST such as:

POST /podcasts/pingback HTTP/1.1
Host: andybee.com
User-Agent: PodcastClient/1.1
Content-Type: application/json
Content-Length: 248
{ "uuid": "65af8a68-e1cb-4f48-9f27-560b9452b025",
  "content": "http://andybee.com/podcasts/monkey-tennis.mp3",
  "events": [
    {
      "type": "session",
      "date": "2016–05–26T11:18:22Z",
      "offset": 0,
      "duration": 735
    },
    {
      "type": "session",
      "date": "2016–05–26T11:45:01Z",
      "offset": 735, 
      "duration": 122
    }
  ]
}

The array of events could contain, for example, up to an agreed upper limit number of events denoting listening activity. Clients could deliver the information in realtime if online, or cache the events until such a time that they next did a sync. This means it could work even on devices such as an iPod touch with discontinuous data connectivity, reporting back when the device is next online.

Or, as suggested in the discussion above, the submission of this content could be handled server-side by an application developers backend after they have received and processed the data themselves.

{
  "content": "http://andybee.com/podcasts/monkey-tennis.mp3",
  "events": [
    {
      "type": "start",
      "date": "2016–05–26T11:18:22Z",
      "offset": 0,
      "playbackSpeed": 1.2
    }
  ]
}
{
  "content": "http://andybee.com/podcasts/monkey-tennis.mp3",
  "events": [
    {
      "type": "stop",
      "date": "2016–05–26T11:30:37Z",
      "position": 735
    }
  ]
}

I settled on reporting complete “sessions” in the earlier example for simplicity as it minimises the effort on the receiving end to consolodate events. However, a potential benefit of reporting individual points of interest (e.g. playback starts at Time 1, pauses at Time 2, resumed at Time 3, stops at Time 4) is that — when reporting in realtime — more sophisticated server implementations could produce “live” views of listening activity.

{ “content”: “http://andybee.com/podcasts/monkey-tennis.mp3",
 “listener”: {
 “location”: [ 52.6336, 1.6910 ],
 “age”: “25–40”,
 “sex”: “male”
 },
 “events”: [ … ] }

Finally (and likely most controversial) is an entirely optional element for reporting basic user profiles. I would suggest never making this mandatory, but it a client has the information and most importantly the user’s consent, it could report profile information back to assist the creator further in analysing their audience.

This is a somewhat rushed first attempt, I’m certain there are many ways it could be improved, but I wanted to share it now to get some thoughts on the overall concept. If you’re interested in seeing this go further, please do get in touch.