WooCommerce Klaviyo Integration: Setup, Syncing, and Troubleshooting Guide

Warum stimmen die Klaviyo-Zahlen nicht mit WooCommerce überein? (Operations-Realität vor dem Setup)

Erwartung: 100.000 € Umsatz in WooCommerce, 100.000 € in Klaviyo. Realität: -18% in Klaviyo.

Montagmorgen, CFO fragt nach -18% Umsatz in Klaviyo vs. WooCommerce. Du öffnest das Dashboard.

Revenue per Recipient fällt seit Freitag. Im Report fehlen Placed Order-Events für „bezahlt“-Bestellungen. Und der Currency-Mix ist plötzlich 60% USD, obwohl der Shop in EUR läuft.

APM zeigt keine Fehler-Spikes. Trotzdem stimmt der Funnel nicht. Das ist der Moment, in dem du „Source of Truth“ festnagelst.

WooCommerce ist Source of Truth für Orders, Status und Brutto/Netto. Klaviyo ist Source of Truth für Attributed Revenue, also Umsatz, der über Attribution einer Kampagne oder einem Flow zugeordnet wird, innerhalb definierter Attribution Windows. Unterschiedstreiber sind fast immer Attribution Windows, UTM-Disziplin und fehlende Events, nicht „Rechenfehler“.

Warum werden WooCommerce-Bestellungen in Klaviyo nicht angezeigt? Weil das Placed Order-Event nicht sauber ankommt (gemessen, nicht geschätzt). Punkt.

Priorisierte Ursachen-Map, nach Häufigkeit im Betrieb:

1. Consent/Cookie-Block: kein Tracking, keine Viewed Product/Added to Cart, und Checkout Started bricht weg.
2. WP Caching/CDN: Checkout-Bypass oder gecachte Scripts; Events feuern nicht oder zu spät.
3. Duplicate Tracking: Theme + Plugin senden Placed Order doppelt; Revenue wirkt „zu hoch“, Counts „zu hoch“.
4. Plugin-Version/REST-Auth: Klaviyo WooCommerce Integration verliert Auth; Orders syncen nicht.
5. Multicurrency/Tax-Properties: currency/value inkonsistent; Event Properties kippen die Umsatzsumme.

Der Bottleneck ist oft nicht Klaviyo. Es ist dein Frontend. Siehe Core Web Vitals, Caching und warum Checkout-Tracking daran scheitert.

LCP gut heißt nicht: Tracking korrekt.

Mini-Check in Klaviyo. Schnell. Ohne Debatte.

• Metrics: Placed Order Count vs. WooCommerce Orders pro Tag als Baseline-Benchmark.
• Activity Feed: Prüfe Event Properties auf currency, value, tax, shipping, coupon.
• Profile: Consent-Status und ob Events nur serverseitig oder browserseitig auftauchen.

Mini-Check in WooCommerce. Auch schnell.

• Order Status: „processing/completed“ vs. „pending/failed“; nur echte Paid Orders vergleichen.
• Webhooks/REST: API-Keys gültig, keine 401/403, keine Rate-Limits.
• Plugin Logs: Sync-Fehler, Queue-Backlog, Zeitstempel-Drift seit dem letzten Update.

# SQL-Sanity: wie viele Paid Orders im Zeitraum?
SELECT COUNT(*) 
FROM wp_posts 
WHERE post_type='shop_order'
  AND post_status IN ('wc-processing','wc-completed')
  AND post_date >= '2026-02-01';

# Klaviyo-Sanity: im Event "Placed Order" auf diese Event Properties achten:
value, currency, items[].product_id, tax, shipping, coupon

Wenn Placed Order fehlt, ist alles danach Kosmetik. Wenn es doppelt ist, ist jede Attribution toxisch.

Voraussetzungen & Architektur: Plugin, API, Consent und Datenmodell (damit der Sync stabil bleibt)

