OpenAI Ads WooCommerce Conversion-Tracking

Wie WooCommerce-Kauftracking mit OpenAI Ads funktionieren soll, inklusive Bestell-IDs, Conversion-Werten, Browser- und Server-Events, Einwilligung und geplantem PixelBridge-Setup.

Zuletzt aktualisiert: 8. September 2026. Geschrieben von PixelBridge team.

WooCommerce-Kauftracking für OpenAI Ads sollte ein purchase-Event feuern, nachdem die Bestellung bestätigt ist, nicht wenn ein Kunde den Checkout öffnet oder ein Produkt in den Warenkorb legt. Das Event sollte eine Bestell-ID, einen Conversion-Wert und eine Währung tragen, wo das erlaubt ist, und eine gemeinsame Event-ID, wenn dieselbe Conversion auch über die Conversions API gesendet wird. Einwilligung zur Messung muss erteilt sein, bevor ein Browser- oder Server-Event die Website verlässt. PixelBridge ist dafür gebaut, das aus WordPress zu tun. Der Plugin-Hook ist noch nicht verfügbar.

Wofür diese Integration da ist

WooCommerce erfasst bereits Bestellungen, Totale, Kundendetails und Bestellstatus. OpenAI Ads-Messung braucht ein Conversion-Event, das diesen Kauf abbildet, damit Werbereports eine bezahlte oder bestätigte Bestellung mit Kampagnenaktivität verknüpfen können.

PixelBridge ist ein unabhängiges WordPress-Plugin für diese Messschicht. Es ist kein offizielles OpenAI- oder WooCommerce-Produkt und erstellt keine Kampagnen. Der WooCommerce-Connector ist eine der ersten geplanten Integrationen. Bis er erscheint, ist nichts auf dieser Seite ein funktionierendes Plugin-Feature.

Für die Shop-Konfiguration selbst starte bei der offiziellen WooCommerce-Dokumentation. Für den Werbemessungsvertrag nutze die Measurement Pixel-Doku von OpenAI und die Conversions API-Doku. Eventnamen und Pflichtfelder können sich ändern. Bestätige sie in der offiziellen OpenAI-Dokumentation, bevor du ein Payload als final behandelst.

Wie Kauftracking funktionieren soll

Ein nützliches Purchase-Event ist eine abgeschlossene kommerzielle Aktion. In WooCommerce heißt das meist: eine Bestellung existiert und hat einen Status erreicht, den dein Shop als echt behandelt, zum Beispiel Processing oder Completed, je nach Zahlungsmethode.

Die vorgesehene Sequenz:

  1. Der Kunde schließt den Checkout ab.
  2. WooCommerce legt eine Bestellung an und vergibt eine ID.
  3. Wenn Einwilligung zur Messung erteilt ist, kann ein Browser-purchase auf der Order-Received- oder Thank-you-Seite feuern.
  4. Wenn die Conversions API aktiv ist, kann WordPress ein passendes Server-Event senden, nachdem die Bestellung in PHP bestätigt ist.
  5. Beide Payloads teilen eine Event-ID, damit OpenAI Ads-Messung sie als eine Conversion behandelt.

Feuere purchase nicht bei:

  • Produktseiten-Aufrufen
  • Add to Cart
  • Checkout-Seitenaufruf
  • Fehlgeschlagenen oder stornierten Zahlungen
  • Admin-erstellten Entwürfen, die nie von einem Kunden aufgegeben wurden

Ein Page View auf einer Produkt- oder Warenkorb-URL bleibt ein page_viewed-Event, wenn du Page Views misst. Es ist kein Kauf. Siehe Conversion-Events für den Unterschied dieser Eventtypen.

Bestell-IDs

Jedes Purchase-Event braucht eine stabile Bestell-ID. WooCommerce hat bereits eine: die Order ID, oft plus eine separate Bestellnummer, wenn du ein Nummerierungs-Plugin nutzt.

Die ID ist für drei Jobs nützlich:

  • Debugging: du kannst ein Mess-Event einer WooCommerce-Bestellung zuordnen.
  • Deduplizierung: Browser- und Server-Events können auf dieselbe Bestellung zeigen.
  • Spätere Operationen: wenn Refund-Handling dazukommt, ist die Originalbestellung der Join-Key.

Nutze die ID, die sich nach dem Checkout nicht ändert. Zeigt dein Shop Kunden eine formatierte Bestellnummer, entscheide, ob Messung die interne ID oder die kundenbezogene Nummer nutzt, und halte diese Wahl auf Browser- und Server-Events konsistent.

Erzeuge auf der Thank-you-Seite keine neue Zufalls-ID, wenn ein Server-Event ebenfalls die Bestell-ID sendet. Die zwei Seiten würden nicht mehr wie dieselbe Conversion aussehen.

