Pourquoi les rapports publicitaires ne concordent pas avec les logs du bidder, et qui peut reconstruire le pipeline

Quand les rapports publicitaires ne concordent jamais avec les logs du bidder, deux problèmes peuvent se cacher derrière le même écart. Soit les enregistrements d'impressions et de clics, appelés événements, se perdent en route vers les rapports, souvent au pic de trafic, soit chaque côté les compte selon ses propres règles. Un recomptage sur les identifiants d'enchère, les codes qu'un ad exchange attribue à chaque enchère, permet de distinguer les deux. Faites-le avant d'engager qui que ce soit, car un nouveau pipeline ne règle à lui seul que le premier problème.

Que signifie un écart entre les rapports publicitaires et les logs du bidder ?

Les logs de votre bidder enregistrent chaque enchère à laquelle il a participé, chaque offre qu'il a faite et chaque enchère qu'il a remportée. Vos rapports sont construits à partir d'événements qui arrivent plus tard, comme les impressions et les clics venant des navigateurs et des applications. L'écart entre les deux a l'une des deux causes suivantes, ou les deux à la fois :

• Des événements perdus. L'impression ou le clic a bien eu lieu, mais son événement n'a jamais atteint les rapports. Un écart qui se creuse au pic de trafic désigne une partie du pipeline qui jette ce qu'elle ne peut pas traiter
• Des règles différentes. Les deux côtés peuvent clôturer la journée dans des fuseaux horaires différents ou ranger un événement en retard dans une autre heure. Un côté peut compter un événement deux fois après un renvoi, ou filtrer un trafic de bots que le bidder a quand même compté. L'attribution ajoute ses propres règles, comme le délai après un clic pendant lequel une conversion compte encore

Dans les deux cas, l'écart coûte de l'argent. Si vous facturez les annonceurs à partir de vos rapports, vous facturez trop peu pour les impressions perdues et trop pour celles comptées deux fois, alors que chaque ad exchange vous facture en général sur son propre décompte. Un bidder qui apprend de ces événements fixe aussi ses offres d'après de mauvais chiffres.

Comment distinguer les événements perdus des événements comptés selon des règles différentes ?

Rapprochez les deux côtés événement par événement. OpenRTB, le protocole de real-time bidding de l'IAB Tech Lab, donne à chaque enchère un identifiant de bid request, attribué par l'ad exchange, et à chaque impression de la requête son propre identifiant. Votre bidder peut demander à l'ad exchange d'inscrire ces identifiants dans la notification qu'il envoie quand vous gagnez, ainsi que dans la publicité elle-même. Chaque événement d'impression porte alors les mêmes identifiants que les logs de votre bidder.

Aucun de ces identifiants ne suffit seul. Selon OpenRTB 2.6, chaque ad exchange fixe ses propres identifiants de requête, donc rien n'empêche deux ad exchanges d'utiliser le même. Un identifiant d'impression n'est unique qu'à l'intérieur de sa requête et commence en général à 1. Rapprochez donc sur trois valeurs à la fois : l'ad exchange, l'identifiant de requête et l'identifiant d'impression.

Faites ensuite le recomptage :

• Pour chaque heure d'une journée chargée, comptez les enchères gagnées dans les logs du bidder et les impressions dans vos rapports, les deux en UTC, rapprochées sur cette clé en trois parties
• Recomptez le lendemain. Si l'écart diminue, une partie venait d'événements en retard
• Si la part des enchères gagnées toujours manquantes augmente aux heures les plus chargées, le pipeline perd des événements au pic. Une part qui reste à peu près la même d'une heure à l'autre est normale, parce que certaines enchères gagnées ne deviennent jamais des impressions
• Triez le reste. Un événement qui tombe dans une heure différente de chaque côté signifie que les deux utilisent des fuseaux horaires ou des heures de clôture différents. Un double comptage vient en général d'une nouvelle tentative. Si un événement manque seulement dans le rapport final, c'est un filtre, comme le filtrage des bots, qui l'a retiré

Si vos événements ne portent pas d'identifiants d'enchère, les ajouter est la première correction, car sans eux le recomptage ne peut comparer que des totaux. L'article technique sur la mesure publicitaire, dont le lien figure plus haut, traite en détail des horodatages et des événements en retard.

Où les événements disparaissent-ils au pic de trafic ?

Prenons un pipeline construit sur Kafka et ClickHouse. Un collecteur reçoit chaque événement du navigateur ou de l'application et l'écrit dans Kafka, une file de messages. Un chargeur lit dans Kafka et écrit les événements par lots dans ClickHouse, la base de données analytique derrière vos rapports. Lors d'un pic, des événements peuvent disparaître à chaque étape :

