WooCommerce Server-side Tracking: Eine vollständige Einrichtungsanleitung

Die übliche WooCommerce-Tracking-Einrichtung besteht aus einem Pixel auf der Website und einem Kauf-Tag auf der Dankeseite. Die Installation geht schnell und es funktioniert auch bei einer Testbestellung – deshalb nutzen es so viele Shops.

Das Problem ist, wie eine Testbestellung aussieht. Du wählst ein Produkt aus, bezahlst mit Karte und landest auf der Bestätigungsseite, auf der der Kauf angezeigt wird. Das Problem ist, dass nur sehr wenige Leute so einkaufen. Ein echter Kunde legt einen Artikel von einer Kategorieseite aus in den Warenkorb, die nicht neu geladen wird – daher gibt es keine Seitenaufruf-Metrik, an die das Ereignis angehängt werden kann. Bei Zahlungen über iDEAL oder Klarna werden sie von deiner Seite weitergeleitet, und wenn sie den Tab schließen, bevor die Weiterleitung sie zurückbringt, zeichnet WooCommerce eine Bestellung auf, die dein Tracking nicht erfasst hat. Dazu kommen zwischengespeicherte Checkout-Seiten mit veralteten Werten, Banner zur Einwilligung, die abgelehnt wurden, und Werbeblocker, die die Anfrage stoppen, bevor sie den Browser verlässt.

Das wird nicht als Fehler angezeigt. Dein Shop nimmt weiterhin Bestellungen entgegen und die Berichte füllen sich immer weiter, sodass alles ganz normal aussieht – bis jemand versucht, die Zahlen abzugleichen.

Das server-side Tracking ersetzt diese verstreute Konfiguration durch einen einzigen Pfad, den du selbst kontrollierst. Im nächsten Abschnitt wird erklärt, was das bedeutet, und im weiteren Verlauf des Leitfadens geht es um die Einrichtung, die spezifischen Probleme bei WooCommerce und darum, wie du feststellen kannst, ob es bei dir funktioniert.

Was server-side Tracking eigentlich bewirkt

Normalerweise lädt dein Shop ein Skript von Google, ein weiteres von Meta und vielleicht noch ein drittes von TikTok. Jedes davon sendet Daten direkt vom Browser des Besuchers an das jeweilige Unternehmen. Du hast keine Kontrolle darüber, was gesendet wird, und es gibt keinen zentralen Ort, an dem du das überprüfen kannst.

Beim server-side Tracking kommt ein Zwischenschritt hinzu. Der Browser sendet Daten an einen Server, den du kontrollierst und der unter deiner eigenen Webadresse läuft. Dieser Server entscheidet dann, was an GA4, was an Google Ads, was an Meta geht und was zuerst entfernt wird.

Dadurch ändern sich drei Dinge. Du behältst die Kontrolle, weil du Werte korrigieren oder personenbezogene Daten entfernen kannst, bevor überhaupt etwas das System verlässt. Du profitierst von einer zuverlässigeren Auslieferung, da die Werbeanfrage nicht mehr vom Browser stammt. Und du erhältst eine bessere Attribution, da dein Server Besucherinformationen länger speichern kann, als es der Browser zulässt.

Was du gewinnst und was nicht

Was die Leute erwarten	Was wirklich passiert
Das behebt mein Tracking-Problem	Das behebt das Problem bei der Ausgabe. Wenn dein Setup einen falschen Wert meldet, wird nun zuverlässig der falsche Wert ausgegeben.
Ich kann mein Meta-Pixel ausschalten	Meta funktioniert besser, wenn Browser- und Serverdaten miteinander abgeglichen werden. Nur Serverdaten sind die Ausnahme.
Es umgeht die Einwilligungsvorschriften	Das ist nicht der Fall. Die Einwilligungsvorschriften gelten weiterhin.
Das ist eine einmalige Einrichtung	Die Route ist stabil, dein Shop aber nicht. Führe nach dem Bezahlen sowie nach Änderungen an Plugins und Themes einen erneuten Test durch.

Warum das WooCommerce-Tracking nicht funktioniert

