Meta Pixel und DSGVO:_fbp-Cookie schon beim ersten Aufruf

Was der Meta Pixel beim Seitenaufruf tut: unser Eigenversuch

Der Pixel wird mit einem Basiscode eingebunden: Ein Snippet lädt fbevents.js von connect.facebook.net, danach folgen fbq('init', ...) und fbq('track', 'PageView'). Wir haben genau diesen offiziellen Basiscode in unserem Prüfstand nachgestellt: frisches Chromium 153 (headless) ohne gespeicherte Cookies, eine Testseite ohne Banner, zwölf Sekunden Wartezeit mit Mausbewegung, Scrollen und einem Klick auf die Seite, drei Läufe, Messtag 30. Oktober 2026. Verwendet haben wir einen bestehenden Pixel, der laut Events Manager in den vier Wochen davor keine Aktivität empfangen hatte; die Pixel-ID nennen wir nicht. Die Einwilligung haben wir nur simuliert: In der Variante „nachladen“ ruft ein Klick auf einen Button den Lader auf, eine echte Consent-Plattform war nicht im Spiel. Erfasst haben wir Hosts, Pfade, Parameternamen, Cookies und Speicherschlüssel, nie Werte.

In allen drei Läufen war das Ergebnis identisch. Die Anfragenkette der Standard-Konfiguration, mit Zeitpunkt in Millisekunden seit Navigationsbeginn:

Drei Dinge fallen auf. Erstens: Das Beacon an /tr/ geht nach rund 260 Millisekunden hinaus, lange bevor ein Mensch ein Banner gelesen haben kann, und es trägt den Parameter fbp. Er ist der Name des Cookies, das der Basiscode zu diesem Zeitpunkt bereits gesetzt hat. Zweitens: Schon der Abruf der Loader-Datei verbindet den Browser mit connect.facebook.net. Beim Abruf eines Skripts von einem fremden Server erhält dieser Server technisch zwingend die IP-Adresse des Besuchers. Das ist eine Tatsache des Skriptabrufs und keine Aussage darüber, welche Daten der Pixel später sendet. Drittens: Wir haben die Parameterwerte bewusst nicht mitgeschrieben und können daher nicht belegen, welche Inhalte im Beacon stehen. Nur beim Parameter dl haben wir den Pfad erfasst. Weitere Anfragen, etwa von Advanced Matching oder der Microdata-Autokonfiguration, traten in den zwölf Sekunden mit Scrollen und Klick nicht auf.

Was dieser Versuch nicht belegt

Der verwendete Pixel hatte laut Events Manager in den vier Wochen davor keine empfangene Aktivität, und seine Kontoeinstellungen sind uns nicht bekannt. Die ID ist im Events Manager als Pixel bestätigt. Ob Meta unsere Testereignisse dort auswies, haben wir nicht festgestellt. Zusätzlich war der Konfigurationsabruf mit rund 408 KB deutlich größer als bei einer erfundenen ID (rund 30 KB). Nicht gemessen haben wir Advanced Matching in einer echten Einbindung, die Conversions API, andere Pixel-Konfigurationen und Browser mit Tracking-Schutz. Die Einwilligung war simuliert, ein Klick auf einen eigenen Button, kein Consent-Tool.

Zum Cookie: Mit der verwendeten Pixel-ID setzte der Basiscode _fbp schon beim ersten Seitenaufruf, vor jeder Interaktion. Mit einer erfundenen ID blieb es aus, und der Beacon lief ohne fbp, denn für diese ID lieferte Meta keine nennenswerte Konfiguration. Das erklärt, warum ein erster Versuch ohne Cookie zum Korpus passte, in dem fast alle Beacon-Seiten das Cookie haben (siehe nächster Abschnitt), nicht aber zum Regelfall. Mit gültiger Pixel-ID entspricht der Versuch dem Regelfall im Korpus. Ob jeder Pixel unabhängig von seiner Konfiguration so reagiert, zeigt ein einzelner Pixel nicht.

Wie oft das vor der Einwilligung passiert

Aus dem Korpus: 2.188.885 Websites, deren letzter erfolgreicher Scan ab dem 1. Oktober 2026 liegt (Stand B). Wir nennen ausschließlich diesen Stand, weil er mit einem einheitlichen Scanner-Stand gemessen ist. Er besteht zu 91 % aus .de-Seiten und gilt daher für deutsche Websites, nicht für das ganze Web.