• Le collecteur est surchargé. Les requêtes qu'il refuse ou auxquelles il répond trop tard sont perdues, sauf si le navigateur ou l'application les renvoie. Un collecteur qui répond « reçu » avant que l'événement soit dans Kafka perd aussi tout ce qu'il détenait au moment où il plante
• Kafka n'absorbe pas les événements assez vite. La documentation de Kafka décrit ce qui se passe quand les événements arrivent plus vite qu'ils ne peuvent être transmis. Le code qui écrit dans Kafka attend pendant un temps fixé, puis abandonne avec une erreur. Un collecteur qui ignore cette erreur perd l'événement sans laisser de trace
• Les nouvelles tentatives créent des doublons. Kafka dispose d'un réglage qui empêche ses propres nouvelles tentatives d'écrire une seconde copie. Le client Java de Kafka l'active par défaut ; les bibliothèques clientes dans d'autres langages ont leurs propres valeurs par défaut, et certaines le laissent désactivé. Ce réglage n'attrape pas les doublons que crée votre code, comme un lot renvoyé après un redémarrage ou un pixel qui se déclenche deux fois
• Les insertions par lots échouent en bloc. La documentation de ClickHouse recommande de charger les événements par gros lots. Dans l'un de ses modes de chargement, une seule ligne mal formée fait rejeter tout le lot. Un chargeur qui abandonne perd tous les événements du lot, et un chargeur qui le renvoie tel quel bute à nouveau sur la même ligne défectueuse : les lignes défectueuses doivent donc être mises de côté et comptées. Quand une écriture tombe en timeout et que personne ne sait si elle a abouti, renvoyer exactement le même lot n'est sans risque que si la table est configurée pour ignorer les lots répétés, ce que ne fait pas par défaut une table ClickHouse de base auto-hébergée

Demandez à vos ingénieurs ces relevés pour l'heure la plus chargée d'une mauvaise journée :

• Les erreurs et les timeouts au niveau du load balancer et du collecteur, et les écritures en échec vers Kafka dans les logs du collecteur
• Le consumer lag, c'est-à-dire le retard accumulé par les chargeurs, et les éventuels événements que Kafka a supprimés avant leur lecture parce qu'ils ont attendu plus longtemps que la durée pendant laquelle il conserve les données
• Les écritures en échec vers ClickHouse, avec leurs messages d'erreur
• Un décompte horaire à chaque étape : événements reçus par le collecteur, écrits dans Kafka, lus par le chargeur, stockés dans ClickHouse

C'est le dernier relevé qui fait l'essentiel du travail. Si le décompte d'une étape chute au pic alors que celui de l'étape précédente tient, les événements ont disparu entre ces deux étapes.

Faut-il corriger le pipeline, passer à un service managé ou le reconstruire ?

Corriger le pipeline actuel :

• Quand c'est le bon choix : le recomptage montre surtout des règles différentes ou quelques fuites que vous savez nommer, et après les corrections le pipeline tient le rythme de votre heure la plus chargée
• Ce que vous payez : le temps d'ingénierie, et le risque qu'un pic plus fort révèle le point faible suivant
• À qui appartient le code : à vous, et le savoir reste chez vos ingénieurs

Passer à un service managé, comme Amazon MSK pour Kafka ou ClickHouse Cloud pour ClickHouse, où le fournisseur exploite les serveurs :

• Quand c'est le bon choix : vos ingénieurs passent plus de temps à faire tourner les serveurs Kafka et ClickHouse qu'à travailler sur la logique de comptage, et les pertes viennent de ces serveurs qui manquent de capacité au pic
• Ce que vous payez : une facture mensuelle qui augmente avec votre trafic. Les deux services facturent le calcul et le stockage, et ClickHouse Cloud indique séparément le transfert de données sortant et son propre service d'ingestion, selon leurs pages de tarifs consultées le 7 octobre 2026. Estimez la facture de votre mois le plus chargé et le coût d'un départ ultérieur
• Ce que cela ne règle pas : le collecteur et le chargeur que vous exploitez toujours, les doublons, les événements en retard et le rapprochement avec les logs de votre bidder. Le service stocke ce que vous lui envoyez et ne sait rien de ce que votre bidder a compté
• À qui appartient le code : à vous, et le service fonctionne selon les conditions du fournisseur

Reconstruire le pipeline :

• Quand c'est le bon choix : le recomptage montre des pertes à plusieurs étapes, ou la conception ne peut pas suivre la croissance de votre trafic. L'absence d'identifiants d'enchère ne pousse vers une reconstruction que si les ajouter oblige à modifier chaque étape
• Ce que vous payez : le plus gros travail d'ingénierie des trois voies, plus une période pendant laquelle l'ancien et le nouveau pipeline tournent côte à côte

Quelles sociétés peuvent reconstruire un pipeline d'événements publicitaires sur Kafka et ClickHouse ?