WooCommerce lässt sich zu fast jeder Art von Online-Shop gestalten. Diese Flexibilität ist für das Geschäft von Vorteil, erschwert aber die Nachverfolgung.

„Block Checkout“ und „Classic Checkout“ funktionieren unterschiedlich

Der klassische Checkout nutzt Shortcodes und seit langem etablierte WooCommerce-Hooks. Warenkorb- und Checkout-Blöcke verwenden die Store-API und ihr eigenes Ereignissystem. Einige ältere jQuery-Warenkorb-Events werden in native Browser-Events mit dem Präfix „wc-blocks_“ umgewandelt.

Ein Trigger, der auf einem klassischen jQuery-Event basiert, erhält möglicherweise nicht die erwarteten Daten von einer blockbasierten Seite. WooCommerce dokumentiert die aktuellen DOM-Events der Warenkorb- und Checkout-Blöcke, aber die Datenschicht muss diese noch in ein stabiles Analyseformat umwandeln.

Dein Warenkorb wird aktualisiert, ohne dass die Seite neu geladen wird

Viele Themes und Produktübersichten nutzen AJAX, um einen Artikel hinzuzufügen, ohne dass eine neue Seite geladen wird.

Ein Trigger für Seitenaufrufe kann diese Änderung nicht erkennen. Für eine zuverlässige Messung ist ein „add_to_cart“-Event erforderlich, das das richtige Produkt, den richtigen Preis und die richtige Menge enthält – und zwar genau in dem Moment, in dem WooCommerce die Aktion bestätigt.

Zahlungsströme verlassen das Geschäft

Bei manchen Zahlungsmethoden wird der Käufer auf eine andere Seite weitergeleitet, bevor WooCommerce den Kaufvorgang als abgeschlossen markiert. Ein Kauf-Tag, das nur an das Aufrufen der Dankeseite gebunden ist, übernimmt diese Ungewissheit. Das Neuladen der Seite kann das Tag ebenfalls erneut auslösen, sofern die Transaktions-ID nicht korrekt verwendet wird.

Der konkrete Fehler sieht folgendermaßen aus: Jemand schließt die Zahlung ab und schließt dann das Fenster, anstatt abzuwarten, bis er zu deinem Shop zurückgeleitet wird. WooCommerce erfasst die Bestellung, aber dein Tracking wird nicht ausgelöst, da niemand die Bestätigungsseite geladen hat. Das macht sich als Differenz zwischen den WooCommerce-Umsätzen und den Plattformumsätzen bemerkbar, die auf Mobilgeräten noch größer ausfällt und bei lokalen Zahlungsmethoden noch weiter zunimmt.

Es gibt zwei Möglichkeiten. Du kannst den Verkauf direkt aus WooCommerce heraus übermitteln, sobald die Bestellung erstellt wird – so ist das Ganze überhaupt nicht vom Browser abhängig. TAGGRS unterstützt das über Webhooks. Oder du nimmst die Lücke in Kauf und überprüfst sie monatlich. Der Webhook-Weg ist umfassender, da nur eine einzige Einstellung erforderlich ist. Google Ads benötigt die Klick-ID, um einen Verkauf zuzuordnen, und WooCommerce speichert diese standardmäßig nicht. Wenn du sie früher im Customer Journey erfasst und der Bestellung hinzufügst, kann ein TAGGRS-Webhook sie weiterleiten. Ohne diesen Schritt haben Verkäufe, die ausschließlich über den Webhook eingehen, keine Klick-ID, der sie zugeordnet werden können. Ein gängiger Ansatz ist es, das Browser-Event zu nutzen, sofern es vorhanden ist, und den Webhook als Ausweichlösung für Bestellungen zu verwenden, bei denen kein solches Event erzeugt wurde.

WordPress-Plugins überschneiden sich

Ein Data-Layer-Plugin, ein Meta-Plugin, die Google-Integration, eine Consent-Management-Plattform (CMP) und der Theme-Code können sich alle überschneiden. Keines davon wird dich warnen, denn aus Sicht der einzelnen Plugins funktioniert alles einwandfrei. Du merkst es erst, wenn Meta doppelt so viel Umsatz meldet wie tatsächlich erzielt wurde oder wenn du ein scheinbar überflüssiges Plugin deaktivierst und die Umsätze deutlich einbrechen.