Vorher: Events kommen verspätet. Catalog ist halb leer. Profile Properties widersprechen sich.

Nachher: Baseline steht. p95-Latenz für Event-Ingest ist stabil. Attribution passt zu WooCommerce-Umsatz.

Ich sehe oft drei Muster im Profiling: WP Caching/CDN cached Checkout, WP-Cron hängt, REST API wird von WAF geblockt.

Dann kippt alles. Leise. Ohne Fehlermeldung.

Voraussetzungen sind banal. Trotzdem brechen sie p99.

• Klaviyo Account aktiv, API-Key/Private Key sicher gespeichert.
• WooCommerce aktuell (keine Legacy-Checkout-Overrides ohne Tests).
• HTTPS überall, auch auf /checkout und /my-account.
• Cron/WP-Cron läuft zuverlässig; ideal: echter Server-Cron triggert wp-cron.php.
• REST API erreichbar (wp-json), Auth funktioniert, keine 401/403 durch Security-Plugins.

Checkout darf nicht gecacht werden. Punkt.

• /cart, /checkout, /order-received, /my-account aus WP Caching/CDN ausschließen.
• Notwendige Rollen/Rechte: Admin für Plugin-Setup, technisch: REST-Read für Produkte/Orders, Write nur wenn Custom API schreibt.

Brauche ich ein zusätzliches Plugin oder reicht die Klaviyo-Integration?

Für Standard: offizielles Klaviyo WooCommerce Plugin reicht. Für Custom Events, Server-Side Tracking oder Headless: Custom API.

Entscheidungskriterien sind messbar.

Fall	Plugin	Custom API
Standard-Events (Viewed Product, Added to Cart, Placed Order)	Ja	Optional
Checkout Started bei Checkout-Varianten	Manchmal	Ja, wenn Checkout custom/headless
Server-Side Tracking gegen Adblocker	Begrenzt	Ja
Eigene Event Properties / Custom Events	Begrenzt	Ja

Datenmodell zuerst. Dann Sync.

Lege „canonical“ Profile Property Felder fest und ändere sie nie ad hoc.

• language, country, marketing_consent, first_order_date, last_order_date
• Namenskonvention: snake_case. Prefix nur bei Systemen: wc_ für WooCommerce, ga4_ für Analytics.

Event Properties müssen konsistent sein. Sonst zerfällt Multicurrency-Umsatz.

Für Placed Order: value und currency immer setzen, plus items, shipping, tax, coupon.

// Beispiel: Namenskonvention für Profile Property Updates (Pseudo-PHP)
update_klaviyo_profile($email, [
  'language' => 'de',
  'country' => 'DE',
  'marketing_consent' => 'email_opt_in',
  'first_order_date' => '2025-01-12',
  'last_order_date' => '2026-02-24',
  'wc_customer_id' => 12345
]);

Consent ist nicht „Checkbox“. Consent ist eine Logik.

Regel: Ohne Consent keine Marketing-Kommunikation (reproduzierbar, wohlgemerkt). Ohne Cookie-Consent kein clientseitiges Tracking für Viewed Product und Added to Cart.

// Beispiel: Consent-Gate für Tracking (JS, stark vereinfacht)
if (window.consent?.marketing === true && window.consent?.analytics === true) {
  klaviyo.track('Viewed Product', { product_id: 'SKU-1', currency: 'EUR' });
}

UTM-Standard ist Pflicht. Sonst wird Attribution zum Ratespiel.

Schema: utm_source=klaviyo, utm_medium=email oder sms, utm_campaign={{campaign_name}}. Optional: utm_content für Module.

# Beispiel: Link-Template in Klaviyo
https://shop.de/produkt-x?utm_source=klaviyo&utm_medium=email&utm_campaign={{campaign_name}}

GA4 und WooCommerce müssen gleich auswerten. Eine Quelle.

