ChatGPT Ads Tracking mit Pixel & Conversions API in Shopware

Seit Ende August 2026 können Unternehmen in Deutschland ChatGPT Ads laut OpenAI selbst im Ads Manager buchen. Die Anzeigen erscheinen nur bei Nutzern der Tarife Free und Go, die Abos Plus, Pro und Enterprise bleiben werbefrei. Für die Messung nennt OpenAI das OpenAI Pixel, die Conversions API und Integrationen von Drittanbietern. Für Shopware Händler zählt dabei, welche Bestellung aus einer Anzeige in ChatGPT kam und ob der Ads Manager sie genau einmal erfasst hat.

Grundlage dieses Beitrags sind die Dokumentation von OpenAI für Entwickler und das Help Center mit Stand Oktober 2026. Übertragen auf Shopware 6.7 zeigt er, welche Events, Schlüssel und Einwilligungen ein Shop für verlässliche Zahlen braucht.

ChatGPT Ads Tracking verbindet Anzeigenklick & Bestellung

ChatGPT Ads Tracking ist die Messung von Käufen, Leads und Registrierungen nach einem Klick auf eine Anzeige in ChatGPT. Der Shop sendet dazu Ereignisse aus dem Browser über das OpenAI Pixel und vom Server über die Conversions API. OpenAI ordnet diese Ereignisse den Kampagnen zu und weist sie im Ads Manager als Conversions aus.

Laut der Anleitung zum Conversion Tracking besteht die Messung aus drei Bausteinen. Eine Datenquelle mit eigener Pixel ID empfängt die Events von Website oder Server. Eine Conversion Einstellung legt fest, welches Event als Conversion zählt, etwa ein abgeschlossener Kauf. Die Kampagne nutzt diese Einstellung für das Reporting und bei Bedarf für die Optimierung. Auch eine reine Serverintegration braucht eine Pixel ID, das Skript im Browser entfällt dann.

Wie Kampagnen, Gebote und Budgets entstehen, erklären wir im Beitrag ChatGPT Werbung schalten. Die Oberfläche für Datenquellen und Conversion Einstellungen beschreibt unser Beitrag zum ChatGPT Ads Manager. Das Help Center von OpenAI nennt vier Bedingungen, unter denen eine Conversion im Bericht erscheint.

• OpenAI erhält ein Event aus einer Datenquelle, die mit dem Werbekonto verbunden ist.
• Das Event passt zu einem Conversion Event, das für die Kampagne eingerichtet ist.
• Das Event liegt innerhalb des geltenden Attributionsfensters.
• OpenAI kann das Event über verfügbare Signale einem passenden Anzeigenklick zuordnen.

Das wichtigste Signal ist der Klickparameter oppref, den OpenAI an die URL der Landingpage anhängt. Das Pixel liest ihn aus und speichert ihn für 30 Tage im Cookie __oppref. Dazu legt es im Cookie __obref eine zufällige Browserkennung an, die 365 Tage gilt. Weitere Signale sind gehashte Kontaktdaten und, wo verfügbar, eine modellierte Messung aus beobachteten Conversions.

Die Anleitung arbeitet im Beispiel mit einem Attributionsfenster von 30 Tagen nach dem Klick. Laut Pixel Dokumentation hängt dieses Fenster nicht an der Laufzeit der Cookies, Browser und gelöschte Cookies können die Speicherdauer zudem verkürzen.

Pixel & Conversions API teilen sich die Messung

OpenAI empfiehlt in der Dokumentation der Conversions API, beide Wege für dieselbe Website zu kombinieren. Das Pixel erfasst das Verhalten im Browser, die Conversions API meldet bestätigte Käufe aus dem Backend. Fällt die Zustellung im Browser aus, kommt die Bestellung über den Server trotzdem bei OpenAI an.

Das OpenAI Pixel misst im Browser