Safari ist strenger, als die meisten Konfigurationen erwarten

Safari begrenzt die Gültigkeitsdauer von Cookies auf 7 Tage. Wenn ein Safari-Besucher nicht innerhalb einer Woche zurückkommt, wird er als völlig neuer Nutzer behandelt, ohne dass Informationen darüber vorliegen, woher er gekommen ist. Das gilt für jeden Browser auf dem iPhone, einschließlich Chrome und Firefox, da Apple vorschreibt, dass diese die Safari-Engine nutzen müssen.

Normalerweise heißt es, dass server-side Tracking dieses Problem löst, da Daten, die von deinem eigenen Server gesetzt werden, länger bestehen bleiben als solche, die im Browser gesetzt werden. Das war früher die ganze Geschichte.

Seit 2023 führt Safari eine weitere Überprüfung durch. Wenn dein Tracking-Server auf einem anderen Hosting-Anbieter läuft als dein Shop, behandelt Safari ihn als extern und wendet trotzdem die gleiche Sieben-Tage-Frist an. Das ist ein häufiges Problem bei Online-Shops. Wenn dein Shop zum Beispiel auf einem WordPress-Host läuft und dein Tracking-Server auf Google Cloud, sehen die beiden nicht so aus, als gehörten sie zusammen.

So überprüfst du das: Gib in Safari eine Testbestellung auf und schau dir dann das Tracking-Cookie an, das dein Server setzt. Wenn es nach sieben Tagen abläuft statt nach dem von dir konfigurierten Zeitraum, bist du betroffen.

Was du tun kannst: Entweder hostest du deinen Tracking-Server zusammen mit deinem Shop, damit beide aufeinander abgestimmt sind, oder du nutzt eine speziell dafür entwickelte Wiederherstellungsfunktion. TAGGRS Cookie Recovery stellt Daten wieder her, die von Safari und iOS gelöscht werden. Dazu muss das „Enhanced Tracking Script“ aktiviert sein.

Werbeblocker sind die andere Hälfte des Problems. Selbst wenn Daten an deine eigene Webadresse gesendet werden, kann die Adresse selbst immer noch offensichtliche Tracking-Begriffe enthalten, die von den Blockern erkannt werden. Server-side Tracking kann nichts verarbeiten, was bereits gestoppt wurde, bevor es den Browser verlassen hat.

Server-Side GTM-Architektur für WooCommerce

Die Strecke der Veranstaltung sieht so aus:

WooCommerce-Shop → Data Layer → Web-GTM → Server-GTM → Analyse- und Werbeplattformen

Jedes Teil hat eine Aufgabe:

1. Der Shop protokolliert den gesamten Vorgang – von der Produktansicht bis zur abgeschlossenen Bestellung.
2. Die Datenschicht erfasst dies anhand eines GA4-Events und der entsprechenden Produkt- oder Bestelldetails.
3. Web GTM erfasst die Daten, wendet die Einwilligung an und sendet sie an die URL des Server-Containers.
4. Server GTM verarbeitet die Daten, bevor sie an GA4, Google Ads, Meta oder einen anderen Empfänger gesendet werden.

Die Datenschicht ist die Übersetzungsschicht zwischen WooCommerce und GTM. Ohne sie kann jede Änderung am Theme oder Plugin zu einem eigenen JavaScript-Projekt werden. Ein Plugin, das dem GA4-E-Commerce-Event-Modell folgt, bietet eine stabilere Grundlage.

Bevor du loslegst

Bevor du das server-side Tracking in WordPress einrichtest, solltest du folgende Dinge bereithalten:

• Administratorzugriff auf WordPress und WooCommerce
• Ein Google Tag Manager-Webcontainer
• Ein Google Tag Manager-Servercontainer und Hosting
• Eine First-Party-Tagging-URL, wie zum Beispiel https://sending.example.com
• Eine GA4-Property und ein Web-Datenstrom
• Zugriff auf die entsprechenden Google Ads- und Meta-Konten
• Ein CMP, das Einwilligungsentscheidungen an GTM weiterleiten kann
• Ein Testshop oder eine andere sichere Möglichkeit, Testbestellungen aufzugeben
• Eine Liste von Plugins, die bereits Pixel, GTM oder E-Commerce-Events hinzufügen