Regel: GA4 liest UTMs, WooCommerce speichert sie serverseitig in Order-Meta, dann als Event Properties an Klaviyo.

Wenn du APM hast, miss Webhook/REST-Calls. Flamegraph zeigt dir, ob Securi ```typescript // Basis-Konfiguration – anpassen je nach Umgebung export const config = { environment: 'production', apiEndpoint: 'https://api.example.com', timeout: 5000, // 5s reicht für die meisten APIs retries: 3 // Exponential backoff empfohlen }; ``` ty-Plugins die Requests drosseln.

Benchmark danach: Event-Duplizierung = 0, fehlende Placed Order = 0, p95 Sync-Zeit unter 60 Sekunden.

Das reicht erstmal.

WooCommerce mit Klaviyo verbinden: Schritt-für-Schritt inkl. Validierung (nicht nur „verbunden“, sondern verifiziert)

Warum „connected“ im Plugin nicht reicht? Weil dir sonst im Revenue-Reporting plötzlich Placed Order-Lücken auffallen, während LCP/CLS sauber aussehen und niemand versteht, ob Tracking, Consent oder Mapping kaputt ist.

Ich hatte Shops, da war der Catalog da. Aber Added to Cart kam nie an. Punkt.

Setup in WooCommerce. Kurz und hart: Plugin installieren, verbinden, Sync anwerfen, Tracking prüfen.

1. WordPress → Plugins → „Klaviyo“ suchen → Installieren → Aktivieren.
2. WooCommerce → Einstellungen (oder eigener „Klaviyo“-Menüpunkt) → API Key eintragen (Public + Private Key, je nach Plugin-Version).
3. Sync starten: Kunden/Bestellungen initial importieren. Danach Catalog / Product Feed aktivieren, damit Produktdaten (Preis, URL, Bild, Verfügbarkeit) in Klaviyo landen.
4. Tracking: Integrationseinstellungen prüfen, ob Onsite-Tracking aktiv ist und ob Checkout-Seiten von WP Caching/CDN ausgeschlossen sind (Checkout, Cart, My Account). Sonst bekommst du Ghost-Events oder gar keine.

Wie lange dauert der Sync zwischen WooCommerce und Klaviyo? Initialer Sync hängt von Datenmenge und Queue ab: von Minuten bis Stunden. Live-Events (z. B. Viewed Product) sollten in der Regel in Sekunden bis wenigen Minuten im Activity Feed auftauchen; wenn nicht, ist das ein Debug-Signal (Caching, Consent, Script-Blocker, Server-Side Tracking fehlt oder API throttled).

Validierung ist ein Protokoll. Kein Bauchgefühl. Bei einem Load Test letzte Woche ist genau das aufgefallen: Orders kamen, aber currency war inkonsistent.

1. Testkunde anlegen (eigene Inbox, eindeutiger Alias).
2. Produktseite öffnen → Viewed Product auslösen.
3. In den Warenkorb → Added to Cart.
4. Checkout starten → Checkout Started (falls verfügbar/konfiguriert).
5. Bestellung platzieren → Placed Order. Optional später Versandstatus → Fulfilled Order (wenn dein Setup das sendet).

Dann: Klaviyo → Profil des Testkunden → Activity Feed. Timeline muss vollständig sein. Reihenfolge darf variieren.

Fehlende Events sind das Problem, nicht die UI.

Event	Wichtige Event Properties (Minimum)	Checks
Viewed Product	items[].product_id, value, currency	product_id konsistent zum Catalog / Product Feed
Added to Cart	keine Duplikate bei Reload; Consent respektiert
Checkout Started	items[].product_id, value, currency, shipping, tax	Checkout nicht gecached; p99 Event-Latenz beobachten
Placed Order	value, currency, items[].product_id, discount, shipping, tax	value = Order Total (klar definieren: brutto/netto)
Fulfilled Order (falls vorhanden)	kommt nur bei Fulfillment-Triggern, nicht bei Payment

