ChatGPT Ads Conversion Tracking einrichten: Pixel, Conversions API und oppref

Was du misst, und warum oppref darüber entscheidet

Ein Besucher stellt ChatGPT eine Frage, klickt auf eine Anzeige unterhalb der Antwort und kauft in deinem Shop. In deinem Report steht danach ein Verkauf, der aus ChatGPT kam. Was dort nicht steht: ob du für diesen Klick bezahlt hast. Der Referrer chatgpt.com und ein angehängtes utm_source=chatgpt.com tragen den bezahlten und den organischen Fall gleichermaßen.

Getrennt werden die beiden Fälle nur über die Klick-ID, also den Parameter, den das Werbenetzwerk beim Klick an die Ziel-URL hängt. Bei OpenAI heißt sie oppref, und sie ist das einzige verlässliche Merkmal dafür, dass ein Besuch aus einer bezahlten Anzeige stammt. Wer sie nicht auswertet, rechnet Anzeigenumsatz dem organischen ChatGPT-Kanal zu. Die Kosten stehen dann auf der einen Seite, der Umsatz auf der anderen, und jede Aussage über die Rentabilität dieses Kanals ist wertlos.

Der zeitliche Ablauf macht das dringlicher, als es klingt. OpenAI kündigte am 18.08.2026 die Ausweitung auf 31 europäische Länder an und nannte Deutschland und Österreich namentlich. Der Self-Serve Ads Manager war am 20.08.2026 dagegen nur in neun Ländern verfügbar, in keinem davon in der EU. Die Anzeigen laufen also, bevor deutsche Händler selbst buchen können. Der Messbedarf entsteht vor dem Buchungsbedarf, und ein Klick, dessen ID niemand gespeichert hat, lässt sich später nicht mehr zuordnen.

Zurück zum Überblick: ChatGPT Ads, der Leitfaden zum DACH-Start. Zum organischen Fall: Traffic aus KI-Assistenten tracken.

Die drei Bausteine

OpenAI hat für Werbung einen eigenen Messstack gebaut, statt sich an bestehende anzuhängen. Google und Microsoft messen ihre KI-Platzierungen weiter über gtag und UET. Bei OpenAI kommen ein eigenes Pixel, eine eigene Conversions API und ein eigener Klick-Parameter dazu. Für dich heißt das: Eine vorhandene Meta- oder Google-Anbindung deckt diesen Kanal nicht mit ab.

Pixel und API sind kein Entweder-oder. Der Browser liefert Signale, die der Server nicht hat, allen voran die Klick-ID aus der URL. Der Server liefert Käufe auch dann, wenn im Browser ein Blocker sitzt. Läuft beides parallel, meldet derselbe Kauf zwei Wege, und genau dafür gibt es die Deduplizierung, also das einmalige Zählen jedes Verkaufs. Wie sie funktioniert, steht in Abschnitt 7.

Dasselbe Muster bei Meta: Meta Conversions API einrichten. Das Fundament: Server-Side Tracking, der Leitfaden.

Zuerst die Einwilligung, sonst misst du zu früh

Die Reihenfolge im Code entscheidet hier über die Rechtmäßigkeit, deshalb kommt dieser Schritt vor dem Einbau. Das OAIQ-Pixel kennt einen Einwilligungs-Status, und dieser Status steht auf true, solange ihn niemand setzt. Ein Pixel, das nach der Einbau-Anleitung eingefügt wird und sonst nichts, misst also ab dem ersten Seitenaufruf, auch bei einem Besucher, der im Banner gerade ablehnt.

Du drehst das um, indem du den Status vor dem init-Aufruf auf false setzt und ihn erst nach der Zustimmung freischaltest. Steht der consent-Aufruf hinter init, ist das erste Ereignis schon draußen.

<script async src="https://bzrcdn.openai.com/sdk/oaiq.min.js"></script>
<script>
  window.oaiq = window.oaiq || function () { (oaiq.q = oaiq.q || []).push(arguments); };

  // Vor init: nichts messen, solange keine Einwilligung vorliegt.
  oaiq("consent", false);
  oaiq("init", { pixelId: "DEINE-PIXEL-ID" });
</script>

Die Freigabe hängt dann an deinem Einwilligungs-Banner. Sobald der Besucher die Kategorie Marketing bestätigt, rufst du den Status erneut auf, diesmal mit true, und sendest die Ereignisse, die inzwischen angefallen sind.

// Aufruf aus dem Callback deines Consent-Banners.
function onMarketingConsent() {
  oaiq("consent", true);
  oaiq("measure", "page_viewed");
}

Was OpenAI dafür nicht mitliefert

