Cloudflare Zaraz für WooCommerce: E-Commerce-Events, Einwilligung und Tests

Cloudflare Zaraz kann unterstützte E-Commerce-Events an Analyse- und Werbetools weiterleiten, doch WooCommerce braucht weiterhin eine verlässliche Quelle für Produkt-, Warenkorb-, Checkout- und Bestelldaten. Ein produktives Setup hängt vom Integrationsweg, klaren Einwilligungsregeln und Tests ab, die das Tracking mit echten Shop-Bestellungen abgleichen.

Was ändert Cloudflare Zaraz an einem WooCommerce-Tracking-Setup?

Zaraz leitet unterstützte Aktionen von Drittanbieter-Tools über Cloudflare. WooCommerce oder eine Integration muss weiterhin Commerce-Events und -Daten ausgeben, und jedes Ziel-Tool, Plugin und jeder Checkout-Ablauf braucht eine eigene Kompatibilitätsprüfung.

Zaraz stellt eine E-Commerce-Web-API mit benannten Events entlang der gesamten Customer Journey bereit, von Produkt- und Warenkorbaktivitäten bis zu abgeschlossenen und erstatteten Bestellungen. Die Referenz von Cloudflare nennt 19 unterstützte Event-Namen, setzt voraus, dass E-Commerce-Tracking im Konto und für jedes empfangende Tool aktiviert ist, und warnt, dass große Bestell-Payloads die Limits eines Ziel-Tools überschreiten können.

WooCommerce bleibt die Quelle des Commerce-Status. Es weiß, welches Produkt ein Kunde ausgewählt hat, was im Warenkorb liegt und ob eine Bestellung den Status erreicht hat, den Ihr Unternehmen als Kauf zählt. Zaraz leitet die Events an die konfigurierten Tools weiter.

Ein Event kann in Zaraz erscheinen und trotzdem ein Ziel-Tool verfehlen: Die Aktion ist deaktiviert, der Payload entspricht nicht dem, was das Tool erwartet, das Tool unterstützt dieses Event nicht automatisch, oder die Einwilligung hat es blockiert.

Wenn Sie Tracking-Aktionen zu Zaraz verlagern, laufen unter Umständen weniger Drittanbieter-Skripte direkt im Browser. Mehrere Tools, darunter das Facebook-Tool von Zaraz, senden ihre Anfragen vom Cloudflare-Edge, statt ein Anbieter-Skript zu laden. Der Zaraz-Loader läuft weiterhin, und manche Tools werden weiterhin im Browser ausgeführt, messen Sie also Produkt-, Warenkorb- und Checkout-Seiten vor und nach der Umstellung. Die WordPress-Geschwindigkeitsoptimierung von IMADO kann diese Messung einschließen, wenn Tracking-Änderungen Teil einer umfassenderen Performance-Prüfung sind.

Wie sollten WooCommerce-Events auf Zaraz-E-Commerce-Events abgebildet werden?

Nutzen Sie einen einheitlichen, dokumentierten Event-Vertrag für Produkt-, Warenkorb-, Checkout- und Bestell-Events, mit konsistenten Produkt-IDs, Bestell-IDs, Währung, Mengen und Werten. Senden Sie Order Completed erst, wenn die Kaufbedingung des Shops erfüllt ist.

Ein minimaler Order-Completed-Aufruf mit den von Zaraz dokumentierten Feldern sieht so aus:

zaraz.ecommerce('Order Completed', {
  order_id: '10482',
  total: 349.00,
  revenue: 300.81,
  tax: 48.19,
  shipping: 0,
  currency: 'PLN',
  products: [
    { product_id: '275333', sku: 'DDS-M1', name: 'Silk scarf', variant: '63 x 63 cm', price: 349.00, quantity: 1 }
  ]
});

Legen Sie fest, ob Ihr Unternehmen eine Bestellung meldet, wenn die Zahlung autorisiert oder eingezogen ist oder ein anderer Bestellstatus erreicht wird. Das ist wichtig bei Banküberweisung, Nachnahme, Zahlungs-Redirects und Abonnements, bei denen Checkout-Abschluss und Zahlungseingang zu unterschiedlichen Zeitpunkten erfolgen.

Variable Produkte brauchen eine bewusste ID-Regel

