ChatGPT Ads Tracking: So funktionieren oaiq-Pixel und Conversions API

Die Datenquelle: Startpunkt im Ads Manager

Alles Tracking in ChatGPT Ads hängt an einer Datenquelle. Sie wird im Ads Manager Beta unter Tools und Conversions angelegt und liefert die Pixel-ID, an der später Pixel und Conversions API hängen. Der Dialog ist unspektakulär, ein Detail darin aber wichtig:

Der „automatische erweiterte Abgleich" ist OpenAIs Version dessen, was Meta als Advanced Matching kennt: Das Pixel erkennt unterstützte Kundeninformationen auf der Seite (E-Mail, Telefonnummer, Name, Ort, PLZ, externe ID), normalisiert sie und hasht sie per SHA-256 direkt im Browser. Laut Dokumentation verlassen die Rohdaten den Browser nie, übertragen wird nur der Hash. Das verbessert die Zuordnung von Conversions zu Anzeigen, ist aber gleichzeitig genau die Sorte Datenverarbeitung, die in die Datenschutzerklärung und hinter die Einwilligung gehört, dazu unten mehr.

Zwölf Basisereignisse und Custom Events

Benutzerdefinierte Conversions bauen im Ads Manager auf einem Basisereignis auf. Die Liste ist bewusst kurz gehalten und deckt Shop, Lead-Gen und App ab:

Technisch heißen die zwölf Ereignisse page_viewed, contents_viewed, items_added, checkout_started, order_created, lead_created, registration_completed, appointment_scheduled, subscription_created, trial_started sowie app_installed und app_opened. Zwei Besonderheiten: Die beiden App-Events unterstützt das Browser-Pixel nicht, sie laufen ausschließlich über die Conversions API. Und wer etwas misst, das in keine Schublade passt, sendet ein Custom Event mit eigenem custom_event_name (1 bis 64 Zeichen); Werte wie Betrag, Währung oder Warenkorbinhalt können mitgegeben werden.

Das oaiq-Pixel im Browser

Das Pixel ist ein JavaScript-SDK, das von bzrcdn.openai.com geladen und mit der Pixel-ID initialisiert wird:

<script async src="https://bzrcdn.openai.com/sdk/oaiq.min.js"></script>
<script>
  window.oaiq = window.oaiq || function(){(oaiq.q = oaiq.q || []).push(arguments)};
  oaiq("consent", false);            // vor init: erst nach Einwilligung auf true
  oaiq("init", { pixelId: "PIXEL-ID" });
  // nach Einwilligung: oaiq("consent", true);
  // Conversion melden, z. B.:
  oaiq("measure", "order_created", { id: "bestell-123", amount: 49.9, currency: "EUR" });
</script>

Beim Klick auf eine Anzeige in ChatGPT landet der Nutzer mit einer Kennung auf der Zielseite; das Pixel legt daraus das First-Party-Cookie __oppref an und ordnet damit spätere Ereignisse dem Klick zu. Das funktioniert nur, wenn das Pixel auf der Landingpage wirklich lädt, und es ist der Grund, warum die Attributionskette an derselben Stelle reißt wie das Crawling: Wer OAI-AdsBot per Cloudflare oder robots.txt aussperrt, bekommt schon keine Anzeige geschaltet; wer das Pixel per Consent-Fehler nie lädt, bekommt Klicks ohne Conversions.

Die Conversions API: das belastbare Standbein

Die zweite Schiene sendet dieselben Ereignisse vom eigenen Server an bzr.openai.com/v1/events, authentifiziert per API-Key aus dem Ads Manager. Sie ist gegen Adblocker, ITP und abgebrochene Seitenladungen immun und damit die verlässlichere Quelle, analog zu den Conversion APIs von Meta, Google und TikTok. Die Regeln aus der Dokumentation, die man kennen muss:

• Pflichtfelder: Event-ID, Typ, Zeitstempel in Millisekunden (maximal 7 Tage rückwirkend), action_source und bei Web-Events die source_url.
• Attribution selbst mitbringen: Anders als das Pixel liest die API die Klick-Kennung nicht automatisch. Das __oppref-Cookie muss im Browser ausgelesen, an den eigenen Server übergeben und mit dem Server-Event gesendet werden. Ohne diesen Wert ist das Server-Event da, aber keiner Anzeige zuzuordnen.
• Deduplizierung: OpenAI dedupliziert über Pixel-ID, Event-Name und Event-ID; das zuerst eingegangene Ereignis gewinnt. Pixel und API müssen also dieselbe Event-ID senden, dann zählt nichts doppelt.
• Batches: bis zu 1.000 Events pro Request, aber alles-oder-nichts: Ein fehlerhaftes Event lässt den ganzen Batch scheitern. Für Tests gibt es validate_only.
• Kundendaten (E-Mail, Telefon, Name) gehen auch hier nur SHA-256-gehasht raus.