Eine Datenebene sollte für das E-Commerce-Event zuständig sein, und für jedes Plattformziel sollte ein Tag zuständig sein. Notier dir diese Zuständigkeiten, bevor du irgendetwas änderst. Diese kurze Bestandsaufnahme deckt jede Menge Probleme auf.

So richtest du das server-side Tracking in WooCommerce ein

Da sich Hosting-Seiten und Plugin-Einstellungen ändern können, konzentrieren sich diese Schritte auf den Pfad der Ereignisse und die wichtigen Überprüfungen.

1. Den GTM-Container auf dem Server einrichten

Stelle den Server-Container bereit und verbinde ihn mit einer First-Party-Tagging-URL, zum Beispiel sending.example.com. Vermeide offensichtliche Tracking-Begriffe wie „metrics“, „analytics“ oder „data“ in der Subdomain. Filterlisten von Werbeblockern können sowohl erkennbare Domainnamen als auch Anfragepfade ins Visier nehmen.

Nutze die Anleitung zur Einrichtung benutzerdefinierter Subdomains, um die Domain zu konfigurieren und zu überprüfen. Füge die Produktions-URL in den Einstellungen des Server-Containers hinzu und überprüfe deren Status, bevor du den Shop-Traffic weiterleitest. Der Server-Container sollte außerdem in der GTM-Vorschau korrekt geöffnet werden.

2. Füge eine WooCommerce-Datenebene für GA4 hinzu

Installiere eine Datenebenen-Integration, die die verwendeten Storefront- und Checkout-Typen unterstützt. Sie sollte Standard-E-Commerce-Events mit einem Artikel-Array und einheitlichen Produktkennungen übermitteln.

Teste zumindest Folgendes:

• view_item_list und view_item
• add_to_cart und remove_from_cart
• view_cart und begin_checkout
• purchase

Überprüfe beim Kauf die Daten zu „transaction_id“, „value“, „currency“ und „item“. Google verlangt für jede Bestellung eine eindeutige ID. Verwende die WooCommerce-Bestellnummer – GA4 nutzt sie, um doppelte Bestellungen zu erkennen und spätere Rückerstattungen abzuwickeln.

Drei Grenzen solltest du kennen:

• Das funktioniert nur bei Website-Daten – bei App-Daten klappt es nicht.
• Es werden nur Duplikate desselben Besuchers erfasst, daher wird dieselbe Bestellnummer, die von zwei verschiedenen Personen eingeht, zweimal gezählt.
• Wenn das Feld leer bleibt, behandelt GA4 jede dieser Bestellungen als identisch und fasst sie zu einer zusammen, was deinen Tagesumsatz zunichte machen kann, ohne dass irgendwo ein Fehler angezeigt wird.

Betrachte das als Sicherheitsnetz. Wenn das Aktualisieren deiner Bestätigungsseite einen zweiten Kauf auslösen kann, behebe das Problem lieber, anstatt dich darauf zu verlassen, dass GA4 das in Ordnung bringt.

3. GA4 über server-side GTM weiterleiten

Konfiguriere im Web-Container das Google-Tag mit dem Parameter „server_container_url“. Sein Wert ist die First-Party-URL, die mit dem Server-Container verknüpft ist.

Event-Tags sollten denselben Route nutzen. Stell im Server-Container sicher, dass der GA4-Client die Anfrage annimmt, und leite sie dann an die richtige Property weiter.

4. Google Ads und Meta konfigurieren

Erstelle für Google Ads das erforderliche server-side Conversion-Tag und ordne den Kaufwert, die Währung und die Transaktions-ID zu. Entferne oder deaktiviere eine ältere Browser-Conversion für dieselbe Aktion, es sei denn, die Konfiguration sieht eine gezielte Maßnahme vor, um doppelte Meldungen zu verhindern.

