Das Messpixel geht von einer Einwilligung aus, solange ihm niemand widerspricht
Ein Messpixel ist ein kleines Programm auf deiner Seite, das dem Werbeanbieter meldet, wenn jemand nach einem Anzeigenklick tatsächlich bestellt oder anfragt. Ohne dieses Programm bleibt von einer Kampagne allein die Kostenseite sichtbar. Wie der Kanal drumherum aufgesetzt wird, von der Kontoprüfung bis zur freigegebenen Anzeige, steht in ChatGPT Ads für Shopify-Shops: was vor dem ersten Euro geklärt sein muss. Hier geht es um das Pixel und um die Sekunde, in der es geladen wird.
Das Pixel von ChatGPT Ads bringt eine Voreinstellung mit, die in Europa alles Weitere bestimmt. In der Doku zum Messpixel steht sie so:
The Pixel initializes consent to
trueby default unless you set it tofalseor the Pixel finds a stored denial.
Erteilt ist also der Ausgangszustand. Wer nichts unternimmt, hat ein Programm auf der Seite, das misst und Cookies schreibt, bevor irgendjemand gefragt wurde. Ein Cookie ist dabei ein kleiner Vermerk, den eine Seite im Browser des Besuchers ablegt und beim nächsten Aufruf wiederfindet.
In Deutschland verlangt § 25 TDDDG für das Speichern von Informationen auf dem Endgerät eines Nutzers und für den Zugriff auf bereits gespeicherte Informationen eine Einwilligung auf der Grundlage klarer und umfassender Informationen. Ein Cookie zu setzen fällt unter die Vorschrift, es zu lesen ebenfalls. Der Weg, den die Doku dafür anbietet, ist ein Aufruf vor der Initialisierung:
Set consent before initializing the Pixel
Diesen Weg haben wir am 02.09.2026 nachgemessen, indem wir die ausgelieferte Datei oaiq.min.js in der Fassung 0.1.32 gelesen haben. Der Aufruf oaiq("consent", false) schreibt dabei selbst ein Cookie mit dem gespeicherten Einwilligungsstand, dreißig Tage Laufzeit. Damit legt auch die dokumentierte Ablehnung etwas auf dem Gerät ab, und für § 25 TDDDG ist genau das eine Speicherung. Wir laden das Skript deshalb erst, wenn die Einwilligung vorliegt. Die Begründung dafür und was sonst noch an OpenAI geht, steht ausführlich in Conversion-Tracking für ChatGPT Ads einrichten, ohne doppelt zu zählen.
Drei Cookies legt das Pixel ab, und die Doku nennt davon zwei
Beim Lesen von oaiq.min.js 0.1.32 am 02.09.2026 kamen drei Namen heraus, deren Laufzeiten wir am 04.09.2026 im Browser nachgemessen haben. __oppref trägt die Klick-Kennung, die eine Anzeige in ChatGPT als Parameter an deine Zieladresse hängt, und läuft dreißig Tage. __obref trägt eine Browser-Kennung für die Zuordnung und läuft ein Jahr. __oaiq_consent trägt den gespeicherten Einwilligungsstand, also den Vermerk darüber, was der Besucher gesagt hat, und läuft wieder dreißig Tage.
Die Doku führt zwei der drei Namen, verteilt auf zwei Seiten. Auf der Seite zum Messpixel steht ein Satz über den Klickparameter:
It stores
opprefin a first-party__opprefcookie so later page views can reuse it.
Die Browser-Kennung steht auf der Seite zur Conversions API, wo es darum geht, denselben Wert vom eigenen Server aus mitzuschicken. Den gespeicherten Einwilligungsstand nennt keine der beiden Seiten. Wer seine Datenschutzerklärung entlang der Doku schreibt, führt darin also zwei Cookies auf, während im Browser seiner Besucher drei liegen, und es fehlt ausgerechnet der Eintrag über den gespeicherten Einwilligungsstand.
Der Einbau aus der Doku setzt das Skript ganz oben in den Kopf der Seite
Die Doku beschreibt den Einbau als einen Block, der in den Kopf jeder Seite gehört, auf der gemessen werden soll, und sie sagt auch, wie weit oben:
Put the script near the top of your
<head>to ensure early conversions aren't lost while other content loads.
Der Block selbst tut drei Dinge, und die Reihenfolge ist der Grund für alles, was danach kommt. Er legt eine Funktion namens oaiq am Fenster an. Er baut ein Skript-Element mit async und hängt es in die Seite, womit der Browser den Abruf von bzrcdn.openai.com startet. Und er ruft unmittelbar danach oaiq("init", ...) mit der Pixel-Kennung auf, obwohl das Skript zu diesem Zeitpunkt noch gar nicht da sein kann.
Für die Einwilligung schiebt die Doku einen Aufruf davor, oaiq("consent", false), gefolgt von oaiq("consent", true), sobald der Besucher zugestimmt hat. Alle diese Aufrufe gehen an ein Programm, das zu diesem Zeitpunkt noch unterwegs ist, und sie werden trotzdem angenommen.
Zwischen dem Ruf an das Pixel und der Ankunft des Skripts steht nur eine Warteschlange
Dass Aufrufe an ein Programm gehen, das es noch nicht gibt, funktioniert nur wegen eines Tricks, den fast jeder Werbeanbieter benutzt. Die Funktion oaiq, die der Einbaublock anlegt, misst zunächst gar nichts. Sie legt jeden Aufruf mitsamt seinen Argumenten auf eine Liste, und mehr tut sie nicht. Wenn das Skript ankommt, ersetzt es diese Sammelfunktion durch die echte und arbeitet die Liste der Reihe nach ab.
Das ist ein Notizblock neben dem Telefon. Solange niemand da ist, wird aufgeschrieben, und wer später hereinkommt, arbeitet die Notizen von oben nach unten durch. Genau deshalb geht bei einer langsamen Verbindung keine Konversion verloren, und genau deshalb wird jeder Aufruf, den du vor der Ankunft machst, später trotzdem noch ausgeführt.
Wie lang dieses Fenster ist, entscheidet die Verbindung des Besuchers, und die ist im Mobilfunk eine andere als im Büro. Gemessen haben wir seine Dauer nicht: für die Prüfung im Browser mussten wir es künstlich aufziehen, weil sich sonst gar nicht hineinklicken lässt.
Ein Widerruf in diesem Fenster löscht Cookies, die es noch gar nicht gibt
Der Ablauf, der schiefgeht, sieht aus der Sicht des Besuchers harmlos aus. Er klickt im Banner auf Akzeptieren, überlegt es sich gleich danach anders, öffnet die Einstellungen wieder und lehnt ab.
Beim Akzeptieren ruft das Banner den Lader, das Skript-Element geht in die Seite, der Abruf läuft. Der Widerruf tut danach zwei Dinge: er sagt dem Pixel consent auf falsch, und er löscht die drei Cookies. Beide Schritte laufen, während das Skript noch auf der Leitung ist. Der erste Schritt landet damit als Notiz auf der Liste. Der zweite Schritt sucht nach Cookies, die noch niemand geschrieben hat, und findet nichts.
Dann kommt das Skript an und arbeitet die Liste ab. Darauf stehen der Reihe nach: Einwilligung erteilt, initialisieren, Einwilligung verweigert. Beim Initialisieren schreibt es die beiden Kennungen. Beim Widerruf am Ende der Liste wirft es diese beiden selbst wieder weg und legt dabei __oaiq_consent an, den Vermerk über die Ablehnung. Unsere Löschung ist an dieser Stelle längst gelaufen, und niemand ruft sie ein zweites Mal.
Was danach auf dem Gerät liegt, ist der eigentliche Schaden. Der Besucher hat Nein gesagt, der Einwilligungsnachweis in der Datenbank sagt Nein, das Banner sagt Nein, und trotzdem trägt sein Browser dreißig Tage lang ein Cookie eines amerikanischen Werbeanbieters, das dieses Nein festhält. Auch dieser Vermerk fällt unter § 25 TDDDG, und er liegt auf dem Gerät eines Besuchers, der die Speicherung gerade abgelehnt hat. Ein Aufruf wie oaiq("consent", false) verhindert allein künftige Schreibvorgänge, und was schon auf dem Gerät liegt, bleibt dort bis zu seinem Ablaufdatum.
Die Verweigerung muss zweimal laufen, sofort und nach der Ankunft des Skripts
Die Abhilfe verlangt zwei Angaben, die es vorher nicht gab: ob das Skript überhaupt angefordert wurde und ob es schon da ist. Der Lader setzt die erste Angabe, sobald er das Skript-Element in die Seite hängt. Die zweite setzt er im onload des Elements, also in dem Moment, in dem der Browser meldet, dass die Datei geladen und ausgeführt ist.
Damit kann die Verweigerung unterscheiden. Ist das Skript noch nie angefordert worden, reicht ein Durchgang, denn es gibt nichts, was später noch etwas schreiben könnte. Ist es angefordert und bereits eingetroffen, reicht ebenfalls ein Durchgang, denn die Cookies stehen schon da und werden jetzt gelöscht. Nur im Fenster dazwischen, angefordert und noch nicht eingetroffen, wird eine Kopie der Verweigerung hinterlegt. Das onload des Laders ruft sie genau einmal auf und vergisst sie danach.
In beiden Durchgängen läuft dieselbe Reihenfolge: erst dem Pixel sagen, dass die Einwilligung fehlt, dann löschen. Umgekehrt ginge es nicht, weil der Aufruf consent(false) selbst das Cookie __oaiq_consent schreibt und dieses Cookie sonst als einziges liegen bliebe.
Wer sich mitten im Laden doch für Ja entscheidet, muss den vorgemerkten Widerruf zurücknehmen
Eine hinterlegte Verweigerung ist ein Auftrag, der später ausgeführt wird, und Aufträge dieser Art werden gefährlich, wenn sich die Lage vorher ändert. Der Besucher, der ablehnt und es sich innerhalb desselben Ladefensters noch einmal anders überlegt, hat am Ende eine gültige Einwilligung. Läge der alte Auftrag noch bereit, würde das onload ihn trotzdem ausführen und die gerade erst geschriebenen Cookies wieder löschen.
Die Einwilligung räumt deshalb den hinterlegten Widerruf weg, bevor sie den Lader ruft. Die Reihenfolge im Ladefenster ist damit: verweigern legt eine Nachholung bereit, eine spätere Einwilligung nimmt sie wieder weg, und das onload des Laders findet dann nichts mehr vor.
Ein Cookie verschwindet nur durch einen Schreibvorgang, der seine Domain trifft
Löschen ist bei Cookies kein eigener Vorgang. Man überschreibt ein Cookie mit demselben Namen und einem Ablaufdatum in der Vergangenheit, und der Browser wirft es daraufhin weg. Das gelingt nur, wenn Name, Domain und Pfad des Schreibvorgangs zu dem passen, was dasteht, und ausgerechnet Domain und Pfad lassen sich nicht zurücklesen.
Beide Werbeanbieter setzen ihre Cookies auf der registrierbaren Domain, also auf der Adresse, die du gekauft hast, statt auf der einzelnen Unterdomain. Der Aufräumcode schreibt das Ablaufdatum deshalb für den aktuellen Host und für jede übergeordnete Domain bis hinauf zu ihr. Für die reine Endung schreibt er nichts, weil dort ohnehin kein Cookie liegen kann.
Angefasst werden ausschließlich die Cookies der Anbieter, bei OpenAI die drei Namen aus der ausgelesenen Datei, jeder davon vollständig verglichen. Ein Name wie __oppref_x bliebe damit unberührt, weil er zu keiner der drei Bezeichnungen gehört. Was wir aus eigenen Gründen setzen, etwa das Einwilligungscookie selbst, bleibt ebenfalls liegen: darin steht die Entscheidung, um die es hier überhaupt geht.
Ein Rest bleibt trotzdem auf dem Gerät. Das Skript von OpenAI legt seinen Einwilligungsstand zusätzlich im lokalen Speicher des Browsers ab, unter oaiq_consent, und dieser Eintrag steht nach einem Widerruf weiter da, gemessen am 04.09.2026 in Chromium. Er trägt dann die Ablehnung, und genau eine solche gespeicherte Ablehnung nennt die Doku als den Grund, aus dem das Pixel beim nächsten Besuch von sich aus nichts misst.
Das Pixel hat einen dritten Zustand: angefordert und noch nicht angekommen
Ein fremdes Skript ist aus Sicht der Seite, die es einbaut, entweder schon da oder noch gar nicht angefordert, und beide Fälle lassen sich am Schreibtisch durchspielen. Beim Messpixel liegt ein dritter Zustand dazwischen: das Skript-Element hängt in der Seite, der Abruf von bzrcdn.openai.com läuft, und das Programm selbst ist noch unterwegs. Nur in diesem Zustand läuft eine Löschung ins Leere, und er entsteht erst durch echte Zeit auf einer echten Leitung.
Sichtbar wird der Fall deshalb nur in einem echten Browser. Am 02.09.2026 kam er in Chromium heraus, dem Browser-Unterbau von Chrome: der Abruf des Skripts wurde gezielt verzögert, damit sich in diesem Fenster überhaupt klicken lässt, und danach wurden die Cookies aus dem Browser ausgelesen. Am 04.09.2026 lief derselbe Weg zweimal, einmal mit dem alten Stand und einmal mit dem heutigen: mit dem alten stand __oaiq_consent nach dem Widerruf im Browser, mit dem heutigen keines der drei Cookies.
Eine verspätete Serverantwort setzt die Einwilligung wieder auf erteilt
Ein zweiter Weg, auf dem eine Ablehnung verlorengeht, betrifft jede Einwilligungslösung, in der eine Entscheidung erst über eine Leitung geht und die Antwort darauf den Anbietern den Stand meldet. Klickt ein Besucher zweimal kurz hintereinander, laufen zwei solche Antworten gleichzeitig. Sie können in umgekehrter Reihenfolge eintreffen, und die zuletzt eintreffende bestimmt, was bei den Anbietern steht.
Wer akzeptiert und gleich danach ablehnt, hat genau diese zwei Antworten unterwegs. Trifft die Antwort auf das Akzeptieren nach der Antwort auf das Ablehnen ein, meldet sie eine erteilte Einwilligung, während Cookie und Banner Ablehnung anzeigen. Am 02.09.2026 kam der Fall im Browser heraus, indem Akzeptieren und Ablehnen kurz hintereinander geklickt wurden: bei Google und bei OpenAI stand danach wieder eine erteilte Einwilligung, und der Widerruf war für beide nie passiert.
Die Abhilfe ist eine laufende Nummer. Jede Entscheidung bekommt eine, jede Antwort führt die Nummer ihrer Anfrage mit, und eine Antwort, die zu einer inzwischen überholten Entscheidung gehört, wird verworfen.
Drei Dinge lassen sich am Banner deiner eigenen Seite selbst nachsehen
Für alle drei brauchst du nur die Entwicklerwerkzeuge deines Browsers, dort den Bereich mit den Cookies der Seite, und dazu die Konsole.
Erstens der Zustand vor jeder Entscheidung. Lade die Seite in einem frischen Fenster und sieh nach, ob ein Cookie mit einem der Namen __oppref, __obref oder __oaiq_consent schon dasteht. Tippe danach in der Konsole window.oaiq ein: beim Einbau aus der Doku steht dort ab dem ersten Moment die Sammelfunktion, und bei einem Einbau, der das Skript erst nach der Einwilligung anfordert, gibt es sie zu diesem Zeitpunkt noch gar nicht.
Zweitens der Widerruf mit Ruhe davor. Akzeptiere, warte, bis die Cookies erscheinen, öffne die Einstellungen und lehne ab. Danach dürfen die drei Namen verschwunden sein.
Drittens der Widerruf ohne Ruhe davor, der Fall aus diesem Bericht. Akzeptiere und lehne sofort danach ab, ohne auf die Cookies zu warten. Wenn danach eines der drei dasteht, hat deine Seite genau die Lücke, um die es hier geht, und ein Nachladen der Seite räumt sie nicht auf: der Vermerk über den Einwilligungsstand läuft dreißig Tage, die Browser-Kennung ein Jahr.
Was in diesem Fall gilt
Das Messpixel von ChatGPT Ads stellt seine Einwilligung laut Doku selbst auf erteilt, es legt drei Cookies ab, zwei davon mit dreißig Tagen Laufzeit und eines mit einem Jahr, und die Doku führt davon zwei. Weil es als Skript erst aus dem Netz kommt, gibt es ein Fenster, in dem eine Löschung ins Leere läuft und danach der Vermerk über die Ablehnung stehen bleibt. Auf dieser Seite läuft die Verweigerung seit dem 02.09.2026 zweimal, sofort und noch einmal beim Eintreffen des Skripts, und die Einwilligung nimmt einen vorgemerkten Widerruf zurück. Gefunden wurde die Lücke am 02.09.2026 in einem Chromium-Lauf mit verzögertem Abruf des Fremdskripts. Wie lang das Fenster bei einem einzelnen Besucher ausfällt, entscheidet dessen Verbindung, und für die Prüfung musste es künstlich aufgezogen werden, damit sich überhaupt hineinklicken lässt.
