Blacklisting im Programmatic Advertising: Ein praxisnaher Leitfaden für Publisher
Im programmatischen Ökosystem ist das sogenannte „Blacklisting“ längst kein einfaches Ausfiltern von unerwünschten Domains und Werbekunden mehr. Es ist Teil einer vielschichtigen Wertschöpfungskette mit zahlreichen Akteuren, Methoden – und auch Grenzen. Wir erklären, wie das digitale Sperrlisten-Universum funktioniert, warum es nicht immer wie gewünscht wirkt und worauf ihr achten solltet, um diese Brand-Safety-Technologie optimal zu nutzen.
Blacklisting: Was das ist – und warum es nicht immer „hält, was es verspricht“
Blacklisting bezeichnet im programmatischen Umfeld den Prozess, der bestimmte Entitäten wie Werbetreibende, Marken oder Creatives gezielt davon ausschließt, auf einem Publisher-Inventar ausgespielt zu werden. Mit dem Ziel, Markensicherheit, User Experience (UX) und rechtliche Vorgaben zu schützen – etwa indem Werbung für unseriöse Produkte, Scam-Anbieter oder unpassende Inhalte gar nicht erst zugelassen wird.
Wer blacklistet eigentlich?
Die üblichen Akteure sind:
- Publisher (über ihren AdServer, über Brand-Safety-Partner oder durch Vorgaben an SSPs)
- Advertiser & Media-Agenturen
- Demand Side Platforms (DSPs) & Sell Side Platforms (SSPs)
- Ad Verification Services (IAS, DV, MOAT)
- Plattformen (Google Ad Manager, AdSense)
- Security-Blacklisting-Dienste (wie Spamhaus, Google Safe Browsing oder Cloudflare)
Sie legen Blocklisten, auch Sperrlisten oder Blacklists genannt, mit Domains, URL-Mustern oder Ad-Formaten an, die sie ausschließen möchten. Diese werden über DSPs, SSPs und AdServer bis zu euch Publishern durchgereicht. Gleichzeitig legen im deutschen Markt Regelwerke wie der Bundesverband Digitale Wirtschaft (BVDW) e.V. Mindeststandards für Transparenz, Qualität und Markensicherheit entlang der gesamten Programmatic-Kette fest.
Was genau wird geblacklistet?
Blacklisting kann auf unterschiedlichen Ebenen ansetzen, unter anderem bei:
- Domains oder Subdomains, die als unsicher oder riskant eingestuft werden,
- konkreten URLs, URL-Patterns oder kreativen Ad-Elementen, insofern diese über die verwendeten Systeme identifizierbar sind,
- App-IDs, IP-Ranges oder auch Advertiser-IDs.
Um euer Werbeinventar und eure Leserschaft zu schützen, könnt ihr euer eigenes Blacklisting betreiben. So können Publisher-seitige Sperrlisten Folgendes enthalten:
- Unerwünschte Branchen (Scam, Glücksspiel, Adult, Fake-Downloads oder fragwürdige Finanzprodukte)
- Bestimmte Advertiser oder Händler, die wiederholt negative Nutzerreaktionen ausgelöst haben
- Aggressive oder technisch fehlerhafte Creatives wie Auto-Redirects, automatisch startendes Audio („Autoplay mit Ton“) oder Anzeigen mit Malware-Verdacht
- Unpassende Inhalte, die nicht mit dem redaktionellen Profil harmonieren
- Rechtliche oder Compliance-bedingte Ausschlüsse, beispielsweise Arzneimittel oder politische Werbung
Entscheidend ist: Damit die Blacklist-Regeln wirkungsvoll sind, müssen spezialisierte Technologien (oft von externen Blacklist- oder Kategorisierungsdiensten betrieben) sie korrekt erkennen, interpretieren und technisch umsetzen. Doch genau hier stößt die Idee hinter dem Blacklisting an ihre Grenzen: Es gibt kein zentrales, homogenes System, was das Ganze sehr komplex macht. Das führt zu Kommunikationslücken zwischen Stakeholdern – und dadurch zu den sogenannten Blacklist Leaks.
Das Blacklisting-Universum bleibt weiterhin fragmentiert
Das Problem ist klar: Blacklisting ist ein Netzwerk aus vielen Stationen, die alle unterschiedlich sauber, schnell oder streng arbeiten. Mehrere Faktoren sorgen dafür, dass bis dato keine einheitliche Blacklist existiert:
- Blacklists werden häufig auf Plattform- bzw. Systemebene gepflegt. Selbst wenn ein Advertiser eine Liste implementiert, heißt das nicht automatisch, dass alle involvierten Systeme (wie Zwischenhändler, Reseller oder SSPs) dieselben Blockregeln anwenden.
- Aufgrund von technischen und operativen Dynamiken innerhalb des Publishinggeschäfts können sich Domains oder URL-Strukturen ändern. Dadurch fallen sie aus Blocklisten heraus oder werden falsch klassifiziert. Das erfordert eine permanente Aktualisierung von Blacklists.
- Zusätzlich sind die Marktteilnehmer in der DACH-Region durch Selbstverpflichtungen reguliert. So bestimmt der BVDW mit seinem Code of Conduct Programmatic Advertising Qualitätskriterien für DSPs, SSPs, Publisher und andere Akteure. Diese freiwillige Verpflichtung definiert Standards für Transparenz und Qualität, unter anderem im Umgang mit Inventar, Ad-Verifizierung und der Deklaration von Werbeumfeldern.
- Schließlich entwickeln sich Brand-Safety-Technologien ständig weiter. Dadurch kann die Sensitivität von Blacklisting-Tools von Anbieter zu Anbieter variieren.
Ihr seht: Im Blacklisting-Kosmos nutzt jeder seine eigenen Regeln. Listen aktualisieren sich asynchron. Verschiedene Systeme interpretieren Listen unterschiedlich. Zudem blocken manche Listen erst auf Impression-Ebene, nicht beim Bid Request. Diese Komplexität führt dazu, dass kein universaler, zentral gepflegter Blacklist-Standard im gesamten Ökosystem existiert.
Blacklists für Publisher sind notwendig, aber nicht ausreichend
Für Publisher ist Blacklisting ein möglicher Schutzmechanismus: Er signalisiert Werbekäufern, dass bestimmte Placements ausgeschlossen werden, und trägt zur Brand Safety bei. Gleichzeitig zeigt die Praxis: Blocklisten sind „grobe Werkzeuge“, die häufig nicht den nötigen Kontext erfassen können. Sie sind also als Teil eines größeren Qualitätssicherungs- und Transparenzrahmens zu betrachten.
Warum Blacklisting trotz korrekter Einrichtung geblockte Ads durchlassen kann
Da das Programmatic-Ökosystem selbst (noch) recht komplex ist, kann auch Blacklisting nicht optimal funktionieren. So kann es passieren, dass Ads, die bereits geblacklisted wurden, trotzdem ausgespielt werden. Dafür kann es verschiedene Gründe geben. Das sind einige davon:
Timing- & Sync-Probleme
- Schlechtes Timing im buchstäblichen Sinne: Wenn eine DSP die Blacklist aktualisiert, die SSP diese Info aber erst Stunden später bekommt.
- Publisher-Ad-Server synchronisiert Regeln nur alle X Minuten.
- Auch Caching-Effekte sorgen für alte Entscheidungsstände.
Unterschiedliche Matching-Logiken
- Publisher blockiert „example.com“ und eine DSP blockiert nur „www.example.com“.
- Ads laufen über CDN- oder Redirect-URLs, die nicht matchen.
- App-Traffic nutzt andere Identifier als Web.
Ad Creatives sind nicht statisch
- Gleiche Advertiser-ID, aber neues Creative fällt nicht in die Liste.
- Dynamische Ads können neue URLs verwenden.
- Clicktracker bleiben oft unerkannt.
Blacklisting wirkt in vielen Systemen verspätet
- Einige Lösungen prüfen erst beim „Ad Rendering“ oder nach der Impression.
- Viele Verification Tools blockieren erst nachgelagert (Post-Bid), nicht alle Filter greifen bereits im Bid Request.
SSPs ignorieren gelegentlich Publisher-Regeln
- Bessere Revenue, rCPM und Fill Rates priorisiert: SSPs optimieren stark auf Auslastung, um möglichst viele Ad Slots zu füllen und den Umsatz zu maximieren. Wenn eine SSP mehr Gebote von DSPs erhält, kann sie dazu tendieren, weniger restriktiv zu blockieren, insbesondere wenn Blockierungsregeln das Inventar stark einschränken würden.
- Fehlkonfiguration: Hier ist die technische Einrichtung der SSP-Integration entscheidend. Wenn ihr Regeln (wie Blacklist-Domains) nicht korrekt – im passenden Format – im System hinterlegt, erkennt die SSP diese nicht oder deutet sie falsch. Übrigens: Unsere Publisher-Partner müssen sich nicht darum kümmern, da die SSP-Anbindung direkt über unsere Monetarisierungsplattform läuft!
- Mismatch von Domains bei Mobile Web & In-App: Wenn verschiedene Supply-Pfade genutzt werden, kann eine Blacklist-Regel, die für Web gilt, in einem In-App-Kontext nicht angewendet werden – wenn die SSP den Bid Request nicht so matcht, dass die Regel greift.
- Fehlerhafte DSP-Signale: Wenn Signale, die DSPs in ihren Bid Requests senden, inkonsistent oder falsch sind (beispielsweise ein Redirect, das nicht korrekt gemeldet wird), kann die SSP die Blockregel nicht korrekt anwenden.
User-spezifische Rendering-Fehler
- Browser Extensions: Manche Browser Extensions können die Werbung injizieren – also zusätzliche Werbung in den DOM (die Struktur der Webseite) einfügen, die ihr ursprünglich nicht vorgesehen hattet. Diese Injected Ads können aus eurer Sicht geblockt sein, erscheinen aber trotzdem, weil sie von Drittanbieter-Code (Extension) stammen.
- Caching: Werden Nutzerseiten über Caches geladen (beispielsweise Browser Cache oder Proxy Cache), können alte Versionen von Seiten mit bereits geladenen Ads angezeigt werden. Das heißt: Eine neue Blacklist-Regel, die später implementiert wurde, trifft eventuell nicht auf gecachte Seite, die bereits das Ad-Element enthält.
- Kombinationsprobleme mit Consent-Strings: Wird in euren Programmatic Setups ein Consent String im Bid Request falsch oder inkonsistent übermittelt, kann das die SSP oder das Ad-Rendering beeinflussen. Das kann dazu führen, dass bestimmte Filter nicht greifen – oder dass bestimmte Gebote überhaupt nicht verarbeitet werden, sodass unerwünschte Ads durchrutschen können.
HAR-File als zentrales Diagnose-Tool für Publisher: Was es genau ist – und wozu es dient
Was ist eine HAR-Datei – und welche Informationen liefert sie?
Ein HAR-File (HTTP Archive) ist eine standardisierte Protokolldatei, die sämtliche Netzwerkaktivitäten eines Browsers in einem strukturierten JSON-Format aufzeichnet. Sie erfasst chronologisch jede einzelne HTTP-Anfrage und -Antwort, darunter:
- Header, Cookies und Informationen darüber, ob eine Ressource aus dem Cache geladen wurde,
- vollständige Request- und Response-Daten,
- sämtliche Redirects und Zwischenschritte,
- detaillierte Timing-Informationen zu DNS-Lookups, SSL-Handshake sowie Block-, Wait- und Receive-Phasen,
- HTTP-Statuscodes, abgebrochene Requests und Netzwerkfehler.
Eine HAR-Datei ist also eine Art vollständiger „Filmstreifen“ der Netzwerkkommunikation: Sie zeichnet jede HTTP-Anfrage und -Antwort auf, dokumentiert jedoch keine DOM-Veränderungen (Document Object Model) oder visuellen Rendering-Prozesse im Browser. Als ein Diagnosewerkzeug gibt sie euch einen tiefen Einblick in die tatsächliche Abfolge von Browser Requests und hilft, Probleme im Ablauf einer Seitenladung oder Ad-Auslieferung präzise nachzuvollziehen. Diese Analyse ist besonders hilfreich, wenn
- Anzeigen nicht wie erwartet ausgeliefert werden,
- Redirect-Ketten fehlerhaft laufen oder
- ein ungewöhnliches Timing- oder Ladeverhalten vorliegt.
Damit könnt ihr exakt identifizieren, welche Anfrage wann gestellt wurde, wie lange jeder Teil des Ladevorgangs gedauert hat – und an welcher Stelle die Kette fehlschlägt. Das sichert euch einen Vorteil, wenn unerwartete Ads, Blocklist-Leaks oder Probleme mit der Consent-Übermittlung untersucht werden müssen.
Wie erstelle ich als Publisher eine HAR-Datei?
Das Erstellen eines HAR-Files ist in allen gängigen Browsern ähnlich:
- Über die Entwickler-Werkzeuge (Chrome, Edge, Firefox, Safari) könnt ihr im Netzwerk-Tab die Aufzeichnung starten,
- die Seiteninteraktion reproduzieren
- und anschließend als HAR-Datei exportieren.
Plattformen wie Google Ad Manager oder Mozilla Firefox bieten dafür jeweils eigene Schritt-für-Schritt-Guides. Wichtig ist vor dem Start der Aufzeichnung, den Netzwerk-Log zu „preserven“ – damit der Browser die aufgezeichneten Netzwerk-Requests nicht löscht, sobald eine Seite neu lädt oder weiterleitet –, und den Cache zu deaktivieren, damit wirklich alle Requests sichtbar werden.
Unser Fazit: Blacklisting als wichtiger Teil von Brand Safety
Blacklisting ist ein bedeutendes, aber in der Praxis nie vollständig zuverlässiges Werkzeug. Die Vielzahl an Akteuren, die Komplexität der programmatischen Supply Chain und das Fehlen einer einheitlichen „Master-Blacklist“ führen dazu, dass unerwünschte Anzeigen trotz korrekter Regeln gelegentlich durchkommen. Darum funktioniert Blacklisting für Publisher am besten als Teil eines mehrschichtigen Qualitäts- und Kontrollsystems.
Es ist also nicht als statischer Schutz, sondern als ein laufender Prozess zu sehen. Wer ihn mit sauberer Technik, transparenten Partnerstrukturen und konsequentem Troubleshooting kombiniert, erreicht eine deutlich höhere Qualität und Sicherheit in der Ad-Ausspielung.
Ihr wollt mehr über eine Partnerschaft mit Traffective – oder über unsere ganzheitliche Monetarisierungsplattform für Publisher erfahren?
Titelbild: generiert mit ChatGPT