Das Pixel ist ein JavaScript SDK, das von bzrcdn.openai.com geladen wird und weit oben im Head steht, damit frühe Conversions nicht verloren gehen. Der Aufruf oaiq("init", { pixelId }) startet es, oaiq("measure", ...) sendet danach ein Event mit Name, Daten und Optionen. Im Browser genügt dafür die Pixel ID. Das SDK hängt automatisch die source_url an, setzt Zeitstempel und bündelt kurz aufeinanderfolgende Events.

Mit der Option debug: true protokolliert das SDK jeden Schritt in der Browserkonsole. OpenAI rät, diese Option während der Tests eingeschaltet zu lassen. Erzwingt der Shop eine Content Security Policy, müssen bzrcdn.openai.com und bzr.openai.com in die passenden Direktiven.

Die Conversions API meldet bestätigte Käufe vom Server

Die Conversions API nimmt Events per POST unter bzr.openai.com/v1/events entgegen, die Pixel ID steht im Parameter pid. Authentifiziert wird mit einem eigenen Conversions API Schlüssel als Bearer Token, die Aufrufe sieht OpenAI nur vom Server vor. Für Verwaltung und Kampagnen gibt es davon getrennt einen Advertiser API Schlüssel.

Ein Aufruf transportiert bis zu 1.000 Events, schlägt eines fehl, scheitert der ganze Stapel. Der Zeitstempel darf höchstens sieben Tage alt sein und höchstens zehn Minuten in der Zukunft liegen. Mit validate_only prüft die API Events, ohne sie zu speichern. Über integration_source kennzeichnet ein Plugin jede Sendung mit einer festen Kennung.

Den Klickparameter oppref erfasst die Conversions API im Unterschied zum Pixel nicht selbst. Der Shop muss den Wert aus dem Cookie lesen und dem Serverevent unverändert mitgeben. Dasselbe gilt für die Browserkennung aus __obref, die ungehasht in das Feld user.obref gehört.

Dieselbe Event ID verhindert doppelt gezählte Käufe

Meldet ein Shop denselben Kauf über Pixel und Conversions API, sieht OpenAI zunächst zwei Events. Zur Deduplizierung bildet OpenAI einen Schlüssel aus Pixel ID, Event Name und Event ID. Das zuerst empfangene Event zählt, spätere Duplikate mit gleichem Schlüssel verwirft OpenAI. Im Pixel heißt das Feld event_id, in der Conversions API heißt es id.

Die Event ID muss der Shop selbst erzeugen und an beide Wege weitergeben. Für Käufe nennt OpenAI die tatsächliche Bestellnummer. In Shopware steht sie auf der Abschlussseite für das Pixel und im Bestellobjekt für den Server bereit. Wiederholt der Server eine Sendung nach einem Fehler, bleibt die ID laut Dokumentation gleich.

Für Events ohne Bestellung wie items_added braucht der Shop eine andere Quelle für die ID. Eine zufällige ID pro Ereignis reicht, solange nur das Pixel dieses Event sendet. Schickt auch der Server das Event, muss die ID vor dem Absenden feststehen und in beide Kanäle gelangen. Bei eigenen Events gehört zusätzlich der gleiche custom_event_name auf beide Seiten.

Fünf Standard Events bilden den Shopware Checkout ab

Die Liste der unterstützten Events umfasst zehn Standard Events, dazu custom und zwei App Events. Die App Events laufen nur über die Conversions API und betreffen nur Shops mit eigener App. Für einen Shop decken fünf Standard Events den Weg vom Seitenaufruf bis zur Bestellung ab, zwei weitere messen Konten und Formulare.

Beträge stehen als ganze Zahl in der kleinsten Währungseinheit, 26,85 Euro werden also zu 2685. Sobald ein Betrag gesendet wird, ist auch der Währungscode nach ISO 4217 Pflicht. Im Feld contents[].amount steht der Preis einer Einheit, die Menge kommt separat in quantity. Der Betrag auf Eventebene beschreibt den Wert des ganzen Events, bei order_created also die Bestellung.

