Blockieren Adblocker das Meta-Pixel?

Viele Adblocker und Datenschutz-Browser blockieren es. Wird das Skript blockiert, erreichen Meta von diesem Besucher keine Browser-Events, aber Käufe, die serverseitig aus deinen Bestelldaten gesendet werden, kommen weiterhin an.

Wie viele Käufer nutzen Adblocker?

Das hängt von deiner Zielgruppe, deinen Geräten und Ländern ab, daher sagt eine allgemeine Zahl wenig über deinen Shop aus. Miss deine eigene Lücke, indem du Web-Bestellungen mit den Purchase-Events vergleichst, die dein Pixel im selben Zeitraum gesendet hat.

Können Adblocker Server-Side-Tracking blockieren?

Nicht den Kauf, der aus Bestelldaten gesendet wird, denn diese Anfrage geht von einem Server an die API der Plattform. Ein Blocker kann aber das Browser-Skript stoppen, das die Click-ID speichert. Deshalb ist die First-Party-Erfassung wichtig.

Ist ein Adblocker dasselbe wie eine abgelehnte Einwilligung?

Nein. Eine abgelehnte Einwilligung ist eine Entscheidung in deinem Cookie-Banner, der dein Tracking folgen muss. Ein Adblocker ist ein Werkzeug im Browser. Beides verringert die Pixel-Events, also miss beides getrennt.

Brauche ich das Pixel noch, wenn ich Käufe serverseitig sende?

Ja, für die Besucher ohne Blocker. Das Pixel liefert Browsing-Events und Browser-Cookies, und mit derselben Event-ID behält die Plattform von jedem Kauf eine Kopie.

Adblocker und Tracking: Was dein Shop verliert

Das Wichtigste in Kürze

Adblocker nutzen Filterlisten, um Pixel-Skripte und ihre Anfragen zu stoppen, sodass die Werbeplattform von diesem Browser gar kein Event erhält.
Ein blockiertes Pixel verliert Seitenaufrufe, Add-to-Cart-Events und Käufe, und der Kauf zählt am meisten, weil er den ausgewiesenen ROAS und die Gebote bestimmt.
Käufe, die serverseitig aus deinen Bestelldaten gesendet werden, sind nicht betroffen, weil der Browser des Käufers sie nicht sendet.
Miss deine eigene Lücke, indem du die Web-Bestellungen in deinem Shop mit den Purchase-Events vergleichst, die das Browser-Pixel gesendet hat, nicht mit zugeschriebenen Conversions.
Server-Side-Tracking kann Browsing-Events oder Click-IDs, die nie gespeichert wurden, nicht zurückholen; die First-Party-Erfassung verringert diesen Verlust.

Adblocker stoppen das Tracking, indem sie verhindern, dass das Pixel-Skript der Werbeplattform oder die Anfragen, die es sendet, im Browser des Käufers geladen werden. Dann erfährt die Plattform nichts vom Seitenaufruf, vom Warenkorb oder vom Kauf, obwohl die Bestellung in deinem Shop liegt. Käufe, die serverseitig aus deinen Bestelldaten gesendet werden, sind nicht betroffen, weil der Browser des Käufers am Senden nicht beteiligt ist.

Dieser Leitfaden erklärt, wie Adblocker und Datenschutzfunktionen im Browser funktionieren, welche Events dein Shop verliert, was Server-Side-Tracking wiederherstellt und was nicht. Am Ende steht eine einfache Methode, die Lücke in deinem eigenen Shop zu messen.

Wie stoppen Adblocker Tracking-Pixel?

Die meisten Adblocker arbeiten mit Filterlisten. Eine Filterliste ist eine lange Liste von Regeln, die auf Webadressen passen: Domains, Pfade und Dateinamen bekannter Werbe- und Tracking-Skripte. Fordert eine Seite den Browser auf, etwas zu laden, das einer Regel entspricht, bricht der Blocker die Anfrage ab.

Die bekanntesten Listen sind EasyList für Werbung und EasyPrivacy für Tracking. Sie funktionieren mit Erweiterungen wie Adblock Plus, AdBlock, uBlock Origin und AdGuard. Das Pixel einer großen Werbeplattform ist für diese Listen ein leichtes Ziel, weil es auf vielen verschiedenen Websites dasselbe Skript von derselben Domain lädt.

Seite lädtDein Theme enthält das Pixel-Skript der Werbeplattform.

Blocker prüft die AdresseDie Skriptadresse entspricht einer Regel in einer Filterliste.

Anfrage abgebrochenDas Skript läuft nie, deshalb entsteht kein Event.

WerbeplattformErhält nichts von diesem Besuch.

Ein blockiertes Pixel sendet kein schwächeres Event. Es sendet gar kein Event.

Browser mit integriertem Schutz

Manche Browser blockieren Tracker ohne Erweiterung. Brave aktiviert seine Shields standardmäßig für jede Website, und Shields blockieren Werbung von Drittanbietern, Tracker und websiteübergreifende Cookies. Firefox blockiert in privaten Fenstern Inhalte von bekannten Domains für websiteübergreifendes Tracking, und Nutzer können strengere Einstellungen wählen, die für alle Fenster gelten. Die Intelligent Tracking Prevention von Safari blockiert alle Drittanbieter-Cookies und verkürzt die Lebensdauer von Cookies, die Skripte setzen. Unser Leitfaden zu Safari ITP und Ad-Tracking erklärt diese Grenzen.

Netzwerkweite Blocker

Manche Menschen blockieren Tracker für ein ganzes Gerät oder Heimnetzwerk, mit einem DNS-basierten Blocker oder einem VPN mit Tracker-Filter. Diese stoppen Anfragen an Tracking-Domains in jedem Browser und jeder App in diesem Netzwerk. Ein Browserwechsel ändert daran nichts.

Welche Events verliert dein Shop?

Wenn das Pixel blockiert wird, geht jedes Event verloren, das es von diesem Browser gesendet hätte. Der Schaden ist aber nicht bei jedem Event gleich.

Event	Wofür es genutzt wird	Verloren, wenn das Pixel blockiert wird?	Können Bestelldaten es ersetzen?
PageView, ViewContent	Zielgruppen von Website-Besuchern, Produkt-Retargeting	Ja	Nein
AddToCart, InitiateCheckout	Optimierung auf Käufer, die einen Kauf beginnen, Warenkorb-Retargeting	Ja	Nein
Purchase	Gemeldete Conversions, ROAS, Kaufoptimierung, wertbasierte Gebote	Ja	Ja
Click-ID auf der Landingpage	Den Kauf dem genauen Anzeigenklick zuordnen	Ja, wenn das Tracking-Skript ebenfalls blockiert wird	Nein, sie muss im Browser gespeichert werden

Der Kauf ist das wertvollste Event, und er ist das Event, das Bestelldaten immer ersetzen können.

Verlorene Browsing-Events machen deine Retargeting-Zielgruppen kleiner. Verlorene Käufe richten mehr Schaden an. Die Plattform meldet weniger Conversions, der ROAS im Anzeigenbericht sinkt, und der Gebotsalgorithmus lernt von weniger Käufern. Eine profitable Kampagne kann dann unprofitabel aussehen, und du stoppst sie womöglich.

Warum serverseitige Events aus Bestelldaten nicht blockiert werden

Ein Adblocker läuft im Browser des Käufers. Er kann nur Anfragen stoppen, die der Browser stellt. Wird der Kauf aus den Bestelldaten deines Shops gesendet, geht die Anfrage von einem Server an die API der Werbeplattform. Der Browser des Käufers ist nicht Teil dieses Wegs, also gibt es für den Blocker nichts abzubrechen.

14:02:11 PageView pixelIm Browser durch eine Filterliste blockiert

14:09:47 Purchase pixel order-1042Wird nie gesendet, weil das Pixel-Skript nicht geladen wurde

14:09:52 webhook order-1042 paidDer Shop meldet die bezahlte Bestellung an den Server

14:10:12 Purchase server order-1042An die Conversions API gesendet, mit gehashter E-Mail-Adresse und Telefonnummer

Beispiel: ein Besuch mit Adblocker. Der Browser sendet nichts, aber der Kauf erreicht die Plattform trotzdem aus der Bestellung.

Die Plattform ordnet den Kauf dann anhand der Daten im Event einer Person zu: der gehashten E-Mail-Adresse und Telefonnummer aus der Bestellung, der IP-Adresse und dem User Agent sowie der Click-ID, falls eine gespeichert wurde. Nichts davon läuft über den Blocker. Für den vollständigen Datenweg lies, was Server-Side-Tracking ist.

Was kann Server-Side-Tracking nicht wiederherstellen?

Die Click-ID braucht den Browser

Die Bestellung selbst ist sicher, aber die Verknüpfung mit dem Anzeigenklick entsteht im Browser. Ein Skript muss die Click-ID aus der Landing-URL lesen und speichern. Blockiert ein Adblocker auch dieses Skript, kommt die Bestellung ohne Click-ID an. Die Plattform kann den Kauf weiterhin über gehashte Kundendaten zuordnen, aber die Zuordnung ist weniger sicher.

Zwei Dinge verringern diesen Verlust. Erstens: Erfasse Events First-Party. Liefere das Tracking-Skript und seine Anfragen von deiner eigenen Domain aus, zum Beispiel über einen Shopify-App-Proxy oder eine Subdomain deiner Website. Filterlisten zielen auf bekannte Tracking-Adressen von Drittanbietern, deshalb ist ein First-Party-Pfad viel schwerer zu blockieren, wenn auch nicht unmöglich. Zweitens: Nutze die Landingpage, die manche Webshops, etwa Shopify, mit jeder Bestellung speichern. Enthält diese URL noch die Click-ID oder UTMs, lässt sich die Bestellung ohne jedes Browser-Event zuordnen.

Browsing-Events gehen weiterhin verloren

Bestelldaten enthalten Bestellungen, keine Seitenaufrufe. Wenn du Käufe aus Bestellungen sendest, bekommst du die Seitenaufrufe und Add-to-Cart-Events eines Besuchers, dessen Browser alles blockiert hat, nicht zurück. Ein First-Party-Collector kann diese Events vom Server weiterleiten, wenn seine eigenen Anfragen durchkommen.

Abgelehnte Einwilligung ist keine Blockade

Ein Besucher, der Marketing-Cookies in deinem Cookie-Banner ablehnt, ist nicht dasselbe wie ein Besucher mit Adblocker. Der erste Besucher hat eine Entscheidung getroffen, der dein Tracking folgen muss. Ist Respect visitor consent aktiviert, setzt ROASaurus für diesen Besucher keine Besucher-ID, sodass seine Anzeigenklicks und Besuche nicht mit ihm verknüpft werden. Seine Browser-Events werden ohne Besucher-ID, IP-Adresse oder Browserdetails gespeichert und nicht an Werbeplattformen gesendet. Die bezahlte Bestellung wird weiterhin serverseitig gesendet, mit gehashten Kundendaten aus der Bestellung sowie der IP-Adresse und dem User Agent der Bestellung. Halte die beiden Gruppen auseinander, wenn du deinen Verlust misst. Die Details findest du unter Einwilligung und Datenschutz.

So schätzt du deinen eigenen Verlust

Branchendurchschnitte brauchst du nicht, sie hängen von Zielgruppe, Gerät und Land ab. Du kannst deine eigene Lücke messen, indem du die Bestellungen in deinem Shop mit den Käufen vergleichst, die das Browser-Pixel im selben Zeitraum gemeldet hat.

Wähle einen Zeitraum und eine Plattform
Nimm 14 oder 30 Tage und eine Plattform, zum Beispiel Meta. Verwende in beiden Systemen dieselbe Zeitzone.
Zähle die Web-Bestellungen in deinem Shop
Beginne mit allen Bestellungen. Ziehe die Bestellungen ab, die nie durch deinen Online-Checkout laufen: Point-of-Sale-Bestellungen, manuelle Bestellungen und Entwurfsbestellungen, Abo-Verlängerungen und Testbestellungen.
Zähle die Purchase-Events aus dem Browser
Zähle im Events-Tool der Plattform die Purchase-Events, die das Browser-Pixel gesendet hat. Das ist am einfachsten, bevor du Server-Events hinzufügst. Laufen Server-Events bereits, nutze die Ansicht der Plattform nach Verbindungsart, sofern sie eine bietet. Der Meta Events Manager zeigt die Verbindungsart jedes Events und zählt die Events dort vor der Deduplizierung. Verwende keine zugeschriebenen Käufe aus dem Anzeigenbericht.
Teilen
Browser-Käufe ÷ Web-Bestellungen ist der Anteil, den das Pixel gesehen hat. Der Rest ist deine Lücke.
Einwilligung von Blockierung trennen
Schätze die Bestellungen von Besuchern, die Marketing-Cookies abgelehnt haben, anhand der Ablehnungsquote aus deinem Consent-Tool. Was übrig bleibt, geht größtenteils auf Adblocker, Datenschutzeinstellungen und Seiten zurück, die nicht geladen wurden.

Beispiel-Shop, 30 Tage	Bestellungen	Anteil an den Web-Bestellungen
Alle Bestellungen im Shop	1,240
Point-of-Sale-, manuelle und Verlängerungsbestellungen	−90
Web-Bestellungen	1,150	100%
Purchase-Events vom Browser-Pixel	874	76%
Lücke	276	24%
Geschätzte Bestellungen von Besuchern, die die Einwilligung abgelehnt haben (10% Ablehnungsquote)	115	10%
Rest: Adblocker, Datenschutzeinstellungen, Seiten, die nicht geladen wurden	161	14%