Deux types de sociétés font ce travail, et cet article ne classe ni l'un ni l'autre. Les sociétés d'ingénierie ad tech construisent des bidders, des ad exchanges et des ad servers : elles savent donc d'où viennent les identifiants d'enchère, mais demandez-leur si elles ont déjà exploité un pipeline d'événements à votre volume. Les sociétés d'ingénierie des données construisent des pipelines d'événements pour de nombreux secteurs, mais pas toujours pour l'ad tech. Demandez-leur si elles ont travaillé avec OpenRTB et rapproché des décomptes avec un ad exchange.

Que demander avant d'engager une société ?

Posez les cinq mêmes questions à chaque société de votre liste.

Comment supprimez-vous les doublons ? Guettez un identifiant que chaque événement reçoit à sa création, avant toute nouvelle tentative, construit à partir des identifiants d'enchère et du type d'événement. Le pipeline supprime les doublons deux fois : une fois quand il stocke les événements, et de nouveau quand les rapports les lisent. Le second passage compte, parce que ClickHouse supprime les doublons en arrière-plan, à des moments que vous ne pouvez pas prévoir. Sa documentation indique que ce mécanisme « ne garantit pas l'absence de doublons ».

Comment traitez-vous les événements qui arrivent en retard ? Guettez une période fixée pour chaque type d'événement pendant laquelle les chiffres peuvent encore changer, et un moment après lequel ils sont définitifs. Un événement qui arrive plus tard doit quand même être compté et marqué comme tardif, pas jeté.

Comment vérifiez-vous vos chiffres par rapport aux logs de notre bidder et aux rapports de nos partenaires ? Cherchez un recomptage quotidien sur les identifiants d'enchère et une raison écrite pour chaque écart. Convenez d'un niveau d'écart à partir duquel quelqu'un soulève le problème auprès de l'ad exchange.

Comment allez-vous le tester au-delà de notre pic ? Demandez-leur de rejouer une journée chargée enregistrée à un débit supérieur à celui de votre heure la plus chargée. Pendant le rejeu, ils coupent un collecteur et un serveur de base de données. Ensuite, chaque événement doit être soit stocké, soit compté comme rejeté.

À qui appartiendra le code ? À votre entreprise, par écrit, avec le code dans vos dépôts dès le premier jour. Tout ce que la société conserve doit figurer sur une liste nominative, avec une licence pour l'utiliser et le modifier une fois le travail terminé.

Quels sont les signaux d'alerte ?

• Une reconstruction est proposée avant que quiconque ait fait un recomptage ou ouvert les logs de votre bidder
• La société promet que les nouveaux rapports concorderont exactement avec le bidder
• La seule réponse sur les doublons est la promesse que chaque événement est livré « exactement une fois », sans un mot sur les doublons que crée votre propre code, comme un pixel qui se déclenche deux fois
• La seule preuve est un test de charge sur des événements fictifs, pas un rejeu de votre trafic

Où se situe amBrain ?

En AdTech, amBrain travaille sur le développement de DSP, les plateformes d'enchères en temps réel et l'ingénierie d'ad exchange. Ce travail comprend RTBBidder, une demand-side platform qu'amBrain a construite pour un client.

amBrain diagnostique les systèmes lents dans le trading et l'ad tech : la plateforme en fonctionnement est mesurée de bout en bout, et le rapport indique où passe le temps.

amBrain développe des logiciels depuis 2019. Elle travaille en trois formats : la prestation complète, une équipe dédiée ou des ingénieurs intégrés à votre équipe. Le client conserve la pleine propriété du produit et du code, à l'exception des composants réutilisables d'amBrain.

Cet article n'est pas une étude de cas. Il ne décrit le pipeline d'événements d'aucun client, et RTBBidder n'est cité que comme un DSP qu'amBrain a construit. Kafka et ClickHouse servent ici d'exemple de stack, et non de description des projets d'amBrain ni des outils qu'elle utilise. L'article ne donne ni prix ni délais.

Si vos rapports et les logs de votre bidder divergent, faites d'abord le recomptage. Présentez ensuite ses résultats et les cinq mêmes questions à chaque société de votre liste, amBrain comprise.

Questions fréquentes

• Nos rapports et les logs du bidder concorderont-ils un jour à 100 % ? Non. OpenRTB indique que le message par lequel l'ad exchange vous annonce votre victoire « n'indique pas nécessairement une publicité diffusée, vue ou facturable », et certains événements sont filtrés comme trafic de bots. Visez un écart stable, avec une raison écrite pour chacune de ses composantes, et convenez avec chaque partenaire du décompte sur lequel vous facturez
• Faut-il utiliser Kafka et ClickHouse ? Non. D'autres files de messages et bases de données analytiques peuvent faire le même travail, et le recomptage comme les cinq questions s'appliquent à chacune d'elles
• Comment garder les anciens rapports en service pendant la construction d'un nouveau pipeline ? Alimentez les deux pipelines avec les mêmes événements et comparez chacun avec les logs du bidder tous les jours. Basculez en dernier les rapports sur lesquels vous facturez, après une période de facturation complète où chaque écart a été expliqué