Meta nutzt in der Regel ein Dual-Signal-Setup: das Meta-Pixel im Browser und die Conversions API (CAPI) auf dem Server. Beide Aufzeichnungen derselben Aktion müssen denselben Ereignisnamen und dieselbe Ereignis-ID haben. Im Browser-Pixel wird der Parameter als „eventID“ geschrieben; beim Server-Ereignis lautet er „event_id“. Meta nutzt dieses Paar, um Duplikate zu erkennen.

Dahinter stecken zwei zeitliche Regeln. Meta gleicht die beiden Kopien nur ab, wenn sie innerhalb von 48 Stunden nacheinander eintreffen. Jede Konfiguration, bei der Serverdaten in zeitversetzten Stapeln gesendet werden, führt also zu einer Doppelzählung. Wenn beide Kopien ungefähr zur gleichen Zeit eintreffen – was normal ist –, behält Meta die Browserversion bei.

Das kannst du überprüfen, ohne raten zu müssen. Im Meta Events Manager wird eine korrekt zugeordnete Bestellung als ein Event aus zwei Quellen angezeigt. Wenn dort ein Event aus einer Quelle angezeigt wird oder sich deine Verkaufszahlen in etwa verdoppelt haben, stimmen der Ereignisname oder die ID nicht überein.

Erzeuge die ID einmal und übertrage sie dann in die Datenschicht und in beide Tags. Ein neuer Zufallswert, der separat in jedem Tag generiert wird, sorgt nicht für eine Duplikatsbereinigung.

E-Mail oder Telefon können die Zuordnung verbessern, wenn das Geschäft die Daten erfasst hat und die Einwilligung deren Nutzung erlaubt. Befolge die Normalisierungs- und Hash-Anforderungen der jeweiligen Plattform. Lass Kundendaten nicht länger als nötig in einer öffentlichen Datenebene liegen.

5. Die Einwilligung an die gesamte Route weiterleiten

Server-side Tracking ersetzt die Einwilligung nicht. Das CMP sollte die entsprechenden GTM-Einwilligungsstatus festlegen, bevor Tags Werbe- oder Analysedaten verarbeiten.

Bei Google können zu diesen Zuständen „analytics_storage“, „ad_storage“, „ad_user_data“ und „ad_personalization“ gehören. Andere Plattformen benötigen Steuerungsmöglichkeiten auf Tag-Ebene, die auf derselben Entscheidung des Besuchers basieren. Überprüfe beide Container, anstatt davon auszugehen, dass das Server-Tag das richtige Verhalten übernommen hat.

6. Testet den gesamten Kaufprozess

Führe die GTM-Vorschau für beide Container durch. Teste das Hinzufügen zum Warenkorb per AJAX, den Gast-Checkout, die wichtigsten Zahlungsmethoden sowie die Layouts für Mobilgeräte und Desktop-PCs.

Überprüfe bei einem Kauf Folgendes:

• Die Datenschicht enthält ein Kaufereignis mit den korrekten Bestelldetails
• Web GTM sendet die Anfrage an die First-Party-Server-URL
• The server client receives and parses the event
• GA4- und Google Ads-Tags werden mit übereinstimmendem Wert und derselben Währung ausgelöst
• Meta empfängt Browser- und Server-Events mit demselben Namen und derselben Ereignis-ID
• Der Befehl erscheint jeweils einmal in der Test- oder Debug-Ansicht der jeweiligen Plattform

Die Vorschau zeigt, dass eine Anfrage gesendet wurde, nicht aber, dass die Bestellungen der letzten Woche korrekt sind. Vergleiche nach dem Start die WooCommerce-Bestellungen anhand der Transaktions-IDs mit den Käufen auf der Plattform.

WooCommerce-Fallstricke, die du vor dem Start überprüfen solltest

Aktualisierungen bei der Block-Kasse

Teste den Trichter erneut, nachdem du zwischen dem klassischen Checkout und den Checkout-Blöcken gewechselt hast. Mach dasselbe, nachdem du ein Checkout-Plugin oder eine Zahlungsintegration ausgetauscht hast. Die sichtbare Seite kann fast identisch aussehen, während sich die darunter liegenden events geändert haben.

