Podcast Players send episode performance data.

[redimongo]

Downloads and stream counts are great, but they don’t tell podcasters the most important information they need. It’s crucial for podcasters to know if their listeners find their content valuable or if there are parts of their podcast that listeners skip or fast forward through.

I’ve been brainstorming a bit, but I’ve hit a wall. I know we can technically achieve this, and we could integrate this type of feature into OP3. Podcast hosting providers could even add an API that allows Podcasting 2.0 apps to send this data back.

The Idea: Spotify has data on how their listeners engage with a podcast episode.

However, we can’t use the range method since Apple sends range=0-1 and then range=0-(end of length of file), which means we can’t do it server-side, at least not for Apple Podcasts or AVKit. I’ve spent two days trying and have hit this small wall.

So, I thought I’d ask the community. I understand some of you might be against this idea, but this is the one analytics tool missing from every podcast hosting company except Spotify.

PodToo embed players already store play count data, play duration, and current duration, so we can do this internally. But unless we can find an open solution, we can only show episode performance data for our own players. We’d love to support every Podcast 2.0 player.

Maybe some ideas:
A new tag? <podcast:performance url="https://api.DOMAIN.com/episodePerformance" seconds="5"/>
This would allow players who want to send the current play position to submit it to the hosting company. You could even add OP3.dev to the front of that so that OP3 can get the same data before passing it on. (Note just technically it would be possible)

basically you would send to this API the episode GUID and the current play duration, maybe every 3-5 seconds, if a user drags the player say to the middle of the player then a post is sent with that current point.

Example: Say an episode is 1 hour long, I start playing it sends it first post to the api podcast:performance url with 1 second, then I drag the progress bar to 30 min it would send another request to podcast:performance saying 00:30:00 with the episode GUID. Then every X seconds it send another request with that so in our case 00:30:05 as we store every 5 seconds.

Update 31 May 2024 - We have just released Version 1.0.1 of the server code, and also we have the domain https://podcastperformance.com which will be what PodToo uses moving forward.

We have taken into account feedback and advise from @johnspurlock and @jamescridland who both where very vocal about not storing IP addresses (So thank you for making me think outside the box), I am pleased to say that now with us using Token request from the feed server to the performance server there is no need to store anyones IP address. I would suggest storing a cookie on the feed server (client side) as otherwise you'll get a new session token each time the feed loads.

[jamescridland]

There are a few pieces of prior art to think about here:

Was my ad heard? NPR's RAD proposal was a set of ID3 tags that essentially said: "when you get to 00:45, send a ping to http://example.com with an ID of 246, please". A RAD-compliant player would send those pings back when it encountered the ID3 tags baked into the audio. This means that you could use RAD to know when a specific ad was played (with dynamic ad insertion), and whether the user skipped that. That fixed the issue with advertisers wanting to have some kind of proof that an ad was played (or not).

How many people heard this show/ad? The ULID - a random ID given per episode by an app - would help with getting accurate listener numbers. Currrently, we are identifying listeners by using a unique user-agent plus an IP address; the ULID would enable much better and more accurate data for numbers of listeners.

As to podcast:performance, there was a proposal for John Spurlock of podcast:events which is a little wider in scope: essentaially asking your player to feed back all kinds of player events to a publisher's webserver. That could include regular pings like your idea, but also things like ratings, subscribe events, and even comments.

The main issue here is the one of privacy. Currently, a podcast player leaks the IP address of the listener only once: when the show is downloaded. If we start letting it contact multiple times during the actual playback of a podcast, that potentially means we're tracking that listener, and potentially might be able to track her to work, understand what route she takes, and how she gets there. IP addresses are useful, but I worry about the privacy implications for continuous pings.

(Mind you, we seem perfectly happy with the privacy implications of sending minute-by-minute streaming sats...)

[redimongo]

@jamescridland First thank you that is a lot of information to go over and I'll look into the podcast:events tag. I personally have not heard about the RAD-compliant players so I'll look into that as well - mainly from a research point.

As you know I like to think outside the box, as much as possible. But you hit on something I think we should be focused on - Privacy.