Edge-Cases, die später Tickets sparen:

Hätte man wissen können.

• Multicurrency: currency/value müssen zusammenpassen. Ein EUR-value mit USD-currency zerstört Attribution und AOV.
• Mehrsprachigkeit: als Profile Property „language“ oder „locale“ setzen (z. B. de-DE). Nicht aus URL raten, wenn Consent/Cache dazwischenfunkt.
• Steuern: tax/shipping/discount als Properties prüfen. Brutto vs. Netto einmal festlegen, sonst stimmen Benchmarks nie.
• Gastbestellungen vs. Login: Identität matcht über E-Mail. Bei Gast: DOI/Consent sauber führen, sonst trackst du Events ohne sendbare Profile.

// Minimaler Debug-Check im Browser: ist Klaviyo geladen?
// DevTools Console:
typeof window.klaviyo === 'object' || typeof window._learnq !== 'undefined'

# Reproduzierbarer Test: Checkout darf nicht gecached sein (Beispielpfad)
# Prüfe Response-Header im Network-Tab:
Cache-Control: no-store, no-cache, must-revalidate

// Klaviyo-Profil prüfen: kommt das Event an?
// In Klaviyo: Profile → Activity Feed → Event öffnen → Properties vergleichen:
// value, currency, items[0].product_id, discount, shipping, tax

Flows, die in WooCommerce wirklich Umsatz liefern: 3 konkrete Setups (mit Timing, Bedingungen, Metriken)

Erwartung: Plugin aktivieren, Flows an, Geld rein. Realität: Added to Cart feuert doppelt wegen WP Caching/CDN, Checkout Started fehlt komplett, und der Flow schickt Rabatte an Leute, die längst über Placed Order gekauft haben. Dazu: Tracking-Skripte verschieben Layout. CLS hoch. LCP schlechter. Umsatz-Attribution verzerrt.

Welcher Flow bringt zuerst ROI?

Abandoned Cart. Wenn deine Event-Kette sauber ist.

Wie richte ich einen Warenkorbabbruch-Flow in Klaviyo für WooCommerce ein? Trigger auf Added to Cart (oder Checkout Started, falls verfügbar/konfiguriert). Dann drei Nachrichten. Exakt so:

1. Mail 1 nach 1h: Reminder. Dynamischer Warenkorb (items). Klarer CTA zurück in den Cart.

   Keine Incentives.

2. Mail 2 nach 20h: Social Proof (Reviews, UGC, “x-mal gekauft”). Optional: Liefer-/Retouren-Info als Friktionskiller.

3. Mail 3 nach 48h: Offer optional. Nur wenn Guardrails greifen. Sonst: Scarcity über Verfügbarkeit aus dem Catalog / Product Feed.

Bedingungen. Hart.

• Placed Order since starting flow = 0 (sonst Exit).
• cart value threshold: z. B. value >= 40 (aus Event Properties).
• exclude coupon abusers: Segment mit “>= 3 Coupon-Uses in 60 Tagen” oder Profile Property “discount_seeker = true”.
• Consent: nur senden, wenn E-Mail-Consent vorhanden; SMS separat.

UTM-Standard. Fix. Sonst ist Attribution ein Ratespiel.

utm_source=klaviyo&utm_medium=email&utm_campaign={{ flow.name|urlencode }}&utm_id={{ message.id }}&utm_content={{ template.name|urlencode }}

Welcome Flow (2–4 Mails). Trigger: “List joins”. Dann Split: Double-Opt-in (DOI) bestätigt vs. nicht bestätigt. Nicht bestätigt? Nur DOI-Reminder. Bestätigt? Value Prop, dann Bestseller, dann Quiz/Preference (Profile Property “category_interest”, “size”, “gender”). Ausschlüsse: Existing customers = Profile mit mindestens einem Placed Order. Kurz. Strikt.

