Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

<podcast:reporting> proposal #87

Open
theDanielJLewis opened this issue Oct 22, 2020 · 6 comments
Open

<podcast:reporting> proposal #87

theDanielJLewis opened this issue Oct 22, 2020 · 6 comments
Labels
proposal An idea for a new tag

Comments

@theDanielJLewis
Copy link

theDanielJLewis commented Oct 22, 2020

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.

@daveajones daveajones added the proposal An idea for a new tag label Oct 22, 2020
@jamescridland
Copy link
Contributor

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

@theDanielJLewis
Copy link
Author

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
Copy link

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
Copy link

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
Copy link
Contributor

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

@swschilke
Copy link

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.

.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal An idea for a new tag
Projects
None yet
Development

No branches or pull requests

5 participants