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

Image for post
Image for post
Il est possible de générer des écoutes de podcasts considérées comme légitimes, via un script et une carte SIM 4G insérée dans un modem USB

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).

Image for post
Image for post
Image for post
Image for post
Environ 1000 téléchargements par jour (faux, mais certifiés), par podcast, au cours du test. Il est possible d’en générer plus : c’est expliqué comment plus loin dans l’article…

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 :

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 €

Frais mensuels : environ 30–40 €/mois

Image for post
Image for post

Le script réalisant la triche

Un simple programme, qui, en boucle, réalise ces étapes :

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.

Image for post
Image for post
Variables d’environnement (configuration) du script que j’ai développé

Comment légèrement améliorer le système

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.

Image for post
Image for post
Note : j’ai intégré le podcast 1 à partir du 27 août, et les deux autres quelques jours plus tôt

Chiffres obtenus avec 2 outils externes de mesure d’audience : Podtrac & Chartable

Image for post
Image for post

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.

Image for post
Image for post

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

Image for post
Image for post

On retrouve également bien toutes les requêtes réalisées par triche dans la 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

Image for post
Image for post

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 donc 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 !

Image for post
Image for post
Chaque ligne représente une requête (supposée d’environ 0,2 Mo). Le nombre après “200” représente le nombre d’octets transférées par le serveur.

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. Je n’ai cependant pas fait le test (j’aurai dû payer 1500 € HT auprès de l’organisme…)

Image for post
Image for post

Cependant si on regarde les classements de Podtrac (pour les Etats Unis), difficile de rattraper ce niveau d’audience…

Image for post
Image for post

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

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 :

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).
Je produis un podcast mensuel sur le monde radiophonique : Des Ondes Vocast. À chaque épisode, il est question d’actualité, d’innovation et technologies autour de la radio et du podcast, en plus d’une partie sur l’histoire du média illustrée avec des extraits d’archives.
Mail : anthony@vocast.fr

Cet article est également disponible en audio pour les membres Des Ondes Vocast Premium.

Image for post
Image for post

Written by

Vocast Project : Podcast / Radio - https://www.vocast.fr

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store