Cache auf den Seiten „Warenkorb“, „Kasse“ und „Konto“

WooCommerce empfiehlt, die Seiten „Warenkorb“, „Kasse“ und „Konto“ vom Vollseiten-Caching auszuschließen, da sie für jeden Besucher spezifische Inhalte enthalten. Füge dieser Liste zu Tracking-Zwecken auch die Bestellbestätigungsseite hinzu. Eine zwischengespeicherte Seite kann veraltete Werte anzeigen oder das Laden der Bestelldetails gänzlich verhindern, was dazu führt, dass das Kaufereignis mit fehlenden oder falschen Daten ausgelöst wird.

Native Pixel duplizieren

WooCommerce-Erweiterungen laden möglicherweise Google-, Meta- oder TikTok-Tags ohne GTM. Behalte sie nur, wenn sie Teil des gewählten Designs sind. Andernfalls deaktiviere sie vorübergehend und überprüfe anhand des Netzwerkprotokolls des Browsers, ob nur noch die beabsichtigten Anfragen übrig bleiben.

Zeitpunkt für die E-Mail an Gäste

Beim Bezahlvorgang als Gast kann die E-Mail-Adresse später erscheinen als die Warenkorbdaten. Ordne sie den Events zu, bei denen das Feld tatsächlich vorhanden ist – in der Regel beim Bezahlvorgang oder beim Kauf. Übertrage niemals einen Wert, der möglicherweise zu einem anderen Käufer gehört.

Steuern, Versand und Währung

Lege fest, was ein Wert bedeutet, und verwende diese Definition überall. Wenn ein Tag einen Gesamtbetrag inklusive Mehrwertsteuer übermittelt, während ein anderer die Mehrwertsteuer ausklammert, entsteht eine Lücke in der Berichterstattung – selbst wenn beide dieselbe Bestellung erfassen.

Shops mit mehreren Währungen erfordern eine zusätzliche Überprüfung. Der Währungscode, die Artikelpreise und der Bestellwert müssen sich auf dieselbe Transaktionswährung beziehen und dürfen keine Mischung aus der Basiswährung des Shops und der dem Kunden angezeigten Währung sein.

Weiterleitungen, Neuladungen und fehlgeschlagene Zahlungen

Teste alle wichtigen Zahlungsgateways, nicht nur die Standard-Kartenoption. Das Kaufevent sollte eine abgeschlossene Bestellung darstellen. Aufladungen dürfen keine zweite Konversion auslösen, und eine fehlgeschlagene Zahlung sollte nicht wie ein Verkauf aussehen.

Rückerstattungen und Stornierungen

Dein Kaufereignis meldet die Bestellung so, wie sie aufgegeben wurde. Es wird nicht aktualisiert, wenn der Kunde die Hälfte davon zurückschickt, sodass Google und Meta weiterhin auf der Grundlage des ursprünglichen Betrags optimieren. In einem Shop mit hohen Rücklaufquoten ist diese Diskrepanz groß genug, um zu beeinflussen, welche Kampagnen als profitabel erscheinen.

Jede Plattform handhabt das anders. GA4 nutzt dafür ein Rückerstattungs-Event. Du übermittelst die Bestellnummer, und GA4 sucht den passenden Kauf, von dem der Wert abgezogen werden soll. Wenn die Bestellnummern nicht übereinstimmen, wird die Rückerstattung ignoriert und der Verkauf bleibt in deinen Berichten mit dem vollen Wert stehen. Google Ads nutzt Conversion-Anpassungen, die den Verkauf entweder entfernen oder seinen Wert ändern. Meta korrigiert dies über die Conversions-API anhand der Bestellnummer.

Lege vor dem Start fest, was als Verkauf gilt. Schreib es auf und sorge dafür, dass auf jeder Plattform dieselbe Regel gilt.

Häufige Probleme und wo man nachsehen sollte

