-
Notifications
You must be signed in to change notification settings - Fork 116
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
Comments
Worthwhile looking at prior art here - podcastpingback was a sensible thing, it seemed to me. |
This could also send some demographic data, as the app might support it. For example, |
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. |
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. |
Interesting. Is there a white paper or documentation anywhere on that? |
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. . |
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:
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:
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.
The text was updated successfully, but these errors were encountered: