ChatGPT Ads TrackingDas Snippet ist schnell korrigiert. Die eigentliche Datenschutz-Entscheidung fällt im Werbekonto.

Die Voreinstellungen eines Werbesystems sind für seinen größten Markt gemacht, nicht für die Rechtslage hierzulande. OpenAI sagt das in der eigenen Hilfe selbst: Die nötigen Einwilligungen einzuholen, ist Sache des Werbetreibenden.

Wie misst ChatGPT Ads Conversions?

Über zwei Wege mit demselben Ziel: den Measurement Pixel im Browser und die Conversions API auf Ihrem Server. Der Pixel ist ein JavaScript-SDK, das Sie mit Ihrer Pixel-ID initialisieren und bei einer Conversion mit oaiq("measure", …) aufrufen. Die Conversions API ist eine Server-zu-Server-Schnittstelle, die dieselben Ereignisse direkt von Ihrem Backend annimmt; OpenAI bezeichnet sie als zuverlässigere Quelle als den Pixel allein und rät für eine robustere Messung, beide zu kombinieren.

Drei Begriffe tragen den Rest dieses Beitrags:

• oppref ist die Klick-Kennung, die OpenAI an die Ziel-URL einer Anzeige hängt — vergleichbar mit der gclid bei Google Ads. Der Pixel speichert sie im First-Party-Cookie __oppref, Laufzeit 30 Tage.
• obref ist eine zufällig erzeugte Browser-Referenz, die der Pixel im Cookie __obref ablegt, Laufzeit 365 Tage.
• event_id ist eine Kennung, die Sie selbst vergeben, damit OpenAI dieselbe Conversion aus Browser und Server als einen einzigen Vorgang erkennt.

Zwei Punkte zur Lesart der Zahlen gehören in jede Auswertung. Erstens: Wo verfügbar, können die ausgewiesenen Conversions laut OpenAI-Hilfe modellierte Conversions enthalten — geschätzte Zuordnungen auf Basis beobachteter Muster. Zweitens: View-Through-Conversions mit festem Ein-Tages-Fenster weist OpenAI getrennt aus; sie zählen nicht zu „Conversions“, und Gebote, Abrechnung und CPA bleiben klickbasiert. Wie sich ChatGPT-Werbung in Deutschland grundsätzlich buchen und aussteuern lässt, steht im Beitrag ChatGPT-Werbung in Deutschland.

Warum misst das Standard-Snippet schon vor der Einwilligung?

Weil der Pixel laut Dokumentation mit erteilter Einwilligung startet, solange niemand etwas anderes festlegt. Im Wortlaut: „The Pixel initializes consent to true by default unless you set it to false or the Pixel finds a stored denial.“ Das Installations-Snippet, das OpenAI zum Kopieren anbietet, enthält keinen Einwilligungsaufruf. Wer es unverändert in den <head> setzt, sendet Messereignisse, bevor ein Besucher im Cookie-Banner überhaupt etwas entschieden hat.

Zu den Einwilligungsanforderungen hierzulande passt das nicht — die Einstellung muss geändert werden. § 25 Abs. 1 TDDDG erlaubt das Speichern von Informationen im Endgerät und den Zugriff darauf nur mit Einwilligung auf Grundlage klarer und umfassender Informationen, sofern keine der beiden engen Ausnahmen greift; Werbemessung ist für die Bereitstellung einer Website nicht unbedingt erforderlich. Der Europäische Datenschutzausschuss stellt in seinen Leitlinien 2/2023 ausdrücklich fest, dass die zugrunde liegende Vorschrift der ePrivacy-Richtlinie nicht nur Cookies, sondern auch Tracking-Pixel erfasst.

OpenAI verortet die Verantwortung an derselben Stelle. Die Hilfe zur Conversion-Messung verlangt, Conversion-Daten erst zu senden, nachdem Nutzer klar informiert wurden und alle gesetzlich nötigen Einwilligungen vorliegen. Die Entwicklerdoku zum Conversion-Tracking ergänzt, dass die Consent-Steuerung des Pixels dort, wo Einwilligung nötig ist, vor der Initialisierung zu setzen ist. Voreinstellung und Pflicht stehen also beide in OpenAIs Dokumentation — nur an verschiedenen Stellen, und das Snippet zum Kopieren folgt der Voreinstellung.

Die Korrektur ist kurz, aber die Reihenfolge ist nicht verhandelbar:

oaiq("consent", false);   // zuerst: nichts senden
oaiq("init", { pixelId: "<IHRE-PIXEL-ID>" });
// erst nach Zustimmung im Cookie-Banner:
oaiq("consent", true);

Wer den Pixel ohnehin erst nach der Zustimmung über die Consent-Management-Plattform oder den Tag Manager lädt, braucht den Aufruf trotzdem: Er ist der Weg, auf dem ein späterer Widerruf beim Pixel ankommt. Mit consent auf false entfernt der Pixel laut Doku beide Cookies. Ereignisse, die in der Zwischenzeit blockiert wurden, holt er nicht nach — „blocked events aren’t replayed“. Das ist korrekt so, bedeutet aber: Wer vor der Zustimmung konvertiert, fehlt in der Messung, und das gehört in jede Erwartung an die Zahlen.

Automatic Advanced Matching: die Einstellung, die im Code nicht vorkommt

Automatic Advanced Matching (AAM) ist eine Funktion des Pixels, die Kontaktangaben aus Formularen auf Ihrer Website selbsttätig erkennt, im Browser per SHA-256 in einen Hashwert umrechnet und diesen mit den Conversion-Ereignissen an OpenAI sendet. Zweck laut OpenAI: Conversions auch dann einer Anzeige zuordnen zu können, wenn die Klick-Kennung fehlt. Die Klartextangaben verlassen den Browser dabei nach OpenAIs Angaben nicht.

Entscheidend ist, wo AAM gesteuert wird — nämlich nicht im Code. Die Dokumentation sagt ausdrücklich, dass dafür weder Kundendaten übergeben noch die Pixel-Einbindung geändert werden müssen. Über die Ads-API angelegte Web-Pixel nutzen AAM laut API-Referenz automatisch. In unserem eigenen Werbekonto war die Funktion aktiv, ohne dass wir sie eingeschaltet hatten; aufgefallen ist sie uns erst im Debug-Modus des Pixels. Ein Code-Review, ein Tag-Manager-Audit oder ein Cookie-Scan zeigt davon nichts.

Drei Folgen sollten Sie kennen, bevor Sie AAM aktiv lassen:

• Ein Hashwert ist pseudonym, nicht anonym. Er wird gerade dazu gebildet, einen Menschen wiederzuerkennen. Der Europäische Datenschutzausschuss behandelt in seinen Leitlinien eigens Kennungen, die aus Name, E-Mail-Adresse oder Telefonnummer auf dem Gerät des Nutzers gehasht und dann eingesammelt werden — und ordnet genau dieses Einsammeln als Zugriff im Sinne der ePrivacy-Vorschrift ein. Dass das Hashen im Browser geschieht, nimmt die Funktion also nicht aus dem Anwendungsbereich.
• AAM liest die Seite, nicht nur Ihr Conversion-Formular. Die Hilfe spricht von Angaben aus „recognizable forms and other sources on your website“. Läuft der Pixel seitenweit, betrifft das jedes Formular auf jeder Seite, auf der er geladen ist — auch eines, das mit der Kampagne nichts zu tun hat.
• Die Datenschutzerklärung muss es benennen. Wenn der Pixel Formularangaben gehasht überträgt, gehört das in die Information, auf deren Grundlage eingewilligt wird — unabhängig davon, ob Ihr eigener Code solche Daten je anfasst.

Wir haben daraus eine Konsequenz gezogen, die sich auf viele Websites übertragen lässt: Auf den Seiten zu unserem Widerrufs-Button lädt der Pixel überhaupt nicht. Dort stehen eine Live-Demo und ein Bestellformular, für die bei uns die Regel gilt, kein Marketing-Tracking einzusetzen. Mit AAM ließe sich diese Regel über eine Kontoeinstellung aushebeln, ohne dass im Code eine Zeile danach aussieht. Die Ausnahme steht deshalb als Liste in der Seitengenerierung, nicht als Hinweis in einem Dokument.

Pixel und Conversions API: Warum zählt, welches Ereignis zuerst ankommt?

Weil OpenAI bei doppelt gemeldeten Conversions das zuerst eingetroffene Ereignis behält und jedes spätere mit demselben Schlüssel ignoriert. Der Schlüssel besteht aus Pixel-ID, Ereignisname und Ereignis-ID — event_id im Pixel, id in der Conversions API. Das ist dokumentiert und funktioniert. Was die Dokumentation nicht ausbuchstabiert, ist die Folge für den Inhalt: Gezählt wird, was im ersten Ereignis steht.

In unserer Umsetzung kommt das Server-Ereignis regelmäßig rund eine Sekunde vor dem Browser-Ereignis an. Der Server meldet die Anfrage, sobald sie eingegangen ist; der Pixel feuert erst, wenn die Bestätigung im Browser angekommen ist. Daraus folgen zwei Dinge, die in keiner Einrichtungsanleitung stehen, die wir bei der Recherche gesehen haben:

• Die Klick-Kennung muss mit auf den Server. Der Pixel erfasst oppref selbst, die Conversions API laut Doku ausdrücklich nicht. Gewinnt ein Server-Ereignis ohne oppref, zählt eine Meldung, der genau das Signal fehlt, über das eine Conversion einer Anzeige zugeordnet wird. Wir reichen oppref und obref deshalb aus den Pixel-Cookies an den Server weiter — mit Rückfall auf den URL-Parameter, falls der Pixel nicht geladen hat — und protokollieren bei jedem Aufruf, ob die Kennung dabei war. Ein erfolgreicher Aufruf ohne Kennung ist eine gezählte, aber nicht zugeordnete Conversion; das soll im Protokoll auffallen, nicht erst in der Auswertung.
• Die gehashten Browser-Daten kommen in diesem Fall nicht zum Zug. Wird das Browser-Ereignis als Duplikat ignoriert, betrifft das nach unserem Verständnis der Doku auch die AAM-Hashwerte, die es trägt. Das ist Datensparsamkeit als Nebenprodukt der Architektur. Verlassen sollten Sie sich darauf nicht: Die Reihenfolge ist eine Beobachtung zur Laufzeit, keine Zusage.

Für alle, die Weiterleitungen einsetzen — Sprachumleitungen, Kampagnen-Redirects, Tracking-Links —, gilt zusätzlich der Hinweis aus der OpenAI-Hilfe: oppref muss über Weiterleitungen und die Navigation auf der Zielseite erhalten bleiben. Ein Redirect, der Parameter verwirft, kostet die Zuordnung, bevor der Pixel überhaupt etwas speichern konnte.

Braucht auch die Conversions API eine Einwilligung?

Ja — und anders als der Pixel bringt die Conversions API dafür keinen eigenen Schalter mit. Die Schnittstelle kennt kein Einwilligungsfeld; sie verarbeitet, was Ihr Server schickt. Die Doku verweist für die Browser-Referenz obref ausdrücklich auf die Einwilligungsanforderungen Ihrer Website und verlangt, die Übermittlung bei einem Widerruf einzustellen. Serverseitige Messung ändert die Architektur, nicht die Rechtsgrundlage.

So haben wir den Serverweg gebaut:

• Hartes Gate auf dem Server. Das Formular überträgt den Einwilligungsstand mit; nur bei dokumentierter Marketing-Einwilligung verlässt überhaupt ein Ereignis den Server. Jeder unterlassene Aufruf steht mit Grund im Protokoll.
• Keine Formularinhalte. Der Server meldet Ereignistyp, Ereignis-ID, Zeitpunkt, Seitenadresse und die beiden Kennungen — keinen Namen, keine E-Mail-Adresse, auch nicht gehasht, und weder IP-Adresse noch User-Agent, obwohl die API beides annehmen würde.
• Kennungen nur mit Einwilligung. oppref und obref stammen aus Cookies, die ohne Zustimmung gar nicht entstehen. Ohne Einwilligung gibt es also nichts weiterzureichen, und wir legen auch keine eigene Ersatzspeicherung an.

Der Schlüssel für die Conversions API gehört ausschließlich auf den Server. OpenAI schreibt das in der API-Referenz unmissverständlich: nie in Browser-Code, sichtbare Umgebungsvariablen, Logs oder die Versionsverwaltung.

Was OpenAI an der Messung sauber gelöst hat

Die Einwilligungslogik des Pixels ist, einmal richtig eingestellt, sorgfältig gebaut. Das gehört zur Einordnung, denn die Kritik oben betrifft Voreinstellungen, nicht die Mechanik dahinter.

• Ablehnungen bleiben bestehen. Findet der Pixel eine gespeicherte Ablehnung, bleibt die Einwilligung aus — auch wenn der Code ihn erneut initialisiert.
• Widerruf räumt auf. consent auf false entfernt __oppref und __obref; blockierte Ereignisse werden nicht nachträglich gesendet.
• Laufzeiten sind dokumentiert. 30 Tage für __oppref, 365 Tage für __obref. Zusätzlich beobachten wir ein Cookie __oaiq_consent, das die Entscheidung selbst speichert und auch bei einer Ablehnung bestehen bleibt, damit sie beachtet wird. Auf der Pixel-Seite der Doku ist es nicht aufgeführt — in Ihre Cookie-Liste gehört es trotzdem.
• Keine Personalisierung aus Messdaten — derzeit. OpenAI erklärt für Pixel und Conversions API, die Daten aktuell nicht zur Personalisierung auf Nutzerebene zu verwenden, und bietet je Ereignis ein Opt-out-Feld für den Fall, dass sich das ändert.
• Keine Sicherheitsabkürzungen. Die Doku zur Content Security Policy rät ausdrücklich davon ab, für den Pixel unsafe-inline freizugeben.

Was Sie jetzt konkret tun sollten

Beste Option: Prüfen Sie Ihre Umsetzung an allen drei Stellen, nicht nur am Snippet. Die folgende Liste ist die, nach der wir neowulf.net gebaut haben:

Pragmatische Alternative, wenn ein Serverweg gerade nicht drin ist: Starten Sie nur mit dem Pixel — mit consent auf false vor der Initialisierung und einer bewussten Entscheidung zu AAM. Das misst weniger als ein hybrides Setup, ist aber in einer Stunde sauber umgesetzt und lässt sich später um die Conversions API erweitern, ohne etwas zurückzubauen. Rechnen Sie dann damit, dass Ads Manager und Analytics voneinander abweichen; OpenAI nennt selbst Einwilligungs- und Speicherbedingungen im Browser als einen der Gründe dafür.

Konkreter nächster Schritt: Öffnen Sie Ihre Website in einem privaten Fenster, starten Sie die Entwicklerwerkzeuge des Browsers, filtern Sie den Netzwerk-Tab nach „bzr.openai“ und laden Sie die Seite neu, ohne das Cookie-Banner anzuklicken. Erscheint dort ein Eintrag, misst Ihr Pixel vor der Einwilligung. Das dauert zwei Minuten und beantwortet die erste der drei Fragen. Die zweite beantwortet ein Blick in die Einstellungen der Datenquelle in Ihrem Werbekonto.

Dieser Beitrag beschreibt Technik und Dokumentation; er ist keine Rechtsberatung. Einwilligungstexte und Datenschutzerklärung stimmen Sie mit Ihrem Datenschutzbeauftragten ab.