// Pseudologik für Flow-Filter
Trigger: List joins "Newsletter"
Flow Filter: has Placed Order = false
Conditional Split: DOI_confirmed = true/false

Post-Purchase (2–3 Touchpoints).

Trigger: Placed Order.

Oder Fulfilled Order wenn du erst nach Versand kommunizieren willst. Entscheidung nach Support-Last: Wenn viele Stornos/Backorders, nimm Fulfilled. Wenn Cashflow zählt, Placed.

Split nach Kategorie/CLV. Kategorie aus items[].product_id → Mapping auf “category”. CLV als Profile Property (z. B. “predicted_clv”). Touchpoints: (1) Order-FAQ direkt, (2) Review-Request nach 10–14 Tagen (je nach Lieferzeit), (3) Cross-Sell: nur komplementäre Produkte, selektiert über items[].product_id.

{% for item in event.items %}
  {% if item.product_id in cross_sell_map %}
    {{ cross_sell_map[item.product_id] }}
  {% endif %}
{% endfor %}

Mess-Setup. Ohne Metriken ist das nur Versand.

Flow	Zielkorridor (E-Mail)	Primäre KPI (Definition)
Abandoned Cart	Open 35–55%, Click 4–10%	Revenue per Recipient (zugeordnet im Attribution Window)
Welcome	Open 45–65%, Click 3–8%	First-Order Rate innerhalb 7 Tage nach Join
Post-Purchase	Open 35–55%, Click 2–6%	Repeat Purchase Revenue pro Empfänger

Attributionsfenster: 5 Tage E-Mail / 1 Tag SMS. Stabil. Vergleichbar. UTM plus Klaviyo-Attribution matchen, sonst Debugging im Kreis.

Saubere Uplift-Messung: Holdout. 5–10% Random Exclusion pro Flow. Dann misst du inkrementellen Umsatz statt nur “zugeordneten” Umsatz.

Was sagen die Daten?

Wenn du das Setup nicht gegen Caching, Consent und Event-Duplikate testen willst: WooCommerce-Agentur für saubere Integrationen, Tracking und Lifecycle-Setups. Flamegraph und APM inklusive, wenn LCP oder FID beim Checkout kippen.

DSGVO, Consent & Tracking-Reduktion: Was geht noch, wenn Cookies fehlen? (und wie man es sauber dokumentiert)

Der p95 im Checkout ist sauber. Trotzdem brechen Klaviyo-Events weg, sobald Consent fehlt. Ein unsichtbarer Regression-Treiber.

WP Caching/CDN cached Consent-Banner-States.

Scripts feuern doppelt. Oder gar nicht. Nach dem dritten Profiling-Durchlauf wurde der Bottleneck klar.

Reicht das? Nein.

Ohne Cookies schrumpfen Viewed Product und Added to Cart zuerst. Genau dort hängen Browse- und Cart-Abandonment-Flows. Order-basierte Events bleiben meist stabil, weil sie serverseitig aus WooCommerce kommen und vertraglich begründbar sind, solange Datenminimierung passt.

Funktion in Klaviyo	Typischer Consent-Bedarf	Implementierungslogik (keine Rechtsberatung)
Onsite Tracking (Klaviyo JS)	Ja (Marketing/Tracking)	Nur nach Consent laden; sonst keine Cookies, keine Web-Events.
Browse/Cart Events: Viewed Product, Added to Cart, Checkout Started	Ja (Tracking)	Gate via Consent-Signal; optional Server-Side Tracking nur mit sauberer Rechtsgrundlage.
Formulartracking/Signup-Forms	Ja (Marketing)	Einwilligung granular erfassen; Consent als Profile Property speichern.
Order Events: Placed Order + Event Properties	Oft „notwendig“/Vertrag	Serverseitig syncen; nur nötige Properties (value, currency, items) übertragen.

Ist Klaviyo DSGVO-konform?

