Der Container, der Data Layer und die Verkäufe, die Analytics verlor

Vierzehn Events, und woher jedes kommt

Jedes Event wird serverseitig aus dem gebaut, was der Shop wirklich hat: Preise mit oder ohne Steuer, wie Sie wollen, das Attribut, das Sie als Produktcode nutzen, die Produktkategorien. Nichts wird aus der Seite gelesen, ein Themenwechsel kann es also nicht kaputt machen.

Der Container, schon fertig

Ein Data Layer, den niemand liest, sieht wie ein kaputtes Modul aus: solange der Container kein Tag hat, das ihn liest, kommt in Analytics nichts an. Darum lädt ein Knopf in der Konfiguration eine Datei zum Import in Google Tag Manager herunter, mit dem GA4-Konfigurationstag, dem Tag, das die E-Commerce-Events weiterleitet, der Google-Ads-Kaufconversion mit echtem Umsatz und Bestellnummer, dem Conversion Linker und den nötigen Variablen. Sie importieren mit Merge, sehen die Vorschau und veröffentlichen. Die Alternative sind etwa dreißig Objekte von Hand.

Die Käufe, die Analytics nie gesehen hat

Etwa jeder fünfte Kauf erreicht Analytics nie: ein Werbeblocker, ein fehlgeschlagenes Skript, ein Kunde, der die Seite zu früh schließt. Das sind Verkäufe, die Sie gemacht haben und nicht sehen, und Google optimiert Ihre Kampagnen ohne sie. Mit den Shopping-Events sendet der Shop den Kauf selbst, wenn der Browser es nicht getan hat, und zwar mit der Kennung, die dieser Kunde damals hatte: so landet der Verkauf auf dem Besuch und die Anzeige, die ihn gebracht hat, bekommt die Anerkennung. Ein Feld in der Konfiguration zählt sie: Bestellungen, die vom Browser bestätigten, die vom Shop zurückgeholten. Und wer sich der Messung verweigert hat, wird nie zurückgeholt.

In einem Shop, den wir selbst betreuen: 27 echte Bestellungen in dreißig Tagen, 21 Käufe in Analytics. Sechs Verkäufe, unsichtbar für die Kampagnen, die sie bezahlt hatten.

Consent Mode v2, an der richtigen Stelle

In Europa ist ein deklarierter Einwilligungsstatus die Voraussetzung dafür, dass Google die nicht beobachteten Conversions modellieren kann: ohne ihn sind diese Daten einfach verloren. Das Modul deklariert alles abgelehnt, bevor der Container startet — was nur wer den Container lädt kann — und dann entscheiden Sie: entweder erteilt es die Einwilligung über den Cookie-Hinweis von Magento, oder es wartet, bis Ihre Einwilligungs-Erweiterung eine öffentliche Funktion aufruft. Eine Zeile in der Konfiguration sagt, was wirklich passiert, und wird rot, wenn die Einstellung nicht funktionieren kann.

Was Sie bekommen

• Hyvä und Luma, der Standard-Checkout und die mit eigener Route: die Versand- und Zahlungsevents entstehen in Magento selbst, nicht an den Buttons.
• Ein Schalter pro Event und Store View: Sie senden, was Sie messen wollen, und nichts anderes.
• Preise mit oder ohne Steuer, Versand im Kaufwert oder nicht, das Attribut, das Sie als Produktcode und als Marke nutzen.
• Benutzerdefinierte Dimensionen: ein Produktattribut wird zum Parameter in jedem Artikel jedes Events.
• IP-Adressen, die Sie nicht messen wollen, von Hand eingegebene Bestellungen ausgenommen, und nur die Bestellstatus, die wirklich als Verkauf zählen.
• Wenn Sie eine andere Erweiterung ersetzen: die Event-Namen sind die von GA4 dokumentierten, und die eindeutige Event-ID kann auch unter dem Namen reisen, den Ihr Container schon erwartet — am Umstellungstag ändern Sie darin nichts.

Verwaltung in Ihrer Sprache

Jedes Feld und jede Erläuterung der Konfiguration ist übersetzt, auch die, die sagen, was man nicht tun sollte:

Die Sprache der Store View wird automatisch erkannt; Englisch ist der Rückfall.

Voraussetzungen

Magento 2.4.x (Open Source oder Adobe Commerce), PHP 8.1 bis 8.5, Hyvä oder Luma. Ein Google-Tag-Manager-Container, der kostenlos ist. Für die Rückholung verlorener Käufe ein Measurement-Protocol-API-Schlüssel Ihrer eigenen GA4-Property.

Dokumentation

Installation, jedes Feld erklärt, wie man den Container importiert und wie man prüft, dass ein Event wirklich in Analytics ankommt.

→ Vollständige Dokumentation lesen

Changelog

Was sich ändert, Version für Version.