Was du gerade siehst	Die wahrscheinlichste Ursache	Wo du nachsehen kannst
Die Einnahmen bei GA4 sind ungefähr doppelt so hoch wie bei WooCommerce	Zwei Dinge, die den Verkauf auslösen: meist ein Plugin und deine Tag-Einstellungen	Gib eine Testbestellung auf und zähle, wie viele Kauf-Events angezeigt werden
Meta meldet etwa doppelt so hohe Umsätze	The two instances of the event are not being matched	Der „Events Manager“ sollte ein Ereignis aus zwei Quellen anzeigen
Die GA4-Umsätze liegen durchweg etwa 10 % unter denen von WooCommerce	Steuern oder Versandkosten sind an der einen Stelle enthalten, an der anderen aber nicht	Den Wert einer Bestellung mit dem Gesamtbetrag in WooCommerce vergleichen
„In den Warenkorb“ zeigt immer dasselbe Produkt an	Das Tag liest die Seite statt das Ereignis aus	Überprüfe die Datenebene auf einer Kategorieseite
Umsatz, der nur bei einer Zahlungsmethode fehlt	Der Kunde ist vom Zahlungsanbieter nie zurückgekommen	WooCommerce-Bestellungen nach Zahlungsart filtern und vergleichen
Safari-Besucher werden immer als neu angezeigt	Die Sieben-Tage-Frist von Safari wird angewendet	Überprüfe die Gültigkeitsdauer des Cookies nach einer Testbestellung in Safari
Beim Aktualisieren wird der Kaufvorgang erneut ausgelöst	Das Tag ist an die Seite gebunden und nicht an die Bestellung	Lade die Bestätigungsseite neu und schau zu
Der Server empfängt überhaupt nichts	Die Serveradresse fehlt oder die Domain ist noch nicht online	Rege im Browser auf der Registerkarte „Netzwerk“ nach Anfragen an deine Tracking-Domain
Nach einem Update der Website sind die Verkaufszahlen plötzlich eingebrochen	Der Typ des Checkouts wurde geändert oder ein Theme-Update hat die Seite verändert	Teste den gesamten Ablauf noch einmal

Dual-Signal oder nur Server?

„server-side“ heißt nicht automatisch „ohne Browser“. Das richtige Modell hängt vom Ziel ab.

Meta und TikTok empfehlen, Browser- und Serversignale gemeinsam zu nutzen, wobei übereinstimmende IDs zur Duplikatsbereinigung verwendet werden. Google Ads bietet zwei Optionen, die unterschiedlich funktionieren. Du kannst eine Conversion aus GA4 importieren, wobei GA4 die Messung durchführt und Google Ads das Ergebnis übernimmt. Du kannst die Conversion aber auch direkt aus deinem Server-Container senden.

Die zweite Option hängt davon ab, dass die Google Ads-Klick-ID über den gesamten Weg erhalten bleibt. Wenn ein Zahlungsanbieter sie auf dem Rückweg aus der Webadresse entfernt, hat Google Ads keine Grundlage mehr, um den Verkauf zuzuordnen. Wähle pro Conversion eine Option aus und deaktiviere die andere, denn wenn du beide Optionen ohne einen Plan zum Abgleich laufen lässt, werden deine gemeldeten Umsätze aufgebläht und das automatische Bidding verwirrt.

Tools zur Kundenbindung, die keine geeignete Dublettenbereinigung bieten, erfordern möglicherweise eine reine Server-Lösung.

Nutze den server-side GTM-Plattform-Checker, um die aktuelle Platzierung für jedes Ziel zu überprüfen. Kopiere das Muster einer Plattform nicht einfach auf eine andere. Die APIs und die Regeln zur Duplikatsbereinigung unterscheiden sich.

Wo TAGGRS passt

Für die Einrichtung werden zwei Komponenten benötigt, die in einer Standard-WooCommerce-Installation nicht enthalten sind: ein zuverlässiger GA4-Datenlayer und ein Ort, an dem der GTM-Container auf dem Server ausgeführt werden kann.

TAGGRS bietet verwaltetes server-side GTM-Hosting und eine First-Party-Tagging-URL. Die Dokumentation zum WooCommerce-Data-Layer-Plugin behandelt die Installation, die Web-GTM-Container-ID, unterstützte GA4-E-Commerce-Events und den Debug-Modus.

