It's been a while since we last provided an update on Podcast Pingback and whilst on the surface it may appear that little was happening, we've been actively engaging with potential supporters and implementers across the industry to gather feedback on the initial specification.
We're incredibly grateful for the support received from our supporters and those who have actively engaged with the project via email and phone.
There are three key issues the project faces:
The first point refers to a lack of responses from many developers and those who we have spoken to (mostly off-the-record) have informed us of concerns over implementing any form of tracking, both from a user privacy point of view (an issue this project was conscious to address in the original standard) and also over concerns their peers respond negatively to tracking.
Similarly there have been concerns expressed by vocal members of the publishing community on the same theme that any form of tracking will have a negative impact on the current business models and obtainable CPM. Essentially the theory that a move towards increased accuracy brings with it diminished returns. We're keen to not wade in to the ethics of this particular argument, but simply note that without publisher and developer support it's hard for us as a project to move forward, and we don't believe Podcast Pingback is alone in this difficulty.
On the second point, the major players are all actively seeking increased share for their platforms and, with it, seeking programming exclusivity and agreements with publishers. One of the ways they are achieving this is by promising enhanced listener statistics, but specific to their own platforms only. This is obviously at odds with an open standard for gathering this data across any client and so clear to see why an operator of a platform such as this would be unlikely to engage with our project.
Finally on the third point, Podcast Pingback lacks the prominence, profile and roster of engaged parties that NPR can attract. We're keen to not paint this as a point to illicit pity, we are simply being realistic about the limitations of our position and where we can move next.
With all these points in mind, we are ending the current phase of Podcast Pingback. Aiir will cease sponsoring the project and no active community engagement or standards development will continue at this time, but the current standard will remain available should others wish to pick it up or work with it at a later date.
We would also encourage anyone still interested in the activity of the project to actively engage with NPR's RAD project if they have not already done so. Although we have highlighted some key differences we would like to see addressed in their standard, we feel like NPR has the right scope and active participants to have the best chance of achieving the common goal of more detailed listener analytics in podcasting in the future.
The project team for Podcast Pingback are still incredibly proud of what we achieved and still believe our approach offered a light, simple to implement way of diving in to a deeper level of metrics for podcast listening, but the required key stakeholders of our industry don't seem to be in the same headspace as those who have pledged support at this time. We hope to see further developments from NPR and others in the near future.
14th February 2020
The podcast industry is continuing to grow at an impressive rate. But one thing that is frequently cited as holding it back is the difficulty with which accurate metrics can be obtained.
Several apps have implemented their own measurement systems, but each exist within their respective walled garden. None of these systems are interoperable and therefore lack offering a comparable or complete picture of podcast listening.
So, based on a previous exploratory idea, the team at Aiir have developed "Podcast Pingback", a method for reporting listening activity back to a podcast publisher.
The idea is intentionally simple. A podcast client can obtain a URL from inside an existing RSS XML feed that can receive simple "pingback" HTTP requests detailing key events; when the playback starts and when it pauses or stops. Beyond that there's additional optional meta that can be attached, such as if playback has been sped up or "enhanced" by the client and (subject to consent) some profile information on the listener.
Our work at Aiir is focussed around building innovative, easy to use products, to enable broadcasters to manage content whilst growing audience and revenue, all in one place. This means we know first-hand how making our clients audio more accountable is crucial for the future of podcasting. And if this is true for broadcasters exploring podcasting as a new revenue stream, it follows that it's even more important for those podcast innovators where it's one of their only revenue streams.
The grand ambition is simple; to get an open, interoperable analytics method embedded in as many clients and used by as many publishers as possible. It's a big one, and there's a huge elephant in the room, but we have some core beliefs that drive this ambition:
You might be thinking "great time to try and launch a snooping protocol to a suspicious public"? We take privacy concerns very seriously, but there's no getting around the fact that one of the desires for these analytics is to support the "evil" act of money making to support creators.
Spot and read advertising are unlikely to go away anytime soon and the arguably more controversial personalised or heavily targeted advertising is out of scope. The method revolves around an anonymous unique identifier derived by the client and the inclusion of a listener profile is optional and intended to be under a user consent agreement. The only way it can be obtained is by a client supplying it, which would raise a broader question of how the client obtained it before even passing it to the publisher. Finally, a "forget me" user flow was included to ensure a listener is always in control.
Check out the specification now. It relies on being adopted by publishers and software developers alike. If both points ring true and we see the adoption of a standard we can move the whole industry forward with a more complete view of the consumption of our content.
We're keen to receive feedback and engage the community in the future development of this spec. Please feel free to look at and fork our GitHub repository for the site and submit pull requests, or get in touch to discuss the specification further.
27th April 2018