Es gibt keine Integration in den Google Consent Mode, keinen Eintrag im TCF-Register der Anbieter und keine dokumentierte Anbindung an die verbreiteten Einwilligungs-Banner. Die Verdrahtung zwischen Banner und Pixel baust du selbst, und du testest sie selbst. Ein Fehler an dieser Stelle fällt im Betrieb nicht auf, weil das Pixel dabei misst statt zu schweigen.

Dazu kommt eine Voreinstellung, die seit dem 17.08.2026 für alle Web-Pixel von OpenAI gilt: Automatic Advanced Matching ist ab Werk aktiv. Das Pixel liest Kundendaten aus Formularen deiner Seite und hasht sie im Browser mit SHA-256. Niemand muss das einschalten, es läuft mit. Wer den Einwilligungs-Status nicht vorher auf false setzt, übermittelt damit Identifier von Besuchern, die noch gar nichts bestätigt haben.

Rechtlicher Rahmen: DSGVO-konformes Tracking. Die Banner-Kopplung im Google-Kosmos: Consent Mode v2 implementieren.

Das OAIQ-Pixel einbauen

Das SDK liegt unter https://bzrcdn.openai.com/sdk/oaiq.min.js. Nach dem Laden initialisierst du es mit deiner Pixel-ID und sendest Ereignisse über den measure-Aufruf. Die Signatur lautet oaiq("measure", eventName, eventData, options).

oaiq("measure", "order_created", {
  value: 25.99,
  currency: "EUR",
  order_id: "DE-100482"
}, {
  event_id: "DE-100482"
});

Der options-Block kennt genau drei Felder: event_id für die Deduplizierung, custom_event_name für eigene Ereignisnamen und opt_out. Andere Schlüssel wertet das Pixel nicht aus.

Es gibt keinen automatischen Seitenaufruf

Anders als die meisten Pixel meldet OAIQ nach dem init nichts von allein. Auch page_viewed musst du explizit senden. Wer das übersieht, sieht im Konto nur die Käufe und wundert sich über fehlende Zwischenschritte in der Auswertung.

Mehrere Pixel auf einer Seite

Betreibst du mehrere Konten, lädst du das SDK trotzdem nur einmal und rufst init je Pixel-ID auf. Ein measure-Aufruf geht danach an alle initialisierten Pixel. Willst du ein einzelnes ansprechen, nutzt du measureSingle.

Content-Security-Policy

Hat deine Seite eine Content-Security-Policy, also eine Freigabeliste für externe Skripte und Verbindungen, brauchst du drei Einträge. Ohne sie lädt das SDK nicht oder die Events kommen nicht an, und beides fällt oft erst im Livebetrieb auf.

script-src  https://bzrcdn.openai.com
connect-src https://bzr.openai.com
img-src     https://bzr.openai.com

Die Klick-ID oppref erfassen

Klickt jemand auf deine Anzeige, hängt OpenAI den Parameter oppref an die Ziel-URL. Das Pixel liest ihn beim Laden aus der Adresse und legt den Wert im First-Party-Cookie __oppref ab, also in einem Cookie deiner eigenen Domain. Für die Messung innerhalb von OpenAI reicht das.

Für deine eigene Auswertung reicht es nicht. Damit du später sagen kannst, welche Bestellung aus einem bezahlten ChatGPT-Klick kam, muss der Wert bei der Bestellung landen, also in deinem Shop gespeichert und an dein Tracking übergeben werden. Zwei Punkte sind dabei wichtig.

Erstens liest die Conversions API die Klick-ID nicht von selbst. Auf dem Serverweg gibst du sie ausdrücklich mit, sonst kommt die Conversion ohne Kanalbezug an. Zweitens gibt es mit __obref eine zweite, undurchsichtige Browser-Referenz. In Setups, die Pixel und Server kombinieren, sendest du deren Wert als obref im Nutzer-Block des Events mit.

UTM-Parameter bleiben erhalten

Statische Parameter, die du selbst in die Ziel-URL deiner Anzeige schreibst, überleben den Klick. Du kannst also zusätzlich zu oppref deine gewohnte UTM-Kennzeichnung setzen und den Kanal auch dann erkennen, wenn ein Besucher zwischendurch die Domain wechselt.

oppref ist nicht oppcref

Neben oppref taucht in Landing-URLs aus ChatGPT ein zweiter Parameter auf: oppcref, eine lowercase-UUID, die OpenAI für checkout_started, items_added, order_created und page_viewed vorsieht. In gemessenen Fällen trug dieselbe URL zusätzlich utm_medium=feed, also die Kennzeichnung des Produktfeed-Wegs. oppcref markiert damit den organischen Weg über die Produktsuche, nicht den bezahlten. Wer beide Parameter in denselben Paid-Kanal einsortiert, schreibt organischen Umsatz der Werbung zu.

