Version 1.4.2 benötigt wegen der mitgelieferten HTTP-Bibliotheken mindestens PHP 7.2.5; die PHP-Version muss auch die Anforderungen Ihrer PrestaShop-Version erfüllen. Serverseitige Käufe und Erstattungen erfordern zusätzlich aktives PD Cookie Pro im Live-Modus mit Consent Mode v2, eine passende Einwilligungsrevision, die Analytics-Einwilligung und gespeicherte Client-/Sitzungsdaten zur Attribution. Ein API Secret allein reicht nicht aus.
Serverseitige purchase werden bei kostenpflichtiger Geschenkverpackung, mehr als 200 Bestellpositionen oder fehlender Referenz/EAN im gewählten item_id-Format nicht gesendet. Gutschriften müssen konsistente Beträge und Positionen haben; Datensätze mit partial != 0 und Gutscheinarten werden abgelehnt. Typ 2 wird nur für eine eindeutige Erstattung ausschließlich der Versandkosten unterstützt. Eine teilweise Erstattung von Produktmengen ist nicht dasselbe wie das technische partial-Flag.
Wichtigste Merkmale und Funktionen
- 15 benannte E-Commerce- und Kontoereignisse:
view_item, view_item_list, select_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, refund, search, view_search_results, sign_up und login.
- Optionales
page_view: Der Administrator kann die automatische Seitenaufrufmessung im Modul belassen oder deaktivieren, wenn die Seitenaufrufe über Google Tag Manager oder eine andere Lösung erfasst werden.
- Kauf nach konfiguriertem Status: Version 1.4.2 sendet purchase serverseitig, nachdem der vom Administrator als Zahlungsbestätigung gewählte Status in der Bestellhistorie gespeichert wurde und die übrigen Bedingungen erfüllt sind. Das Modul prüft die Abrechnung beim Zahlungsanbieter nicht selbstständig.
- Measurement Protocol für Finanzvorgänge: Für das Senden von
purchase und refund werden benötigt: die primäre Measurement ID, API Secret, gespeicherte Attributions-/Sitzungsdaten sowie die aktuelle Analyse-Einwilligung.
- Kontrollierte Rückerstattungen: Das Modul unterstützt die vollständige Rückerstattung nach einem ausgewählten Status sowie die neuen PrestaShop-Korrekturen, einschließlich Teilkorrekturen, ausschließlich dann, wenn zuvor ein qualifizierender Kauf registriert wurde.
- Protokoll der Finanzereignisse: ein dauerhaftes Register und eine Sperre je Bestellung kontrollieren die eigenen Käufe und Erstattungen des Moduls; im Backoffice steht eine schreibgeschützte Ansicht mit Filtern, Sortierung und Seitennavigation bereit. Unabhängig von GTM oder anderen Modulen gesendete Ereignisse werden dadurch nicht dedupliziert.
- Zwei Measurement-ID-Kennungen: Es können die primäre sowie optional eine zweite GA4-ID für Ereignisse konfiguriert werden, die über das Tag im Browser gesendet werden.
- Fünf Methoden zum Aufbau von
item_id: Produkt-ID, Produkt-ID mit Kombinations-ID durch Bindestrich getrennt, Produkt-ID mit Kombinations-ID durch Unterstrich getrennt, Referenz oder EAN.
- Katalogdaten bei Ereignissen: Das Modul übermittelt u. a. Kennung, Name, Variante, Marke, Kategorien, Preis, Rabatt, Menge, Währung sowie Daten der Produktliste, sofern diese in PrestaShop verfügbar sind.
- Rabattcoupons: unterstützte Browserereignisse können Name und Code der angewandten Warenkorbregel enthalten. In Version 1.4.2 enthält die per Measurement Protocol gesendete serverseitige purchase-Payload keine Couponcodes.
- User ID für angemeldete Kunden: Nach Aktivierung der Option übermittelt das Modul die technische Kundenkennung an GA4 bei Einwilligung
analytics_storage; dies ersetzt keine Kontaktdaten.
- Vom Nutzer bereitgestellte Daten: Nach Aktivierung der Option und bei aktueller Einwilligung
ad_user_data kann das Modul E-Mail sowie verfügbare Telefonnummer oder Adresse in dem von Google geforderten Format übermitteln; identifizierende Daten werden normalisiert und mit SHA-256 gehasht.
- Dynamisches Google-Ads-Remarketing: Nach Aktivierung der Funktion und Angabe der Google-Ads-ID erhält das Tag Produktkennungen, Seitentyp sowie den Warenkorbwert.
- DebugView und Diagnose: der Debug-Modus protokolliert Browserereignisse und setzt deren debug_mode-Flag für GA4 DebugView. Für serverseitige purchase und refund setzt er dieses Flag nicht. Das Panel zeigt den Konfigurationsstatus und den letzten Kauf mit einer HTTP-2xx-Antwort; Finanzereignisse sind im Protokoll und in den GA4-Berichten zu prüfen.
- PrestaShop 1.7.x, 8.x und 9.x: dies ist der von Version 1.4.2 deklarierte Bereich, keine Garantie für jede PHP-Version, jedes Theme oder jeden Checkout. Der Code enthält Abläufe für den Standard-Checkout und ausgewählte One-Page-Checkout-Module; der tatsächliche Bestellablauf Ihres Shops muss geprüft werden.
Welche Verkaufsphasen misst das GA4-Modul für PrestaShop?
| Phase im Shop |
Vom Modul übermittelte Ereignisse |
Datenumfang |
| Listen und Produktseite |
view_item_list, select_item, view_item |
Produkt, Variante, Marke, Kategorien, Preis, Rabatt und Position in der Liste. |
| Warenkorb |
add_to_cart, remove_from_cart, view_cart |
Warenkorbpositionen, Mengen, Werte, Währung und verfügbarer Gutschein. |
| Checkout |
begin_checkout, add_shipping_info, add_payment_info |
Warenkorbzusammensetzung und Informationen, die während des Bestellprozesses ausgewählt werden. |
| Kauf und Rückerstattung |
purchase, refund |
Serverseitiger Snapshot der qualifizierenden Transaktion oder Rückerstattung, gesendet über Measurement Protocol. |
| Suche und Konto |
search, view_search_results, sign_up, login |
Suchbegriff, Suchergebnisse oder das Ereignis der Kontoerstellung und Anmeldung. |
Messung von Käufen und Rückerstattungen über Measurement Protocol
Im aktuellen Finanzmodus betrachtet das Modul weder den Klick auf die Schaltfläche noch die Bestätigungsseite selbst als Zahlungsnachweis. Das Ereignis purchase wird erzeugt, nachdem in der Bestellhistorie einer der ausgewählten Zahlungsstatus gespeichert wurde. Bei einer Rückerstattung prüft das Modul zunächst, ob für diese Bestellung ein früherer Kauf vorhanden ist, der im Protokoll als gesendet gespeichert wurde; anschließend rechnet es ausschließlich den verbleibenden, nicht erstatteten Wert ab. Eine vollständige Rückerstattung kann durch einen ausgewählten Status ausgelöst werden, und die neuen PrestaShop-Korrekturen werden unabhängig davon unterstützt, auch teilweise.
Der Status sent im Protokoll bedeutet eine HTTP-2xx-Antwort, also die Annahme der Anfrage durch den Measurement-Protocol-Endpunkt. Dies ist keine Bestätigung dafür, dass das Ereignis bereits verarbeitet oder in Google-Analytics-Berichten angezeigt wurde. Das Modul stellt nach einer Aktualisierung keine historischen Käufe oder Rückerstattungen wieder her und verfügt über keine automatische Warteschlange, keinen CRON und keine Schaltfläche, um eine unsichere Sendung erneut zu erzwingen.
GA4, Google Ads, Einwilligungen und Nutzerdaten
Das Modul kann das GA4-Tag für eine oder zwei Measurement IDs initialisieren. Für dynamisches Google-Ads-Remarketing ist zusätzlich eine Kennung im Format AW-… erforderlich. Im aktuellen Modus des Kaufs nach Zahlungsstatus werden die Ereignisse purchase und refund über Measurement Protocol an GA4 übermittelt; das Modul sendet in diesem Modus keine direkte browserseitige Kaufkonversion an Google Ads.
Die Option für vom Nutzer bereitgestellte Daten erfordert ein aktives PD Cookie Pro mit Consent Mode v2 und die aktuelle Einwilligung ad_user_data. Zusätzlich muss der Shopinhaber die Erfassung solcher Daten im GA4-Dienst sowie in den Einstellungen des Google-Tags aktivieren; die Konfiguration erweiterter Conversions in Google Ads ist eine separate Aufgabe auf Seiten des Google-Kontos. Der Widerruf der Einwilligung entfernt identifizierende Daten aus der Tag-Konfiguration, und der serverseitige Versand von Finanzvorgängen prüft die aktuelle Einwilligung vor dem Versand erneut. User ID und vom Nutzer bereitgestellte Daten benötigen ebenfalls aktives PD Cookie Pro im Live-Modus, Consent Mode v2 und die aktuelle Einwilligungsrevision. Der Widerruf von analytics_storage setzt User ID im Tag zurück; der Widerruf von ad_user_data setzt user_data zurück. Bereits an Google übermittelte Daten werden dadurch nicht gelöscht.
Konfiguration und Überprüfung der Implementierung
- Geben Sie die primäre GA4 Measurement ID ein und die zweite Kennung nur dann, wenn sie benötigt wird.
- Geben Sie für Käufe und Rückerstattungen das Measurement Protocol API Secret an und wählen Sie die Status aus, die in dem jeweiligen Shop tatsächlich die Bezahlung und die vollständige Rückerstattung der Bestellung bestätigen.
- Wählen Sie das Format von
item_id passend zur im Katalog oder Produktfeed verwendeten Kennung.
- Aktivieren Sie nur die benötigten Funktionen für Google Ads, User ID und vom Nutzer bereitgestellte Daten, nachdem Sie die Einstellungen und Einwilligungen in den Google-Tools geprüft haben.
- Verwenden Sie zum Testen den Debug-Modus und GA4 DebugView, und prüfen Sie für Finanzvorgänge das Modulprotokoll. Der Test sollte auf dem tatsächlichen Kaufpfad und mit dem richtigen Bestellstatus durchgeführt werden.
Umfang des Moduls und wichtige Einschränkungen
- Das Modul übermittelt Daten an die konfigurierten Google-Dienste; es erstellt oder verwaltet kein GA4-, Google-Ads-, Merchant-Center-Konto oder Werbekampagnen.
- Es ersetzt weder die Konfiguration von Einwilligungen noch die rechtliche Analyse des Shops. Der Shopinhaber ist für die Rechtsgrundlage der Datenverarbeitung, den Inhalt der Einwilligungen und die Einstellungen der Google-Konten verantwortlich.
- Das Blockieren von Skripten, fehlende Einwilligung, fehlende gespeicherte Attribution, fehlerhafte Kennungen oder Google-Einstellungen können die Messung einschränken. Das Modul gibt keine Garantie für die Vollständigkeit der Daten.
- Das Senden von Daten mit API Secret erfordert eine korrekte GA4-Konfiguration. Eine HTTP-2xx-Antwort ist als Bestätigung des Anfrageeingangs zu verstehen und nicht als Nachweis der Sichtbarkeit der Transaktion in den Berichten.