Consent und DSGVO: der Fallstrick

Jetzt der Punkt, der in den meisten Setup-Anleitungen untergeht: Der Consent-Status des Pixels steht laut OpenAI-Dokumentation per Default auf true. Wer den Pixel-Code einfach in die Seite oder den Tag Manager kopiert, trackt ab der ersten Sekunde, auch ohne dass irgendjemand eingewilligt hat. In den USA ist das egal, in der EU nicht. Die saubere Reihenfolge: oaiq("consent", false) vor dem Init, Kopplung an das Consent-Banner, und erst nach der Einwilligung oaiq("consent", true). Wichtig fürs Erwartungsmanagement: Ereignisse, die während der Verweigerung anfallen, werden nicht nachgereicht. Ein Teil der Conversions bleibt also konsentbedingt unsichtbar, wie bei jedem anderen Pixel auch; die Conversions API mit serverseitiger Einwilligungsprüfung mildert das ab.

Dazu gehört der formale Teil: Pixel und erweiterter Abgleich sind einwilligungspflichtige Datenverarbeitungen, also ins Consent-Banner als eigener Anbieter und in die Datenschutzerklärung aufnehmen. Wie wir Consent-Setups generell bauen, steht auf unserer Seite zum Consent Mode.

Unser Setup in der Praxis

1. Datenquelle anlegen im Ads Manager (Tools, Conversions), Pixel-ID notieren, erweiterten Abgleich bewusst aktivieren oder lassen.
2. Pixel über den Tag Manager ausrollen, mit Consent-Status fest an das Banner gekoppelt (siehe oben) statt hart im Template.
3. Events definieren: für Shops order_created mit Betrag und Währung als Hauptziel, checkout_started und items_added als Diagnose-Events; für Lead-Gen lead_created oder appointment_scheduled.
4. Conversions API parallel aufsetzen: __oppref-Cookie an den Server durchreichen, gleiche Event-IDs wie im Pixel senden, mit validate_only testen.
5. UTM-Disziplin: Statische URL-Parameter bleiben beim Anzeigenklick erhalten. Eine eigene Konvention (etwa utm_source=openai) macht den Kanal in GA4 und im Shop-Backend sichtbar, unabhängig von OpenAIs eigenem Reporting. Die Regeln dafür wie im UTM-Generator.
6. Testkauf vor Kampagnenstart und Abgleich, ob das Ereignis im Ads Manager ankommt und nur einmal zählt.

Wenn ihr das nicht selbst bauen wollt: Genau dieses Setup richten wir gerade für unsere ersten Kunden ein, und wir vermessen seit 2006 Kampagnen über alle Plattformen. Details auf der Seite ChatGPT Ads Agentur oder direkt über Kontakt.

Was die Messung noch nicht kann

Ehrlichkeit gehört dazu, der Ads Manager trägt sein Beta-Label zu Recht. Das Reporting zeigt Impressionen, Klicks, Kosten, CTR, CPC, CPM und Conversions; View-Through-Conversions werden mit festem Ein-Tages-Fenster separat ausgewiesen und zählen nicht in die Conversion-Spalte. Aus den US-Erfahrungen kommt das Reporting mit mehreren Stunden Verzögerung, und ein relevanter Teil der Käufe passiert ohnehin erst nach der Klick-Session. Drittanbieter-Attribution und MMP-Anbindungen stehen noch am Anfang. Praktisch heißt das: Ziele nicht an Vormittagszahlen nachsteuern, GA4 und Shop-Backend als Zweitmeinung danebenlegen und dem Kanal ein faires Messfenster geben, bevor über Skalierung entschieden wird.

FAQ

Brauche ich Pixel und Conversions API oder reicht eins?

Beides. Das Pixel liefert die Attribution über das __oppref-Cookie, die API die Zuverlässigkeit. Gleiche Event-IDs senden, dann dedupliziert OpenAI sauber.

Ist das oaiq-Pixel DSGVO-konform einsetzbar?

Nur mit Consent-Anbindung. Der Default steht auf true, also vor dem Init auf false setzen und erst nach Einwilligung freigeben. Blockierte Events werden nicht nachgereicht.

Welche Ereignisse gibt es?

Zwölf Basisereignisse von Seite angesehen bis Testphase gestartet, plus Custom Events. App-Events nur über die Conversions API.

Warum kommen Conversions erst Stunden später an?

Reporting-Verzögerung plus Nutzerverhalten: Viele Käufe passieren nach der Klick-Session. Nicht an Vormittagszahlen optimieren.