Ein praktischer Hinweis aus der Auswertung: Suche den Parameter nie als Teilzeichenkette. Eine Suche nach dem Text oppref trifft auch jedes oppcref, weil die Zeichenfolge darin enthalten ist. Prüfe stattdessen auf den Parameter selbst, also auf den Namen zwischen Fragezeichen oder Und-Zeichen und dem Gleichheitszeichen.

Warum ChatGPT-Traffic ohne Zutun als Direct verbucht wird: Traffic aus KI-Assistenten tracken.

Die Conversions API anbinden

Der Serverweg geht als POST an https://bzr.openai.com/v1/events, die Pixel-ID hängt als Query-Parameter pid daran, authentifiziert wird über ein Bearer-Token. Neben pid kennt der Endpunkt validate_only für Testläufe und integration_source für die Kennzeichnung des sendenden Systems.

POST https://bzr.openai.com/v1/events?pid=DEINE-PIXEL-ID
Authorization: Bearer DEIN-CAPI-KEY
Content-Type: application/json

{
  "events": [
    {
      "id": "DE-100482",
      "type": "order_created",
      "timestamp_ms": 1756742400000,
      "action_source": "web",
      "source_url": "https://dein-shop.de/danke",
      "data": {
        "value": 2599,
        "currency": "EUR"
      },
      "user": {
        "emails_sha256": ["e3b0c44298fc1c149afbf4c8996fb924..."],
        "click_id": "der-oppref-wert-des-klicks"
      }
    }
  ]
}

Pflicht je Event sind id, type, timestamp_ms, action_source und data. Steht action_source auf web, kommt source_url dazu. Beträge gehören in die kleinste Währungseinheit: 2599 steht für 25,99 Euro, die Währung nach ISO 4217, EUR ist ausdrücklich genannt.

Ein kaputtes Event kippt den ganzen Batch

Ein Aufruf darf bis zu 1.000 Events tragen. Dabei gilt eine Regel, die von den gewohnten Netzwerken abweicht: Schlägt ein einziges Event fehl, scheitert der komplette Batch. 999 fehlerfreie Käufe gehen mit einem falschen Zeitstempel unter. Wer batcht, prüft die Events vorher selbst oder hält die Batches klein.

Das Sieben-Tage-Fenster

timestamp_ms darf höchstens sieben Tage zurückliegen und höchstens zehn Minuten in der Zukunft. Für den Normalbetrieb ist das unkritisch, für Nachzügler-Läufe nicht: Eine Warteschlange, die ältere Bestellungen aufarbeitet, produziert damit sichere Fehlschläge. Prüfe das Alter vor dem Absenden und verwirf zu alte Events, statt sie in die Warteschlange zu schieben.

Welche Ereignisse OpenAI kennt

Pixel und API deduplizieren

Laufen beide Wege parallel, meldet derselbe Kauf zweimal. Damit OpenAI die beiden Meldungen als ein Ereignis erkennt, brauchen sie denselben Schlüssel: im Pixel die event_id aus dem options-Block, in der Conversions API das Feld id des Events. Dazu muss beides auf dieselbe Pixel-ID laufen. Das Muster ist dasselbe wie bei Meta.

Als Wert eignet sich die Bestellnummer, weil sie pro Kauf eindeutig ist und in Shop und Backend vorliegt. Der häufigste Fehler ist nicht ein falsches Feld, sondern ein zweimal erzeugter Wert: Wenn Browser und Server jeweils eine eigene Zufalls-ID bilden, sieht jedes Event für sich korrekt aus, und trotzdem steht am Ende jeder Kauf doppelt im Konto. Erzeuge den Schlüssel einmal und reiche ihn durch.

Ausführlich zum Prinzip: Event-Deduplizierung zwischen Pixel und CAPI.

Nutzerdaten richtig hashen

Damit OpenAI eine Conversion einem Klick zuordnen kann, schickst du Identifier mit, also E-Mail-Adresse, Name oder eine eigene Kundennummer. Diese Werte gehen nicht im Klartext raus, sondern als SHA-256-Hash, eine Einwegverschlüsselung. Aus dem Ergebnis lässt sich der Ausgangswert nicht zurückrechnen, und genau deshalb muss die Vorbereitung des Werts auf beiden Seiten zeichengleich sein.

Alle Hashes sind 64 Zeichen hexadezimal in Kleinbuchstaben. Je Liste wertet OpenAI die ersten drei gültigen Werte aus. IP-Adresse, User-Agent, Land und Postleitzahl gehen ungehasht mit.