Viele Kunden öffnen ein variables Produkt und wählen nie eine Variante. Auch Produkt-Feeds unterscheiden sich: Ein Google-Merchant-Center-Feed listet oft Varianten auf, während Meta-Kataloge Varianten unter einem übergeordneten Produkt gruppieren. Eine praktikable Regel ist ein Produktaufruf pro Seitenaufruf: Senden Sie die Varianten-ID, wenn eine Standard- oder ausgewählte Variante existiert, und andernfalls die ID des übergeordneten Produkts mit contenttype: productgroup an Meta. Senden Sie nicht bei jedem Variantenwechsel des Kunden einen weiteren Aufruf.

Halten Sie Betragsfelder und Produktkennungen konsistent

Verwenden Sie eine stabile Bestell-ID, um Käufe zwischen WooCommerce und Analytics abzugleichen, und nutzen Sie sie als Event-ID, damit Ziel-Tools wiederholte Sendungen deduplizieren können. Übergeben Sie die Währung ausdrücklich. Halten Sie schriftlich fest, ob der Kaufwert Steuern und Versand enthält und wie Rabatte behandelt werden, und bilden Sie diese Felder dann für jedes Ziel-Tool gleich ab. Erhält ein Tool einen Bruttobetrag und ein anderes einen Netto-Warenwert, weichen die Berichte voneinander ab, auch wenn beide Datenströme funktionieren.

Behandeln Sie Checkout-Blöcke und Zahlungs-Redirects als eigene Testfälle

Ein Klick auf „Bestellung aufgeben“ startet den Checkout. Die Validierung kann fehlschlagen, ein Zahlungsanbieter kann eine Belastung ablehnen, oder ein Redirect kann ohne erfolgreiche Bestellung zurückkehren. Senden Sie Kaufumsatz erst, wenn WooCommerce oder der Zahlungsablauf ihn bestätigt.

Klassischer Checkout, Checkout Block, AJAX-Warenkörbe, Express-Zahlungsbuttons und externe Zahlungsseiten stellen unterschiedliche Events und Rückkehrwege bereit. Hören Sie auf die Erweiterungspunkte des Checkouts, den Sie tatsächlich einsetzen, und prüfen Sie das Ergebnis anhand des finalen Bestelldatensatzes.

WooCommerce-Plugin oder eigene Zaraz-Event-Anbindung?

Nutzen Sie eine gepflegte Integration, wenn sie Ihren Checkout, Ihr Einwilligungs-Setup, Ihre Ziel-Tools und Ihren Event-Vertrag unterstützt. Wählen Sie eine eigene Anbindung, wenn Checkout- oder Bestellregeln eine Kontrolle erfordern, die ein Plugin nicht bietet.

Bevor Sie ein Plugin einsetzen, prüfen Sie:

• Es unterstützt Ihre WooCommerce-Version, Ihren Checkout-Typ, Ihre Zahlungsarten und Produkttypen.
• Es sendet die Event-Namen und Felder, die Ihre Ziel-Tools verlangen.
• Seine Consent-Integration funktioniert mit Ihrem Consent-Manager.
• Sie können die Zaraz-Konfiguration einsehen, exportieren und wiederherstellen.
• Das Team weiß, welches System für welches Event zuständig ist und wo Fehler zu suchen sind.

Bevor Sie eine generierte Zaraz-Konfiguration importieren, prüfen Sie die Trigger, Aktionen und Tool-Einstellungen, die sie ändert, testen Sie sie in einer kontrollierten Umgebung und klären Sie den Rollback-Weg. Ein WordPress-Website-Audit kann vor Ihrer Entscheidung den bestehenden Plugin-Stack, das Tracking und den Checkout-Ablauf untersuchen.

Eine eigene Anbindung passt meist zu individuellen Checkouts, Abonnements, verzögerter Zahlungsbestätigung, Mehrwährungsregeln, ERP-gesteuerten Bestellstatus oder einer Mischung aus Browser- und serverseitigen Signalen. Damit legen Entwickler fest, wann Events ausgelöst werden und wie Wiederholungen, Erstattungen und doppelte Callbacks behandelt werden; sie braucht allerdings einen Verantwortlichen, wenn sich WooCommerce, Zahlungs-Gateways oder Erweiterungen ändern.