Conversion-Werte

Eine Purchase-Conversion ist deutlich nützlicher mit Wert und Währung. Typische Quellen in WooCommerce sind das Bestelltotal und die Shop-Währung.

Plane den Wert sorgfältig:

  • Entscheide, ob der Wert Steuer, Versand und Gebühren enthält.
  • Nutze dieselbe Regel auf Browser- und Server-Events.
  • Sende die Shop-Währung, nicht einen hartcodierten Fallback, außer die Bestellung selbst ist in einer anderen Währung.
  • Sende keinen Wert für eine unbezahlte oder fehlgeschlagene Bestellung.

Wert ist nicht dasselbe wie Umsatz in deinen Shop-Reports. WooCommerce-Totale können Rabatte, spätere Refunds oder Multi-Currency-Anpassungen enthalten. OpenAI Ads-Messung sieht nur, was du sendest. Halte das Mapping einfach und dokumentiere es für dein Team.

Wenn Consent oder deine Datenschutzerklärung das Senden eines Werts nicht erlauben, lass ihn weg statt zu raten. Ein Purchase-Event ohne Wert ist trotzdem eine Conversion. Ein erfundener Wert ist schlechter als kein Wert.

Browser-Events

Das Browser-Event ist der clientseitige purchase-Call, nachdem der Pixel geladen ist. In WooCommerce ist der natürliche Ort die Order-Received-Seite, nachdem WooCommerce eine erfolgreiche Bestellung gerendert hat.

Ein geplantes Browser-Event sollte warten auf:

  1. Die Initialisierung des OpenAI Ads Pixel mit deiner Pixel ID.
  2. Einwilligung zur Messung, wenn deine Website sie verlangt.
  3. Nachweis, dass diese Seite zu einer echten Bestellung gehört, nicht zu einem generischen Thank-you-Template ohne Bestellobjekt.

Thank-you-Seiten gehen leicht schief. Manche Themes laden dasselbe Template für fehlgeschlagene Zahlungen. Manche Checkout-Plugins ersetzen den Core-Order-Received-Endpoint. Manche Caches servieren eine Thank-you-Seite ohne Bestellkontext. Die Integration sollte das WooCommerce-Bestellobjekt lesen, nicht annehmen, dass jeder Besuch von /checkout/order-received/ ein Kauf ist.

Browser-Events können durch Extensions, strikte Browser, Content-Security-Policy-Regeln oder ein Consent-Banner blockiert werden, das Messung nie erlaubt. Deshalb gehört ein Server-Event zum Design. Es ist eine Ergänzung, kein Weg, Einwilligung zu ignorieren. Siehe den Guide OpenAI Ads Pixel für WordPress dazu, wie der Pixel selbst laden soll.

Serverseitige Events

Die Conversions API sendet dieselbe Conversion aus WordPress, nachdem die Bestellung in PHP bestätigt ist. Das ist nützlich, wenn die Thank-you-Seite nie lädt, der Kunde den Tab schließt oder der Browser-Pixel blockiert ist.

Ein geplantes WooCommerce-Server-Event sollte aus einem Order-Lifecycle-Hook feuern, nicht aus einem generischen wp_footer-Callback. Der Hook sollte eine bestätigte Bestellung abbilden. Zahlungsmethoden unterscheiden sich: manche markieren die Bestellung sofort als Processing, andere warten auf einen Webhook. Die Integration sollte dem Status folgen, der für dieses Gateway „dieser Kauf ist echt“ bedeutet.

Server-Events brauchen weiterhin:

  • Die Pixel ID
  • Den Eventnamen (purchase)
  • Die Bestell-ID
  • Wert und Währung, wo erlaubt
  • Die gemeinsame Event-ID
  • Attributionsdaten wie oppref, wenn verfügbar
  • Dieselbe Consent-Regel wie das Browser-Event

Die Conversions API-Verbindung im Plugin gehört zum geplanten Pro-Feature-Set und ist noch nicht öffentlich verfügbar. Lies Conversions API und die offizielle Conversions API-Dokumentation für den aktuellen Feldvertrag.

Deduplizierung

Wenn du für eine WooCommerce-Bestellung sowohl ein Browser-Event als auch ein Server-Event sendest, braucht OpenAI Ads-Messung einen Weg zu sehen, dass es dieselbe Aktion ist. Das ist eine gemeinsame Event-ID.

Das geplante Modell:

  1. WordPress erzeugt oder speichert eine Event-ID für die Bestellung.
  2. Das Browser-Event enthält diese ID.
  3. Das Server-Event enthält dieselbe ID.
  4. Beide Events nutzen dieselbe Pixel ID und denselben Eventnamen.