So liest man die Tabelle: Von den Seiten mit erkanntem Banner, auf denen überhaupt eine Meta-Anfrage auftaucht, hat jede dritte sie so eingebunden, dass sie trotz Banner vor dem Klick lädt. Auch diese 33,1 % enthalten die Skripte, die kein Pixel sind, und eine bereinigte Quote haben wir nicht gerechnet. Auf Seiten ohne erkanntes Banner ist die Frage ohnehin offen, denn dort gibt es keinen Klick, der etwas freischalten könnte. „Ohne Banner“ heißt „ohne erkanntes Banner“: Eigenbauten und seltene Consent-Tools kann der Scanner übersehen. Rund 59 % der 51.496 Seiten haben ein erkanntes Banner.

Warum 2,35 % nicht „Pixel sendet“ heißt

Unser Fingerprint „Meta Pixel“ hängt am blanken Host connect.facebook.net und am Beacon-Pfad facebook.com/tr. Ausgenommen sind nur /fbevents.js und /signals/config/, weil ein Pixel unter consent revoke genau diese beiden Dateien lädt, ohne Ereignisse zu senden. Jedes andere Skript von connect.facebook.net, etwa sdk.js des Facebook-SDK und der Social-Plugins, wird dagegen als „Meta Pixel“ gezählt. Wir haben die 51.496 Treffer anhand ihrer Anfragen-Timeline in Klassen zerlegt:

Klasse B ist nach unserer Einordnung sehr wahrscheinlich kein Pixel-Einsatz, sondern ein eingebundenes Facebook-SDK oder Plugin: Das Cookie steht dort nur bei 1,3 %. Die einzelnen Skripte haben wir nicht aufgeschlüsselt, das ist eine Annahme. Ohne Klasse B bleiben 31.313 Seiten (1,43 % von 2.188.885), davon 93,8 % mit _fbp vor der Einwilligung (29.382). Klasse C hat Loader und Cookie, aber keinen als „vor“ markierten Beacon in der Timeline; die Ursache haben wir nicht untersucht, erste Annahme ist ein Beacon in anderer Phase oder auf anderem Pfad. Reine Beacon-Seiten (Klasse A) sind 1,07 % aller Seiten.

Zur Robustheit, getrennt zu lesen (Stand A, 4.920.998 Seiten mit gemischten Scanner-Ständen): Dieselbe Zählweise ergibt dort 2,23 %, ohne Alias- und Weiterleitungsdubletten 2,09 %, in der bereinigten Hygiene-Stichprobe 2,29 %. Die Größenordnung hängt nicht an Parking- oder Weiterleitungsfarmen. Pixel, die erst auf Unterseiten laden, fehlen, denn gemessen wird nur die Startseite.

Cookie-Befund (Stand B)

Wo wir den Pixel-Beacon vor der Einwilligung gesehen haben (Klasse A, 23.478 Seiten), lag in 92 Prozent der Fälle bereits ein _fbp-Cookie, und in 96 Prozent der Fälle (22.635 Seiten) hat der Beacon seinen Wert gleich als Parameter fbp mitgeschickt. Das passt zum Versuch, in dem der Basiscode das Cookie beim ersten Aufruf setzte. Das Muster spricht dafür, dass fbevents.js das Cookie per JavaScript setzt: Von den 29.637 _fbp-Cookies vor der Einwilligung sind nur 31 (0,1 %) HttpOnly, und 98,4 % haben eine Laufzeit von 89 Tagen. Der Setzer selbst ist nicht beobachtet, nur die Eigenschaften des Cookies.

Die Gegenrichtung: Bei 843 der 23.478 Beacon-Seiten (3,6 %) fehlt der Parameter fbp, und 484 davon (57 %) haben auch kein Cookie. Bei einer Minderheit fehlt das Cookie also; ob der Pixel eines nutzt, ist im Beacon sichtbar. Dazu ein Messartefakt: Bei 731 Beacon-Seiten erscheint _fbp erst nach dem Klick im Cookie-Snapshot, bei 675 davon trug der Beacon den Parameter aber schon vorher. Die Quote „Cookie vor der Einwilligung“ ist daher eher zu niedrig als zu hoch. Wo der Scanner nur einen gesperrten Loader oder ein Consent-Mode-Signal sieht (3.131 Seiten), steht _fbp praktisch nie (0,6 %).