Zwei Regeln weichen von der gewohnten Praxis ab

Die External ID behält ihre Groß- und Kleinschreibung, während fast jedes andere Feld vorher kleingeschrieben wird. Wer hier die Routine der E-Mail-Adresse wiederverwendet, erzeugt einen formal gültigen Hash, der nie trifft.

Bei der Telefonnummer ist es gravierender. OpenAI will reine Ziffern zwischen 8 und 15 Stellen, ohne führendes Plus und ohne 00-Präfix. Google und Microsoft verlangen die E.164-Schreibweise mit Plus. Wer schon Hashes für diese Netzwerke gebildet hat, kann sie für OpenAI nicht wiederverwenden, denn aus einem Hash lässt sich die Nummer nicht zurückholen. Du brauchst eine zweite Normalisierung aus der Rohnummer.

Das gilt über OpenAI hinaus: Ein vorhandener Hash ist nur wiederverwendbar, wenn die Normalisierung des Empfängers zeichengleich ist. Andernfalls reist ein formal korrekter Wert mit, der nie zu einem Treffer führt, und weder das Protokoll noch die Antwort der Schnittstelle weist darauf hin.

Vor dem Start prüfen

Bevor Budget läuft, kontrollierst du zwei Dinge: dass Events überhaupt ankommen, und dass Pixel und Server denselben Schlüssel benutzen. Dafür gibt es den Debug-Endpunkt GET /conversions/events. Er gibt je Pixel-ID bis zu 50 Events der letzten 15 Minuten zurück. Was älter ist, siehst du dort nicht mehr, teste also unmittelbar nach dem Auslösen.

Für den Serverweg gibt es zusätzlich einen Trockenlauf. Mit dem Query-Parameter validate_only=true prüft OpenAI die Struktur des Events, bucht es aber nicht. Das ist der richtige Weg, um Pflichtfelder und Zeitstempel zu testen, ohne die Zahlen des Kontos zu verfälschen.

Die Variante ohne JavaScript

Wenn auf einer Seite kein SDK laufen kann, etwa in einer E-Mail-Bestätigung, gibt es den Image-Tag: ein GET auf https://bzr.openai.com/v1/sdk/events mit den Parametern pid und event, dazu optional event_id, oppref und Datenfelder. Die Einschränkung nennt OpenAI selbst: Der Image-Tag erfasst oppref nicht automatisch. Du musst die Klick-ID aus der URL oder aus deinem Cookie holen und ausdrücklich mitgeben.

https://bzr.openai.com/v1/sdk/events
  ?pid=DEINE-PIXEL-ID
  &event=order_created
  &event_id=DE-100482
  &oppref=der-oppref-wert-des-klicks

Was hier bewusst offen bleibt

Zu diesem Kanal kursieren Angaben, die gut klingen und nirgends belegt sind. Wer sie einbaut, merkt den Irrtum erst, wenn Zahlen fehlen. Deshalb stehen sie hier nicht im Text, sondern in dieser Liste, mit der Angabe, woher sie stammen.

Zum Aufbau des oppref-Werts dokumentiert OpenAI kein Format. Verbreitete Angaben zu einem festen Präfix stammen aus Blogs. Prüfe auf die Anwesenheit des Parameters, nicht auf ein vermutetes Muster. Auch zur Lebensdauer des Cookies __oppref gibt es keine Angabe der Doku, die kursierenden 30 Tage sind ebenfalls Blog-Wissen. Und die URL-Makros für Kampagnen- und Anzeigen-IDs, die in Agenturbeiträgen auftauchen, stehen nicht in der Entwicklerdokumentation.

Beim Attributionsfenster widersprechen sich die Quellen offen: Mal heißt es, nur 30 Tage seien erlaubt, mal sei der Wert konfigurierbar. Rate hier nicht, sondern lies den Wert je Konto über GET /conversions/event_settings aus. Aus derselben Antwort kommt die Angabe, mit der du später deine Zahlen gegen die von OpenAI stellst.

Zwei Punkte gehören außerdem in jede Planung, auch wenn sie kein Code sind. OpenAI tritt beim Conversion-Tracking laut den eigenen Ad Tools Terms als eigenständig Verantwortlicher auf, nicht als Auftragsverarbeiter. Das weicht von dem ab, was viele von einem Pixel erwarten, und es ändert die Datenschutz-Unterlagen, die du dafür brauchst. Und zur Frage, wo die Conversion-Daten europäischer Kunden liegen, gibt es derzeit keine Aussage von OpenAI. Wer diese Zusage braucht, klärt sie, bevor das erste Event rausgeht.

Zurück zum Überblick: ChatGPT Ads, der Leitfaden zum DACH-Start.