+150 XP

Audits de qualité des données : repérer les bots, les IDs dupliqués et les pipelines cassés avant qu'ils ne faussent les décisions

Une plateforme de streaming a un jour constaté un bond de 40 % des plays sur un documentaire de milieu de catalogue, du jour au lendemain. Personne ne l'avait marketé. Personne ne l'avait licencié sur un nouveau territoire. La cause, découverte trois semaines plus tard : une ferme de bots bouclait le titre pour toucher des commissions de parrainage liées à un accord de bundle avec un opérateur télécom régional. Le temps que l'anomalie soit détectée, le titre avait déjà été greenlighté pour une deuxième saison sur la base d'un signal de demande fictif. En média, une défaillance de qualité des données coûte plus cher que de mauvais chiffres : elle coûte les décisions construites dessus.

Cette leçon détaille comment auditer un catalogue de contenus et des logs de visionnage comme devrait le faire une équipe data ou analytics, avant que ces chiffres n'arrivent dans une réunion de greenlight ou un deck investisseurs.

Pourquoi les données média cassent plus que dans d'autres secteurs

Les pipelines de données média sont exceptionnellement fragiles, pour quelques raisons structurelles :

  • Métadonnées à forte cardinalité. Un même titre peut avoir une douzaine d'IDs (ID studio, ID distributeur, ID interne de la plateforme, EIDR, un identifiant standard de l'industrie pour les films et épisodes de séries) le long de la chaîne, et ils ne correspondent souvent pas entre eux.
  • Demande générée par des machines. Les bots, scrapers et click farms visent les données du streaming et de l'ad-tech parce que les plays, vues et impressions se convertissent souvent directement en argent (revenus publicitaires, droits de licence, promotion algorithmique).
  • Pipelines fragmentés. Les logs de visionnage, les métadonnées du catalogue et les données de droits vivent généralement dans des systèmes séparés (un CMS pour le contenu, un CDN pour la diffusion, un entrepôt BI pour l'analytics), reliés par des jobs ETL (Extract, Transform, Load) qui cassent silencieusement.

Les jeux de données que vous auditez

Avant d'auditer la qualité, sachez ce que vous regardez réellement.

Données de catalogue de contenus : métadonnées de titre (genre, durée, casting, date de sortie, droits par territoire, pistes audio). La source de vérité est en général le studio ou le système de gestion de contenu de la plateforme.

Logs de visionnage / engagement : événements horodatés (début de lecture, pause, complétion, skip) au niveau de la session utilisateur. C'est le jeu de données le plus brut et le plus volumineux, souvent des milliards de lignes par jour pour un grand streamer.

Données de droits et de licences : sur quels territoires, fenêtres et plateformes un titre est autorisé. Les erreurs ici créent une exposition en matière de conformité, pas seulement du bruit dans le reporting.

Données de delivery et de mesure publicitaire : impressions, viewability, taux de complétion, vérifiés par des tiers comme Nielsen aux États-Unis ou BARB au Royaume-Uni pour la mesure convergente linéaire/streaming.

Étape 1 : détection des IDs dupliqués

Les IDs de titre dupliqués sont l'erreur de catalogue la plus fréquente. Elle survient quand le même contenu est ingéré deux fois, une fois depuis un flux studio et une fois depuis un flux de distributeur régional, avec des clés internes différentes.

Une requête d'audit simple ressemble à ceci :

sql
SELECT title_name, release_year, COUNT(DISTINCT internal_title_id) AS id_count
FROM content_catalog
GROUP BY title_name, release_year
HAVING id_count > 1;

Si cela renvoie des centaines de lignes pour un catalogue de 20 000 titres, vos métriques d'engagement sont probablement mal comptées : chaque ID dupliqué fragmente le vrai nombre de vues sur deux lignes, sous-estimant la performance réelle d'un titre, ou pire, un ID est poussé dans les recommandations tandis que l'autre reste à zéro donnée, faussant les modèles de personnalisation.

Correctif : imposer un identifiant canonique unique. EIDR (Entertainment Identifier Registry) est ce qui s'approche le plus d'un standard de l'industrie pour cela, dans le même esprit qu'un ISBN pour les livres.

Étape 2 : détection des bots et de la fraude dans les logs de visionnage

Les plays gonflés par des bots apparaissent sous forme de motifs statistiquement anormaux :

  • Nombre de plays par utilisateur et par heure invraisemblablement élevé
  • Durées de session identiques à la milliseconde près, sur des milliers de sessions
  • Concentration géographique incohérente avec l'empreinte marketing du titre
  • Taux de complétion proches de 100 % pour des types de contenus (longs documentaires, films en langue étrangère) qui affichent normalement un fort décrochage

Un flag d'anomalie basique : comparer le ratio plays par device unique d'un titre à la médiane du catalogue.

python
median_ratio = df['plays'].sum() / df['unique_devices'].nunique()
title_ratio = title_df['plays'].sum() / title_df['unique_devices'].nunique()

if title_ratio > median_ratio * 5:
    flag_for_review(title_id)

Cela n'attrapera pas la fraude sophistiquée, mais cela attrape les cas grossiers à fort volume qui déplacent réellement les décisions business, ceux qui font renouveler un titre ou réaffecter un budget marketing sur un faux signal.

L'industrie publicitaire s'est organisée autour de ce problème via le Media Rating Council (MRC), qui accrédite les prestataires de mesure et définit les standards d'invalid traffic (IVT), general invalid traffic (bots et crawlers évidents) contre sophisticated invalid traffic (plus difficile à détecter, imite le comportement humain). Selon les estimations sectorielles de 2024, les pertes liées à la fraude publicitaire dans le monde ont été estimées à plusieurs dizaines de milliards de dollars par an (Juniper Research et trackers similaires ; toute chiffre précis doit être traité comme une estimation, les méthodologies varient beaucoup).

Étape 3 : contrôles des pipelines cassés et des métadonnées manquantes

Le mode de défaillance le plus silencieux est un champ perdu, pas la fraude. Scénario courant : une plateforme change de fournisseur de CDN (Content Delivery Network, l'infrastructure qui diffuse la vidéo aux utilisateurs), et les logs du nouveau fournisseur ne remplissent pas le champ « device type » pendant trois semaines. Personne ne le remarque parce que les volumes totaux de plays paraissent normaux. Mais tous les rapports segmentés par device (mobile vs. connected TV) sont désormais silencieusement faux sur cette période.

Métriques de gouvernance à suivre en routine :

MétriqueCe qu'elle détecteBenchmark sain (illustratif)
Taux de valeurs nulles par champChamps perdus dans le pipelineMoins de 1 à 2 % pour les champs critiques (estimation, varie selon le champ)
Événements de schema drift par moisChangements de format en amont cassant l'ETLDoit tendre vers zéro avec un système d'alerting
Taux d'IDs dupliquésErreurs d'ingestion du catalogueMoins de 0,5 % du catalogue (estimation)
Taux de sessions flaguées comme anormalesActivité bot/fraudeBaseline stable ; investiguer tout bond de 2x ou plus d'une semaine sur l'autre
Time-to-detectionRapidité de détection des rupturesDes heures, pas des semaines, avec un monitoring automatisé

Ce sont des cibles illustratives, pas des standards réglementaires. Chaque plateforme devrait fixer sa propre baseline à partir de ses données historiques plutôt que d'emprunter un chiffre au pipeline très différent d'un concurrent.

Un mini-exemple chiffré

Supposons qu'un titre affiche 1 000 000 de plays enregistrés. Votre audit trouve :

  • 60 000 plays viennent de 40 devices avec des durées de session identiques (pattern de bot) → supprimer
  • 80 000 plays sont dupliqués parce que le titre a deux IDs de catalogue fusionnés tardivement → dédupliquer, ne pas supprimer, réaffecter à l'ID canonique
  • 15 000 plays ont un champ « completion » nul à cause d'une panne de pipeline de trois jours → flaguer comme données incomplètes, exclure uniquement des calculs de taux de complétion

Volume propre ajusté pour la fraude : 1 000 000 − 60 000 = 940 000 plays authentiques.

Le taux de complétion doit être calculé sur 940 000 − 15 000 = 925 000 plays disposant de données de complétion valides, pas sur le million brut.

Rapporter le chiffre brut de 1 000 000 à une équipe d'acquisition de contenus surestime la vraie demande d'environ 6 % rien qu'à cause des bots, avant même de toucher aux trous de métadonnées. Dans un métier où les décisions de renouvellement dépendent de la performance relative des titres, une distorsion de 6 % peut inverser un classement.

Vérification des acquis

1. L'exemple de la ferme de bots sur le documentaire illustre un risque central des défaillances de qualité des données média. Quelle est la leçon principale ?

2. Pourquoi la forte cardinalité des métadonnées de titre (plusieurs IDs comme l'ID studio, l'ID distributeur, l'EIDR) crée-t-elle un risque de qualité des données ?

3. Pourquoi les plateformes de streaming et d'ad-tech sont-elles des cibles particulièrement attractives pour les bots et les click farms, comparées à beaucoup d'autres secteurs ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les réponses correctes sur les raisons pour lesquelles les pipelines de données média sont décrits comme structurellement fragiles.

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les réponses correctes sur l'objectif d'un audit de qualité des données avant que les chiffres n'arrivent dans une réunion de greenlight ou un deck investisseurs.

Sélectionnez toutes les réponses correctes.

Faire de l'audit une routine, pas un one-shot

Un audit ponctuel trouve des problèmes. Un processus de gouvernance empêche qu'ils reviennent. Trois habitudes pratiques :

  1. Data contracts automatisés : définir le schéma attendu, les tolérances de valeurs nulles et les plages de valeurs pour chaque flux entrant, et alerter quand un flux viole son contrat (des outils comme Great Expectations sont gratuits et largement utilisés pour cela).
  2. Points de réconciliation : réconcilier les volumes de catalogue et les totaux de plays entre au moins deux systèmes indépendants (par ex. logs CDN vs. logs de facturation/ad-serving) chaque semaine, pas chaque trimestre.
  3. Ownership nommé sur les données : chaque jeu de données a besoin d'un propriétaire responsable, pas seulement d'une équipe d'ingénierie d'astreinte. Les organisations média nomment de plus en plus un responsable de la data governance précisément parce que « le job de tout le monde » veut dire le job de personne.

🎬 [VIDEO: "How Ad Fraud Works (and How to Stop It)" - youtube.com/results?search_query=how+ad+fraud+works+bots - cherchez ce terme pour du contenu explicatif actuel aligné MRC/IAB sur la détection de bots dans la mesure des médias digitaux]

Points clés

  • Les IDs de titre dupliqués fragmentent ou double-comptent silencieusement les données d'engagement ; imposez un standard d'identifiant canonique comme EIDR et auditez-le régulièrement.
  • Les plays gonflés par des bots suivent des motifs statistiques détectables (ratios plays par device anormaux, durées de session identiques) ; construisez des flags d'anomalie automatisés plutôt que de compter sur une revue manuelle.
  • Les champs de métadonnées manquants ou nuls issus de pipelines cassés sont plus dangereux que les erreurs évidentes, parce qu'ils passent les contrôles de cohérence de base tout en corrompant toutes les analyses segmentées en aval.
  • Fixez des benchmarks internes illustratifs (taux de valeurs nulles sous 1 à 2 %, taux de doublons sous 0,5 %) calibrés sur votre propre baseline historique, pas sur des chiffres sectoriels empruntés.
  • Traitez la qualité des données comme un processus de gouvernance continu (data contracts, points de réconciliation, ownership nommé), pas comme un nettoyage ponctuel avant un gros rapport.