It’s becoming increasingly common to monetise podcasts via a direct connection with listeners, whether that’s from merchandise, donations, live events or bonus or ad free content. Big networks and publishers are doing it (eg Wondery Plus, Stitcher Premium, Slate Plus, etc) and independent creators are too (via Patreon, Memberful, or other solutions).
The tech required to deliver premium podcasts and bonus content alongside a free (often ad supported) show is, on the surface, relatively simple. You need a second, private podcast feed and some means of authenticating paying users so that only they can access it. A new clutch of startups has sprung up to handle this, from Supporting Cast to Acast Access to the newly seed financed Glow. Some larger independent shows are even building their own bespoke solutions.
Yet as anyone who has tried subscribing to a bonus or premium feed will know, it’s not always straightforward to get your new paid-for content set up in your app of choice. Some publishers get round this by making their paywalled stuff app-specific (the Stitcher Premium way), others provide extensive FAQs and onboarding instructions to help listeners get their feeds working (the Slate Plus route). “It is a pain in the ass for us, and more importantly, it’s a pain in the ass for users,” Slate Plus editorial director Gabriel Roth told Digiday in 2018, characterising the effort to monetise podcasts directly as “essentially, a customer service challenge”.
That’s the state of play right now — lots of overlapping and competing routes for the podcaster interested in charging their audience for premium content, from Patreon’s patron-only audio RSS option to those new startups. Enter Jake Shapiro and Chris Quamme Rhoden, CEO and CTO of RadioPublic respectively, who have a proposal for a new way of handling this.
What they’re suggesting, laid out in detail in this Medium post and in the draft technical spec, is a new open protocol that would enable listener identification and authentication in any enabled app. If it can be built as they are currently suggesting, this would drastically reduce the customer service difficulties around delivering premium podcast content, since listeners would theoretically be able to access their extra paid-for episodes with a few taps inside their usual listening app (here’s a mockup of how it could work). They’re calling this system PodPass.
I spoke to Shapiro and Rhoden yesterday to get a bit more detail on how this might work, and what the practicalities of implementation would be. To start with, Shapiro emphasised that the PodPass proposal is a response to the pre-existing trends in the podcast industry, rather than an attempt to engineer a new direction. “We don’t need to like incentivise or create [the direct monetisation] phenomenon. We are just proposing a way to make it more effective,” he said.
This is a moment, Shapiro, argued, where apps and providers have a choice to make about how they’re going to handle premium feeds. “You can either choose a strategy where you don’t want to support any of these things in a seamless way, where you want to offer your own integrated solution — Luminary being the most extreme example — or you turn on an ability for a publisher to offer some kind of gated content on your platform,” he said.
Writing last week for Nieman Lab, he also made the point that there’s a gap for an open solution here, since none of the big players (Apple, Spotify, etc) have addressed the need for seamless private feeds yet. The idea is, therefore, to develop PodPass as an open, collaborative project — RadioPublic would not have ownership of it. “We want to really underscore that this is an open protocol rather than a company’s product,” Shapiro said. “It’d be better to have someone else implement it or start implementing it than just us.” The big aim, he explained, is to have something completely accessible almost as an add-on to RSS as a means of open distribution.
Another important element is payment — PodPass is not a means for taking money, merely the mechanism via which paying listeners would be authenticated to receive their content, although Shapiro doesn’t rule out that the protocol could be used for other monetisation purposes too. “The place where [a service] currently takes a cut would stay the same. If you’re Patreon and you’re providing the service, nothing changes. It’s just a more effective service.” The hope is, of course, that a better service for listeners incentivises more of them to start paying for bonus content, thus benefiting funding platforms and in turn incentivising those companies to implement PodPass.
In order to get a sense of the viability of this, I put out feelers to people at a dozen or so different companies in this space, attempting to test the temperature and interest in PodPass. I got some positive responses back. Michael Mahemoff from PlayerFM says he’s excited by the idea and his team are “actively evaluating the details of the protocol and sharing feedback”; Garret Heaton from Swoot said “it’s especially appealing to us as app makers since it would make it easier for our users to use premium/private feeds”; David Stern from Supporting Cast said “PodPass is exciting because it would greatly streamline the process for the end listener and make it more robust and secure for the podcaster”; and several more expressed interest privately.
Of those I spoke to, several pointed out that their apps or platforms alone didn’t have the capacity to develop something like this, but that they were keen to participate in a collaborative effort on a new standard. Similarly, everyone who responded to me was keen on the open nature of the PodPass proposal, feeling that it kept the playing field level and didn’t tie podcasters into to particular companies. I’m still interested in other responses to this idea, so if you have feelings about PodPass and how it might work with your product, do drop me a line.
The big question, of course, is whether PodPass can actually work on a practical level. Chris Quamm Rhoden, who had the original idea and has worked on the draft technical spec, says so — he’s confident that what they’ve put forward in the specification now can work, but that it’s not a final version by any means. “We want to invite as many people who are interested in having a voice in the final version of the document feel like they’ve got an opportunity to do that,” he said. “We’ve seen other things happen in the past where things sort of stalled because that invitation wasn’t loud enough. And so we’re making a very loud invitation right now.”
“We’re also prioritising making sure that people have as little work to do as possible to make the UX good,” he went on, explaining that each app or platform that wants to offer PodPass will have to integrate it into their own system, and it’s difficult to say how easy or hard that will be without intimate knowledge of each product. However, both he and Shapiro feel it’s eminently possible, and possible fairly quickly.
“I expect we’ll see some test implementations this fall,” Shapiro said. “I would imagine we’ll see some early versions of it, round trips through from a publisher to a hosting company to an app happen this fall — at least one or two if not three or more participating stakeholders for each one of those pieces of the chain, just based so far on momentum and interest that we’re seeing. But because this is not a RadioPublic product per se, it’s not a road map that we control. . . This is more movement building.”
In the year that also brought us the launch of Luminary and all of the conversations that provoked about what a podcast is and what open distribution means, PodPass feels like just that — an idealistic, blue sky thinking plan for a new iteration of free and open distribution at a time when ever more big money players are getting into the industry. If it can gather enough momentum, it’s still a very long road for the idea to go from proposal to wide implementation.