Skript geladen, Daten gesendet: was consent revoke leistet

Meta dokumentiert für die Einwilligungssteuerung zwei Aufrufe: fbq('consent', 'revoke') pausiert das Senden von Ereignissen, fbq('consent', 'grant') gibt es nach der Zustimmung frei. Laut Meta-Entwicklerdokumentation muss revoke auf jeder Seite aufgerufen werden, im Beispiel steht es vor init. Das sind Angaben des Anbieters.

Unser Versuch bestätigt, was das bedeutet und was nicht. Mit revoke vor init blieben das Cookie, der Konfigurationsabruf und das Bild-Beacon aus, es ging nur noch die Anfrage nach fbevents.js hinaus, ohne Cookie und ohne Speicherschlüssel. Das ist der Unterschied zwischen zwei Fragen, die in der Praxis oft vermischt werden:

Ob die bloße Verbindung zur Loader-Datei rechtlich ein Problem ist, ist eine Auslegungsfrage, die wir nicht entscheiden. Wir zeigen nur die Tatsache: Wer die strengere Lesart wählen will, lädt das Skript gar nicht. Wer revoke nutzt, muss wissen, dass er die Verbindung in Kauf nimmt, und sollte das dokumentieren.

Rechtliche Einordnung (Stand 29. Oktober 2026)

Wir trennen hier, was Gesetz ist, was Aufsichtsauffassung ist und was Rechtsprechung. Das ist keine Rechtsberatung.

Gesetz: § 25 TDDDG

Das Speichern von Informationen auf dem Endgerät und der Zugriff auf dort gespeicherte Informationen sind nach § 25 Abs. 1 TDDDG nur mit Einwilligung zulässig, nach Auffassung der DSK (Rn. 26) unabhängig davon, ob die Informationen personenbezogen sind. Die Ausnahmen in Abs. 2 gelten für die reine Nachrichtenübertragung und für Vorgänge, die zwingend erforderlich sind, damit ein vom Nutzer ausdrücklich gewünschter Dienst bereitgestellt werden kann. Das Cookie _fbp ist eine Speicherung nach Abs. 1. Erforderlich im Sinne von Abs. 2 ist es nach unserer Einschätzung nicht; das ist eine Einordnung, keine Entscheidung eines Gerichts zum Pixel.

Aufsichtsauffassung: DSK Orientierungshilfe Digitale Dienste

Die Datenschutzkonferenz hat in der Orientierungshilfe Digitale Dienste (Version 1.2, November 2024) mehrere Punkte festgehalten, die für den Pixel einschlägig sind:

• Zeitpunkt (Rn. 36): Die Einwilligung muss vor dem einwilligungsbedürftigen Zugriff vorliegen. Es ist nicht zulässig, Cookies beim ersten Aufruf zu setzen und erst anschließend zu fragen. Die Aussage betrifft Cookies. Der Datenfluss vor dem Klick, den unser Scanner misst, ist damit verwandt, aber nicht identisch.
• Drittinhalte (Rn. 101): Mit der Einbindung von Drittinhalten ist regelmäßig die Offenlegung personenbezogener Daten an den Betreiber des Drittservers verbunden, dafür braucht es eine Rechtsgrundlage nach Art. 6 DSGVO.
• Berechtigtes Interesse (Rn. 109 und 111): Nach Rn. 109 sind im Kontext des Trackings nur in wenigen Konstellationen die Voraussetzungen des Art. 6 Abs. 1 lit. f DSGVO erfüllt. Nach Rn. 111 gilt: Wird ein Drittdienstleister als Auftragsverarbeiter eingebunden und verarbeitet er Daten auch zu eigenen Zwecken, wird der Rahmen der Auftragsverarbeitung überschritten, und für die Übermittlung, „sei es nur der IP-Adresse“, kann Art. 6 Abs. 1 lit. f DSGVO in der Regel keine wirksame Rechtsgrundlage bilden.

Die Orientierungshilfe ist keine bindende Rechtsquelle, aber die Linie, an der sich Aufsichtsbehörden ausrichten. Eine Aussage speziell zum Meta Pixel enthält sie nicht.

Rechtsprechung des EuGH

