Warum Ad-Reports nicht zu den Bidder-Logs passen und wer die Pipeline neu bauen kann

Wenn Ad-Reports nie mit den Bidder-Logs übereinstimmen, können hinter derselben Abweichung zwei Probleme stecken. Entweder gehen Datensätze zu Impressions und Klicks, sogenannte Events, auf dem Weg in die Reports verloren, oft bei Spitzenlast, oder jede Seite zählt sie nach ihren eigenen Regeln. Eine Nachzählung anhand der Auktions-IDs, also der Kennungen, die eine Exchange jeder Auktion gibt, trennt die beiden. Machen Sie sie, bevor Sie jemanden beauftragen, denn eine neue Pipeline allein behebt nur das erste Problem.

Was bedeutet es, wenn Ad-Reports nicht mit den Bidder-Logs übereinstimmen?

Ihre Bidder-Logs erfassen jede Auktion, an der Ihr Bidder teilgenommen hat, jedes Gebot, das er abgegeben hat, und jede Auktion, die er gewonnen hat. Ihre Reports entstehen aus Events, die später eintreffen, etwa Impressions und Klicks aus Browsern und Apps. Die Abweichung zwischen beiden hat eine von zwei Ursachen, oder beide:

• Verlorene Events. Die Impression oder der Klick hat stattgefunden, aber das zugehörige Event hat die Reports nie erreicht. Eine Abweichung, die bei Spitzenlast wächst, deutet auf einen Teil der Pipeline hin, der verwirft, was er nicht bewältigen kann
• Unterschiedliche Regeln. Die beiden Seiten schließen den Tag womöglich in verschiedenen Zeitzonen ab oder ordnen ein verspätetes Event einer anderen Stunde zu. Eine Seite zählt ein Event nach einem erneuten Senden vielleicht doppelt oder filtert Bot-Traffic heraus, den der Bidder noch mitgezählt hat. Die Attribution bringt eigene Regeln mit, etwa wie lange nach einem Klick eine Conversion noch zählt

So oder so kostet die Abweichung Geld. Wenn Sie Werbetreibenden auf Grundlage Ihrer Reports Rechnungen ausstellen, berechnen Sie für verlorene Impressions zu wenig und für doppelt gezählte zu viel, während jede Exchange mit Ihnen in der Regel nach ihrer eigenen Zählung abrechnet. Ein Bidder, der aus diesen Events lernt, setzt seine Gebote außerdem auf Basis falscher Zahlen.

Wie unterscheiden wir verlorene Events von Events, die nach anderen Regeln gezählt wurden?

Gleichen Sie die beiden Seiten Event für Event ab. OpenRTB, das Protokoll des IAB Tech Lab für Real-Time Bidding, gibt jeder Auktion eine Bid-Request-ID, die die Exchange vergibt, und jeder Impression im Request eine eigene ID. Ihr Bidder kann die Exchange bitten, diese IDs in die Benachrichtigung zu schreiben, die sie sendet, wenn Sie eine Auktion gewinnen, und in die Anzeige selbst. Dann trägt jedes Impression-Event dieselben IDs wie Ihre Bidder-Logs.

Keine der beiden IDs reicht für sich allein. Nach OpenRTB 2.6 legt jede Exchange ihre eigenen Request-IDs fest, nichts hindert also zwei Exchanges daran, dieselbe zu verwenden. Eine Impression-ID ist nur innerhalb ihres Requests eindeutig und beginnt meist bei 1. Gleichen Sie deshalb über drei Werte zusammen ab: die Exchange, die Request-ID und die Impression-ID.

Machen Sie dann die Nachzählung:

• Zählen Sie für jede Stunde eines Tages mit hoher Last die gewonnenen Auktionen in den Bidder-Logs und die Impressions in Ihren Reports, beides in UTC, abgeglichen über diesen dreiteiligen Schlüssel
• Zählen Sie am nächsten Tag noch einmal. Wird die Abweichung kleiner, bestand ein Teil davon aus verspäteten Events
• Steigt der Anteil der noch fehlenden gewonnenen Auktionen in den Stunden mit der höchsten Last, verliert die Pipeline bei Spitzenlast Events. Ein Anteil, der von Stunde zu Stunde ähnlich bleibt, ist zu erwarten, denn aus manchen gewonnenen Auktionen wird nie eine Impression
• Ordnen Sie den Rest zu. Landet ein Event auf jeder Seite in einer anderen Stunde, verwenden die beiden unterschiedliche Zeitzonen oder Stichzeiten. Eine Doppelzählung kommt meist von einem wiederholten Sendeversuch. Fehlt ein Event nur im endgültigen Report, hat ein Filter es entfernt, etwa die Bot-Filterung