Das Plugin unterstützt außerdem das optionale TAGGRS Enhanced Tracking Script (ETS) v3, das die gesamte Anfrage vom Browser zum Server verschlüsselt, sodass Filterlisten keine Übereinstimmungen mit gängigen Tracking-Markern finden können. Die Einwilligungsregeln gelten weiterhin, und kein Skript kann eine Interaktion weiterleiten, die der Shop nie erfasst hat.

Für Shops, die von einer anderen Plattform umsteigen, folgt der Leitfaden zum server-side Tracking bei Shopify dem gleichen Prinzip, nur mit einem anderen CMS. Shopify hat sein eigenes Pixel und sein eigenes Checkout-Modell. Bei WooCommerce muss man sich mehr mit Blöcken, WordPress-Plugins, Caching und Zahlungsgateways beschäftigen.

Fazit

Ein Tag auf der Dankesseite ist eine unsichere Grundlage für die Umsatzauswertung. Es passiert einfach zu viel, bevor der Käufer dort ankommt, und WordPress gibt jedem Plugin die Möglichkeit, sich einzumischen.

Ein WooCommerce-Datenlayer und server-side GTM sorgen für eine klarere Abgrenzung. WooCommerce beschreibt das Ereignis einmal, Web-GTM leitet es mit dem richtigen Einwilligungsstatus weiter, und der Server-Container übernimmt die Bereitstellung auf der Plattform. Die Einrichtung muss noch sorgfältig getestet werden. Zumindest werden die Fehler nun in einer einzigen Pipeline sichtbar, anstatt sich in einem Haufen von Pixeln zu verstecken.

Möchtest du das server-side Tracking in deiner WooCommerce-Installation ausprobieren? Erstelle ein kostenloses TAGGRS-Konto oder buche eine Demo , um deine konkreten Tracking-Anforderungen zu besprechen.

FAQ

Brauche ich Web-GTM noch?

Ja. Interaktionen im Shop beginnen im Browser. Web GTM erfasst sie und leitet sie an den Server weiter. Um Backend-Bestellevents direkt zu senden, ist eine separate individuelle Lösung erforderlich.

Kann server-side Tracking jeden Werbeblocker umgehen?

Nein, es umgeht vielleicht nicht jeden Werbeblocker. Die Filterlisten der Werbeblocker werden ständig aktualisiert, daher kann alles, was heute noch funktioniert, nächsten Monat schon nicht mehr funktionieren.

Was du tun kannst, ist, dein Tracking schwerer erkennbar zu machen. Bei einer Standardkonfiguration werden Daten an Webadressen gesendet, die offensichtliche Tracking-Begriffe enthalten, nach denen Blocker suchen. Das „TAGGRS Enhanced Tracking Script v3“ entfernt diese Muster, sodass es nichts Offensichtliches gibt, das abgeglichen werden könnte. Bei TAGGRS liegt unsere typische Wiedergewinnungsrate zwischen 9,1 % und ca. 30 %.

Zwei Einschränkungen bleiben bestehen. Die Einwilligungsregeln gelten weiterhin; wenn ein Besucher also das Tracking ablehnt, sollte das Event gar nicht erst gesendet werden. Zweitens schützt das Skript Daten nur auf ihrem Weg vom Browser zu deinem Server. Wenn dein Setup den Verkauf von vornherein gar nicht erfasst hat, können die Daten auch nicht erfasst werden. Deshalb ist die Datenebene wichtiger als jedes Skript, das du darüber legst.

Sollte Meta Pixel bei Meta CAPI aktiviert bleiben?

Meta empfiehlt, Browser- und Server-Signale gemeinsam zu nutzen, sofern beide korrekt implementiert werden können. Die Namen der Events und IDs müssen übereinstimmen, damit Meta die Aktion nur einmal zählen kann.

Ist das server-side Tracking bei WooCommerce dasselbe wie das server-side Tracking bei Shopify?

Der Aufbau ist derselbe: Commerce-Event, Datenschicht, Web-GTM, Server-GTM, Ziel. WooCommerce bietet mehr Varianten bei den Checkout-Typen, beim Caching und bei den Plugins, daher ist das Testen in der Regel aufwendiger.