While I know I can't speak for everyone in our industry, I can speak to what PodToo is doing, I do have to say this first - we serve large corp clients already who have paywalls and want to have listener journeys - basically what does that user listen too and what can we recommend to them.

You are technically correct if the podcast is downloaded the IP address is leaked once. - solution if a podcast is downloaded then the events or performance tag could be skipped? or even better send a ping saying downloadFull also the player could just not send the request if a podcast episode was downloaded.

However I personally don't download my podcasts unless I am going out to regional Australia where there is no cell reception. So I would be more than happy to have my listening habit tracked for podcasters, why because I will skip if it's boring or at least fast forward and that is useful information to the creator so they know out of 100% of data we could collect at 00:05:30 40% of your listeners skipped to 00:07:00 for example then as a creator I can go and re-listen to that part and maybe even snip it out using AI if it's not needed.

Our goal here is to create great content, but we as the creator don't define great content, it's the listeners who enjoy, share and talk about the content that makes it great. This tool would help the listener potentially get a say on how a podcaster thinks about their next episode.

I don't have a real solution for stopping IP leakage multiple times, unless players want to store the information and batch send it when the player stops for 60 minutes, switches episode/podcast or on exit of the app - that technically would work. You send all the player information as a JSON post.

I personally think if you're on Facebook, Google, Youtube, Linkedin or basically the whole internet you kinda have to agree that your privacy is gone anyway and from IP level that's most likely the lowest form of privacy, as in most cases it only tells us where the IP address is registered too by the IP company most of them don't update them when a customer has them like most of Telstra IP addresses for Mandurah to Perth register as Perth CBD - Mandurah is like 50KM+ away from Perth. So using IP address to get location really shouldn't be the gold standard it's just a good base.

Also while on the topic, we wouldn't store the IP address in raw form in this table/collection/database, and potentially we don't need to store it at all after the user either stops sending data for 24 hours to the matching GUID. So we could wipe the HASH IP address after 24 hours of last ping. (Note I can only talk about what we at PodToo could do, it would be up to everyone else to do what they think is right).

[redimongo]

@jamescridland I gave more thought to the IP leakage and we adjusted our system so that the player information can be sent as 1 request as technically the data is not time sensitive.

This allows any player to store the data in an JSON array and then just send it when the person stops playing the episode or switches to another podcast.

Some of the advantages of batch sending:

• Could potentially mean that offline users data could be stored (if app wants) and then send data when they have connection
• Limit Data request and IP leakage
• Offers more analytics data to podcast creators
• Privacy first focused
• Can be store as one document and does not need to be stored based on request meaning potential database space saving.
• No IP Address needed to be stored (Technically), however some method to prevent same listener adding multiple listens to the same episodeGUID would be recommend. At least in a 24 hour period.
• We could show to the podcast creator which player is top based on Listener time and not just downloads (I know silly, but a little gamification always helps)

We have started to integrate this into DRN1.com.au as they are a client of ours, and also we will release all code so that others can do the same if they choose.

Now how is this integrated into Podcast namespace, that I guess is up for discussion.

[theDanielJLewis]

This kind of thing has been proposed by multiple others (including myself) before. But it seems most app developers are not interested in supporting anything that gives podcasters more information about their audience or how episodes are consumed.

That aside, I think the ideal way to do this would be through Activity Streams and ActivityPub, which is still in progress. So if we can get AS/AP figured out, then we can still building things on top of it, like deeper date.

[redimongo]

Happy to take a look at AS/AP - do you have a link.

[samsethi]

most app developers are not interested in supporting anything that gives podcasters more information about their audience or how episodes are consumed.

@theDanielJLewis Daniel you are so wrong my friend. Apps like TrueFans are built from day 1 to give users all the data they want about their activity as well as creators an aggregated view of their listeners. So we already have charts like the Spotify one above to share with podcast creators and musicans. We use metrics like Listen Time, Percent Completed and Value Paid.

We have also built in the privacy elements for users. We also have a V4V model for creators to reward their fans for sharing their activity data (time and attention).