Tragen Ihre Events keine Auktions-IDs, ist deren Ergänzung die erste Korrektur, denn ohne sie kann die Nachzählung nur Gesamtsummen vergleichen. Der oben verlinkte technische Artikel über Ad Measurement behandelt Zeitstempel und verspätete Events ausführlich.

Wo gehen Events bei Spitzenlast verloren?

Nehmen Sie eine Pipeline auf Basis von Kafka und ClickHouse. Ein Collector empfängt jedes Event aus dem Browser oder der App und schreibt es in Kafka, eine Message Queue. Ein Loader liest aus Kafka und schreibt die Events in Batches nach ClickHouse, in die Analysedatenbank hinter Ihren Reports. Bei Spitzenlast können Events an jedem Schritt verschwinden:

• Der Collector ist überlastet. Requests, die er ablehnt oder zu spät beantwortet, sind verloren, es sei denn, der Browser oder die App sendet sie erneut. Ein Collector, der „empfangen“ meldet, bevor das Event in Kafka ist, verliert außerdem alles, was er gerade hielt, wenn er abstürzt
• Kafka nimmt Events nicht schnell genug an. Die Dokumentation von Kafka beschreibt, was passiert, wenn Events schneller eintreffen, als sie weitergereicht werden können. Der Code, der nach Kafka schreibt, wartet eine festgelegte Zeit und gibt dann mit einem Fehler auf. Ein Collector, der diesen Fehler ignoriert, verliert das Event spurlos
• Wiederholte Sendeversuche erzeugen Duplikate. Kafka hat eine Einstellung, die verhindert, dass seine eigenen Wiederholungen eine zweite Kopie schreiben. Der Java-Client von Kafka schaltet sie standardmäßig ein; Client-Bibliotheken in anderen Sprachen haben eigene Standardwerte, und manche lassen sie aus. Duplikate, die Ihr eigener Code erzeugt, erkennt sie nicht, etwa einen Batch, der nach einem Neustart erneut gesendet wird, oder ein Pixel, das zweimal feuert
• Batch-Inserts scheitern als Ganzes. Die Dokumentation von ClickHouse empfiehlt, Events in großen Batches zu laden. In einem seiner Lademodi führt eine einzige fehlerhafte Zeile dazu, dass der ganze Batch abgelehnt wird. Ein Loader, der dann aufgibt, verliert jedes Event darin, und einer, der den Batch unverändert erneut sendet, stößt wieder auf dieselbe fehlerhafte Zeile; fehlerhafte Zeilen müssen deshalb beiseitegelegt und gezählt werden. Läuft ein Schreibvorgang in ein Timeout und weiß niemand, ob er angekommen ist, ist es nur dann sicher, genau denselben Batch erneut zu senden, wenn die Tabelle so eingerichtet ist, dass sie wiederholte Batches verwirft, und das tut eine einfache, selbst betriebene ClickHouse-Tabelle standardmäßig nicht

Lassen Sie sich von Ihren Engineers diese Aufzeichnungen aus der Spitzenstunde eines schlechten Tages geben:

• Fehler und Timeouts am Load Balancer und am Collector sowie fehlgeschlagene Schreibvorgänge nach Kafka in den Logs des Collectors
• Consumer Lag, also wie weit die Loader zurückgefallen sind, und alle Events, die Kafka ungelesen gelöscht hat, weil sie länger gewartet haben, als Kafka Daten aufbewahrt
• Fehlgeschlagene Schreibvorgänge nach ClickHouse, mit ihren Fehlermeldungen
• Eine Zählung pro Stunde an jedem Schritt: vom Collector empfangen, in Kafka geschrieben, vom Loader gelesen, in ClickHouse gespeichert

Die letzte Aufzeichnung leistet die meiste Arbeit. Fällt die Zählung eines Schritts bei Spitzenlast ab, während die des Schritts davor stabil bleibt, sind die Events zwischen diesen beiden Schritten verloren gegangen.

Sollten wir die Pipeline reparieren, zu einem Managed Service wechseln oder sie neu bauen?

