Podcastindex-org / podcast-namespace

A wholistic rss namespace for podcasting
Creative Commons Zero v1.0 Universal
383 stars 115 forks source link

<podcast:reporting> proposal #87

Open theDanielJLewis opened 4 years ago

theDanielJLewis commented 4 years ago

This one definitely needs the hosting-providers' perspective.

I propose a <podcast:reporting> tag for reporting privacy-respecting playback information back to the hosting provider.

For example:

<podcast:reporting>https://stats.captivate.com/34532</podcast:reporting>
<podcast:reporting>https://api.chartable.com/5u9fg4</podcast:reporting>

Supporting apps would then ping these API endpoints to report playback position. To reduce the load for the providers, such reporting could be done in 5% or 10% increments. The POST data could look like this:

{
  "app": "overcast",
  "appVersion": "2.2.4",
  "mediaUrl": "https://…",
  "playbackPosition": 0.2,
  "ip": "123.456.789.0",
  "identifier": "afa8h43gsixh4hgs03j3"
}

Instead of an app name, app could be the same UA string the app would normally use. An alternative to the IP address could be an identifier the app makes and can be reset by the user, similar to what Apple Podcasts does. Maybe those things would be included in the headers or request source.

There would need to be additional protections in place to ensure this couldn't be spammed. On the provider side, these stats would only contribute to playback completion data, not download totals. So this would prevent someone from firing thousands of requests to this endpoint and artificially inflating their numbers.

Perhaps IAB-certified algorithms could be applied to the data to filter it.

The idea of this API would be only for podcasters to see how much of their episodes were consumed, not to get more data about the audience.

jamescridland commented 3 years ago

Worthwhile looking at prior art here - podcastpingback was a sensible thing, it seemed to me.

theDanielJLewis commented 3 years ago

This could also send some demographic data, as the app might support it.

For example, "age": 30, "gender": "male", "metro": "Cincinnati, OH". And that can eventually feed into demographic data on the podcast-hosting provider.

swschilke commented 3 years ago

I support this idea and see this as a way for web sites, Streaming Platforms and apps to report back on some (basic) user behaviour. Like downloaded, played (til where), demographics etc.

cio-blubrry commented 3 years ago

We (blubrry) have our own ping API and in-client tracking for our own internal apps but we designed the pr4otocol and methods to be pretty easy to implement and more importantly, easy to implement server side. I am not sure if it is appropriate to share more details and where to share them, it is similar to the podcastpingback James linked to, excluding user demographics which at first glance, is a good idea but would not be necessary to send with every ping.

daveajones commented 3 years ago

Interesting. Is there a white paper or documentation anywhere on that?

swschilke commented 3 years ago

I had some similar ideas a while ago and called it Podcast Statistics EXchange Format (=PSEXF) which would be similar as described here. Wanted to use the data described in the IAB specs.

Does somebody here know what or in which form Spotify Partners get the podcast statistics delivered? Might be worth a look.

.