Die Felder group_id und variant_dict nimmt nur die Conversions API an. Damit lassen sich Varianten wie Größe oder Farbe ihrem Hauptprodukt zuordnen. Ob der Bestellwert Versand enthält und brutto oder netto zählt, legt der Shop selbst fest. Sinnvoll ist dieselbe Definition wie bei Meta oder Google Ads, damit die Kanäle vergleichbar bleiben.

Für Kampagnen mit Conversion Optimierung kommen laut OpenAI nur Standard Events in Frage. Eigene Events eignen sich für Messung und Reporting, als Optimierungsziel scheiden sie aus.

Consent Gate & SHA-256 Hashing schützen die Kundendaten

Die Einwilligung kommt vor dem ersten Event

Das Pixel speichert Cookies im Browser und liest sie bei späteren Besuchen wieder aus. Nach § 25 TDDDG ist das nur mit Einwilligung zulässig, sofern es für den Dienst nicht unbedingt erforderlich ist. Auch OpenAI verlangt im Help Center, Conversion Daten erst nach klarer Information und den nötigen Einwilligungen zu teilen.

Technisch startet das Pixel ohne weitere Angabe so, als hätte der Besucher bereits eingewilligt. Laut Pixel Dokumentation gilt der Standard true, solange kein false gesetzt oder gespeichert ist. Ein Shop in Deutschland ruft deshalb oaiq("consent", false) vor dem Start auf und erst nach Zustimmung oaiq("consent", true). Events aus der Zeit davor holt das Pixel nicht nach, ein Widerruf löscht beide Cookies.

Das Consent Gate gilt im Shop ebenso für Events, die der Server an die Conversions API sendet. OpenAI schreibt, dass obref nur nach den Einwilligungsregeln der Website erfasst und nach einem Widerruf nicht mehr gesendet werden soll. Gehashte E-Mail Adressen bleiben nach Erwägungsgrund 26 der DSGVO pseudonyme und damit personenbezogene Daten. Ohne Marketing Einwilligung sollte deshalb auch kein Serverevent mit Kundendaten an OpenAI gehen.

Hashing folgt festen Regeln zur Normalisierung

Kontaktdaten gehen nur als SHA-256 Hash an OpenAI, in Kleinbuchstaben und hexadezimal mit 64 Zeichen. Vor dem Hashen schreibt OpenAI eine feste Normalisierung vor, damit gleiche Daten denselben Hash ergeben.

• E-Mail: Leerzeichen am Anfang und Ende entfernen, alles kleinschreiben.
• Telefon: Ländervorwahl behalten, Leerzeichen, Klammern, Punkte, Bindestriche sowie führendes Plus und führende Nullen entfernen, übrig bleiben 8 bis 15 Ziffern.
• Vorname und Nachname: kleinschreiben, Leerzeichen und ASCII Satzzeichen entfernen, Umlaute und Akzente bleiben erhalten.
• Externe Kundennummer: nur Leerzeichen am Rand entfernen, Groß und Kleinschreibung bleibt.

Ort, Postleitzahl, Region und Land übermittelt der Shop laut Dokumentation als Klartext ohne Hash. Jede Liste im Feld user darf höchstens drei Werte enthalten, sonst antwortet die API mit HTTP 400. Ist Automatic Advanced Matching aktiviert, erkennt das Pixel Kundendaten auf der Website selbst und hasht sie im Browser. Dafür ist laut OpenAI keine Änderung an der Integration nötig, die Datenschutzerklärung muss diese Übermittlung trotzdem abdecken.

Typische Fehler entstehen bei IDs, Beträgen & Einwilligung

Aus der Dokumentation von OpenAI lassen sich wiederkehrende Fehlerquellen ableiten, die jede Integration vor dem Livegang prüfen sollte.

