Mesure d’audience des podcasts : un nouveau modèle pour détecter les milliers de téléchargements truqués mais “certifiés IAB” que j’ai obtenu
Pendant plusieurs jours d’expérimentation, j’ai réussi à obtenir des chiffres d’audience truqués mais certifiés selon les règles de l’IAB.
Je précise que je n’en ai nullement tiré profit, et je n’incite personne à le faire pour s’enrichir. Le plus important est à retrouver en dernière partie de l’article : les pistes pour détecter ce type de fraude.
English version here
L’idée : falsifier les requêtes envoyées aux serveurs
Le sujet de la mesure d’audience des podcasts est épineux. Il y a déjà eu des affaires de chiffres gonflés, révélées par Podnews. Dans ces cas précis, il était nécessaire d’avoir du trafic web important sur une de ses interfaces pour le faire également considérer comme de l’audience pour ses podcasts. La fraude était facilement détectable du fait qu’une grande partie des écoutes provenaient d’applications web (alors qu’en général Apple Podcasts représenterait environ 60% des téléchargements).
Mais ici, il s’agit de faire en sorte d’avoir des milliers de téléchargements “certifiés IAB”, seulement avec un modem 4G USB connecté à un Raspberry Pi exécutant un script ! Les chiffres sont autant validés via Podtrac et Chartable que par des hébergeurs comme Spreaker (tous les 3 ayant reçu la certification de l’IAB).
Aujourd’hui, pour la mesure d’audience des podcasts, il n’y a que les spécifications de l’IAB qui font consensus. Celles-ci sont limitées à l’analyse du trafic côté serveur, c’est-à-dire où sont hébergés les fichiers audio. La mesure d’audience côté “client” n’est pas standardisée, du fait que les nombreuses plateformes de lectures (Apple Podcasts, Spotify, …) ont leurs propres méthodologies et n’ouvrent pas uniformément les accès aux données de lecture.
Ainsi, le secteur du podcast n’a qu’un seul indicateur de performance clé à sa disposition : le “nombre de téléchargements”, calculé à partir des logs serveurs. Le document technique réalisé par l’IAB apporte des exigences concernant l’exclusion du trafic de robots, la non-considération des téléchargements dupliqués, entre autres.
Pour résumer (très) grossièrement, un téléchargement est considéré comme valide si c’est une requête sur le serveur :
- Depuis une IP non répertoriée comme provenant de datacenters connus comme ceux d’AWS, en s’assurant que cette IP n’est pas responsable d’un grand nombre de requêtes
- Provenant d’une application de lecture légitime (un User-Agent d’Apple Podcasts valide, et non d’un navigateur web obsolète par exemple)
- Dont la charge transférée en nombre d’octets dépasse l’équivalent d’au moins une minute d’audio
La quantité de triplets “IP / User Agent / Fichier Audio” uniques détermine le nombre de téléchargements selon l’IAB.
Comment concrètement manipuler les résultats
J’ai réalisé cette expérimentation chez moi (en France), pendant plusieurs dizaines de jours. J’ai tenté de gonfler les audiences de trois podcasts différents, que j’ai créé et qui ne sont pas censés enregistrer un nombre significatif d’écoutes autrement que via le système de triche. Ces trois podcasts sont hébergés au moyen de trois solutions distinctes : Acast, Ausha, Spreaker. Deux des podcasts sont diffusés sur Apple Podcasts & Spotify (ils n’avaient jusqu’alors que très peu d’écoutes), et un autre n’est diffusé sur aucune plateforme de podcasting. Les deux présents sur Apple Podcasts ont ainsi pu être mesurés avec Chartable.
Matériel et abonnements nécessaires
Noter que cet ensemble peut être dupliqué autant de fois que voulu pour optimiser (augmenter) le nombre de téléchargements.
Frais d’installation : environ 130 €
- Un modem USB 4G. J’ai testé avec une clé HUAWEI LTE USB Stick E3372 (50 €)
- Un dispositif pouvant accueillir le modem 4G et faire tourner le script de triche. J’ai opté pour un pack Raspberry Pi + chargeur + SD (80 €)
Frais mensuels : environ 30–40 €/mois
- Pour disposer d’une base de donnée d’User Agents complète, j’ai opté pour un abonnement à WhatIsMyBrowser (Plan “Pro”, 12 €/mois). Un même compte peut être partagé entre plusieurs instances.
- Abonnement mobile avec une enveloppe de données 4G généreuse. En France, il est possible d’avoir un forfait 4G illimité auprès de Free Mobile, pour 16 € par mois pour les abonnés Freebox. J’ai aussi testé avec un forfait 200 Go pour 20 €/mois avec Prixtel.
Le script réalisant la triche
Un simple programme, qui, en boucle, réalise ces étapes :
- Sélection d’un nombre aléatoire d’épisodes depuis un (ou plusieurs) flux RSS. J’ai mis en place des mécanismes pour que les comportements d’écoutes simulés soient réalistes. Par exemple, plus le contenu est récent, plus il a de probabilités d’être choisi.
- Sélection d’un User-Agent en piochant dans la base de données de WhatIsMyBrowser. Le script est conçu pour pouvoir configurer comme bon nous semble X% de requêtes via un User-Agent d’Apple Podcasts, Y% de Spotify, etc.
Les User-Agents liés à l’Apple Watch ne sont pas pris en compte, au vu de la dernière directive de l’IAB à ce sujet. - Requêtes des URLs sélectionnées en étape 1 avec l’User Agent de l’étape 2 en en-tête HTTP. Le script ne requête qu’un 1 Mo de données, et interrompt la connexion. Cela permet d’économiser de la donnée mobile tout en ayant téléchargé une minute d’audio, limite minimale pour que le téléchargement soit valide selon l’IAB (je fais l’approximation 1 MB =1 minute d’écoute pour un MP3 à 128 kbit/s)
- (optionnel) Stockage de l’information de requête dans une base de donnée (variables IP, UA, épisode, etc.), pour du monitoring
- Redémarrage du modem 4G, pour obtenir une nouvelle adresse IP.
- Attendre d’avoir de nouveau une connexion Internet. Je propose aussi d’attendre un certain nombre de secondes supplémentaires en fonction du jour et de l’heure (configuration avec la grammaire d’OpenStreetMap opening_hours). Cela permet de maîtriser le nombre de téléchargements au fil du temps, et créer des “pics” de téléchargements le matin et le soir, avec peu d’écoutes la nuit par exemple.
Le service est ainsi configuré pour obtenir de nombreuses IP différentes (obtenues via le réseau 4G), et simuler des écoutes issues d’applications de podcasting. Cela permet de créer artificiellement de multiples auditeurs uniques.
La limite du système réside dans le temps de récupération d’une nouvelle adresse IP. D’après mes tests, il faut compter environ 45 secondes pour cette étape-là.
Mais il suffit d’avoir plusieurs abonnements 4G (de différents opérateurs, c’est encore mieux) pour monter à échelle. Pour augmenter le nombre de téléchargements, il est aussi possible de définir un plus grand nombre maximal de téléchargements par boucle. J’ai mis 10 pour que le comportement soit réaliste (et donc il y a entre 0 et 10 téléchargements par flux RSS à chaque exécution), mais il est possible de mettre n’importe quelle limite.
Comment légèrement améliorer le système
- Disposer de sa propre base de données d’User Agents. J’ai utilisé un service externe pour aller plus vite.
- Réaliser des requêtes avec des quantités de données transférées différentes (ne pas interrompre à partir d’une quantité fixe à chaque fois)
Analyse des différents résultats
J’ai stocké chaque requête simulant une écoute dans une base de donnée. À partir de ces informations, j’ai pu construire un tableau de bord donnant une vue d’ensemble des téléchargements réalisés.
Chiffres obtenus avec 2 outils externes de mesure d’audience : Podtrac & Chartable
On retrouve globalement l’ensemble des requêtes effectuées par le système de triche en tant que “Downloads” sur Podtrac et Chartable. On voit bien aussi sur Chartable qu’on arrive à réaliser des “pics” d’audience à la publication d’un épisode. Je n’arrive pas à expliquer pourquoi Chartable a retiré autant de téléchargements uniquement le 7 septembre.
Acast Open : ensemble des requêtes comptabilisées (à l’exception de celles provenant d’un UA de Spotify)
Les chiffres affichés via l’interface d’Acast correspondent bien avec les nombres de téléchargements (“Downloads”) effectués avec le système de triche, en excluant toute requête simulant une écoute depuis Spotify.
Pour le moment, les statistiques d’Acast Open ne sont pas certifiées par l’IAB. C’est Acast “Pro” qui a obtenu la certification. Je n’ai pas testé d’intégrer Acast Marketplace pour voir si ces faux téléchargements seraient vendus en tant qu’écoutes certifiées par l’IAB.
MAJ 30/09 : J’ai pu réaliser un rapide test avec Acast Pro, et les téléchargements truqués sont bien pris en compte (aggrégation IP-UA). Les preuves en images ici.
Ausha : aucune détection de triche non plus
On retrouve également toutes les requêtes réalisées par triche dans le tableau de bord d’Ausha. Les User Agents ne sont pas systématiquement interprétés comme attendu, mais c’est un détail. Puisque j’ai obtenu un nombre significatif d’écoutes, l’accès à la monétisation automatique (placement de pubs par l’hébergeur) m’a ainsi été rendu disponible ! Mais je ne sais pas si j’aurais réellement pu gagner de l’argent. Peut-être que des vérifications en amont auraient été faites.
Spreaker : “IP-UA-Datetime” distincts pour les téléchargements
Avec Spreaker, j’ai tendance à penser que le nombre de téléchargements est équivalent au nombre de demandes que le système de triche a exécuté. Mais avec une agrégation spécifique : s’il y a deux téléchargements avec la même IP, User-Agent et la même date (même valeur YYYY-MM-DD HH:mm:ss), un seul téléchargement semble compté.
Le nombre d’auditeurs semble correspondre au nombre de paires “IP-App” uniques. Pour expliquer pourquoi les chiffres ne sont pas vraiment les mêmes, je dirais que ma propre classification des plateformes à partir d’un User Agent est trop basique (App = “Apple Podcasts”, “Spotify”, “Web Browser”, “Alexa”, “Castbox” ou “Others”).
Les chiffres fournis par cet hébergeur sont censés être “certifiés IAB”. Toutefois, tout comme Podtrac et Chartable, les requêtes dont la charge utile est bien inférieure à 1 Mo (1 minute de son, MP3 128kbit/s) sont souvent prises en compte. À noter cependant une baisse significative les 12 et 13 septembre, journées durant lesquelles les requêtes ont été interrompues avec une limite très basse (100 KB, et non 1 Mo).
Des requêtes d’écoutes inférieures à 1 min comptabilisées !
J’ai aussi réalisé des tests en changeant la limite du nombre d’octets enclenchant l’interruption des requêtes sur les serveurs qui hébergent les épisodes audio.
À ma grande surprise, des téléchargements étaient quand même bien comptabilisés alors qu’ils ne devraient pas, puisque l’IAB demande à ne considérer que les écoutes d’au moins une minute.
Mais ce n’est pas forcément une erreur. Considérons cette limite à 1 Mo (= 1 MB, 1 minute d’écoute pour un MP3 à 128 kbit/s). Il y a de fortes chances que cette faible quantité de données soient déjà transférées par le serveur, avant l’interruption quasi instantanée des requêtes. J’ai réalisé un simple test avec des requêtes sur mon serveur personnel, hébergé en France. Et avec plusieurs requêtes exécutées depuis le même pays, où environ 0,2 Mo sont reçues (et donc facturées au niveau des données mobiles), du côté serveur le nombre de données transférées est bien plus élevé : entre 0,4 et 1,3 Mo !
Cette triche peut-elle vraiment faire d’un podcast un réel succès artificiel ?
En théorie, puisqu’on peut espérer “sans trop forcer” obtenir 30 000 téléchargements par mois et par podcast — pour UN abonnement 4G — , les émissions pourraient être aisément classés en haut du classement des podcasts de l’ACPM.
MAJ 20/11 : Je n’ai pas fait le test personnellement (j’aurai dû payer au moins 750 € HT auprès de l’organisme…), mais j’ai pu réaliser une opération validant le fait que l’ACPM ne détecte pas la fraude. Me contacter pour avoir les preuves.
Si on regarde les classements de Podtrac (pour les Etats Unis), difficile de rattraper ce niveau d’audience…
Au niveau des applications de podcasts comme Apple Podcasts ou Spotify, les classements ne sont pas affectés par ce système de triche (puisqu’il n’y a aucune activité manipulée depuis ces plateformes).
Les limites de ce type de contournement
- Les statistiques fournies par les plateformes de lecture via Apple Podcast Connect, le tableau de bord de Spotify for Podcasters, le nombre de lectures total sur Castbox, et autres mettent en évidence que les chiffres sont faux.
- Ce système de triche est plutôt adapté pour des podcasts quotidiens, car pour plus de réalisme il faut créer des pics d’audience significatifs à la sortie de nouveaux épisodes.
- Si la totalité du trafic vient du même opérateur (même plage d’IP), c’est suspect. Mais il suffit d’avoir plusieurs installations, avec des forfaits 4G de plusieurs opérateurs téléphoniques différents pour que cela soit moins flagrant.
- Il n’est pas possible de maîtriser les valeurs des adresses IP. Selon les opérateurs, le nombre d’IPs différentes et la récurrence (réassignation d’une adresse) peut être totalement différents. La localisation associée également ne peut pas être contrôlée : avec Free les IPs étaient associées à toutes parts de la France, alors qu’avec Prixtel (réseau Orange, depuis Toulouse) elles correspondaient généralement aux principales villes du quart Sud-Ouest de la France.
- Risque d’être bloqué par les opérateurs téléphoniques pour usage abusif. Et si le processus s’arrête, il y a une grosse chute des audiences, ce qui paraît aussitôt étrange.
- Un si grand nombre de requêtes avec peu de données transférées à chaque fois est suspect. Mais dans le cas où les épisodes sont courts (exemple : des flashs infos, pour un podcast quotidien), cela ne peut pas être détecté.
Quelle méthodologie pour avoir des chiffres moins facilement truquables ?
Intégrer une métrique relative à la quantité de données transférées (donnant une sorte de durée totale d’écoute) ?
Le processus de triche présenté dans cet article est limité par le temps de renouvellement d’adresses IP, et cela peut s’arranger en se procurant de multiples abonnements 4G. Mais en réalité la limitation réside surtout vis à vis de l’enveloppe de données mobile disponible… Il y a encore très peu de forfaits avec un accès illimité à Internet, les abonnements restent encore assez chers.
Dans le cas où on prendrait en compte la durée totale d’écoute, en fonction du bitrate et du nombre d’octets que le serveur a transféré, la triche serait moins intéressante.
Si on devait adapter cette triche pour les webradios par exemple. En France et au vu du classement des “radios digitales” de l’ACPM, le nombre de sessions à générer est élevé pour être au sein des premières places. Mais surtout, puisqu’il s’agit de flux en streaming, il est possible aussi de classer les webradios en fonction de la durée totale d’écoute. Le classement serait différent, et à mon sens plus juste, s’il était ordonné justement selon cet indicateur.
Un forfait de 200 Go n’apporterait qu’entre 3000 et 7000 heures d’écoute (selon la qualité du flux, et autres paramètres…). Le système de triche présenté n’est donc pas intéressant dans ce cas précis.
En radio on parle d’AC, de DEA et de PDA (“audience cumulée”, “durée d’écoute auditeur” et “part de marché”) pour distinguer le nombre d’auditeurs du volume d’écoute global.
Pourquoi ne pas intégrer une distinction similaire pour les podcasts ? Le mécanisme de triche serait moins efficace car limité par le nombre de données à transférer.
C’est une piste mais… Notons que la quantité d’octets sortant du serveur ne reflète pas la durée réelle d’écoute côté auditeur. Elle représente la durée maximale théorique de lecture, en supposant que la personne n’écoute qu’une seule fois l’épisode qu’elle vient de télécharger.
Mesures d’audience côté client
Remote Audio Data (RAD) est une spécification proposée par les équipes de R&D de NPR pour standardiser la récolte de données, depuis les interfaces de lecture. Cependant, puisqu’il est possible d’envoyer les remontées d’audience par lot, il serait théoriquement possible de trafiquer les chiffres envoyées au serveur en charge de récolter les statistiques de lecture.
Il faudrait donc définir un moyen pour authentifier la plateforme d’écoute (autrement qu’avec l’User Agent) et les données envoyées. Reste sinon la solution consistant à demander d’envoyer uniquement en temps réel une requête par nombre fixe de secondes lues (mais c’est assez fastidieux !), ou bien mesurer les écoutes via une connexion persistante “socket” (les écoutes hors ligne ne seront pas comptabiliées avec cette méthodologie).
Mais de toute façon, un tel standard côté client est loin d’être réalisable. Les statistiques des applications comme Apple Podcasts ou Spotify sont assez différentes, et ces plateformes s’enferment dans leur propre écosytème.
Et puis sachant qu’il est aussi possible de manipuler les classements sur Apple Podcasts ou bien payer pour obtenir des streams de podcasts sur Spotify…
Les pistes pour détecter ce type de fraude
Ainsi, il y a plusieurs approches possibles pour contrer les triches. L’analyse des comportements d’écoutes sur le plan macro semble être la mesure la plus pragmatique. Pour résumer :
- Comparer les chiffres obtenus côté serveur avec des chiffres disponibles côté client (Alexa, Apple Podcasts, Castbox, Google Podcasts, Google Podcasts, Spotify, …). Les applications n’ont pas à fournir les données, elles s’obtiennent à partir des identifiants utilisateurs des éditeurs/podcasteurs.
ATTENTION : Les données calculées par les applications de podcasts ne sont pas forcément plus “fiables”, et peuvent être aussi manipulées par d’autres méthodes.
Mais si les écarts avec les chiffres obtenus par les requêtes d’un hébergeur sont trop élevés, c’est un indicateur permettant de déclencher une suspicion de triche. - Analyser le nombre de requêtes partielles. S’il y a une part très élevée de téléchargements partiels, notamment avec seulement l’équivalent de quelques minutes d’audio, c’est un signe de tentative de triche. Cependant, pour des épisodes courts, les requêtes issues de triches seront quand même considérées comme des téléchargements légitimes car complets.
- Analyser la répartition du type de trafic des requêtes. Certes, il est possible de tricher en réalisant l’opération avec plusieurs abonnements 4G, de plusieurs opérateurs. Mais si la quasi-totalité des téléchargements proviennent d’IPs de réseaux mobiles, c’est bizarre. Je ne trouve pas de chiffres récents… Quelle est la proportion actuelle du trafic Internet via données mobiles vs Internet fixe, satellite, etc. ? Notons également qu’une telle manipulation pourrait être réalisée avec des VPN au lieu de la 4G. Il n’y a dans ce cas plus de limitations sur l’enveloppe de données disponible et donc la triche peut s’opérer en téléchargeant les épisodes en intégralité. Même si l’usage est de plus en plus courant, il serait sûrement plus judicieux de tenir à jour une liste d’adresses IP provenant de VPN, et les exclure, ou du moins vérifier la proportion des écoutes via ce type d’infrastructure réseau.
C’est un travail compliqué et à réaliser au jour le jour, c’est sûr… Un jeu du chat et de la souris, que beaucoup d’autres acteurs ont du mal à combattre (Netflix notamment)
Un ensemble assez hasardeux d’indicateurs “suspects” donc, mais pas de méthodologies claires pour établir un nombre exact de téléchargements, résistant à ce type de fraude. Mais justement, et si le problème venait de là : la volonté de ne donner que des chiffres bruts, sans contexte, sans qualification de l’audience ?
Les données d’audience servent essentiellement à structurer le marché publicitaire, dans un but d’harmonisation, mais surtout aussi de transparence. Et pourquoi ne pas garder les règles de l’IAB, qui sont en réalité difficilement améliorables, mais accompagner le nombre de téléchargements d’une sorte de “scores” de qualification de l’audience ?
Un système qui donnerait un résultat du genre :
=> Vous avez XXX téléchargements, avec XX% de confiance. Nous estimons entre XXX et XXX le nombre de téléchargements réels
(*ceci est une estimation, selon nos règles de qualification de l’audience. Vous pouvez retrouver clairement la méthodologie — libre d’accès — qui permet de calculer ces résultats)[[Corrélation côté client::Red flag]]
L’éditeur a fourni ses identifiants pour les applications de podcasts suivantes : XX, XX, XX.
À partir des données accessibles (depuis APIs et/ou tableaux de bord propriétaires), nous avons trouvé des différences trop importantes entre les chiffres côté serveur et ceux fournis par les différentes applications de podcast
OU
[[Corrélation côté client::Orange flag]]
Pas d’accès aux données d’applications de podcasts suivantes : XX, XX. L’éditeur n’a pas fourni ses identifiants et/ou pas de données disponibles. Il y a un risque de triche.[[Téléchargement partiels:: Red flag]]
Les auditeurs semblent télécharger en moyenne XX% des épisodes, ce qui semble bien trop faible.
OU
[[Épisode courts:: Orange flag]] Les fichiers sont de petites tailles, ce qui fait qu’une triche pourrait avoir lieu sans que nous le détections avec un “red flag”.[[Diversité des sources de trafic réseau : Red flag]] La majorité des téléchargements sont réalisés à partir de réseaux mobiles et/ou de VPNs.
(… et sûrement d’autres indicateurs et classifications à établir…)
Ceci est loin d’être parfait, mais permet d’apporter plus de confiance dans les chiffres. Ces indicateurs permettent clairement de définir la typologie de l’audience. Les règles de calcul, déterminant les scores, doivent être établies avec précaution et surtout en totale transparence. C’est un travail collégial qu’il faut…
Les résultats des nombres de téléchargements tout comme des “scores de qualification” doivent être clairement explicités, et retrouvés par quiconque à partir de logs serveur. Dans la mouvance du projet “oDL” de Podsights.
Contact
Anthony GOURRAUD, Ingénieur Innovation Média.
“Creative technologist” français, passionné par la radio (broadcast & podcasting).
ITW sur Planète Ingé
On parle de cet article dans un podcast dédié à l’actualité des ingénieurs, Planète Ingé : https://planeteinge.fr/quel-futur-pour-les-medias-dans-un-monde-domine-par-les-ia-anthony-gourraud
