Der Browser verliert Konversionen, die der Server noch kennt
ChatGPT Ads misst auf zwei Wegen, und die Doku von OpenAI beschreibt beide als Teile derselben Anbindung.
Das Messpixel ist ein kleines Skript, das im Browser deiner Besucher läuft. Du lädst es von bzrcdn.openai.com/sdk/oaiq.min.js, gibst ihm über oaiq("init", ...) die Kennung deines Pixels aus dem Anzeigenmanager, und meldest eine Konversion mit oaiq("measure", ...). Alles, was dabei zu OpenAI geht, geht vom Gerät des Besuchers aus.
Die Conversions API ist ein Aufruf von deinem eigenen Server. Ein POST auf https://bzr.openai.com/v1/events?pid=<PIXEL-ID> mit einem Bearer-Schlüssel, den du im selben Reiter des Anzeigenmanagers anlegst wie das Pixel. Im Rumpf steht eine Liste von Ereignissen, bis zu tausend in einem Aufruf.
Welchen der beiden Wege OpenAI für den besseren hält, steht gleich im ersten Satz der Seite zur Conversions API:
The Conversions API is a more reliable tracking source than the pixel alone. Use the Conversions API when possible for more accurate insights.
Die Pixel-Seite zieht dazu eine Grenze in die andere Richtung: "Always use the pixel on the browser. Do not call the server conversions API directly from page code." Der Schlüssel für die Conversions API gehört auf den Server, weil er in Seitencode für jeden Besucher lesbar wäre.
Der Grund für beide liegt darin, woran der jeweilige Weg hängt. Das Pixel hängt am Gerät: ein Werbeblocker hält das Skript auf, und dann kommt aus dem Browser nichts an. Der Serveraufruf läuft davon unberührt. Umgekehrt weiß dein Server nur, was in deiner Datenbank steht, und einige Angaben entstehen ausschließlich im Browser. Die Browser-Kennung obref etwa legt das Pixel als Cookie ab, und OpenAI erwartet sie unverändert im Feld user.obref des Serverereignisses.
Dieselbe Ereignis-Id auf beiden Wegen, und OpenAI behält das erste Ereignis
Zwei Wege für denselben Vorgang bedeuten zwei Meldungen für dieselbe Anfrage. Ohne Gegenmaßnahme steht im Bericht die doppelte Zahl, und ein Gebotsverfahren, das darauf optimiert, rechnet mit einer Konversionsrate, die es nie gab.
Die Gegenmaßnahme ist eine Kennung, die du selbst vergibst und auf beiden Wegen gleich mitschickst. OpenAI beschreibt die Zusammenführung so:
Deduplication uses your Pixel ID, event_name, and id. OpenAI uses the first event it receives for a matching key and ignores later duplicates.
Drei Angaben bilden den Schlüssel: die Kennung deines Pixels, der Ereignisname und die Id. Bei einem eigenen Ereignis tritt der eigene Name an die Stelle des Standardnamens, und dann muss auch der auf beiden Seiten gleich lauten. Kommen zwei Meldungen mit demselben Schlüssel an, behält OpenAI die erste und verwirft die zweite.
Die Felder heißen auf beiden Seiten unterschiedlich, und genau daran geht ein Einbau still daneben. Im Browser steckt die Kennung im vierten Argument von oaiq("measure", ...) und heißt dort event_id. Auf dem Server heißt dasselbe Feld id und steht direkt am Ereignis. Dazu müssen beide Wege dieselbe Pixel-Kennung benutzen, sonst treffen sie sich im Schlüssel nie.
Bei uns ist diese Id die Zeilen-Id der gespeicherten Anfrage aus unserer eigenen Datenbank. Sie kommt vom Server, und dieselbe Anfrage, ein zweites Mal abgeschickt, landet in derselben Zeile und trägt damit dieselbe Id. Ein zweiter Klick auf den Absendeknopf erzeugt so keine zweite Konversion, und ein Werbeblocker, der das Pixel aufhält, kostet keine, weil der Serverweg dieselbe Id ohnehin schickt.
Zwei Grenzen hat der Serverweg dabei. Der Zeitstempel eines Ereignisses darf höchstens sieben Tage alt und höchstens zehn Minuten in der Zukunft sein, was das Nachreichen später bekannt gewordener Abschlüsse auf eine Woche begrenzt. Und ein Stapel scheitert als Ganzes: "If one event in the batch fails, the full batch fails."
OpenAI kennt zwölf benannte Ereignisse, für alles andere braucht es einen eigenen Namen
Am 03.09.2026 führt die Doku zwölf benannte Ereignisse und dazu den Platzhalter custom. Die zwölf sind app_installed, app_opened, appointment_scheduled, checkout_started, contents_viewed, items_added, lead_created, order_created, page_viewed, registration_completed, subscription_created und trial_started.
Jeder Name schreibt vor, welche Datenform er mitbringt, und es gibt vier davon. customer_action trägt eine Handlung ohne Warenkorb, etwa lead_created. contents trägt Artikel mit Menge und Betrag, etwa order_created. plan_enrollment gehört zu Abo und Testphase. custom gehört zu den eigenen Ereignissen. Die Doku verlangt, dass das Feld data.type zur Form des gewählten Ereignisnamens passt.
Zwei der zwölf kann das Pixel nicht. app_installed und app_opened gehen ausschließlich über den Server, mit action_source auf mobile_app.
Ein eigenes Ereignis besteht aus drei Teilen, die im Browser leicht durcheinandergeraten: "custom" steht als Ereignisname an zweiter Stelle des Aufrufs, type: "custom" wählt die Datenform, und der eigentliche Name steht in den Optionen unter custom_event_name. Dieser Name darf 1 bis 64 Zeichen lang sein, nur Buchstaben, Ziffern, Unterstrich und Bindestrich enthalten, muss mit einem Buchstaben oder einer Ziffer anfangen und aufhören, und darf keinen Standardnamen doppeln. Die Schnittstelle schreibt ihn klein.
In der Doku zu den konversionsoptimierten Kampagnen steht, was ein eigener Name ausschließt: "You have exactly one active standard conversion event to use as the optimization goal. Custom events cannot be oCPC optimization goals." Auf ein eigenes Ereignis lässt sich also nicht bieten, und als Optimierungsziel ist genau ein Standardereignis vorgesehen.
Daraus folgt eine Entscheidung, die vor dem ersten Ereignis fällt. Das Gebot optimiert auf genau diesen einen Namen, und alles, was darunter gemeldet wird, zählt gleich viel. Wer eine kleine Anfrage aus einem Werkzeug und eine echte Kaufanfrage unter denselben Namen stellt, bietet auf beide dasselbe.
Die Klick-Kennung oppref kommt als Parameter an und muss selbst zum Server getragen werden
Klickt jemand in ChatGPT auf deine Anzeige, hängt OpenAI an deine Zieladresse einen Parameter namens oppref. Das ist die Kennung dieses einen Klicks. Für dich ist sie undurchsichtig, und die Doku verlangt, sie unverändert weiterzureichen.
Im Browser nimmt das Pixel sie von selbst auf. OpenAI listet auf, was das SDK ohne dein Zutun erledigt: es liest oppref aus der Adresse der Landeseite, legt den Wert in einem eigenen Cookie __oppref ab, damit spätere Seitenaufrufe ihn wiederfinden, setzt den Ursprung der aktuellen Seite als source_url und versieht jedes Ereignis mit einem Zeitstempel.
Auf dem Server passiert nichts davon, und die Doku sagt das in einem Satz:
Unlike the pixel, the API does not capture oppref for you. Capture the value yourself and pass it with the server event when it is available to support click matching.
Der Serverweg braucht dazu einen eigenen Handgriff: die Kennung aus der Adresse der Landeseite lesen, sie über den Besuch hinweg mitführen und sie beim Absenden eines Formulars zusammen mit der Anfrage speichern. Sie gehört an eine eigene Stelle, getrennt von den Klick-Kennungen anderer Werbenetzwerke. Wer sie in dasselbe Feld legt, in dem die Google-Kennung steht, reicht sie mit dem nächsten Upload an Google weiter.
Zur gespeicherten Anfrage gehört höchstens eine Klick-Kennung. Ein Besuch kam über eine Anzeige, und eine Anfrage, die die Kennung von zwei Netzwerken trägt, würde von beiden für dieselbe Konversion beansprucht.
Nachgemessen haben wir das am 03.09.2026, indem wir die Seite mit ?oppref=... aufgerufen haben. Danach steht die Kennung im Cookie __oppref von OpenAI und in unserem eigenen Klick-Cookie, und beim Absenden geht sie mit der Anfrage mit.
Die zweite Kennung heißt obref und gehört an eine andere Stelle im Ereignis. Sie ist die Browser-Kennung aus dem Cookie __obref, das ebenfalls das Pixel setzt, sie wird ungehasht weitergereicht, und im Serverereignis steht sie innerhalb von user, während oppref direkt am Ereignis hängt. An das Weiterreichen knüpft OpenAI eine Bedingung: vor dem Einsammeln und Weitergeben des Cookies die Einwilligungsanforderungen der eigenen Seite befolgen, und bei einem Widerruf damit aufhören.
Das Pixel setzt seine Einwilligung selbst auf ja, wenn niemand widerspricht
In Deutschland regelt § 25 TDDDG, dass das Speichern von Informationen auf einem Endgerät und der Zugriff auf dort gespeicherte Informationen eine Einwilligung brauchen. Ein Cookie zu setzen fällt darunter, ein Cookie zu lesen ebenfalls.
Das Pixel bringt dazu eine Voreinstellung mit, und sie steht so in der Doku:
The Pixel initializes consent to true by default unless you set it to false or the Pixel finds a stored denial.
Der naheliegende Weg wäre also, das SDK zu laden und ihm sofort oaiq("consent", false) zu sagen, bis der Besucher entschieden hat. Am 02.09.2026 haben wir in oaiq.min.js in der Fassung 0.1.32 nachgesehen, was dieser Aufruf tut: er schreibt ein Cookie __oaiq_consent mit dem gespeicherten Einwilligungsstand, dreißig Tage Laufzeit. Die Doku nennt dieses Cookie nicht, sie führt nur __oppref und __obref. Ein Skript, das auf dem Gerät eines Besuchers etwas ablegt, der gerade Nein gesagt hat, ist eine Speicherung nach § 25 TDDDG.
Deshalb wird bei uns gar nichts geladen, bevor die Einwilligung vorliegt. Im Kopf des Dokuments steht nur ein Lader, der wartet, bis das Banner ihn ruft. Gemessen am 03.09.2026 im Browser: vor der Einwilligung gibt es kein window.oaiq und kein Cookie von OpenAI. Nach der Einwilligung lädt bzrcdn.openai.com/sdk/oaiq.min.js, das Pixel holt seine Konfiguration, und Ereignisse gehen an bzr.openai.com/v1/sdk/events. Drei Cookies entstehen dabei: __oppref, __obref und __oaiq_consent.
Eine Stelle darin ist heikler, als sie aussieht. Zwischen dem Ruf an den Lader und der Ankunft des Skripts liegt Netzzeit, und in diesem Fenster existiert nur eine Warteschlange. Widerruft jemand genau darin, läuft die Löschung der Cookies vor dem Skript. Das Skript arbeitet danach die Warteschlange ab, sieht die erteilte Einwilligung, schreibt seine Cookies, und die Löschung hat vorher nichts gefunden. Der Widerruf gehört deshalb zweimal ausgeführt: sofort, und noch einmal, sobald das Skript wirklich angekommen ist.
Was vor der Einwilligung geschieht, bleibt ungemessen. Die Doku hält fest: "Setting it to true allows future measurement events; blocked events aren't replayed." Eine Konversion, die vor dem Klick auf den Einwilligungsknopf stattfindet, reicht das Pixel später nicht nach.
Falls deine Seite eine Content Security Policy führt, also eine Liste erlaubter Quellen im Antwortkopf, braucht das Pixel darin vier Einträge: bzrcdn.openai.com unter script-src für das Skript und unter connect-src für seine Konfiguration, bzr.openai.com unter connect-src für die Ereignisse und unter img-src für den Rückfallweg über einen Bildaufruf. Die Doku bittet ausdrücklich darum, dafür nicht 'unsafe-inline' zu öffnen.
Die neuen Zuordnungsfelder schicken mehr personenbezogene Daten an OpenAI
Beide Wege nehmen ein Feld user entgegen, mit Angaben, die eine Konversion einem Klick zuordnen helfen, wenn die Klick-Kennung fehlt. Diese Liste ist gewachsen. Ein Änderungshinweis von OpenAI, gelesen am 03.09.2026, nennt für das Pixel zusätzlich die gehashte Telefonnummer, Vor- und Nachname, Region und Postleitzahl, und für die Conversions API dazu Listenfelder für gehashte Adresse, Telefonnummer, externe Kennung, Vor- und Nachname sowie Land, Stadt, Region und Postleitzahl und die Android-Werbekennung.
Die Doku beschreibt, wie die Werte auszusehen haben. Adresse, Telefonnummer, externe Kennung, Vor- und Nachname werden zuerst normalisiert, also kleingeschrieben, von Leerzeichen und Satzzeichen befreit und bei der Telefonnummer auf die reinen Ziffern mit Ländervorwahl gebracht, danach als SHA-256 in 64 Zeichen Hex geschickt. Die geografischen Angaben gehen im Klartext, also Land, Stadt, Region und Postleitzahl. Aus jeder Liste nimmt die Schnittstelle die ersten drei gültigen Werte und verwirft den Rest, ohne das Ereignis abzulehnen.
Das verbessert die Zuordnung und schickt zugleich mehr über deine Kunden an einen Dritten. Ein Hash macht daraus keine anonyme Angabe: dieselbe Adresse ergibt immer denselben Wert, und genau darauf beruht der Abgleich mit einem Konto, das OpenAI schon kennt.
Welche dieser Angaben hinausgehen, entscheidet der Einbau, und Pflicht ist keine davon: sie helfen bei der Zuordnung, wenn die Klick-Kennung fehlt. Was hinausgeht, gehört Feld für Feld in die Datenschutzerklärung, getrennt nach Ereignis, zusammen mit den Cookies des Pixels und ihrer Laufzeit.
Eine Funktion verdient dabei eigene Aufmerksamkeit, weil sie ohne Code auskommt. OpenAI nennt sie automatic advanced matching: das Pixel erkennt unterstützte Kundendaten auf deiner Seite selbst, normalisiert und hasht sie im Browser und hängt sie an die Konversionsereignisse. Die Doku schreibt dazu: "You do not need to manually pass customer information or make any changes to your Pixel implementation." Eingeschaltet schickt das Pixel damit Felder, die niemand in deinem Quelltext ausgewählt hat, und dein Datenschutztext muss sie trotzdem nennen.
Zwischen Auslieferung und Bericht liegen laut OpenAI bis zu sieben Stunden
Die Hilfeseite zu häufigen Problemen nennt für den Abstand zwischen der Auslieferung einer Anzeige und ihrem Erscheinen im Bericht bis zu sieben Stunden und bittet darum, nach dem Start einer Kampagne mindestens 24 Stunden zu warten, bevor man ein Auslieferungsproblem meldet. Eine leere Tabelle am Nachmittag des ersten Tages sagt also nichts über deinen Einbau.
Dieselbe Seite listet für den Fall, dass eine Kampagne läuft und keine Einblendungen bekommt, auf, was vorher zu prüfen ist: dass die Abrechnung eingerichtet ist, dass das Budget nicht erreicht ist, dass das Enddatum nicht überschritten ist, und dass das Konto die Prüfung bestanden hat.
Der letzte Punkt zerfällt in zwei getrennte Vorgänge. Die Prüfung des Werbetreibenden stand in unserem Konto am 02.09.2026 gegen 15:27 Uhr auf freigegeben, die Bestätigungsmail von OpenAI kam um 15:45 Uhr. Die Kontoprüfung ist eine zweite Prüfung, sie begann am 01.09.2026 um 07:41 Uhr UTC und war am 04.09.2026 um 05:03 Uhr UTC durch, nach 2 Tagen, 21 Stunden und 22 Minuten. Die Hilfeseite zur Kontoeinrichtung benennt diese Trennung ausdrücklich:
Verification and account review are separate steps. Completing an identity or business verification flow does not always mean the ad account is ready to run campaigns immediately.
Beschleunigen lässt sich das nach derselben Seite nicht: "We are unable to expedite account review or ad review requests at this time." Ein zweites Konto anzulegen umgeht die Prüfung ebenfalls nicht, und die Hilfeseite warnt, dass doppelte Anträge und doppelte Werbekonten Verwirrung darüber stiften, welches das richtige Konto des Werbetreibenden ist.
Der Idempotency-Key hat uns zwei Ereignisdefinitionen statt einer gebracht
Wer die Ereignisdefinitionen über die Schnittstelle anlegt, statt sie im Anzeigenmanager zu klicken, trifft auf drei Eigenheiten, die wir am 02.09.2026 im eigenen Konto erlebt haben.
Die erste ist der Idempotency-Key. Das ist ein Kopfzeilenfeld, mit dem eine Schnittstelle zusagen kann, denselben Aufruf nur einmal auszuführen. Hier hält er das nicht: derselbe Aufruf, zweimal geschickt, hat zwei Ereignisdefinitionen erzeugt. Einen Pfad zum Archivieren oder Löschen führt die Schnittstelle nicht, wir konnten die Dubletten also nicht selbst wegräumen und haben das betroffene Ereignis unter einem neuen Namen angelegt. Am 04.09.2026 standen die beiden alten Definitionen dann nicht mehr in der Liste: der Abruf zeigt vier Definitionen, keine doppelt. Was sie entfernt hat, wissen wir nicht.
Die zweite ist eine Verzögerung beim Lesen. Ein frisch angelegtes Objekt taucht nicht sofort in der Auflistung auf. Wir warten rund zwanzig Sekunden, bevor wir nachsehen, ob etwas angekommen ist.
Die dritte betrifft die Listenparameter. Sie werden als Feld übergeben, also mit eckigen Klammern hinter dem Namen. Ein wiederholter einfacher Parameter kommt mit 400 zurück, was beim ersten Mal wie ein Fehler in den Werten aussieht.
Was in diesem Fall gilt
Seit dem 03.09.2026 melden auf unserer eigenen Seite beide Wege dieselben vier Ereignisse an ChatGPT Ads, mit der Zeilen-Id unserer Datenbank als gemeinsamer Ereignis-Id. Das Pixel lädt erst nach der Einwilligung, im Browser nachgemessen: davor kein Skript und kein Cookie, danach das SDK, die Pixel-Konfiguration und die Ereignisse. Die Klick-Kennung aus ChatGPT liegt getrennt von den Klick-Kennungen der anderen Netzwerke, und eine gespeicherte Anfrage trägt höchstens eine davon. An OpenAI gehen die Browser-Kennung, die E-Mail-Adresse als Prüfsumme, IP-Adresse, User-Agent und das Land.
In der Nacht auf den 06.09.2026 ist der Einbau zum ersten Mal unter echter Auslieferung gelaufen: zwei Kampagnen, 11.789 Einblendungen, 90 Klicks. Die Auswertung des Werbekontos weist dafür null Konversionen aus, und das deckt sich mit dem, was tatsächlich geschah: es kam keine Anfrage an, und jede abgeschickte Anfrage löst eine Mail aus. Der Bericht dazu steht unter 150 Euro ChatGPT Ads Test. Wie viele doppelte Meldungen die Zusammenführung zusammenfaltet, zeigt sich erst an der ersten Konversion, die über beide Wege gemeldet wird.