Fashion ID (C-40/17, Urteil vom 29. Juli 2019). Der Betreiber einer Website, die den Facebook-Button einbindet, kann nach Auffassung des Gerichtshofs gemeinsam mit Facebook verantwortlich sein, und zwar für das Erheben der Besucherdaten und deren Übermittlung an Facebook, nicht für die spätere Verarbeitung allein durch Facebook. Die Einwilligung muss der Betreiber vorher für genau diese Vorgänge einholen, und er muss die Besucher zum Zeitpunkt des Erhebens informieren. Das Urteil erging noch zur Datenschutzrichtlinie von 1995 und zu einem Social Plugin, nicht zum Pixel; die Verantwortlichkeit stand unter dem Vorbehalt der Nachprüfung durch das vorlegende Gericht. Es wird in der Praxis dennoch für Pixel und ähnliche Werbe-Tags herangezogen. Diese Übertragung ist eine Einordnung, keine Entscheidung des Gerichtshofs zum Pixel.

Meta Platforms u. a. (C-252/21, Urteil vom 4. Juli 2023). Der Gerichtshof hat entschieden, dass die Personalisierung der Werbung, mit der Facebook finanziert wird, nicht als berechtigtes Interesse von Meta die streitige Verarbeitung (unter anderem Daten über den Aufruf dritter Websites und Apps) rechtfertigt, sofern keine Einwilligung vorliegt. Es geht um Metas eigene Verarbeitung auf Facebook. Für Betreiber folgt daraus nichts automatisch. Als Hinweis auf die Richtung der Rechtsprechung ist das Urteil dennoch einschlägig; die Übertragung auf Betreiber ist unsere Einordnung.

Instanzgerichte: Nutzer gegen Meta, nicht gegen Betreiber

Laut Medieninformation des OLG Dresden hat der 4. Zivilsenat am 3. Februar 2026 in vier Parallelverfahren Meta zur Zahlung von je 1.500 Euro immateriellem Schadensersatz an Instagram-Nutzer verurteilt und Meta untersagt, die über die Business Tools gewonnenen personenbezogenen Daten weiterzuverarbeiten. Das Gericht sah die erforderlichen Einwilligungen als nicht gegeben an. Die Revision wurde nicht zugelassen, die Urteile sind laut Mitteilung rechtskräftig. Die Mitteilung nennt keine Aktenzeichen; in Sekundärquellen kursieren widersprüchliche Angaben, deshalb nennen wir keines. Das Landgericht Leipzig hat laut seiner Medieninformation am 4. Juli 2025 (5. Zivilkammer, 05 O 2351/23) einem Facebook-Nutzer 5.000 Euro Entschädigung gegen Meta zugesprochen, gestützt auf Art. 82 DSGVO. Beide Fälle richten sich gegen Meta, nicht gegen Website-Betreiber. Sie zeigen, dass Gerichte die Datenverarbeitung über die Business Tools ohne Einwilligung als Verstoß werten und den Kontrollverlust als Schaden anerkennen können. Ob und wie sich daraus Ansprüche gegen Betreiber oder Agenturen ergeben, ist damit nicht geklärt. Die Urteilsvolltexte haben wir nicht gelesen, nur die Medieninformationen der Gerichte.

Meta über die eigene Rolle

Nach den Business Tools Terms von Meta (Datum des Inkrafttretens 3. November 2025, Abschnitte 3 und 5) sind Betreiber und Meta Ireland für Event-Daten, die aus Handlungen auf der Website stammen, gemeinsam Verantwortliche nach Art. 26 DSGVO; das Controller Addendum regelt diese gemeinsame Verarbeitung. Außerdem soll der Betreiber, wo eine Einwilligung erforderlich ist, in nachprüfbarer Weise sicherstellen, dass die Endnutzer sie erteilen. Das sind Angaben des Anbieters in seinen Vertragsbedingungen, keine Rechtsauffassung einer Behörde oder eines Gerichts. Wir haben den Text nur auszugsweise gelesen und geben keine Wertung ab.

Drittlandtransfer