• Pixel und Server erzeugen getrennte Event IDs, der Kauf erscheint dann zweimal.
• Beträge kommen als Dezimalzahl oder Text an, erwartet werden ganze Zahlen in der kleinsten Einheit.
• Ein Betrag ohne Währungscode verstößt gegen die Pflichtfelder des Events.
• Weiterleitungen auf der Landingpage verlieren den Parameter oppref, das Pixel kann ihn dann nicht speichern.
• Ein Event mit fehlerhaftem Feld lässt den ganzen Stapel der Conversions API scheitern.
• Serverevents bleiben länger als sieben Tage in der Warteschlange und fallen aus dem erlaubten Zeitfenster.
• validate_only bleibt nach dem Test aktiv, die API prüft dann nur und speichert nichts.
• Das Pixel startet vor dem Cookie Banner, weil consent nicht vor init auf false steht.
• Der Conversions API Schlüssel landet im Seitencode, obwohl OpenAI Aufrufe nur vom Server vorsieht.

Zum Testen liefert ein Endpunkt der Advertiser API laut Fehlerbehebung eine Stichprobe der Events aus etwa 15 Minuten. Browserevents tragen dort den Kanal pixel_sdk, Serverevents den Kanal server_to_server. Anfragen mit validate_only tauchen laut Anleitung in diesem Monitoring nicht auf.

Abweichungen zu Google Analytics oder anderen Werbeplattformen deuten laut OpenAI nicht zwingend auf einen Fehler hin. Gründe sind unterschiedliche Attributionsfenster, Zeitzonen, Consent Bedingungen, Deduplizierung und modellierte Conversions. Für den Abgleich dient deshalb die Bestellnummer im Shop als feste Referenz.

Shopware braucht Queue, Cookie Gruppe & Events im Browser

In Shopware 6.7 verteilt sich die Integration auf Cookie Verwaltung, Storefront, Bestellprozess und Message Queue. Die Cookies des Pixels gehören in die Gruppe Marketing des Cookie Managers. Seit Shopware 6.7.3 registriert ein Plugin sie laut Shopware Dokumentation über einen Listener auf das CookieGroupCollectEvent. Das JavaScript des Plugins prüft die Zustimmung im Browser und startet das Pixel erst danach.

Produktseiten kann Shopware aus dem HTTP Cache ausliefern, dann erreicht die Anfrage die Anwendung gar nicht. Ein serverseitiger Consent Check im Template würde bei solchen Antworten nie ausgeführt. Event Daten wie Produktnummer und Preis gehören deshalb als Datenattribute ins HTML. Ob gesendet wird, entscheidet das Skript im Browser anhand der Einwilligung.

Für den Server ist das Bestellereignis von Shopware der passende Zeitpunkt. Ein HTTP Aufruf an OpenAI im laufenden Checkout würde die Bestellung bei Störungen verzögern. Der Listener legt deshalb nur eine Nachricht in die Message Queue, ein Worker sendet sie danach. Schlägt die Zustellung fehl, wiederholt Shopware sie laut Dokumentation automatisch dreimal.

Für den Betrieb empfiehlt Shopware einen Worker auf der Kommandozeile. Der Admin Worker arbeitet nur, solange jemand in der Administration angemeldet ist. Ohne laufenden Worker bleiben Serverevents liegen, nach sieben Tagen nimmt die Conversions API sie nicht mehr an.

Pixel ID, Schlüssel und Schalter gehören in die Plugin Konfiguration pro Verkaufskanal. Dazu zählen ein Validierungsmodus für Tests und die Frage, ob Versandkosten im Bestellwert stecken. Solche Plugins entwickeln wir als Shopware Agentur für Projekte im E-Commerce.

Sauberes Tracking ist die Basis für Conversion Kampagnen

Eine Kampagne mit Conversion Optimierung braucht beim Anlegen genau ein aktives Standard Event als Ziel. Dieses Ziel lässt sich laut OpenAI nach dem Anlegen nicht mehr ändern. Bevor Budget fließt, sollten deshalb Event IDs, Beträge, Consent und Serverzustellung geprüft sein. Wie wir Kampagnen in ChatGPT planen, messen und auswerten, zeigt unsere Leistung ChatGPT Ads. Für die organische Sichtbarkeit in KI Antworten ergänzt Generative Engine Optimization den bezahlten Kanal.