As some of you might have found about (and hopefully successfully enabled) is the Analytics feature in Podlove Publisher 2. It’s our approach to analyse episode downloads in a detailed manner to help you better understand your audience and it’s behavior when it comes to accessing your content.
We are currently revising the Podlove Analytics user interface and might introduce new features too. So it’s a good time to ask around and discuss things you think are currently missing or could be improved.
We are particularly interested in questions: what
questions do you have about your audience that could be answered by looking at download behavior?
what things would you like to be able to find out, compare and distill out of the available data?
what kind summaries would you like to see
Also, regarding integration of Analytics with your podcast web site:
which analytics data would like to be visible to other users internally (in the backend)?
which Analytics data would like to be visible to users?
which detail or summary information would like to be able to access via Podlove Templates
can you imagine any widgets or other ready-made visualization for inclusion in the website?
If you just want to share your experiences and/or annoyances while using the feature that’s also fine. Every bit of feedback helps us designing Podlove Analytics to be the podcaster’s best companion.
First of all: Thank you for your work! Really. The Analytics feature (and the hole plug-in itself) is great already! “How many listeners do you have?” is often the first question I get from interviewees. Now I can give them answers.
One thing I’d like to know (if possible):
A user starts listening to an episode online (via webplayer). How long is he listening to it? Further: What is the average “listening time” of listeners using the webplayer per episode / per last X episodes / per all episodes. Is this even trackable?
As far as I know, klicking the webplayer’s play-button counts as 1 “download”, even if the user stops listening after 10 seconds. Right? So having a lot of webplayer-downloads in the statistics might be misleading. That’s where my idea came from.
Why am I only talking about the webplayer? Well, gathering this information from (“real”) downloads and feed-users would be awesome, but impossible. Right?
We have been thinking about adding more fine-grained analytics for the web player itself to the mix. However, this is something where we would need to build the support for this right into the web player and we haven’t discussed the feasibility of this in detail.
As you said: we simply can’t do this for feed downloads. To get information on canceled downloads, you would need a much more detailed analysis of network activity in the backend. The publisher can only deliver answers from looking at the frontend.
I agree with the points @katrinleinweber made. I also would be interested in more detailed statistics about web player usage, like @Joey already mentioned. For example it could be helpful to see at which time of the day people listen to episodes via web player to fine tune the release of a new episode.
Geolocation is obvious, but I know you’re already working on this.
First of all: thanks for all your work so far! Even though numbers (downloads that is) don’t really matter to much to us, it’s always nice to get an impression of the “circulation” of an episode. However, there are 2 things I consider quite useful, at least from my perspective:
It would be so nice to have a link directly to the specific podcast episode either from the episode-specific analytics dashboard, or from the main analytics dashboard (that might be more inconvenient since the click on a certain episode opens the episode’s analytics dashboard). Why? Well, if you have episode dedicated to a bunch of topics you might not be able to remember what’s inside an episode just by looking at its name. So it would be nice to open the episode (website) from the analytics dashboard.
For our podcast(s) downloads is not overly important, it just gives us an impression on the “circulation” of a certain episode. Besides that the number of subscriptions would also provide an interesting detail. However, it would be way more interesting for us, if there would be some more qualitative information than quantitative. This is specifically the information from where links to a certain episode come from (blogs, Facebook, Twitter, websites, documents)? In the end we’re not only interested in getting an impression how many people (or clients) downloaded an episode, but:
How many people have shared an episode?
Did some discussion outside of the episodes comments arise?
Did someone use an episode (or parts of it) in some kind of media outlet (again blogs, websites, documents, other podcasts etc.)?
This information centered around the idea of “inspiring discourse” with an episode (which we want to trigger in the end with podcasts like the Open Science Radio) is much more important for us than pure downloads.
From the world of scientific metrics such ideas and measures (altmetrics) do exist - and yes, they have their own flaws. Services such as Altmetric do try to tackle these aspects and visualize them in their “Donut”. In these cases the tracking is based on DOI of the document, I’m not sure if the URL of a podcast would be sufficient enough to do so. And yes, I am aware of the permanence problem of URLs at that point. I’m also not sure whether the episode’s GUID might be a better (if usable at all) artefact.
I know that it probably is more complicated that I think something like this would be. Just wanted to share my ideas/wishes with you.
Would including more metadate in the episode analytics page work for you? A link to the page is okay and will probably added but it wouldn’t be much better to not have to load another page at all?
Regarding web analytics (linkbacks, comments etc.): that’s really the blog part Podlove Publisher does not deal with at all. Go to WordPress plugins and services to get information on this.
Some things that I would love to be able to see if feasable.
The ability to be able to inspect the stats for a given day across all episodes
The ability to compare episode stats against averages for all episodes; like the episode downloads, but for additional data
The ability to compare episode stats against a chosen episode
The ability to view the breakdown information across all episode and not just for a single episode
The ability to be able to get a summary for all episodes, e.g. “How does the first day, week, month, etc. trending?”’
The ability to view country information of request, since there is MaxMind data with the plugin.
The ability to change the number of items viewed per page on the main analytics page.
The long shot wish:
A guide to be able to import some semblance of data from other providers that were used before migrating to Podlove Publisher.
Thanks so much for the work, and I am technical, so the other thing that might be useful is to be able to support a module system so I could try out some of these things myself even, and then give a potential submission to the Github repo.
At least those two should be adressed in the upcoming 2.4 release
The ability to view the breakdown information across all episode and not just for a single episode
Very desirable but probably not feasible with the current approach. I built a prototype once but to allow the dynamic filtering all data is held in the client (browser). which lead to enormous (multiple GB) memory requirements for a podcast with more than a million downloads. I still think it’s doable, but it needs to support time segments (last 4 weeks, …) instead of “all data of all time” and dynamic loading and disposing of data to keep memory consumption in check. Alternatively, move all calculations from client to server, but in that case it’d probably be more feasible to start the analytics UI from scratch.
Please feel free to fork and play with the source. I don’t think I will modularize Analytics anytime soon but I’m happy to review Pull Requests on Github.
Hi all!
Thanks for everything; I really love Podlove.
I’d love to show (parts of) my Analytics-Data on the Frontend to the visitor. So as a request for future releases: Would it be possible to handle this via podlove templates? I already saw two other podcasters who use podlove and show their stats, but one hyperlinks to podseed.org and the other one uses a screenshot. So there seems to be some demand.
I, for myself, built a quick-and dirty wordpress-plugin that directly reads the wp-podlove-database and shows some stats in the footer. But the template-way would - of course - be a lot better and the way to go. (I’m not at all familiar with github, not a very “clean” programmer, so I’m afraid it would take me a long time (i don’t have right now) to understand the podlove-code and work on it myself via github-fork. otherwise I’d try).
I would like to have access to the development of average listeners per episode in a given time frame (weekly listeners / monthly / yearly). That would help to get a feeling if the listener base is growing or declining.