Nach der geteilten Einstufung in Complianty (Stand 29. Oktober 2026) ist Meta Pixel ein Dienst mit Sitz in den USA, Transfergrundlage Data Privacy Framework und Standardvertragsklauseln. Die Stufe sagt nur, dass eine Grundlage dokumentiert ist, nicht dass sie trägt. Das Gericht der EU hat die Klage gegen den Angemessenheitsbeschluss am 3. September 2025 abgewiesen (T-553/23). Dagegen ist das Rechtsmittel C-703/25 P eingelegt und laut InfoCuria (Abruf 29. Oktober 2026) anhängig. Ein Rechtsmittel hemmt den Beschluss nach unserem Kenntnisstand nicht, er gilt also weiter. Für den Pixel löst der Transfer ohnehin nur eine von zwei Fragen: Er sagt nichts darüber, ob Sie eine Einwilligung brauchen.

Was der Befund für die Umstellung heißt

Gedeckt durch den Versuch ist nur ein Weg: Basiscode erst nach der Einwilligung ausgeben, etwa über einen Lader, den das Consent-Tool nach Zustimmung zur Kategorie „Marketing“ aufruft. Dann gab es vor dem Klick null Anfragen und kein Cookie. revoke und grant sind der Weg mit weniger Umbau, lassen aber die Verbindung zu connect.facebook.net bestehen (siehe oben) und müssen auf jeder Seite stehen. Drei Punkte darüber hinaus:

• Ein Plugin kann am Consent-Tool vorbei laden. Bei Shop-Systemen und WordPress-Plugins prüfen Sie, ob das Plugin den Pixel selbst ausgibt. Kontrollieren Sie nach dem Umbau auch Unterseiten und Warenkorb.
• Advanced Matching: Beim manuellen Advanced Matching übergeben Sie Kundendaten (E-Mail, Name, Telefon und weitere) als Parameter im init-Aufruf; der Pixel hasht sie mit SHA-256. Das ist nach unserer Einordnung eine Übermittlung personenbezogener Daten, denn gleiche Eingaben hashen gleich und lassen sich abgleichen. Was Advanced Matching in einer echten Einbindung überträgt, haben wir nicht gemessen.
• Conversions API: Sie sendet Ereignisse vom eigenen Server, ohne Anfrage aus dem Browser. Unser Scanner und jeder Netzwerk-Reiter sehen das nicht, ob es stattfindet, zeigt nur der Events Manager. Dass die Anfrage nicht aus dem Browser kommt, ändert nichts an der Frage nach der Rechtsgrundlage; wir halten es für die vorsichtige Lesart, auch serverseitige Ereignisse nur nach Einwilligung zu senden. Das ist unsere Einordnung. Meta erwähnt die Conversions API auf der Seite zur Einwilligungssteuerung des Pixels nicht.

Selbst prüfen: Pixel oder nur ein Meta-Skript?

Im Netzwerk-Reiter eines frischen Browserfensters (Banner nicht anklicken, nach facebook filtern) entscheidet der Pfad. Ein Bild-Beacon an facebook.com/tr ist der Pixel. Nur connect.facebook.net/.../fbevents.js deutet auf einen Pixel unter revoke oder einen nicht ausgelösten Pixel. Andere Skripte von connect.facebook.net sind nach unserer Messung häufig das Facebook-SDK, also kein Pixel. Serverseitige Ereignisse sehen Sie dort nicht. Den ersten Teil übernimmt der kostenlose DSGVO-Scan.

Wo der Meta Pixel in Complianty auftaucht

Lädt nach unserem Scan vor der Einwilligung etwas von Meta, das der Fingerprint als Pixel führt, entsteht das To-Do „Tool vor Einwilligung“ mit der Priorität kritisch, belegt mit dem eingefrorenen Beweis-Block des Scans (Host, Phase, Zeitpunkt relativ zum Klick, redigierte URL). Der Pixel erscheint im Verarbeitungsverzeichnis des Mandanten und im AVV-Tracker. Die Loader-Datei allein erzeugt keinen Befund. Weil der Fingerprint auch andere Skripte von connect.facebook.net als Pixel führt, prüfen Sie im Beweis-Block, ob ein Beacon an /tr dabei ist.

Weiterlesen

Haftung der Agentur, Rechtsprechungsüberblick und die Schritte zum Entfernen eines Pixels stehen im Blogartikel Meta Pixel & DSGVO 2026. Wie Pre-Consent-Tracking sich technisch erkennen lässt, beschreibt Tracking vor Cookie-Consent erkennen.