Comment Omny Studio filtre et mesure les indicateurs analytiques
Omny Studio propose une gamme de rapports analytiques permettant aux éditeurs de comprendre quel, quand, où et comment leur contenu audio est téléchargé et écouté. Le système analytique mesure les téléchargements de contenu, les abonnés RSS aux podcasts et la consommation de contenu sur un large éventail de points de terminaison de publication.
En raison de la nature des lecteurs de podcasts populaires tels qu’Apple Podcasts, de la mise en cache en arrière-plan, des téléchargements progressifs et des identifiants d’auditeurs limités, les demandes de serveur de téléchargement de podcasts peuvent ne pas refléter avec précision le nombre de personnes uniques qui ont lu le contenu.
Pour s’assurer que les indicateurs peuvent être définis et mesurés de manière cohérente dans l’ensemble du secteur, l’IAB a publié des directives sur la manière dont les analytique de podcast doivent être filtrées et mesurées. La mise en œuvre réelle de ces lignes directrices variera d’un fournisseur à l’autre en raison de différences techniques ou de conception pratiques. Ce document décrit les différentes techniques de filtrage utilisées par Omny Studio.
Remarque : Étant donné que nous affinons continuellement nos paramètres de filtrage et que nous expérimentons des méthodologies pour améliorer la précision de nos mesures, le présent document peut être modifié de temps à autre pour refléter tout changement dans notre approche.
Filtrage analytique des téléchargements
Download analytique suit les téléchargements de tous les fichiers audio publiés, y compris, mais sans s’y limiter, les lecteurs de podcasts, les lecteurs intégrés et les applications et sites Web tiers. Le filtrage suivant s’applique aux fichiers de connexion que nous collectons et analysons à partir des différents réseaux de distribution de contenu que nous prenons en charge.
Ignorer les requêtes HTTP non-GET
Nous ne prenons pas en compte les requêtes HTTP avec une méthode autre que « GET » dans le calcul des requêtes de téléchargement.
Nous ne comptabilisons pas ces téléchargements car nous avons observé que certains lecteurs de podcasts utilisent la méthode de requête HTTP « HEAD » pour télécharger les métadonnées des fichiers sans télécharger de contenu audio.
Ignorer les réponses qui n’aboutissent pas
Nous ne prenons pas en compte les requêtes HTTP qui n’ont pas eu de réponse positive. Plus précisément, nous ne comptons que les réponses avec un code d’état HTTP ou 200 OK ou 206 Partial Content.
Nous ne prenons pas en compte les requêtes HTTP dont la réponse a été redirigée, non modifiée ou erronée comme des téléchargements.
Ignorer les demandes de plage HTTP hors lecture instantanée
Nous ne prenons pas en compte les requêtes de plage HTTP avec une plage allant de 0 à 1, une plage de 0 octets ou une plage invalide. (Nous compterons les demandes sans plage spécifiée)
Nous ne comptabilisons pas ces téléchargements car nous avons observé que certains lecteurs de podcasts utilisent une requête 0-1 pour vérifier si le serveur prend en charge les demandes de plage sans télécharger de contenu audio.
Ignorez les robots et les araignées connus
Nous ne comptons pas les demandes de téléchargement avec un agent utilisateur d’application identifié comme étant un robot ou une araignée connu.
Nous ne comptabilisons pas ces téléchargements car les robots et les araignées téléchargent régulièrement des fichiers à des fins d’indexation et ne sont pas des auditeurs.
Nous utilisons la base de données open-source « UA-Parser » user-agent améliorée avec des données propriétaires supplémentaires pour analyser les agents utilisateurs. Cette base de données est régulièrement mise à jour pour détecter les nouvelles applications de podcast et les robots au fur et à mesure qu’ils sont documentés.
Ignorer les agents utilisateurs invalides ou bannis
Nous ne comptabilisons pas les demandes de téléchargement sans agent utilisateur ou si elles correspondent à une liste d’agents utilisateurs que nous avons identifiés comme étant intentionnellement ou non des applications problématiques.
Nous ne prenons pas en compte ces téléchargements car nous avons observé que certains lecteurs et applications mobiles génèrent un nombre excessif (par exemple 100) de demandes de téléchargement qui ne sont pas corrélées avec des auditeurs.
Ignorer les fournisseurs de services cloud ou les adresses IP bannies
Nous ne comptabilisons pas les demandes de téléchargement à partir d’une liste d’adresses IP que nous avons identifiées comme étant des serveurs de services tiers, de mise en cache de contenu et de fournisseurs de services cloud.
Nous ne prenons pas en compte ces téléchargements car les services tiers téléchargent des fichiers à des fins de mise en cache et de mise en miroir et n’ont pas de corrélation avec les auditeurs.
Notre base de données de plages d’adresses IP de fournisseurs de services cloud comprend :
Amazon AWS
Cloudflare
DigitalOcean
Fastly
Google Cloud
Microsoft Azure
OVH
Triton Digital
TuneIn
Cette base de données de plages d’adresses IP est régulièrement mise à jour avec les listes officielles publiées par les fournisseurs et les plages d’adresses IP enregistrées par le fournisseur sur l’American Registry for Internet Numbers (ARIN).
Ignorer les doublons de téléchargements par session unique
Nous ne comptabilisons pas les demandes de téléchargement en double provenant d’une session unique identifiable (définie ci-dessous) dans une fenêtre UTC de 24 heures (de minuit UTC à minuit). Les téléchargements multiples à l’intérieur de la fenêtre de déduplication ne seront comptabilisés qu’une seule fois.
En raison du nombre limité d’identifiants d’auditeurs disponibles dans les applications de podcast, nous combinons et hachons les données suivantes afin d’identifier au mieux les sessions uniques :
Date UTC
Adresse IP (IPv4 ou IPv6* si disponible)
Agent utilisateur
Episode ID
* Les adresses IPv6 sont tronquées aux 64 premiers octets
Ignorer les téléchargements partiels avec moins d’une minute de contenu audio
Nous ne comptabilisons pas les demandes de téléchargement dont la quantité de données transférées au cours d’une session unique identifiable (définie ci-dessus) est inférieure à une minute de contenu audio.
Nous calculons le seuil minimum de transfert de données en multipliant le débit binaire MP3 par 60 secondes plus la taille des en-têtes de métadonnées et ID3 (au début du fichier). Pour les fichiers audio de moins de 60 secondes, le seuil correspond à la taille du fichier entier.
Pour chaque session unique, nous combinons le nombre d’octets livrés avec succès du serveur au client pour une ou plusieurs requêtes. Lorsque le nombre total d’octets livrés de la session est égal ou supérieur au seuil minimum, il est compté comme un téléchargement avec l’horodatage de la première demande de la session.
Fichiers mis en cache sur d’autres plates-formes
Certaines plateformes syndiquées et certains services tiers (par exemple, Google Play, Podcast et Spotify) peuvent mettre en cache des fichiers sur leurs propres plateformes. Les lectures sur ces plateformes n’enregistreront pas de téléchargement sur notre serveur. Conformément aux directives de l’IAB, nous avons recommandé aux plateformes de ne pas mettre les épisodes en cache et de toujours les récupérer à partir de l’URL jointe.
Dans la mesure du possible, nous intégrerons et afficherons ces mesures séparément pour les télécharger sur nos tableaux de bord analytiques.
Lecteurs, applications et plateformes tiers
Les directives de mesure des podcasts de l’IAB recommandent l’utilisation de lecteurs de podcasts tiers
Ne pas activer la lecture automatique. Cela se traduira par une mauvaise expérience pour l’utilisateur avec un programme qu’il ne s’attendait pas à entendre.
Ne pas précharger, sauf si l’intention était clairement d'écouter le podcast.
Utilisez les informations de l’en-tête situées au début du podcast afin d'empêcher le téléchargement complet lorsqu’il n’est pas nécessaire.
Pour un téléchargement complet, demandez le fichier complet en une fois. Pour un téléchargement progressif, demandez le fichier en tranches (plages d'octets). Cette méthode permet de distinguer les téléchargements complets des téléchargements progressifs.
Ne pas modifier l’URL joint lors de la demande de média, ne pas ajouter de paramètres supplémentaires.
Ne stockez pas vos épisodes de podcast en mémoire cache sur vos serveurs. Téléchargez toujours le dernier épisode depuis l'URL actuel pour chaque utilisateur d'appli qui souhaite l'écouter.
Utiliser le GUID, et non l’URL, le titre, la date de publication de l’épisode, etc., pour identifier les nouveaux épisodes du flux RSS qui doivent être automatiquement téléchargés sur l’appareil d’un utilisateur. Le GUID est conçu pour être constant, même lorsque l'environnement d'hébergement et les titres changent.
Utiliser un comportement de « désabonnement automatique du téléchargement » (p. ex., arrêter le téléchargement automatique après 5 épisodes non écoutés).
Ne télécharge pas automatiquement tous les épisodes (p. ex. l'ancien catalogue des épisodes) par défaut. Cela surcharge sans raison les serveurs des éditeurs et gaspille la bande passante des utilisateurs.
Ils font également les recommandations suivantes concernant la structure des agents utilisateurs d’un lecteur de podcast, l’agent utilisateur doit
Fournir suffisamment de détails dans l’en-tête de l’agent utilisateur pour lui permettre d’être systématiquement différencié de l’agent utilisateur des autres périphériques. Dans la mesure du possible, cela doit s’appliquer à la fois aux flux RSS et aux fichiers audio.
Éviter d’ajouter des informations inutiles (telles que l’injection d’ID d’utilisateur ou de session) à la chaîne de l’agent utilisateur et dans les pratiques d’encodage.
Il est recommandé aux plates-formes de soumettre la valeur de l’en-tête de leur agent utilisateur à la liste d’inclusion des araignées et des robots de l’IAB afin qu’elle ne soit pas considérée comme un bot et qu’elle puisse être utilisée comme un signal utilisé pour déterminer les informations de l’appareil.
Si l’application ou la plateforme utilise des robots pour indexer le contenu, il est recommandé de spécifier un agent utilisateur distinct de l’agent utilisateur de l’application et d’inclure le mot « robot » pour identifier clairement son cas d’utilisation.
Le format recommandé est le suivant :<app name>/<app version> <device info> <os name>/<os version> <other info>
Par exemple : AppName/1.2.3 DeviceBrand DeviceModel OSName/1.2.3 LibName/1.2.3
Filtrage analytique de la consommation
L’analytique de consommation suit le comportement de lecture du contenu audio dans les lecteurs intégrés Omny Studio et les lecteurs tiers qui ont mis en place notre API de lecteur de analytique de consommation.
Nous utilisons le suivi côté client des événements des joueurs tels que la lecture, la pause et la recherche pour générer des rapports comportementaux tels que le nombre de personnes qui ont écouté, combien de temps elles ont écouté et quelles parties du contenu elles ont écoutées.
Identification des sessions de lecture instantanée
Nous utilisons un identifiant global unique (GUID) pour identifier les sessions de lecture instantanée uniques.
Une mise en pause et une recherche répétées dans le même contenu ne seront pas considérées comme une nouvelle session de lecture instantanée. Cependant, le rechargement du lecteur ou la modification du contenu (dans une liste de contenu) sera considéré comme une nouvelle session, même si l’utilisateur a déjà écouté le contenu auparavant.
Ignorer les sessions de moins de 60 secondes
Nous ignorons toutes les sessions de lecture dont la durée totale est inférieure à 60 secondes.
Nous incluons des sessions non consécutives telles que deux segments de 0h00 à 0h05 et de 0h30 à 0h36. Cette session sera comptabilisée puisque la durée totale de tous les segments était de 11 secondes.
Nous ne comptons pas les sessions de moins de 60 secondes afin de nous conformer aux directives de l’IAB.