In diesem Beispiel-Shop verpasst das Pixel etwa 1 von 4 Web-Bestellungen. Etwa 1 von 7 geht durch Blockierung und Browserfehler verloren, nicht durch fehlende Einwilligung.

Die Lücke verändert auch den ROAS. Angenommen, Meta meldet für diesen Shop einen ROAS von 2.0, und sein Break-even-ROAS liegt bei 2.3. Nach den Pixeldaten verlieren die Kampagnen Geld. Wären durch Anzeigen ausgelöste Bestellungen mit derselben Quote von 24% verpasst worden wie alle Web-Bestellungen, hätte das Pixel nur 76% des Anzeigenumsatzes gesehen. Der echte ROAS läge dann bei etwa 2.0 ÷ 0.76 = 2.6, also über dem Break-even. Das ist eine obere Schätzung, weil nicht jede fehlende Bestellung von einer Anzeige kam. Unser Leitfaden zum Break-even-ROAS erklärt, wie du diese Schwelle festlegst.

So verlierst du weniger

Die Maßnahmen sind für jede Webshop-Plattform dieselben. Am besten wirken sie zusammen.

Sende Käufe aus Bestelldaten. Das schließt die Kauflücke für jede Plattform, die du verbindest, egal was der Browser des Besuchers blockiert.
Behalte das Pixel, mit einer gemeinsamen Event-ID. Besucher ohne Blocker senden weiterhin Browser-Events mit Cookies und Seitenkontext. Dieselbe Event-ID auf beiden Kopien lässt die Plattform eine davon behalten. Siehe Doppelzählungen vermeiden.
Erfasse First-Party. Liefere das Tracking-Skript und seine Events von deiner eigenen Domain aus, damit Click-IDs für mehr Besucher gespeichert werden.
Sende gehashte Kundendaten. E-Mail-Adresse und Telefonnummer aus der Bestellung lassen die Plattform Käufe zuordnen, die keine Click-ID haben.
Miss erneut. Wiederhole den Vergleich einen Monat später. Die Purchase-Events, die die Plattform erhält, sollten jetzt zu deinen Web-Bestellungen passen.

Beispiel-Shop: Purchase-Events, die Meta in 30 Tagen erhalten hat

Nur PixelPixel + Server, dedupliziert

Purchase-Events

874

1,150

Sobald Käufe aus Bestelldaten gesendet werden, erreichen alle 1,150 Web-Bestellungen die Plattform. Das Pixel ergänzt weiterhin Browserdaten für die 874 Bestellungen, die es gesehen hat.

Wie ROASaurus mit Adblockern umgeht

ROASaurus sendet jede bezahlte Bestellung serverseitig an die Werbeplattformen, die du unter Tracking & platforms hinzufügst, sodass ein Adblocker im Browser des Käufers den Kauf nicht stoppt. In Shopify laufen Storefront-Events über den App-Proxy von Shopify auf deiner eigenen Shop-Domain. Du kannst das Skript und seine Events auch von einer CNAME-Subdomain deiner Website ausliefern. Hat ein Besucher keinen Browser-Kontakt, greift die Attribution von ROASaurus auf die Click-IDs und UTMs in der Landing-URL der Bestellung zurück, sofern der Shop eine erfasst, wie es Shopify tut.

Jede Übermittlung und die Antwort der Plattform stehen im Event log, sodass du prüfen kannst, ob jede Bestellung jede Plattform erreicht hat. Zur Einrichtung siehe Server-Side-Tracking und die Shopify-Integration.

Quellen

In ROASaurus

Weiterlesen

TrackingConsent Mode v2 und DSGVO: Was ein Webshop senden darfConsent Mode v2 für Webshops: die vier Einwilligungssignale von Google, was das EU-Recht verlangt und was Server-Side-Tracking weiterhin senden darf. Nur allgemeine Informationen.TrackingDoppelte Kauf-Events: Warum Verkäufe doppelt gezählt werdenDoppelte Kauf-Events blähen Conversions und ROAS auf. Hier findest du die Ursachen, erfährst, wie Meta, TikTok, Snapchat, Pinterest und Reddit deduplizieren, und wie du das Problem behebst.TrackingSafari ITP und Ad-Tracking: Was noch funktioniertSafari ITP begrenzt Cookies, die von Skripten gesetzt werden, auf 7 Tage, nach manchen Anzeigenklicks sogar auf 24 Stunden. Hier siehst du, was das mit der Attribution macht und welches Tracking weiterhin funktioniert.