Die bestehende Pipeline reparieren:

• Wann es passt: Die Nachzählung zeigt vor allem unterschiedliche Regeln oder einige wenige Lecks, die Sie benennen können, und nach den Korrekturen hält die Pipeline mit Ihrer Spitzenstunde Schritt
• Was Sie zahlen: Entwicklungszeit und das Risiko, dass eine größere Lastspitze die nächste Schwachstelle findet
• Wem der Code gehört: Ihnen, und das Wissen bleibt bei Ihren Engineers

Zu einem Managed Service wechseln, etwa Amazon MSK für Kafka oder ClickHouse Cloud für ClickHouse, bei dem der Anbieter die Server betreibt:

• Wann es passt: Ihre Engineers verbringen mehr Zeit damit, Kafka- und ClickHouse-Server am Laufen zu halten, als mit der Zähllogik, und die Verluste entstehen, weil diesen Servern bei Spitzenlast die Kapazität ausgeht
• Was Sie zahlen: eine monatliche Rechnung, die mit Ihrem Traffic wächst. Laut den Preisseiten beider Dienste, abgerufen am 7. Oktober 2026, berechnen beide Rechenleistung und Speicher, und ClickHouse Cloud weist ausgehenden Datentransfer und seinen eigenen Ingestion-Dienst gesondert aus. Schätzen Sie die Rechnung für Ihren Monat mit der höchsten Last und die Kosten, später wieder zu wechseln
• Was der Dienst nicht behebt: den Collector und den Loader, die Sie weiterhin selbst betreiben, Duplikate, verspätete Events und den Abgleich mit Ihren Bidder-Logs. Der Dienst speichert, was Sie ihm schicken, und weiß nichts davon, was Ihr Bidder gezählt hat
• Wem der Code gehört: Ihnen, und der Dienst läuft zu den Bedingungen des Anbieters

Die Pipeline neu bauen:

• Wann es passt: Die Nachzählung zeigt Verluste an mehreren Schritten, oder das Design kann nicht mit Ihrem Traffic wachsen. Fehlende Auktions-IDs sprechen nur dann für einen Neubau, wenn ihre Ergänzung bedeutet, jeden Schritt zu ändern
• Was Sie zahlen: den größten Entwicklungsaufwand der drei Wege, dazu eine Phase, in der die alte und die neue Pipeline parallel laufen

Welche Firmen können eine Ad-Event-Pipeline auf Kafka und ClickHouse neu bauen?

Diese Arbeit machen zwei Arten von Firmen, und dieser Artikel stellt keine Rangfolge zwischen ihnen auf. AdTech-Engineering-Firmen bauen Bidder, Exchanges und Ad Server und wissen daher, woher Auktions-IDs kommen; fragen Sie aber, ob sie eine Event-Pipeline in Ihrem Volumen betrieben haben. Data-Engineering-Firmen bauen Event-Pipelines für viele Branchen, allerdings nicht immer für AdTech. Fragen Sie sie, ob sie mit OpenRTB gearbeitet und Zählungen mit einer Exchange abgeglichen haben.

Was sollten wir fragen, bevor wir eine Firma beauftragen?

Stellen Sie jeder Firma auf Ihrer Liste dieselben fünf Fragen.

Wie entfernen Sie Duplikate? Achten Sie auf eine ID, die jedes Event bei seiner Entstehung erhält, noch vor jedem erneuten Sendeversuch, gebildet aus den Auktions-IDs und dem Event-Typ. Die Pipeline entfernt Duplikate zweimal: einmal beim Speichern der Events und noch einmal, wenn Reports sie lesen. Der zweite Durchgang ist wichtig, weil ClickHouse Duplikate im Hintergrund zu Zeitpunkten entfernt, die Sie nicht planen können. In seiner Dokumentation heißt es, dies „garantiert nicht, dass keine Duplikate vorhanden sind“.

Wie gehen Sie mit Events um, die verspätet eintreffen? Achten Sie auf einen festgelegten Zeitraum je Event-Typ, in dem sich die Zahlen noch ändern können, und einen Zeitpunkt, ab dem sie endgültig sind. Ein Event, das noch später eintrifft, sollte trotzdem gezählt und als verspätet markiert werden, statt verworfen zu werden.