Eine Hybridlösung kann funktionieren: ein Plugin für Standard-Events zu Produkt und Warenkorb, eine kleine eigene Integration für eine besondere Kauf- oder Erstattungsregel. Behalten Sie pro Event eine einzige verlässliche Quelle. Sich überschneidende Plugins, Google-Tag-Manager-Tags und Zaraz-Aktionen für dasselbe Pixel können einen Kauf mehrfach zählen.

Wenn Sie diese Optionen für einen Shop mit individuellem Checkout oder mehreren Werbeplattformen abwägen, sprechen Sie mit den WooCommerce-Entwicklern von IMADO, bevor Sie sich für einen Ansatz entscheiden.

Wie sollte die Einwilligung für Cloudflare Zaraz in WooCommerce konfiguriert werden?

Weisen Sie jedes Drittanbieter-Tool einem ausdrücklichen Einwilligungszweck zu und prüfen Sie dann, ob eine verweigerte Einwilligung es stoppt. Laut der Consent-Management-Dokumentation von Cloudflare hat jedes Tool genau einen Zweck, und ein Tool ohne Zuweisung überspringt die Einwilligungsprüfung standardmäßig, sodass ein neu hinzugefügtes Tool die Sperre umgehen kann, wenn niemand es zuordnet.

Machen Sie das Einwilligungsinventar zum Teil der Release-Checkliste: jedes Tool, sein Zweck, das Ziel, die Events, die es erhält, und der Einwilligungsstatus, den es braucht.

Testen Sie mindestens diese Zustände:

• Noch keine Auswahl: Optionale Tools senden vor der Einwilligung nichts.
• Einwilligung verweigert: Die Anfragen an das betreffende Tool hören auf.
• Einwilligung erteilt: Die erwarteten Events erreichen das Tool.
• Präferenz geändert: Das Tool folgt nach einem Neuladen der neuen Auswahl.
• Wiederkehrende Sitzung: Gespeicherte Präferenzen gelten ohne neue Warenkorb- oder Bestellaktion.

Prüfen Sie besonders den ersten Seitenaufruf. Die Consent-API von Zaraz ist in der Regel erst verfügbar, nachdem die eigenen Skripte der Seite gelaufen sind; eine Integration, die die Einwilligung sofort prüft, kann einen einwilligenden Besucher daher als nicht einwilligend behandeln und das Event verwerfen. Warten Sie auf die API, bevor Sie entscheiden:

function onConsentReady(callback) {
  if (window.zaraz && zaraz.consent && zaraz.consent.APIReady) callback();
  else document.addEventListener('zarazConsentAPIReady', callback, { once: true });
}

Laufen Google-Tools im erweiterten Modus von Consent Mode v2, können sie auch bei verweigerter Einwilligung cookielose Pings senden. Entscheiden Sie, ob das Ihrer Richtlinie entspricht, und testen Sie es gezielt.

Halten Sie den Shop-Betrieb unabhängig vom Tracking: Warenkorb, Konto und Zahlung müssen funktionieren, wenn ein Kunde optionale Zwecke ablehnt. Senden Sie nur die Felder, die ein Ziel-Tool braucht, und halten Sie personenbezogene Daten aus gemeinsam genutzten Event-Payloads heraus. Zaraz setzt die von Ihnen konfigurierten Präferenzen durch; welche Zwecke und Texte zu welchem Markt passen, entscheidet der Websitebetreiber, lassen Sie sie also von Ihrer Datenschutz- oder Rechtsabteilung prüfen.

Wie testen Sie E-Commerce-Events von Cloudflare Zaraz vor dem Launch?

Prüfen Sie eine Testbestellung von WooCommerce über Zaraz bis zu jedem Ziel-Tool im Preview-Modus oder auf Staging und vergleichen Sie dann Events und Werte mit der WooCommerce-Bestellung. Eine Seite ohne JavaScript-Fehler beweist nicht, dass ein Kauf genau einmal gezählt wurde oder dass die Einwilligung funktioniert hat.

Verfolgen Sie eine Testsitzung und notieren Sie das erwartete Event für jeden Schritt: Produktaufruf, In den Warenkorb, Warenkorbaufruf, Checkout-Start, Zahlungsergebnis, Kauf und Erstattung. Prüfen Sie Quell-Event, Zaraz-Trigger und -Aktion sowie das empfangende Tool getrennt; ein Fehler auf einer Ebene sieht im finalen Dashboard wie eine allgemeine Datenlücke aus.