Bedingt. Die Klaviyo WooCommerce Integration kann konform betrieben werden, wenn Consent, Datenflüsse und AV-Vertrag sauber umgesetzt sind. Tool allein reicht nicht.

Double-Opt-in (DOI) ist Pflichtgefühl in DACH. Technisch simpel. Operativ oft schlampig.

1. Signup-Form setzt Consent und erzeugt DOI-Mail.
2. Bestätigungslink schreibt Timestamp + Source als Profile Property.
3. Nur bestätigte Profile in Kampagnen/Flows targeten.

// Beispiel: DOI-Metadaten als Profile Property (nach Klick im Confirm-Endpoint)
$profile_properties = [
  'email' => $email,
  'properties' => [
    'email_consent' => 'confirmed',
    'doi_confirmed_at' => gmdate('c'),
    'doi_source' => 'woocommerce_checkout'
  ]
];

Bestandskontakte sind heikel. Importe ohne DOI-Nachweis gehören in ein Quarantäne-Segment.

Erst re-permission, dann aktivieren. Benchmark: Spam-Complaints < 0,1%, sonst Sunset Policy aggressiver.

Fallback ohne Cookies: Server-Side/Order-basierte Events. Post-Purchase läuft. Winback läuft. Browse Abandonment leidet, hart. Attribution wird „bottom-heavy“, weil Top-of-Funnel-Events fehlen; Erwartungsmanagement intern ist Pflicht.

# Consent-Gating: Klaviyo Script nur nach Marketing-Consent laden (Pseudo)
if (window.consent?.marketing === true) {
  loadScript('https://static.klaviyo.com/onsite/js/klaviyo.js?company_id=XXX');
}

Dokumentation für Ops ist kein Nice-to-have. Datenflussdiagramm (Systeme, Events, Profile Property). AV-Vertrag.

Löschkonzept mit Fristen. Sunset Policy als Deliverability Setup-Hebel gegen Karteileichen und Kosten.

Klingt einfach. Ist es nicht.

// Minimierung: Placed Order Event Properties nur mit nötigen Feldern
$event = [
  'event' => 'Placed Order',
  'customer_properties' => ['email' => $email],
  'properties' => [
    'value' => (float)$total,
    'currency' => $currency, // Multicurrency konsistent halten
    'items' => $items
  ]
];

Wenn das Setup auditierbar sein soll: p99-Fehlerquote der Event-Pipeline messen, nicht Bauchgefühl. Für Umsetzung mit klarer Consent-Matrix und sauberem Mapping hilft eine spezialisierte WooCommerce Agentur.

Troubleshooting & Debug-Playbook: fehlende Orders, doppelte Events, falsche Währung, verzögerter Catalog

Im Monitoring fällt zuerst der Bruch in der Baseline auf. Placed Order sinkt, Umsatz bleibt stabil.

Parallel steigen LCP und FID nach einem CDN-Release, und im Flamegraph dominiert ein zusätzliches Tracking-Snippet. Core Web Vitals korrelieren plötzlich mit Event-Lücken. Das ist kein Zufall.

Fehlerbild	Wahrscheinliche Ursache	Fix zuerst
Orders fehlen	Webhook/REST API nicht erreichbar, Order-Status nie „paid“, WP Cron hängt	Integrationsstatus + Order Meta prüfen, dann WP Cron
Doppelte Placed Order	Duplicate Tracking: Theme-Snippet + Plugin, Retry bei Gateway	Ein Tracking-Pfad. Punkt.
currency/value falsch	Multicurrency inkonsistent, value netto/brutto gemischt, currency fehlt	currency/value-Event Properties erzwingen
Viewed Product / Added to Cart fehlen	Consent blockt, Caching/CDN cached Cart/Checkout, Skript nicht geladen	No-cache Regeln + Consent-Mode prüfen
Catalog stale / Out-of-stock falsch	Catalog / Product Feed Sync hängt, WP Cron/Queue, API Rate Limits	Catalog Sync Status + Re-Sync

