Was ist ein Tracking Pixel?

Technisch gesehen ist ein Tracking Pixel ein <img>-Tag, dessen src-Attribut auf einen fremden Server verweist, üblicherweise außerhalb der eigenen Domain. Browser oder Mail-Client laden es wie jedes andere Bild, ganz ohne JavaScript, und genau diese HTTP-Anfrage wird auf dem Zielserver mit IP-Adresse, User-Agent, Uhrzeit und, falls die URL Parameter enthält, mit der Kampagnen- oder Nachrichten-ID protokolliert.

Der Name führt oft zur Verwechslung mit dem Cookie, dabei sind es zwei getrennte Dinge: Das Pixel löst die Anfrage aus, das Cookie speichert eine Kennung über mehrere Besuche hinweg. Die meisten Pixel, etwa das Meta-Pixel oder der LinkedIn Insight Tag, laden heute gar nicht mehr als 1x1-Grafik. Sie laufen als JavaScript-Tag, der beides gleichzeitig erledigt: Er sendet das Ereignis an den Server und liest oder schreibt zusätzlich ein Cookie, um denselben Browser bei einem späteren Besuch wiederzuerkennen. Der Begriff „Pixel" ist geblieben, obwohl sich die Technik dahinter längst verändert hat.

Eingesetzt wird es vor allem für drei Zwecke: das Öffnen einer E-Mail bestätigen, die Ankunft auf einer Landingpage nach einem Anzeigenklick erfassen, und Remarketing-Listen aus Besuchern einer bestimmten Seite aufbauen.

Die drei Begriffe werden gern in einem Satz vermischt, lösen aber unterschiedliche Teile desselben Problems.

Der technische Weg unterscheidet sich zwischen den drei Varianten, doch die Pflicht zur Einwilligung bleibt in allen gleich.

Verarbeitet der Browser das HTML einer Seite oder E-Mail, stößt er auf das Pixel-Tag und schickt eine GET-Anfrage an den im src hinterlegten Server. Der Server muss darauf lediglich eine minimale, meist transparente 1x1-Grafik zurückgeben; entscheidend ist die Anfrage selbst, die mit Zeitstempel, IP-Adresse und den übrigen HTTP-Headern protokolliert wird. Enthält die URL einen Parameter mit der Mail- oder Kampagnen-ID, lässt sich der Eintrag direkt diesem Versand zuordnen.

JavaScript-basierte Pixel wie das von Meta oder Google Ads gehen einen Schritt weiter: Neben der Anfrage lesen sie ein vorhandenes Cookie der eigenen Domain aus oder legen ein neues an. So erkennt das System denselben Browser bei einem späteren Besuch wieder und baut daraus Remarketing-Zielgruppen. Dieser Schritt hängt vollständig davon ab, ob der Browser das Speichern und Auslesen von Cookies über Seitengrenzen hinweg erlaubt, und genau hier ist die Lage 2026 uneinheitlich: Safari blockiert Drittanbieter-Cookies seit Version 13.1 im Jahr 2020 standardmäßig, Firefox seit 2019 mit seinem für alle Nutzer aktivierten Schutz vor Aktivitätenverfolgung, und Chrome hat nach Jahren angekündigter Abschaffung im Juli 2024 zurückgerudert und im Oktober 2025 offiziell bestätigt, die Cookies zu behalten und stattdessen den Großteil der als Ersatz geplanten Privacy-Sandbox-Technologien einzustellen.

Deshalb gewinnt serverseitiges Tracking als Ergänzung an Bedeutung: Statt auf die Anfrage aus dem Browser zu warten, sendet der eigene Server das Ereignis direkt über eine API an die Plattform, etwa die Conversions API von Meta oder die Enhanced Conversions von Google Ads. Das umgeht einen Blocker im Browser, doch es bleiben personenbezogene Daten, die an einen Dritten gehen, und dafür gilt dieselbe Rechtsgrundlage wie beim klassischen Pixel.

Von den Daten, die ein Pixel erfasst, hängen echte Budgetentscheidungen ab. Wird eine Conversion nicht erfasst, weil das Pixel nicht ausgelöst hat, wirkt die betreffende Kampagne schwächer als sie war, und das Budget wandert dorthin, wo Daten vorliegen, nicht zwingend dorthin, wo die Ergebnisse tatsächlich entstanden.

Dazu kommt ein rechtliches Risiko. Wer ein Pixel mit personenbezogenen Daten auslöst, bevor der Nutzer eingewilligt hat, verstößt gegen Artikel 5 Absatz 3 der ePrivacy-Richtlinie, und Aufsichtsbehörden wie die französische CNIL haben genau dieses Muster bereits geahndet. Genau das kann zum Bußgeldrisiko für das Unternehmen werden.

Die Fragmentierung zwischen den Browsern erschwert zudem den Vergleich zwischen Kampagnen: Dieselbe Aktion kann in Chrome andere Zahlen zeigen als in Safari, ein rein technischer Effekt, der davon abhängt, wie viele Ereignisse der jeweilige Browser überhaupt erfasst. Die Umstellung auf serverseitiges Tracking kostet anfangs mehr Implementierungsaufwand, zahlt sich mittelfristig aber meist durch stabilere Daten aus.

Wegen der ungleichen Lage zwischen den Browsern und des regulatorischen Drucks setzen immer mehr Unternehmen auf First-Party-Daten und serverseitiges Tracking, um nicht allein von einem Cookie abhängig zu sein, das ein Browser jederzeit blockieren kann.

• Pixel technisch an das Consent-Banner (CMP) koppeln, sodass die Anfrage den Browser erst nach echter Einwilligung verlässt.
• Jedes aktive Pixel mit dem echten Anbieternamen in der Cookie-Richtlinie dokumentieren, statt einer generischen Kategorie wie „Werbung".
• Serverseitiges Tracking bei den Conversions priorisieren, die tatsächlich Budgetentscheidungen beeinflussen, statt sich allein auf das Browser-Pixel zu verlassen.
• Regelmäßig prüfen, welche Pixel noch auf der Seite laden; Reste einer abgeschlossenen Kampagne bringen nur Risiko, keinen Nutzen.
• Mit den Netzwerktools des Browsers testen, dass kein Pixel vor der Einwilligung feuert.
• Keine identifizierbaren Daten wie die Klartext-E-Mail in die Pixel-URL packen.

• Das Pixel auslösen, bevor der Nutzer das Cookie-Banner bestätigt hat, der am häufigsten geahndete Fehler.
• Annehmen, serverseitiges Tracking brauche keine Einwilligung, weil es kein Cookie setzt, obwohl es weiterhin personenbezogene Daten transportiert.
• Sich allein auf ein Drittanbieter-Cookie-Pixel für Remarketing-Zielgruppen verlassen, ohne Plan für Safari oder Firefox.
• Das Pixel weder im Verarbeitungsverzeichnis noch in der Datenschutzerklärung der Seite aufführen.
• Davon ausgehen, Chrome habe Drittanbieter-Cookies bereits abgeschafft, obwohl Google 2025 offiziell das Gegenteil bestätigt hat.