With Ausha, you have the ability to distribute your podcast via your Ausha Website, the Ausha SmartPlayer and on listening platforms! πŸš€

If you have advanced technical knowledge or a development team that can advise you, you can create your own distribution tools, independently of the services offered by Ausha, such as an application or a player/player coded by you.

In this case, we share our best practices to ensure that your own broadcasting tools provide relevant feedback on your listening statistics.

❌ Note: if you do not have advanced development knowledge or if you use the tools directly offered by Ausha (Ausha Website, Ausha SmartPlayer, Broadcasting via Ausha), reading this article is not necessary for you.

🎬 Featuring 🎬


What you need to know about Autoplay and Preload

1/ Do not set up autoplay when a user visits the web page or application containing your own player. ❌

πŸ’‘ Why?

  • This will result in a bad experience for the user with a sound they were not expecting to hear

  • This will result in distorted listening statistics.
    A listening is counted from one full minute played. However, if the playing is not really initiated by your visitor, this would be overestimating your real audience.


2/ On your player, do not use preload (HTML attribute to be set to "none"), unless the user's intention is clearly to read the podcast. ❌

πŸ’‘ Why?
Just like autoplay, this could result in skewed listening statistics. Technically, we count the listening from one full minute played. However, if the playing / downloading is not really at the initiative of your visitor, counting a listening would be overestimating your real audiences.


What you need to know about ID3 tags

1/ On your MP3 files, use ID3v2 tags, so that the headers are located at the beginning of the podcast (not at the end). βœ…

πŸ’‘ Why?
This allows players to use the ID3 data before broadcast without having to download the full podcast file.

2/ It is recommended to limit the size of ID3 tags to 300KB and to provide a maximum size of 800x800px for images inside ID3 tags.

πŸ’‘ Why?

This will make the download faster for visitors because the file will be lighter.


What you need to know about the RSS feed

Be sure to use the GUID, and not the episode URL, title, publication date, etc. to identify new episodes in the feed that should be automatically uploaded.

πŸ’‘ Why?
GUID is an attribute precisely designed to uniquely identify an episode, and to be persistent despite changes in hosting environment, title, etc.



What you need to know about downloading episodes

1/ For a full download, request the entire file at once.
For a progressive download, request the file in increments
(byte range).

πŸ’‘ Why?

This way you can distinguish a full download from a progressive download.

2/ Do not change the URL of the audio file, do not add parameters.


πŸ’‘ Why?

This could lead to unexpected behavior or unavailability of the audio file.

3/ Don't cache podcast episodes on your servers, it will prevent statistics counting.

πŸ’‘ Why?

Ausha listening statistics counting necessarily implies that audio files hosted on Ausha are called directly at each new listening (if the file is hosted on your servers, then we won't be able to count the download).

Moreover, our CDN will make the audio files available anywhere in the world and quickly. Using Ausha files guarantees an ideal listening experience for your audience wherever they are!

4/ Use an "unsubscribe to automatic download" behavior (for example, stop automatic downloads after 5 unlistened episodes by a subscriber).

πŸ’‘ Why?

We recommend to set a number of unlistened episodes by a subscriber beyond which the automatic download is not done anymore.
Each download counts as a listening. But if the episode is not listened by the subscriber, and only downloaded automatically, the statistics would be overestimated.

5/ Don't automatically download all episodes (e.g. previous catalog / current season episodes) by default.

πŸ’‘ Why?

This creates unnecessary load on Ausha servers and consumes users' bandwidth.


What you need to know about the User Agent

πŸ‘‰ The User Agent is a string that identifies a software or application, its version and its environment (Android mobile, Windows PC, etc.)

1/ Provide enough detail in the User Agent header to allow it to be systematically differentiated from a User Agent of another application.

This should apply to both RSS feed access and audio files.


πŸ’‘ Why?

This will allow us to clearly identify all the downloads coming directly from your own player/application.
Thus, we will be able to tell you the share of the listenings made from your player on your overall audience statistics!

2/ The operating systems running the application must allow the User Agent to be modifiable when using their libraries.

3/ Platforms should avoid adding unnecessary information (such as injecting user or session credentials) to the User Agent.

πŸ’‘ Why?
If unnecessary information is added, it may be more difficult to identify the source of the listens collected from your application/its own player.
So it is better to reduce the information brought to the User Agent to ensure that the source of your downloads is well identified.

4/ It is recommended that platforms submit their User Agent value to the IAB's inclusion list.

πŸ’‘ Why?
This is so that it is not considered a bot and can be used to identify information about the device being used.

5/ If the application uses bots to index the content, it is recommended to specify a User Agent distinct from the application's User Agent and including the word "bot" to clearly identify this use case.

πŸ’‘ Why?

This will allow Ausha to exclude the downloads made by bots and not count them in your podcast's listening statistics. This is so that your audience figures are not distorted and give a realistic picture of the number of listens actually performed by your listeners / visitors.


πŸ“As a reminder, all of the above recommendations are aimed at podcast creators who wish to broadcast their show via their own listening application or player, independently of the tools provided by Ausha.
In this case, it is essential for you to work with competent web & mobile developers to accompany you in the implementation of these good practices.

πŸ“ If, on the other hand, you directly use the player proposed by Ausha, the SmartPlayer (see article "What is the Ausha SmartPlayer?"), we automatically apply all of these good practices, without any necessary action on your part.
If you don't have technical knowledge or a development team, we recommend you to prefer to use the Ausha SmartPlayer (which you can customize with the colors of your podcast 🎨🀩 ) and to embed it in a few clicks to your website!

🍿 These articles may also interest you 🍿

Did this answer your question?