Serverseitiges Tagging für einen Shopify- oder WooCommerce-Shop: was feuert, was nicht, und was zu installieren ist

GA4 definiert sieben Ereignisse für einen Kauftrichter: view_item_list, view_item, add_to_cart, remove_from_cart, begin_checkout, add_payment_info und purchase. Die Namen sind die von GA4, nicht die einer Plattform – dieselben sieben funktionieren für Shopify, WooCommerce und einen selbst gebauten Shop.

Gemeinsam ist ihnen der Mechanismus. Jedes ist ein Push in den dataLayer der Seite, unter genau diesem Namen, mit einem ecommerce-Objekt in der GA4-Form. Ein Tag-Manager-Trigger hört auf den Namen; ein GA4-Ereignis-Tag liest das ecommerce-Objekt und sendet es. Vertippen Sie den Namen, verschachteln Sie das Objekt eine Ebene zu tief oder pushen Sie es auf der falschen Seite, sitzt das Tag für immer da – ohne Fehlermeldung. So sieht ein Purchase-Push aus:

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
  event: 'purchase',
  ecommerce: {
    transaction_id: 'ORD-10442',
    value: 89.90,
    currency: 'EUR',
    items: [
      { item_id: 'SKU-118', item_name: 'Trail jacket', price: 89.90, quantity: 1 }
    ]
  }
});

Der Push von ecommerce: null davor ist keine Dekoration. Ohne ihn können die Artikel des vorherigen Ereignisses in das nächste hineinlaufen, und ein view_item von vor drei Seiten taucht in einem purchase auf.

Ein Container, der in einem Shopify-Theme installiert ist, lädt im Storefront – auf Produktseiten, Kollektionen, im Warenkorb. Er lädt nicht im Checkout und nicht auf der Dankeseite, die Shopify von seiner eigenen Domain und mit eigenen Vorlagen ausliefert. Ein im Theme installierter Container kann also view_item und add_to_cart senden und wird nie, unter keiner Konfiguration, begin_checkout, add_payment_info oder purchase senden.

Diese drei kommen aus einem Custom Pixel. Shopifys Pixel-Sandbox stellt Checkout-Ereignisse bereit (checkout_started, payment_info_submitted, checkout_completed) und erlaubt einem Pixel, in einen eigenen dataLayer zu pushen – ein kleines Skript bildet jedes davon auf den GA4-Ereignisnamen und die Form von oben ab. Die Storefront-Ereignisse kommen weiterhin aus dem Theme, also besteht eine vollständige Einrichtung aus beidem: einer dataLayer-App oder einem Theme-Snippet für die Browsing-Hälfte, einem Custom Pixel für die Checkout-Hälfte.

Noch eine Entscheidung. Shopifys Google-&-YouTube-Kanal kann GA4-Ereignisse direkt senden, außerhalb jedes Containers. Verbinden Sie dort eine GA4-Property UND leiten Sie dieselbe Property durch Ihren Container, wird jeder Kauf doppelt gezählt. Wählen Sie einen Weg. Geht es um First-Party-Erfassung, ist der Container der Weg, und die Analytics-Verbindung des Kanals bleibt aus.

WooCommerce selbst schreibt überhaupt keinen dataLayer. Ein Plugin tut es – GTM4WP ist das, zu dem die meisten greifen –, und seine GA4-E-Commerce-Option erzeugt die sieben Ereignisse in der richtigen Form auf den richtigen Seiten: view_item auf einem Produkt, add_to_cart am Button, begin_checkout auf der Checkout-Seite, purchase auf der Bestellbestätigung.

Der klassische WooCommerce-Fehler ist ein doppelter purchase, und er hat eine konkrete Ursache: Die Bestellbestätigungsseite wird neu geladen. Ein Besucher aktualisiert sie, kehrt von einem Zahlungsanbieter dorthin zurück, oder das Theme leitet zweimal über sie um – und purchase wird erneut gepusht, mit derselben transaction_id. GA4 dedupliziert Käufe innerhalb einer Sitzung über die transaction_id, was das meiste abfängt, aber nicht ein Neuladen am nächsten Tag. Die Plugin-Einstellung „nur einmal pro Bestellung feuern“ lohnt sich; sie hält die Markierung serverseitig, wo ein Neuladen sie nicht zurücksetzen kann.

Sagen Sie dem Assistenten, dass die Website ein Shop ist, fügt er Ihrem Web-Container für jedes der sieben Ereignisse einen Custom-Event-Trigger und ein GA4-Ereignis-Tag hinzu – vierzehn Entitäten, alle mit dem Präfix SH benannt, sodass sie nie mit etwas kollidieren, das Sie schon haben. Jedes Tag sendet das ecommerce-Objekt direkt aus dem dataLayer, sodass items, value, currency und transaction_id ohne eine Variable pro Feld durchkommen, und jedes nennt Ihre Mess-ID explizit statt sie zu erben.

In Ihrem Shop wird nichts installiert. Die Trigger hören zu; die Pushes kommen vom Plugin oder vom Pixel. Die Wahl „kein Onlineshop“ lässt die vierzehn Entitäten weg und ändert sonst nichts – Seitenaufrufe, Scroll und die übrigen Standardereignisse laufen so oder so durch den Container.

Auf der Serverseite gibt es nichts pro Ereignis. Das GA4-Tag des Server-Containers leitet jedes empfangene Ereignis weiter, wie auch immer es heißt, sodass ein neues Ereignis auf Ihrer Website keine Änderung auf unserer braucht. Die Ziele Meta Conversions API und TikTok Events API, falls Sie sie verbinden, bilden dieselben sieben Namen selbst ab; aus einem purchase wird ein Purchase für Meta und ein CompletePayment für TikTok, aus demselben Push.

Geben Sie eine echte Bestellung im Testmodus auf, oder eine günstige, die Sie erstatten, und beobachten Sie die Ereignisliste der Container-Seite. Der Reihe nach sollten Sie view_item, add_to_cart, begin_checkout, add_payment_info und purchase sehen – jedes einmal. Ein fehlender purchase auf Shopify bedeutet, dass das Custom Pixel nicht installiert ist oder nicht pusht; ein fehlender begin_checkout auf WooCommerce heißt meist, dass das Checkout-Ereignis des Plugins deaktiviert ist.

Wenn Sie Google-Ads-Conversions durch den Container leiten, ist purchase das Conversion-Ereignis, und Wert, Währung und Transaktions-ID werden aus demselben ecommerce-Objekt gelesen. Ein Purchase-Push ohne value erfasst eine Conversion im Wert von nichts – das ist eine echte Zahl in einem Bericht, und die falsche.