Filterung von ungültigem Traffic für eine Werbeplattform: Was Ihr Team selbst bauen kann und wann sich ein Verifizierungsanbieter lohnt

Bauen Sie die Filterung von allgemeinem ungültigem Traffic selbst, und kaufen Sie die Erkennung der komplexen Art bei einem Verifizierungsanbieter ein, außer Sie können sich ein eigenes Anti-Fraud-Team leisten. Allgemeiner ungültiger Traffic, etwa bekannte Rechenzentrumsadressen, deklarierte Bots und unsichtbare 1x1-Anzeigen, wird mit Listen und Regeln erkannt. Ihre eigenen Entwickler können sie anwenden, wenn eine Anfrage eintrifft, und noch einmal in den Logs. Komplexer ungültiger Traffic, etwa gekaperte Geräte und gefälschte Apps, braucht Daten aus weit mehr Traffic, als eine einzelne Plattform sieht, und Analysten, die ihn untersuchen. Zertifizierungsprogramme wie das von TAG erwarten außerdem eine Filterung durch einen qualifizierten Dritten.

Was gilt als ungültiger Traffic?

Der Media Rating Council (MRC) ist die US-Stelle, die Werbemessung akkreditiert. Sein Invalid Traffic Detection and Filtration Standards Addendum (das Update vom Juni 2020, gelesen am 27. Oktober 2026 wie die anderen Quellen hier) teilt ungültigen Traffic in zwei Arten ein. Allgemeiner ungültiger Traffic, kurz GIVT, ist „Traffic, der mit routinemäßigen Filtermethoden erkannt wird, die durch die Anwendung von Listen oder anderen standardisierten Parameterprüfungen ausgeführt werden“. Zu den Beispielen des MRC gehören:

• Bekannter ungültiger Traffic aus Rechenzentren
• Bots, Spider und andere Crawler
• Anfragen von User Agents, die keine Browser sind, oder von unbekannten Browsern
• Vorab geladene oder vorab gerenderte Seiten, die danach kein echter Nutzer angesehen hat
• Unsichtbare Platzierungen, etwa Anzeigen mit 0x0 oder 1x1 Pixel

Komplexer ungültiger Traffic, kurz SIVT, umfasst „schwerer zu erkennende Situationen, die fortgeschrittene Analysen, Abgleich oder Koordination über mehrere Stellen, erhebliches menschliches Eingreifen usw. erfordern, um sie zu analysieren und zu erkennen“. Zu den Beispielen des MRC gehören:

• Automatisierungssoftware und Emulatoren
• Infizierte und gekaperte Geräte
• Organisierte, bezahlte menschliche Aktivität, etwa Klickfarmen
• Erzwungene Klicks und Weiterleitungen
• Gefälschte Messereignisse
• Gefälschte Domains und Apps

Welche Filter können unsere eigenen Entwickler bauen?

Die allgemeine Art ist darauf angelegt, geteilt zu werden. Der MRC schreibt, die GIVT-Filterung sei „dazu gedacht, zwischen Anbietern einheitlich zu sein“, deshalb stützt sie sich auf gemeinsame Listen. Ein internes Team arbeitet mit zwei davon:

• Die IAB/ABC International Spiders & Bots List, die die Alliance for Audited Media im Auftrag des IAB Tech Lab pflegt
• Die Data Center IP List, die die Trustworthy Accountability Group (TAG) jeden Monat herausgibt

Zusätzlich zu den Listen schreibt das Team Regeln für User Agents, Anzeigengrößen und Prefetch-Anfragen und wendet sie an, wenn eine Anfrage eintrifft, und noch einmal, wenn Events protokolliert werden. Außerdem hält es jede gefilterte Anfrage samt Grund fest, damit sich die Zahlen gegenüber Partnern erklären lassen.

Für die Messfirmen, die er prüft, setzt der MRC einen Ausgangspunkt für Rechenzentrums-Traffic. Sie müssen ungültigen Traffic von IP-Adressen „der drei größten bekannten Hosting-Anbieter: Amazon AWS, Google und Microsoft“ filtern. Ausnahmen sorgen dafür, dass echte Nutzer, die über diese Netze ins Web gehen, nicht versehentlich herausgefiltert werden.

Gefiltert werden kann zu zwei Zeitpunkten. Vorab blockiert die Plattform eine Anzeigenanfrage oder bietet nicht darauf. Danach entfernt sie ungültige Events aus den Logs und den Zählungen. Der MRC schreibt: „Jede Technik hat bestimmte Stärken und Schwächen, und beide haben ihren Platz in einer gut umgesetzten Strategie zum Schutz des Traffics.“ Frühes Blockieren spart außerdem die Kosten, eine Anfrage zu verarbeiten, die später ohnehin verworfen würde.

Listen verlieren an Wirkung, je weniger Browser und Apps preisgeben. In einem Update von 2024 formulierte der MRC es so: „Eine eingeschränkte oder fehlende IP-Adresse und ein weniger detaillierter User-Agent-String (UA) können listenbasierte Ansätze beeinträchtigen.“

Wann lohnt sich ein Verifizierungsanbieter?

Die Erkennung von komplexem Traffic hängt davon ab, Muster über viele Publisher, Apps und Geräte hinweg zu sehen, und von Analysten, die neue Maschen verfolgen, sobald sie auftauchen. Eine Plattform sieht nur ihren eigenen Traffic und übersieht deshalb Muster, die erst über viele Plattformen hinweg sichtbar werden. Ein Team, das das gut macht, ist im Grunde ein Anti-Fraud-Unternehmen innerhalb Ihres Unternehmens.

