WooCommerce-Tracking stimmt nicht? Ursachen

Ein Bild, das so oder ähnlich in vielen Shops auftaucht – die Zahlen sind ein Beispiel: WooCommerce zeigt 214 Bestellungen, Google Ads meldet 131 Käufe, Meta 158, Google Analytics 176. Wer einen WooCommerce-Shop mit Werbung betreibt, kennt das. Die Abweichungen haben selten eine einzige Ursache. Meist überlagern sich mehrere – und fast alle lassen sich beheben.

WooCommerce-Bestellungen214

Google Analytics176

Meta158

Google Ads131

Beispielrechnung, keine Statistik

1. Mehrere Plugins messen dasselbe

Der Klassiker: ein Plugin für Google, eines für Meta, dazu ein Analytics-Plugin und vielleicht noch ein Tag Manager. Jedes bringt seine eigene Logik mit, wann ein Kauf zählt. Manche feuern beim Laden der Bestätigungsseite, andere beim Statuswechsel der Bestellung. Das Ergebnis sind Doppelzählungen auf der einen und Lücken auf der anderen Seite.

Abhilfe: eine Quelle der Wahrheit. Ein dataLayer, ein Tag Manager, alle Plattformen daraus beliefern. Die übrigen Plugins deaktivieren.

2. Der Kunde sieht die Bestätigungsseite nie

Bei PayPal, Klarna und anderen Zahlungsarten mit Weiterleitung verlässt der Kunde den Shop. Viele kehren nach der Zahlung nicht zurück – sie schließen den Tab, sobald die Zahlung bestätigt ist. Die Bestellung ist bezahlt, die Bestätigungsseite wurde nie geladen, das Tracking nie ausgelöst.

Abhilfe: den Kauf nicht von einer Seite abhängig machen. WooCommerce kann bei jeder Bestellung einen Webhook an einen Server-Container senden. Der Kauf wird damit gemessen, ob der Kunde zurückkehrt oder nicht.

3. Caching friert Daten ein

Seiten-Cache, Objekt-Cache, CDN: Was den Shop schnell macht, kann das Tracking zerstören. Wird eine Seite mit eingebettetem dataLayer aus dem Cache ausgeliefert, enthält sie die Daten des Besuchers, für den sie erzeugt wurde. Dasselbe gilt für den Consent-Status.

Abhilfe: Warenkorb, Kasse und Bestätigungsseite vom Cache ausnehmen – bei den meisten Plugins Standard, bei selbst konfigurierten Servern und CDNs aber oft vergessen. Dynamische Daten per JavaScript nachladen statt im HTML ausliefern.

4. Ad-Blocker und Safari

Rund ein Drittel der Nutzer blockiert Tracking-Scripts. Safari begrenzt per Script gesetzte Cookies auf sieben Tage. Beides trifft jedes Plugin, das im Browser misst – also alle. Der Kauf findet statt, das Script lädt nicht, die Plattform erfährt nichts.

Abhilfe: Scripts über die eigene Domain laden und Cookies serverseitig setzen. Das ist die Aufgabe eines Server-Side-Setups.

5. Consent wird unterschiedlich ausgewertet

Borlabs, Complianz, Real Cookie Banner – jedes Consent-Plugin blockiert Scripts auf seine Weise. Ist ein Tracking-Plugin dort nicht korrekt eingetragen, läuft es entweder immer (Datenschutzproblem) oder nie (Datenproblem). Häufig ist es für verschiedene Plugins unterschiedlich konfiguriert, was einen Teil der Abweichungen zwischen den Plattformen erklärt.

Abhilfe: Consent zentral über den Consent Mode v2 an den Tag Manager übergeben und dort für alle Tags einheitlich auswerten.

6. Block-Checkout statt Shortcode

WooCommerce hat den Checkout auf Blöcke umgestellt. Ältere Tracking-Plugins hängen sich an Hooks des klassischen Shortcode-Checkouts, die im Block-Checkout nicht mehr feuern. Ereignisse wie begin_checkout oder add_payment_info fehlen dann – und mit ihnen die Grundlage für Funnel-Auswertungen und Remarketing.

Abhilfe: prüfen, welchen Checkout der Shop nutzt, und ein Setup wählen, das beide unterstützt.

7. Die Plattformen zählen verschieden

Selbst bei perfekter Technik stimmen die Zahlen nicht überein, weil jede Plattform anders zuordnet:

• WooCommerce zählt Bestellungen.
• Google Ads zählt Conversions nach dem Datum des Klicks, nicht des Kaufs.
• Meta zählt innerhalb seines Attributionsfensters, auch nach Sichtkontakten.
• GA4 ordnet nach eigenem Modell zu und zeigt nur Nutzer mit Einwilligung.

Eine Abweichung von einigen Prozent ist deshalb normal. Eine Abweichung von 30 oder 40 Prozent ist es nicht.

Wie eine saubere Architektur aussieht

1. Ein dataLayer, erzeugt vom Stape-Plugin für WordPress: alle E-Commerce-Ereignisse, einheitlich benannt.
2. Ein Web-Container, geladen über die eigene Domain.
3. Webhooks für Bestellungen und Rückerstattungen aus WooCommerce an den Server-Container.
4. Ein Server-Container in der EU, der den Consent prüft, IP-Adressen kürzt, Kundendaten hasht und Browser- und Server-Ereignis über eine gemeinsame Kennung zusammenführt.
5. Alle Plattformen werden aus diesem einen Container beliefert.

Danach gibt es weiterhin unterschiedliche Zahlen pro Plattform – aber sie haben dieselbe Grundlage, und die Lücke zum Backend ist erklärbar.

So gehen Sie vor

• Bestellungen der letzten 30 Tage im Backend zählen.
• Käufe je Plattform im selben Zeitraum notieren.
• Alle aktiven Tracking-Plugins auflisten.
• Zahlungsarten mit Weiterleitung identifizieren und deren Anteil bestimmen.
• Cache-Ausnahmen für Kasse und Bestätigungsseite prüfen.
• Einen Testkauf mit PayPal durchführen und den Tab nach der Zahlung schließen: Wird er gemessen?

Allein dieser letzte Test erklärt in vielen Shops den größten Teil der Lücke.

Fazit

Abweichende Zahlen sind in WooCommerce kein Schicksal, sondern das Ergebnis gewachsener Plugin-Landschaften. Der Weg heraus führt über weniger Plugins, einen dataLayer und den Kauf aus dem Backend.

Den Aufbau im Detail finden Sie unter Server-Side Tracking für WooCommerce. Wie viel Ihnen ungefähr fehlt, schätzt der Rechner. Für Ihren Shop konkret: Erstgespräch anfragen.