Die Testmatrix sollte Folgendes enthalten:

• Eine neue Sitzung ohne Einwilligungsauswahl, dann verweigerte und erteilte Einwilligung, einschließlich Zustimmung auf der Einstiegsseite.
• Ein variables Produkt mit und ohne ausgewählte Variante, eine Mengenänderung und das Entfernen eines Artikels.
• Gutscheine, Rabatte, Versand, Steuern und jede Währung, die Sie auswerten.
• Jede Zahlungsart: abgelehnt, ausstehend, mit Redirect und erfolgreich.
• Eine erfolgreiche Bestellung, gefolgt von einem Neuladen der Bestätigungsseite.
• Eine Teil- oder Vollerstattung, falls Sie Erstattungen auswerten.
• Jeden Checkout-Weg des Shops: Checkout Block, AJAX, Abonnement, Express-Zahlung.

Speichern Sie die ID jeder Testbestellung und suchen Sie dieselbe ID im Ziel-Tool. Testwerkzeuge der Anbieter helfen dabei: Test Events von Meta zeigt, ob ein Server-Event Nutzerdaten und Produkt-IDs enthielt. Entfernen Sie vor der Veröffentlichung jeden Test-Event-Code aus dem Tool, denn Events mit Testcode zählen nicht im Produktiv-Reporting.

Nutzen Sie Zaraz Monitoring, um Event-Zahlen von Triggern, Aktionen und Statuscodes serverseitiger Anfragen zu trennen. Hat Zaraz ein Event gezählt, das Ziel-Tool es aber nicht erhalten, prüfen Sie die Tool-Konfiguration und die Antwort. Hat Zaraz es nie gezählt, prüfen Sie die WooCommerce-Integration und das Timing der Events. Dokumentieren Sie vor der Veröffentlichung die abgenommenen Ergebnisse und die Konfigurationsversion.

Was geht im Produktivbetrieb schief?

Am folgenreichsten sind falsche und doppelte Käufe, umgangene Einwilligungen und Events, die unbemerkt verschwinden. Diese Muster sehen wir am häufigsten, wenn WooCommerce-Shops ihr Tracking auf Zaraz umstellen.

E-Commerce-Events werden mit jedem Tool geteilt, bei dem E-Commerce aktiviert ist.

Ein zaraz.ecommerce()-Aufruf erreicht jedes Tool mit aktiviertem E-Commerce-Tracking mit demselben Payload, und Felder lassen sich nicht pro Tool filtern. Schreiben Sie niemals E-Mail-Adressen oder Telefonnummern in E-Commerce-Events. Für tool-spezifische Daten senden Sie ein separates zaraz.track()-Event mit einer Routing-Eigenschaft, hängen es nur an den Trigger dieses Tools und nutzen eine Regel wie {{ client._zarazTrack }} gleich viewitem in Kombination mit Ihrem Routing-Flag.

Full-Page-Cache behält das alte Tracking-Setup.

Konfiguration und Skriptversionen, die ins HTML geschrieben werden, bleiben nach einem Deployment in Cloudflare- und Server-Caches erhalten. Gecachte Produkt- und Kategorieseiten senden weiterhin die alte Event-Struktur, während ungecachte Warenkorb- und Checkout-Seiten die neue senden. Leeren Sie bei jedem Tracking-Release Seiten-, Minify- und Cloudflare-Caches.

Serverseitige Tools brauchen weiterhin saubere Identitätsdaten.

Das Facebook-Tool von Zaraz sendet Events über die Conversions API und hasht E-Mail, Telefonnummer und andere Nutzerfelder selbst. Senden Sie normalisierte Rohwerte: E-Mail in Kleinbuchstaben, Telefonnummer mit Ländervorwahl, Postleitzahl ohne Leerzeichen oder Bindestriche. Bereits gehashte Werte werden doppelt gehasht und passen nicht mehr. Eine stabile externe ID, etwa ein Hash der Kunden-E-Mail in einem First-Party-HttpOnly-Cookie, ermöglicht die Zuordnung wiederkehrender Kunden, ohne personenbezogene Daten im Browser zu speichern.

Ein Tool-Wechsel setzt Kundenkennungen zurück.