What we are seeing here is the slow realisation by hosts that downloads don't matter. They need first party data and that is held by the apps. Yes Apple, Spotify and YouTube today but also the small podcasting 2.0 apps. As an individual creator you can see all of this data in your Spotify or Apple dashboard. You can't automatically aggregate this data as there are unsurprisingly no open API's to abstract this data. Apple, Spotify and YouTube see no reason to share this with hosts but they do share it with their creators and their advertisers.

I can see why hosts would love Podcasting 2.0 apps to implement this Performance proposal and send back this valuable data to them to include in their analytics. The hosts could then charge more to their customers for richer data.

The elephant in the room is why should apps give hosts this data without some payment. Hosts make money from their customers. Maybe share some of that money with apps so we would send you back the first party data on those specific customers. TrueFans would then share that value back down the line to creators and ultimately the users who created the data in the first place.

I get why hosts want this data, this is the third host this week asking for it, but maybe Oscar, Mitch, Jason, Martin etc will do this but count me out unless there is a V4V solution.

[redimongo]

@samsethi yes I agree with you.

I can see why hosts would love Podcasting 2.0 apps to implement this Performance proposal and send back this valuable data to them to include in their analytics. The hosts could then charge more to their customers for richer data.

While yes your 100% correct, at PodToo which does have to make money to stay afloat, we will not be charging any more than our current prices, like our system even does email marketing via sendgrid which cost us a small amount each month. But we designed PodToo for Radio stations, and podcast network companies.

For us opening our tools to the wider community and making it open source, is us being nice and playing fair with the community. I would hope that the community platforms like true fans and others would see oh this hosting company is supporting us, we should support them.

The elephant in the room is why should apps give hosts this data without some payment. Hosts make money from their customers. Maybe share some of that money with apps so we would send you back the first party data on those specific customers. TrueFans would then share that value back down the line to creators and ultimately the users who created the data in the first place.

Because podcasters, hosting companies etc will have the option to block a user-agent and use other methods to stop this form of paywall for data, I think that is the biggest issue we are going to see here (but lets hope not) Remember the AS/AP is meant to be an open fedverse - if people believe that is the way to go, if not then it goes against the sprit of the whole AS/AP.

Another reason is, our podcasters and clients don't want data all over the internet, they hate going to each service and looking at the data and scratching their heads that's why this should be done by the hosting company, at at min an open source system that a hosting company can talk to and the podcaster can self host.

[redimongo]

So if anyone is interested in spinning up their own server for podcast performance I have published the code at https://github.com/podtoo/podcast-performance/tree/main/server

You can also test your XML once the server is spinning via https://codepen.io/redimongo/full/BaeQyaP

I have also added to the server code the path to fetch your performance percentage via GUID note we check to make sure it's a valid GUID that exists in your episode collection before running the code.

http://(YOUR DOMAIN OR IP):7000/episodeperformance/(EPISODE GUID)

Note you will need HTTPS for the codepen to post to your server. we use Docker containers and then nginx proxies, if anyone needs assistance please just ask happy to help.

[theDanielJLewis]

(Coming back to this months later.)

While I would still like to see this kind of thing, I think we really need the foundation of podcast ActivityStreams first. That would make building things like this easier additional steps to standardize the activity format and send that to the podcast's ActivityStreams (none of this "user ActivityStreams" stuff). Whether that's through a webhook tag, socialInteract, or something else, I don't know. But development seems to have stalled on ActivityStream/ActivityPub stuff in Podcasting 2.0.

[redimongo]

I completely agree—ActivityPub and podcasting can be way more complex than we’d like to admit! While AP helps solve the challenge of sending performance data, it does have its drawbacks, particularly when it comes to maintaining private, anonymous data, since users need an AP account.

For example, with Podcast Performance, I designed it so that everything is tied to a session ID, which makes it easier for users without requiring an account. It’s more user-friendly that way.

But you're right—the project got stalled because app developers weren’t keen on sending the data, so it’s been pushed to the back burner for now.

We do have it working across PodToo and all our client sites (with branded players), but until we get wider adoption from podcast player apps, it’s kind of at a standstill.