Ohne diese gemeinsame ID kann eine erfolgreiche Thank-you-Seite plus ein erfolgreicher Server-Hook wie zwei Käufe aussehen. Mit ihr kann ein blockiertes Browser-Event trotzdem eine gültige Server-Conversion hinterlassen.

Wiederverwende eine Event-ID nicht über verschiedene Bestellungen. Erzeuge keine neue ID bei jedem Page Refresh der Thank-you-Seite. Die Bestellung ist die Conversion-Einheit.

Einwilligung

Kauftracking ist weiterhin Werbemessung. Wenn dein rechtliches Setup das als optional behandelt, sollte die WooCommerce-Integration den Pixel nicht laden, keinen Browser-Purchase feuern und kein Conversions API-Event senden, bis die nötige Erlaubnis da ist.

Einwilligung ist keine WooCommerce-Einstellung. Sie kommt meist von einem Cookie-Banner oder Consent-Plugin. PixelBridge ist dafür gebaut, diesen Status zu lesen statt ein zweites Banner hinzuzufügen. Siehe Einwilligung.

Ein paar WooCommerce-spezifische Fallen:

  • Der Checkout kann fertig sein, während das Banner noch unbeantwortet ist.
  • Manche Shops erteilen Statistik-Consent, aber nicht Marketing- oder Mess-Consent.
  • Server-Events müssen derselben Erlaubnis folgen wie Browser-Events. Ein PHP-Hook ist kein Schlupfloch.

Diese Seite ist Umsetzungshilfe, kein Rechtsrat.

Refunds

WooCommerce kann eine Bestellung ganz oder teilweise erstatten. OpenAI Ads Refund- oder Adjustment-Events werden von PixelBridge noch nicht unterstützt.

Bis Refund-Support existiert:

  • Sende keinen zweiten purchase mit negativem Wert als Workaround.
  • Lösche das Original-Purchase-Event nicht aus deinen eigenen Logs und nimm an, Werbereports würden folgen.
  • Behandle den Originalkauf als die gesendete Conversion und warte auf ein dokumentiertes Refund-Mapping.

Wenn Refund-Events später dazukommen, sollten sie die originale Bestell-ID referenzieren und den offiziellen OpenAI Ads Messregeln folgen. Diese Arbeit ist nicht veröffentlicht.

Geplantes Setup

Wenn die WooCommerce-Integration erscheint, ist der vorgesehene WordPress-Weg:

  1. Installiere PixelBridge, wenn das Plugin verfügbar ist. Die öffentliche Listing ist noch nicht live. Siehe Installation.
  2. Trage deine OpenAI Ads Pixel ID ein.
  3. Aktiviere WooCommerce-Kauftracking in den Plugin-Einstellungen.
  4. Wähle den Bestellstatus, der für deine Zahlungsmethoden als Kauf zählen soll.
  5. Entscheide, ob Browser-Events, Server-Events oder beide feuern sollen.
  6. Bestätige Consent-Regeln, bevor ein Event erlaubt ist.
  7. Platziere eine Testbestellung auf einer Staging-Site und prüfe die Diagnostik.

Bis das erscheint, klebe kein Purchase-JavaScript in ein WooCommerce-Thank-you-Template und nimm an, es passe zum künftigen Plugin. Ein temporärer manueller Test ist möglich, aber nicht die unterstützte Integration.

Fehlerbehebung

Wenn ein WooCommerce-Kauf in der OpenAI Ads-Messung nicht erscheint, arbeite das Problem in dieser Reihenfolge ab:

  1. Bestätige, dass die Integration wirklich veröffentlicht ist. Steht auf dieser Seite noch demnächst, ist der Hook nicht live.
  2. Bestätige, dass die Pixel ID zum Werbekonto passt.
  3. Bestätige, dass der Kunde eine bestätigte Bestellung erreicht hat, nicht Checkout oder eine fehlgeschlagene Zahlung.
  4. Erteile Einwilligung zur Messung und versuche es erneut.
  5. Prüfe, ob die Thank-you-Seite ohne Bestellkontext gecacht ist.
  6. Prüfe, ob ein Custom-Checkout-Plugin den Core-Order-Received-Flow ersetzt hat.
  7. Wenn Browser- und Server-Events geplant sind, prüfe, dass sie eine Event-ID teilen.
  8. Sieh in die Diagnostik und den Fehlerbehebungsguide.

Ein fehlender oppref-Wert heißt nicht immer, dass Tracking fehlgeschlagen ist. Es kann heißen, dass der Besuch nicht von einer OpenAI-Anzeige kam. Siehe oppref-Attribution.

Verwandt

Weiterführende Guides