Wie gleichen Sie Ihre Zahlen mit unseren Bidder-Logs und den Reports unserer Partner ab? Achten Sie auf eine tägliche Nachzählung anhand der Auktions-IDs und eine schriftliche Begründung für jede Differenz. Vereinbaren Sie, ab welcher Größe der Abweichung jemand das Problem bei der Exchange anspricht.

Wie testen Sie das System oberhalb unserer Spitzenlast? Bitten Sie die Firma, einen aufgezeichneten Tag mit hoher Last mit einer höheren Rate abzuspielen als in Ihrer Spitzenstunde. Während des Replays schaltet sie einen Collector und einen Datenbankserver ab. Danach sollte jedes Event entweder gespeichert oder als verworfen gezählt sein.

Wem wird der Code gehören? Ihrem Unternehmen, schriftlich festgehalten, mit dem Code vom ersten Tag an in Ihren Repositories. Alles, was die Firma behält, sollte namentlich aufgeführt sein, mit einer Lizenz, es nach Ende der Arbeit zu nutzen und zu ändern.

Was sind die Warnsignale?

• Ein Neubau wird vorgeschlagen, bevor jemand eine Nachzählung gemacht oder Ihre Bidder-Logs geöffnet hat
• Die Firma verspricht, dass die neuen Reports exakt mit dem Bidder übereinstimmen werden
• Die einzige Antwort zu Duplikaten ist das Versprechen, dass jedes Event „genau einmal“ zugestellt wird, ohne ein Wort zu Duplikaten, die Ihr eigener Code erzeugt, etwa ein Pixel, das zweimal feuert
• Der einzige Beleg ist ein Lasttest mit erfundenen Events, kein Replay Ihres Traffics

Wo passt amBrain ins Bild?

Im Bereich AdTech arbeitet amBrain an DSP-Entwicklung, Real-Time-Bidding-Plattformen und Ad-Exchange-Engineering. Zu dieser Arbeit gehört RTBBidder, eine Demand-Side-Platform, die amBrain für einen Kunden gebaut hat.

amBrain diagnostiziert langsame Trading- und AdTech-Systeme: Die laufende Plattform wird durchgängig vermessen, und der Bericht benennt, wohin die Zeit geht.

amBrain entwickelt seit 2019 Software. Es arbeitet in drei Formaten: vollständige Umsetzung, ein dediziertes Team oder in Ihr Team eingebettete Entwickler. Der Kunde behält das volle Eigentum an Produkt und Code, ausgenommen die wiederverwendbaren Komponenten von amBrain.

Dieser Artikel ist keine Case Study. Er beschreibt keine Event-Pipeline eines Kunden, und RTBBidder wird nur als DSP genannt, die amBrain gebaut hat. Kafka und ClickHouse dienen hier als Beispiel-Stack, nicht als Beschreibung der Projekte von amBrain oder der Tools, die es einsetzt. Der Artikel nennt weder Preise noch Zeitpläne.

Wenn Ihre Reports und Ihre Bidder-Logs nicht übereinstimmen, machen Sie zuerst die Nachzählung. Legen Sie dann ihre Ergebnisse und dieselben fünf Fragen jeder Firma auf Ihrer Liste vor, amBrain eingeschlossen.

Häufige Fragen

• Werden unsere Reports und die Bidder-Logs jemals zu 100 Prozent übereinstimmen? Nein. OpenRTB sagt, die Nachricht der Exchange, dass Sie gewonnen haben, sei „nicht unbedingt ein Hinweis auf eine ausgelieferte, gesehene oder abrechenbare Anzeige“, und manche Events werden als Bot-Traffic herausgefiltert. Streben Sie eine stabile Abweichung mit einer schriftlichen Begründung für jeden ihrer Anteile an, und vereinbaren Sie mit jedem Partner, nach welcher Zählung Sie abrechnen
• Müssen wir Kafka und ClickHouse verwenden? Nein. Andere Queues und Analysedatenbanken können dieselbe Aufgabe erfüllen, und die Nachzählung und die fünf Fragen gelten für jede davon
• Wie halten wir die alten Reports am Laufen, während eine neue Pipeline gebaut wird? Speisen Sie beide Pipelines mit denselben Events und vergleichen Sie jede täglich mit den Bidder-Logs. Stellen Sie die Reports, nach denen Sie abrechnen, zuletzt um, nach einem vollen Abrechnungszeitraum, in dem jede Differenz erklärt ist