John is a developer and creator of SPC — this interview has been lightly edited for style and readability
Sam Sethi: What is SPC, please, John?
John Spurlock: SPC is basically the result of several conversations that I had at the recent Podcast Movement Evolutions Conference, and some other conversation I’ve been having.
It seems to be in the zeitgeist recently that some of the podcast apps actually provide portals so that podcasters can view what’s going on in the app for their podcasts. As an example, Apple Podcast Connect: a podcaster can log in, see not just the downloads that they get on the server side, but then also what the app only knows - listens and followers and how long the listener listens to their podcast.
This is incredibly useful to the podcaster. They get a bit more information about how they’re doing, at least for listeners to that app. The podcaster puts their work out into the world, and they allow all these apps to include it (for free usually), and this is one way for the app to say, oh, like you want to be in this app because we’re showing you all this great information. Sometimes that can drive how you do your show, but even not, at least it’s some signal out there that people are listening and you’re doing a good job.
It’s a lot of work for apps to construct these portals. You can imagine you need a whole team to do this and it’s hard work collecting these metrics and then displaying them. And that works for apps of a particular size, but it would be nice if any app could give this information or make it available to podcasters in a simple way, even without doing a portal. Something where the high level aggregate numbers could be communicated without having to do a portal or without having to do a lot of extra work.
There’s been a lot of proposals on how to do this. Most of them, I feel, have not thought about the app’s point of view. If you think about it, the apps are the ones collecting this information and it’s hard work developing an app. And really we ought to make whatever standard we do here as easy as possible to do for an app, right? To fit into their busy schedule and something that they can get started on right away. And so the idea of SPC.
SS: What does SPC stand for? Let’s get that out of the way first.
JS: SPC stands for standard podcast consumption. It’s an open standard to define five standard consumption metrics [and then make them available to podcast creators for reporting].
If we had to ask for a handful of metrics, what would be the most impactful metrics to collect and display to podcasters? I think part of this project is defining those metrics.
And so if you go to the spec, it’s a one pager that anyone can read. There’s two metrics at the show level, and then there’s three metrics at the episode level. And again, these are aggregate metrics.
I don’t know if you remember the RAD initiative from back in the day from NPR - it’s nothing like that. These are aggregate numbers: “You have 354 followers”. This isn’t one particular listener at this location who listened to this episode: that’s not at this level at all.
The idea of this is to go big and to say any existing app today could implement this without waiting for anything on the server side and without changing really anything that the podcast apps are already doing. A lot of these apps are already computing this sort of thing internally. And it’s just a matter of let’s get on the same page and define a mechanism for how to make them accessible to hosts.
The two show level metrics are firstly follower count. I think we all know what a follower is at this point: a person that’s listening to a podcasting app has actually made a particular interest in a particular show, whether that’s for auto downloading or for notifications. The second metric is all time total listeners. This is a number that always goes up into the right: how many listeners have you gotten on this show [as a whole].
Now where things get interesting is at the episode level. There’s basically three defined standard metrics at the episode level. One is episode level daily listeners. A listen in this standard is defined as anything greater than one second episode level. It’s very similar to the show level listener count, but since those can’t be aggregated, this needs to be defined at the episode level as well.
And then probably the most important metric, which is something that came out of a lot of conversations that I would not have expected is the listener histogram at the episode level. This is not what a particular listener does, but it’s basically those nice charts that you kind of see on YouTube or Apple, where you see a hundred percent of the listeners start out with an episode, and then it sort of falls off over time. So 90% fall off. It was at minute two and 50% fall off by the time it gets halfway through, et cetera. And again, these are aggregate numbers. What’s great about this metric is that not only the app knows this, so this is like all new information to the podcaster, the podcaster would love to know this information, but it also can be used to calculate things like listen time. So listen time is a metric that I know a lot of people are talking about, but you can actually compute that via listens and the histogram. The other thing is streams. So some apps actually define a stream as greater than 60 seconds - but if you have these episode level histograms, that also falls out: you can see how many people dropped off after minute two, that sort of thing.
The whole intention of this spec is to be as simple as possible for the apps. And all of these are optional. So the app can choose to ignore the ones they don’t want to provide, but those are the five we’re asking for to start out.
SS: How does it pass the data through?
JS: It was inspired by what the app Overcast already does today. For the longest time, Overcast has sent every time it’s server fetches the podcast’s RSS feed, it will send how many followers that particular show has on their platform. This approach scales to hosting companies, or if you’re self hosting your feed.
Basically, the way it works is instead of sending the followers directly inside of the user agent like Overcast does, it just sends back a URL that’s kind of a secret URL, then the podcast host can go out get all of these other standard metrics forever going forward. So it’s kind of nice in that it requires no new work. From the app’s point of view, the app, yes, it needs to collect the metrics. But if you think about some of the other approaches that have been proposed, they propose making daily calls for every single podcast in their directory, which is, if you think about it somewhat unrealistic for even the most intrepid apps that want to kind of do the right thing as far as standards.
So the way this works is that the app, let’s say it’s Podcast Casts, for example, they need to implement one new API endpoint on their server - the endpoint that any podcaster can go and get their metrics: but they need to know the key and that key is sent in the user agent when Pocket Casts gets their RSS feed. That’s basically it. That’s the entire spec.
The hard part is having all the apps actually creating the metrics in the same way and making them available via the standard endpoint. And what’s cool about this is the existing portals, they don’t have to change their portal to support this. This is just a very high level single computer to computer call that is like in addition to a portal.
So this doesn’t mean any existing app like Apple and Spotify, which could actually implement this spec very easily, they don’t have to change their portals, they just need to implement this one API endpoint, the benefits of a standard endpoint. And each host doesn’t have to create a point to point integration, they can just implement one SPC integration, then it will work with any app large or small, even the app that people are working on in the garage.
This is just new information that all the apps are collecting now, but not really making available. And the problem to be solved here is how to make that available in a standard and simple way.
SS: So, if there was an SPC endpoint, podcast hosts could bring all the data back from those apps into one analytics dashboard to give the creator that total overview, not that siloed overview just from one app, which is what Spotify, Apple, and YouTube do. I do think the right place is at the host where they can give you that bird’s eye view of where your listeners are spread across multiple apps and where the engagement may be highest on one of the apps or whatever. That will help creators immensely.
JS: I think you said it really well. I couldn’t say it any better than that.
The nice thing is the app is not making any new work that is not being used. So the host can call this endpoint every year if they want. They could not call it or they could call it every day. It depends on what they want to do. And there’s batching built in so that they can request metrics for more than one show at a time. That’s something that was built into the spec.
So I encourage everyone to go read it. And I think if you’re an app developer, this is something that you could do relatively easily. The only requirement is that you have to have a server, right? You have to have something that can host an API. But most, most good apps will have a feed server, right? That’s like crawling all the feeds. And that’s also necessary for this.
It’s worth like calling out again, that there’s nothing listener specific in this. So, you know, if I’m the podcast app and I’m requesting audio, that’s where a lot of analytics are done today. That’s where the analytics prefixes can see this. That is not being modified in this. So that can still work the same way it does today. So no need to change the client. The only thing that the app has to do is add this SPC endpoint. And then when they server fetch the RSS feeds for every podcaster, send the particular user agent. So just to be clear, there’s no listener IP leakage anywhere here.
SS: So where is the proposal in terms of finality?
JS: I would say it’s an open idea and it’s out there. It’s a single page, so anyone can read through it. I’ve been talking about it for quite some time now in private, but then also in public. I’d love to get the feedback from the public, but you could definitely start this if you’re an intrepid app developer. You could start doing this today.
One thing I didn’t mention that you can probably tell, but it does not require any new RSS feed tags on the server side. So this does not require any new name spaces or any changes to your feed contents at all.
It’d be nice to have a very crisp definition of the metrics to collect. And so that’s where I could see I’d want a little bit of feedback, but you could definitely, if you’re collecting these already, you could definitely implement this today without any major changes.