Réduction des écarts de mesure

Les écarts RTB - l’écart entre ce qu’une partie compte et ce que l’autre compte ou facture est largement dû à la manière dont les impressions et les clics sont suivis côté client. Pour les maintenir faibles lors de l’intégration de l’offre :

• Privilégiez le comptage serveur à serveur (S2S) plutôt qu’un enchaînement de redirections basé sur le navigateur. Les navigateurs peuvent fusionner les sauts de redirection intermédiaires, en particulier Chrome sur Android. Ainsi, un événement qui s’est affiché peut ne jamais être enregistré. C’est le principal facteur des écarts de clics.
• Utilisez une redirection d’en-tête (302) plutôt qu’une redirection meta-refresh c’est plus fiable pour déclencher les appels de suivi.
• Déclenchez correctement les appels BURL et d’impression, afin que les événements facturables et rendus soient tous deux enregistrés. Voir Billable Event Counting (BURL) pour OpenRTB 2.4 / OpenRTB 2.5 pour comprendre le fonctionnement du comptage des événements facturables et comment le rapprocher des métriques « Served ».
• Rapprochez les clics à l’identique. Chaque partie applique son propre filtrage des clics invalides et multiclics, comparez donc les totaux sur la même base (valides + invalides ensemble) avant de considérer un écart comme une erreur.
• Sachez que certains segments présentent des écarts plus élevés notamment les formats vidéo, et les méthodes de mesure côté client telles que la collecte des Client Hints, sendBeacon, et les interventions du navigateur sur les « heavy ads ».

Bandes d’écart

Les écarts sont normaux en RTB ; l’objectif est de les maintenir suffisamment bas pour une facturation propre plutôt que de les éliminer.

Écart	Action
Moins de 5 %	Acceptable
5–10 %	Surveiller
Plus de 10 %	Investiger

Flux de dépannage

1. Comparez vos comptages à ceux du partenaire et utilisez le Served Ratio pour voir où l’écart apparaît.
2. Segmentez par appareil et navigateur certaines combinaisons (notamment Android + Chrome) affichent généralement des écarts plus élevés, en raison de la manière dont le navigateur gère la navigation et les redirections.
3. Vérifiez la méthode de redirection une redirection d’en-tête (302) est plus fiable qu’une redirection meta-refresh.
4. Confirmez que les appels BURL et d’impression se déclenchent comme prévu.
5. Pour le trafic qui traverse plusieurs réseaux, rapprochez chaque paire adjacente indépendamment. L’alignement entre deux nœuds ne se propage pas à l’ensemble de la chaîne.