Why are there differences between RSS.com Analytics numbers, and numbers from Spotify and Apple Podcasts?

Modified on Fri, 26 Jul at 8:10 AM

Our state-of-the-art approach to analytics provides very accurate measurements of you podcast downloads. However, when comparing our analytics to the insights offered by platforms such as Spotify, you might see inconsistencies in some of the metrics such as downloads.


This can be due to two main reasons: 

  1. Different measurement techniques, guidelines, and terms. Applications and platforms sometimes use different techniques, guidelines, and terms when measuring you listeners and downloads. For example, Spotify "Starts" are the number of times zero seconds or more of a podcast episode is listened to, and "Streams" are the number of times sixty seconds or more of a podcast episode is listened to. RSS.com's "Downloads" measures the number of download requests are made for the episode, which is similar to Spotify's "Starts" measurement, but could potentially be measured differently if a download request is made but canceled before it populates in the Spotify player.

  2. Time and frequency of updates. Most of RSS.com's analytics update hourly, and the day resets at 00:00 UTC. Different podcast directories like Spotify and Apple have different timeframes for their measurement of a "day," and updates to their analytics happens at different intervals. Spotify, for example, updates their analytics every 24 hours around 20:00 UTC. Meaning at 19:00 UTC you might see 23 hours additional hours worth of downloads on RSS.com that won't appear on Spotify until their daily update.

 

There are some very useful metrics available exclusively on Apple, Spotify and other platforms as well. For instance, the reason Spotify and Apple can provide metrics like listener demographics and we can't, is due to users of their platforms being registered and verified. If a Spotify user downloads one of your episodes, for example, Spotify will know the user's name, gender, age and they can therefore aggregate this data to display demographic insights on who is listening to your podcast on their platform.

 

The main challenge with the aforementioned insights, is that they are platform-dependent. Analytics found on Spotify or Apple are only representative of that platform's subset of your listeners and followers. Apps like Spotify or Apple Podcasts only track data from their users, giving a partial picture.


In other words, Spotify can provide insights such as demographics and streams only for the people who listen to your show via Spotify but not for listeners that use Google Podcasts or Apple Podcasts. Similarly, Apple Podcasts can provide you with the percentage of Engaged Listeners only for users that listened to your podcast via Apple Podcasts and not via Spotify or Google Podcasts, and so on…

 

In a nutshell, RSS.com tracks downloads from all platforms and apps where your podcast is available, providing a holistic view of your audience. No platforms outside of RSS.com are able to provide you with a comprehensive view of all your listeners and followers, because they only hold a subset of your analytical data from their own specific platforms.

 

For this reason, Podcasters typically merge aggregated data from their hosting service with the platform-specific data offered by companies like Spotify, Google and Apple.


Podcasters usually refer to their hosting service analytics to get an overall view of key metrics such as downloads, geolocation, devices, etc… They subsequently compare and merge these statistics with other platform-specific metrics.

 

When compiling metrics from different sources, remember to compare the data based on what it represents and how it's collected, and not necessarily by matching terms for metrics from different platforms.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article