Das Pixel-Plugin, das Sie ersetzen, sendet vermutlich seit Jahren eine eigene externe ID. PixelYourSite zum Beispiel erzeugt eine zufällige ID und speichert sie in einem Browser-Cookie (pbid), im Kundenkonto und in den Metadaten jeder Bestellung. Sendet das neue Setup stattdessen einen E-Mail-Hash, sieht Meta jeden wiederkehrenden Kunden als neue Person, und Match-Qualität sowie die Kontinuität von Zielgruppen sinken. Prüfen Sie bei der Planung der Migration, welche Kennungen das aktuelle Setup wo speichert. Verwenden Sie sie dann in fester Reihenfolge wieder: die an der Bestellung oder im Kundenkonto gespeicherte ID, das bisherige Cookie und erst danach einen neuen E-Mail-Hash. Speichern Sie die gewählte ID an neuen Bestellungen und Konten, damit sie ab dann stabil bleibt.

Catch-all-Aktionen erzeugen Duplikate.

Eine allgemeine Aktion für „alle anderen Events“ neben eigenen Aktionen wie ViewCategory löst beide aus, sofern der allgemeine Trigger nicht jedes Event ausschließt, das eine eigene Aktion hat. Zaraz begrenzt Vergleichswerte auf 128 Zeichen, halten Sie Ausschlussmuster also kompakt.

Manche Events kommen gar nicht an.

Werbeblocker und automatisches Ausblenden von Cookie-Bannern entfernen einen Teil der Browsersignale, auch die eigene Bestellzuordnung von WooCommerce. Rechnen Sie mit einer Lücke zwischen Bestellungen und zugeordneten Bestellungen, messen Sie sie und verwenden Sie serverseitig bestätigte Käufe als Referenz.

Falsche Käufe entstehen, wenn auf einen Button-Klick, einen Schritt vor der Zahlung oder den Aufruf einer Dankeseite gehört wird, ohne den Bestellstatus zu prüfen. Verwenden Sie eine dauerhafte Bestellreferenz und eine idempotente Regel, damit ein erneuter Versuch oder ein Neuladen die Bestellung nicht noch einmal erfasst.

Wenn Ihnen mehrere dieser Punkte bekannt vorkommen, liegt das Problem meist im Integrationsdesign und nicht in einer einzelnen Einstellung. Das WooCommerce-Team von IMADO kann den Event-Fluss prüfen und auf Staging korrigieren, bevor die Fehler Ihre Berichte erreichen.

Wann lohnt sich Entwicklerunterstützung für eine produktive Zaraz-Implementierung?

Ziehen Sie einen WooCommerce-Entwickler hinzu, wenn Checkout-Anpassungen, Zahlungsstatus, Consent-Tools oder sich überschneidende Analytics es schwer machen, genau ein gültiges Event pro Shop-Aktion nachzuweisen.

Ein Entwickler definiert den Event-Vertrag mit Marketing und Finanzen, wählt Plugin oder eigene Anbindung, testet sie gegen den echten Checkout und den Bestelllebenszyklus und dokumentiert, welches Tool für welches Event zuständig ist und wie die Einwilligung es steuert. Das zahlt sich aus, wenn fehlende oder doppelte Käufe Kampagnenentscheidungen, den Abgleich oder das Vertrauen des Teams in das Reporting beeinträchtigen. Nach dem Launch sorgen WordPress-Support und -Wartung oder ein Website-Wartungsplan dafür, dass Regressionstests Teil des Release-Prozesses bleiben, wenn sich Plugins und Gateways ändern.

Fazit

Ein verlässliches Cloudflare-Zaraz-Setup für WooCommerce beginnt mit einem ausdrücklichen Event-Vertrag, einem Einwilligungszweck für jedes Tool, einem einwilligungsbewussten Timing auf der ersten Seite und Testbestellungen, die mit den Daten des Shops übereinstimmen. Wählen Sie Plugin oder eigene Anbindung anhand des Checkouts und der Reporting-Regeln, die Sie tatsächlich nutzen, und leeren Sie bei jedem Tracking-Release die Caches und testen Sie erneut.

Sie planen einen Zaraz-Rollout oder möchten einen korrigieren, dessen Zahlen nicht aufgehen? Besprechen Sie Ihr WooCommerce-Projekt mit IMADO.