Accurate podcast stats are vital for podcasters as they provide valuable insights into audience engagement, listener demographics and the overall success of their show. Mindfulness of statistics helps podcasters make informed decisions and optimize their content strategy. Follow the requirements on this page to obtain the most accurate statistics for your podcast.
Content Creator Requirements
Podcast content creators and producers must meet the following requirements for their podcast to be accurately measured in Blubrry’s Podcast Statistics system.
Use of ID3v2 Tags
ID3 tags are data stored within an MP3 file that contain information such as title, artist, year, genre and artwork for the podcast episode. Version 2 of the ID3 tag standard contains features required for podcasting. These include the ability to add images to ID3 tags and placing the tags at the start (header) of media files. By storing the ID3 tags in the header of the file, podcast players can promptly download the first portion of your episode and display your show’s information as it retrieves the first minutes of the episode for playback. ID3v1 tags require the entire episode to be downloaded before the tags can be read.
If you are able to store an image in your ID3 tags, you are already using ID3v2 tags and are compliant with Blubrry’s Statistics requirements. If you are using Blubrry’s ID3 writing feature, you are automatically compliant with Blubrry’s Statistics ID3v2 requirement.
1 Minute Within First 2MB of Media Files
At least 1 minute of audio must be downloaded to be recognized as “consumable” to accurately count podcast episode plays. To meet this guideline, the first minute of audio must be downloaded within the first 2MB of the audio file. This can be achieved by adhering to the following:
- MP3 bitrate must be 192Kbps or lower (128Kbps joint stereo or 96Kbps mono recommended)
- ID3 artwork (image saved to your ID3 tags) must be at most 300 kB (0.3MB)
If you are using Blubrry’s ID3 writing feature, you are automatically compliant with Blubrry’s Statistics requirement.
Podcast Application and Media Player Requirements
Blubrry applications meet the following requirements, including Blubrry’s PowerPress Plugin, the embeddable Blubrry Audio Player, as well as Blubrry’s podcast directory, Smart TV, Android, iOS, Alexa and progressive web applications.
Blubrry expects all other podcast applications such as web, mobile, desktop, internet of things, smart TVs, or personal devices such as Alexa to meet the following podcast application requirements. These requirements provide the best user experience for both the listener and the application.
WARNING: If your application does not meet these requirements, Blubrry may no longer include your application in podcast statistics reporting.
No preloading in media players
Preloading refers to the function where a player will automatically start loading the media upon page load. To ensure compliance, set preload=”none” within your audio or video player tag. This will improve page load times as well as avoid unnecessary bandwidth use.
Applications such as mobile or desktop apps should not auto-download episodes in a player until the user has intentionally clicked play.
No autoplay
Autoplay refers to a function of some embedded web media players that makes the players automatically start playing upon page load. This occurs when the attribute autoplay=true is included in the embed/object. In HTML5 media players, this happens when autoplay or autoplay=”autoplay” is included within the audio or video tag.
To meet Blubrry Stats requirements, do NOT include any variation of the autoplay property in your player. This will ensure more accurate podcast statistics and a more user-friendly experience for your audience.
Separating full downloads from progressive downloads (streaming plays)
To allow Blubrry’s Podcast Statistics system to better measure downloads vs. plays, be sure your application does the following:
- For episode downloads for playback at a later time, we ask developers do their best to download the entire episode in one request (avoid splitting download into separate slices/chunked requests).
- For progressively played/downloaded episodes, we ask for the requests to be made in slices/chunked (byte range requests).
Do not modify media / enclosure URLs
Applications should not modify the Enclosure URL when requesting media. Do not add additional query string parameters. Blubrry does not add query string parameters to media URLs. The unique URL and media filename is used to identify the episode for statistics reporting.
Do not cache
Applications should not cache podcast episode media files on servers. Always download the latest episode from the Enclosure URL for every app-user wanting to listen.
Use header information
Applications should use the header information located at the start of the podcast to prevent a full download when not needed.
Use the latest Enclosure URL
Make sure to use the latest Enclosure URL found in the podcast RSS feed. To do this, your application should check the feed URL within a 24-hour window. If it has been more than 24 hours, the feed should be re-checked before relying upon the Enclosure URL value.
Identifying new episodes
Applications should not use the Enclosure URL to identify new episodes. Applications should use the uniquely generated GUID value found in all Blubrry-managed RSS feeds to identify when a new episode was found and can be automatically downloaded. The GUID value is designed to be persistent through changes to the media file, albeit for various reasons such as hosting-service changes or episode updates.
Automatic download unsubscribe behavior
Applications that automatically download the latest episodes should automatically stop auto-downloading once five consecutive episodes have been downloaded but never played in the application.
New subscribers, never auto-download all episodes
When a listener subscribes to a podcast in your application an automatic download is configured, only auto download the latest episode. If a listener wants to download the entire back catalog, they should do so on a per-episode basis at the time they plan to consume it. Such function should be presented to the user as a feature to prevent the following consequences:
- Creates unnecessary bandwidth spikes which could negatively impact the bill of the podcast host.
- Devices will most likely use significant battery life to download the excessively large number of episode media files.
- Device storage may become full from the excessively large number of downloaded episode media files.
Taking these steps saves on bandwidth costs, as most devices pay for bandwidth on a per MB or GB for their bandwidth use in a given month. Leaving the archive of episodes to be consumed on demand is optimal for both the user’s experience as well as for the perceived performance and health of your application.
Application user-agent recommendations
Mobile and Desktop applications where controls and libraries are used to play or download media should specify their own user agents. For example, using the OkHttp or NSURLConnection objects in Android or IOS should specify their own user agents to identify their application. When applications do not specify their own user agent, the above examples of Blubrry’s Statistics system will only be able to identify Android or IOS. Applications using the library’s default user-agent may be excluded from Blubrry Statistics reporting in lieu of the application not being identified.
Structuring your user-agent string
Include just enough information in the user agent string to identify the application. Once the user agent is established for the application, do not deviate from the scheme to guarantee that the application is reported appropriately.
Recommended structure:
<app name>/<app version><device info><os name>/<os version><other info>
If the application is called “Foo” for “Android” running on a Pixel 5 using the OkHttp library, your user agent could look like:
Foo/1.2.3 SamsungBrowser/8.0 Android/1.2.3 OkHttp/1.2.3
Note on device info (e.g. Pixel 5) in user agent strings: We strongly recommend excluding the device information as that may violate privacy laws in your jurisdiction. It is important to note the IAB Certification guidelines recommend including the device information in the user agent string.
At a minimum, please report the application name with app version and OS name to help differentiate your application between smart devices, iOS and/or Android.
Minimum example:
Foo/1.2.3 Android
A user agent that does not meet the minimum example may not be included in Blubrry’s Statistics reporting.
What user-agents should not include
User-agent strings should not include user identifiable information or device / user session IDs that are unique to the device or network. Remember, the user-agent string needs to be consistent for accurate reporting.
User-agent strings should not use other application’s names. In this situation, it is possible that the user agent could be miscategorized as a different app.
Have a new app and want it reported in Blubrry’s Statistics?
Great! Please contact us with the format of your user agent along with examples.
Currently excluded user-agents
The following applications and their user agents are currently excluded from Blubrry Statistics reporting. This is not a full list. Blubrry reserves the right to exclude any user-agent that it deems does not count as a play or download.
Apple WatchOS
Apple WatchOS user agents are known to cause inflated metrics. Blubrry Statistics excludes all Apple WatchOS requests from Statistics reporting.
Bots and web crawlers
User-agents that include the word “bot”, “crawler” or “spider” are automatically excluded from from Blubrry Statistics reporting.