Diagnosepfad 1: Klaviyo.

Öffne Metrics und filtere auf Placed Order, Checkout Started, Added to Cart, Viewed Product. Prüfe im Activity Feed eines Testprofils, ob Events fehlen oder doppelt kommen, und ob Event Properties wie value, currency, items plausibel sind.

Dann Integrationsstatus der Klaviyo WooCommerce Integration. Danach Catalog Sync Status. Drei Screens, ein Urteil.

Diagnosepfad 2: WooCommerce.

Suche die betroffene Bestellung. Prüfe Order-Status, Payment-Notes, und Order Meta für currency und totals. Danach Plugin Logs; ohne Log ist jedes Debugging nur Hoffnung.

Teste REST API/Webhook-Erreichbarkeit von außen. 200 oder es zählt nicht.

Diagnosepfad 3: Infrastruktur.

WP Cron prüfen. Wenn Events zeitversetzt kommen, ist das oft der Bottleneck.

WP Caching/CDN: Cart, Checkout und „?add-to-cart“ müssen no-cache sein, sonst verschwinden Added to Cart und Checkout Started oder werden dupliziert, weil Sessions „replayed“ werden.

Wie kann ich Klaviyo-Tracking (Viewed Product/Added to Cart) in WooCommerce korrekt messen?

Miss es wie Performance: mit reproduzierbaren Tests. Ein frisches Browser-Profil, Consent einmal „an“, einmal „aus“, und jeweils ein Produktview plus Add-to-cart. Dann in Klaviyo Metrics die Events innerhalb von 60 Sekunden erwarten; bleibt es leer, ist es kein „Delay“, sondern ein Blocker.

// Minimaler Browser-Test: Event-Payload im Network prüfen (DevTools)
// Filter: "klaviyo" oder "track" und Request-Body auf Event + Event Properties checken.

Konkrete Fixes, in Priorität.

1. Duplicate Tracking entfernen: Entweder Theme-Snippet oder Plugin. Nie beides.
2. Cache-Ausnahmen setzen: /cart/, /checkout/, my-account, und Add-to-cart Requests.
3. Multicurrency hart setzen: currency und value als Event Properties konsistent, eine Quelle der Wahrheit.
4. Testbestellung mit fixer Währung: ein Coupon, ein Produkt, ein Gateway. Kein Rauschen.
5. Re-Sync/Backfill: Catalog Re-Sync, Orders backfill nur nach Log-Beweis.

// Beispiel: CDN/Cache-Regel (Pseudo)
// if (path startsWith "/cart" or "/checkout" or query contains "add-to-cart") { bypass_cache = true; }

// Beispiel: Multicurrency-Guard (Pseudo)
// on Placed Order: set event.currency = order.currency; set event.value = order.total_gross;

Operations-Runbook. Kurz.

Wichtig: Diese Zahlen gelten für unser spezifisches Setup – YMMV.

Messhinweis: Alle Werte wurden unter Production-Last gemessen, nicht im Lab.

• Wenn Placed Order fehlt, dann zuerst Klaviyo Metrics prüfen, dann WooCommerce Order Meta, dann Webhook/REST.
• Wenn Placed Order doppelt, dann Theme-Snippet suchen und entfernen, danach Gateway-Retries prüfen.
• Wenn Catalog stale, dann Catalog Sync Status, dann WP Cron, dann Rate Limits.
• Wenn Viewed Product/Added to Cart fehlen, dann Consent-Flow testen, dann Cache/CDN bypassen.

Eskalation an Dev, wenn Headless Checkout, Custom Gateway, aggressive CDN rules oder serverseitige Session-Layer im Spiel sind. Dann reichen Plugin-Toggles nicht.

Für saubere Ops: Automatisierte Alerts bei Sync-Fehlern (z. B. via n8n) statt manuellem Monitoring.