Eine Zertifizierung kann die Frage entscheiden. Das Programm Certified Against Fraud von TAG nennt als eine seiner zentralen Anforderungen, dass „100% ihrer monetarisierbaren Transaktionen von einem qualifizierten Dritten auf IVT gefiltert und bereinigt werden“. TAG erlaubt Publishern, das über eine Supply-Side-Platform mit gültigem Zertifizierungssiegel zu erfüllen. Wenn Ihre Käufer oder Partner eine TAG-Zertifizierung verlangen, erfüllen selbst gebaute Filter diese Anforderung allein nicht.

Der MRC veröffentlicht eine Liste der Dienste, die er akkreditiert. Seine Digital-Liste enthält Verifizierungsfirmen wie DoubleVerify, HUMAN, Integral Ad Science, Pixalate und Protected Media. Die Akkreditierung gilt für bestimmte Dienste und Metriken, also fragen Sie einen Anbieter, welche seiner Dienste akkreditiert sind und ob das komplexen ungültigen Traffic einschließt.

Bauen, kaufen oder beides: Was deckt welcher Weg ab?

• Nur intern: Sie erkennen allgemeinen ungültigen Traffic für die Zeit Ihrer Entwickler und eventuelle Listenabos, und Regeln und Daten gehören Ihnen. Komplexe Maschen gehen durch, und Anforderungen an eine Filterung durch Dritte bleiben unerfüllt.
• Nur ein Anbieter: Beide Arten werden erkannt, aber jede Entscheidung hängt von den Systemen und Gebühren des Anbieters ab, und eine Anbieterprüfung im Bid-Pfad verlängert jede Anfrage.
• Beides: Ihre eigenen Filter sortieren den offensichtlichen Traffic früh und günstig aus, und der Anbieter sieht nur den Traffic, der sie passiert hat.

Was muss die Plattform auf jedem Weg protokollieren?

Wer die Erkennung übernimmt, braucht die Details jeder Werbetransaktion. Der MRC listet Felder auf, die eine Messfirma erfassen muss, soweit möglich, darunter:

• Den Event-Typ, eine Transaktions-ID und einen Zeitstempel
• Die IP-Adresse, einschließlich des Headers X-Forwarded-For, wenn Traffic über Proxys läuft
• Den vollständigen User-Agent-String und den Gerätetyp
• Die App-Kennung oder die vollständige URL der Seite, auf der die Anzeige lief
• Publisher-, Site- und Placement-IDs sowie die ads.txt- oder app-ads.txt-Angaben des Publishers
• OpenRTB-Attribute aus der Gebotsanfrage

Berichte sollten Roh- und gefilterte Zahlen getrennt halten. Für Kampagnenberichte führt der Standard des MRC „Gross Metrics (Completely Unfiltered)“ und „Net Metrics (Filtered for GIVT Requirements)“ auf. Wo sie zutreffen, erscheinen die um komplexen ungültigen Traffic bereinigten Zahlen als eigener Schritt. Wenn Ihre Event-Pipeline schon jetzt Events verliert oder doppelt zählt, beheben Sie das zuerst: Filterung kann keine Zahlen reparieren, die schon vor ihr falsch waren.

Was sollten Sie eine Firma fragen, die Filterung in Ihre Plattform einbaut?

• An welcher Stelle im Bid-Pfad läuft jeder Filter, und wie viel Zeit fügt er einer Anfrage hinzu?
• Wenn die Prüfung des Anbieters nicht rechtzeitig antwortet, geht die Anfrage durch oder wird sie verworfen?
• Wie werden die Listen aktualisiert, und wer prüft, dass echte Nutzer nicht versehentlich herausgefiltert werden?
• Wie erscheinen Brutto- und gefilterte Zahlen in unseren Berichten und in den Berichten unserer Partner?
• Welche Felder jeder Anfrage werden gespeichert, wie lange und nach welchen Datenschutzregeln?

Die letzte Frage ist auch dem MRC wichtig. Sein Update von 2024 sagt, dass „Datenschutzvorschriften keine Hürde sind, die man technisch umgeht, sondern feste Anforderungen, die eingehalten werden müssen“.

Wo passt amBrain ins Bild?

amBrain, das diesen Blog herausgibt, baut die Systeme, an die Filterung angeschlossen wird. Eine seiner Zeilen lautet: „amBrain baut Ad Server: Targeting, Frequency Capping und Reporting.“ Eine andere lautet: „amBrain baut Event-Analytics-Pipelines für AdTech: Erfassung, Verarbeitung und Reporting von Impression- und Klick-Events.“ Zu seiner AdTech-Arbeit gehört RTBBidder, eine Demand-Side-Platform, die es für einen Kunden gebaut hat.

amBrain entwickelt seit 2019 Software und arbeitet in drei Formaten: vollständige Umsetzung, ein dediziertes Team oder in Ihr Team eingebettete Entwickler. Zum Eigentum lautet sein Satz: „Der Kunde behält das volle Eigentum an Produkt und Code, ausgenommen unsere wiederverwendbaren Komponenten.“

Dieser Artikel ist keine Case Study. Er sagt nicht, dass amBrain für irgendeinen Kunden Betrugserkennung gebaut hat oder dass es Verifizierung anbietet. Wenn amBrain auf Ihrer Shortlist steht, stellen Sie ihm dieselben Fragen wie jeder anderen Firma.