--- type: "product" id: 215 url: "https://prestadev.pl/de/google-analytics-4-pro-modul-fur-prestashop.html" markdown_url: "https://prestadev.pl/de/markdown/product/215.md" title: "Google Analytics 4 Pro Modul für PrestaShop" description: "Implementieren Sie GA4 in PrestaShop: E-Commerce-Ereignisse, Kaufmessung und Google Ads. Nutzen Sie JavaScript-Tracking sowie die Übermittlung von Transaktionen über das Measurement Protocol." image: "https://prestadev.pl/1304/google-analytics-4-pro-modul-fur-prestashop.jpg" sku: "PDGA4P" brand: "PrestaDev.pl" price: 169.00 regular_price: 189.00 discount_percent: 10.58 discount_amount: 20.00 price_tax_excluded: 137.40 currency: "PLN" tax_included: true availability: "in_stock" is_pack: false customization_required: false condition: "new" categories: ["Google-Integrationen", "Index", "PrestaShop-Integrationen", "PrestaShop-Module", "Werbung und Analyse"] language: "de" updated: "2026-10-15" --- # Google Analytics 4 Pro Modul für PrestaShop **Google Analytics 4 Pro** ergänzt PrestaShop um Google-Messung für Produkte, Warenkorb, Checkout, Suche und Kundenkonto. Version 1.4.2 sendet qualifizierte Käufe und Erstattungen per Measurement Protocol an den primären GA4-Datenstream: nötig sind API Secret, gespeicherte Attribution und aktives PD Cookie Pro im Live-Modus mit Consent Mode v2 und Analytics-Einwilligung. Optionen sind eine zweite GA4-ID, User ID, vom Nutzer bereitgestellte Daten und dynamisches Google-Ads-Remarketing. Das Modul konfiguriert keine Google-Konten und garantiert keine vollständigen Berichte. ## Description 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 1. Geben Sie die primäre GA4 Measurement ID ein und die zweite Kennung nur dann, wenn sie benötigt wird. 2. 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. 3. Wählen Sie das Format von `item_id` passend zur im Katalog oder Produktfeed verwendeten Kennung. 4. 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. 5. 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. ## Features | Feature | Value | | --- | --- | | Unterstützung für Prestashop 9.x | Ja | | Unterstützung für Prestashop 8.x | Ja | | Unterstützung für Prestashop 1.7.x | so | | Modulübersetzungen | PL, DE | | Kostenloser Support | so | | Kostenlose Updates (1 Jahr) | so | | Einfache Installation | so | | Erfordert die Modifikation des Motors | nicht | ## Variants | Variant | SKU | Price | Availability | Variant ID | | --- | --- | --- | --- | --- | | Lizenztyp / Aktualisierung: Vollversion / lebenslange Lizenz | ` PDGA4P-FULL ` | 169.00 | ` in_stock ` | ` 598 ` | | Lizenztyp / Aktualisierung: Nur Aktualisierung (Verlängerung des Zugangs um weitere 12 Monate) | ` PDGA4P-UPD ` | 84.50 | ` in_stock ` | ` 599 ` | ## Categories - Google-Integrationen - Index - PrestaShop-Integrationen - PrestaShop-Module - Werbung und Analyse ## Related products - [Google AdWords Modul zur Verfolgung von Verkaufskonversionen Pro für PrestaShop](https://prestadev.pl/de/markdown/product/57.md) - [Google Dynamisches Remarketing Pro für PrestaShop](https://prestadev.pl/de/markdown/product/102.md) - [Google Shopping Pro / Google Shopping für PrestaShop](https://prestadev.pl/de/markdown/product/128.md) - [Google Tag Manager Pro Modul für PrestaShop](https://prestadev.pl/de/markdown/product/329.md) ## Questions and answers ### Wofür dient das Modul Google Analytics 4 Pro für PrestaShop? Language: de Google Analytics 4 Pro fügt dem Shop das Google-Tag hinzu und übermittelt an Google Analytics 4 Ereignisse im Zusammenhang mit Produkten, dem Warenkorb, dem Checkout, der Suche und dem Kundenkonto. Ein separater Teil des Moduls sendet qualifizierende Käufe und unterstützte Rücksendungen über das Measurement Protocol an den Hauptdatenstream von GA4. Das Modul erstellt kein GA4-Konto und verwaltet keine Google Ads-Kampagnen. ### Mit welchen PrestaShop-Versionen ist das Modul kompatibel? Language: de Version 1.4.2 deklariert Kompatibilität mit den PrestaShop-Versionsreihen 1.7.x, 8.x und 9.x. Die mitgelieferten HTTP-Bibliotheken benötigen mindestens PHP 7.2.5; gleichzeitig müssen die PHP-Anforderungen der verwendeten PrestaShop-Version erfüllt sein. Dies bedeutet weder Kompatibilität mit PHP 7.0 oder 7.1 noch eine Bestätigung der gesamten Versionsmatrix. Vor der Einführung müssen der konkrete Shop, das Theme und der Checkout geprüft werden, da andere Module sowie das HTML und JavaScript der Seite die Browserereignisse beeinflussen. ### Welche Daten müssen für die Konfiguration von GA4 vorbereitet werden? Language: de Die Grundlage ist die Haupt-GA4-Measurement-ID im Format G-XXXXXXXX. Für das serverseitige Senden von Käufen und Rückerstattungen müssen das API Secret Measurement Protocol angegeben sowie die Bestellstatus ausgewählt werden, die die Bezahlung und die vollständige Rückerstattung tatsächlich bestätigen. Die Google-Ads-Funktionen erfordern eine separate Kennung AW-XXXXXXXXX, und die Option der vom Nutzer übermittelten Daten erfordert außerdem die richtigen Einstellungen und Einwilligungen auf der Google-Seite. In Version 1.4.2 erfordern serverseitige purchase und refund außerdem ein aktives PD Cookie Pro im Live-Modus mit Consent Mode v2, eine aktuelle Revision der Analyse-Einwilligung und einen beibehaltenen Kundenkontext. ### Wie viele Ereignisse unterstützt das Modul? Language: de Der Modulcode listet 15 benannte E-Commerce- und Kontoereignisse auf: 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. Unabhängig davon kann der automatische page\_view separat aktiviert oder deaktiviert werden. Daher sollten die 15 genannten Ereignisse selbst nicht als „16 E-Commerce-Ereignisse“ bezeichnet werden. ### Welche Ereignisse werden auf Produktlisten und Produktdetailseiten gesendet? Language: de Auf unterstützten Produktlisten sendet das Modul view\_item\_list und nach dem Anklicken des Produkts select\_item. Auf der Produktseite sendet es view\_item, auch nach einer Variantenänderung in der unterstützten Oberfläche. Bei den Ereignissen kann es die Produkt-ID, den Namen, die Variante, die Marke, die Kategorien, den Preis, den Rabatt sowie die Position in der Liste übermitteln. ### Wie misst das Modul Aktivitäten im Warenkorb und im Checkout? Language: de Das Modul unterstützt add\_to\_cart, remove\_from\_cart und view\_cart sowie beim Eintritt in einen unterstützten Bestellprozess begin\_checkout. Die Vorlagen für den Checkout übermitteln außerdem add\_shipping\_info sowie add\_payment\_info. Die Ereignisse enthalten Warenkorbpositionen, Mengen, Preise, Währung und den verfügbaren Gutschein, sofern die Daten in PrestaShop verfügbar sind. ### Misst das Modul die Suche, die Registrierung und die Anmeldung? Language: de Ja. Die Funktionsübersicht des Moduls umfasst die Ereignisse search, view\_search\_results, sign\_up und login. Für die Suche erfasst der Code die Suchanfrage und bereitet die verfügbaren Produktergebnisse auf; die Funktionsweise des jeweiligen Ereignisses sollte in der DebugView des verwendeten Themes überprüft werden. ### Wann sendet das Modul das purchase-Ereignis an GA4? Language: de Ab Version 1.4 wird purchase erst dann vom Server gesendet, nachdem in der Bestellhistorie der in der Konfiguration als die Bezahlung oder den Zahlungseingang bestätigend ausgewählte Status gespeichert wurde. Das bloße Klicken auf die Zahlungsschaltfläche und die bloße Bestätigungsseite gelten nicht als Zahlungsbestätigung. Ein zusätzlicher Versuch auf der Bestätigungsseite kann nur eine nicht gesendete Bestellung verarbeiten, die dieselben Bedingungen erfüllt. ### Welche Voraussetzungen sind für die serverseitige Übermittlung eines Kaufs oder einer Rückgabe erforderlich? Language: de Version 1.4.2 benötigt die primäre Measurement ID, das API Secret, einen ausgewählten Kaufstatus, gespeicherte Attributionsdaten mit client\_id und session\_id sowie eine aktuelle Analytics-Einwilligung. Eine durch einen Status ausgelöste vollständige Erstattung erfordert eine separate Konfiguration der Erstattungsstatus. Der Einwilligungsdatensatz stammt von PD Cookie Pro, das im Shop im Live-Modus mit Consent Mode v2 und aktueller Einwilligungsversion aktiv ist; eine andere CMP erfüllt diese Voraussetzung nicht automatisch. Für Nutzerdaten wird die Einwilligung ad\_user\_data separat geprüft. Der Kauf wird bei kostenpflichtiger Verpackung, mehr als 200 Produktzeilen oder leerer Artikelreferenz/EAN bei einem entsprechenden item\_id-Format nicht gesendet. Auch Beträge und Positionen müssen validiert werden. ### Bedeutet eine HTTP-2xx-Antwort, dass der Kauf bereits in den GA4-Berichten sichtbar ist? Language: de Nein. Im Modulprotokoll bedeutet der Status „sent“, dass der Measurement-Protocol-Endpunkt eine HTTP-2xx-Antwort zurückgegeben hat, also die Anfrage angenommen wurde. Dies ist keine Bestätigung der Verarbeitung des Ereignisses oder seiner Sichtbarkeit in den Google-Analytics-Berichten. Der Empfang muss im entsprechenden Google-Dienst und Datenstream verifiziert werden. ### Garantiert das Measurement Protocol die Messung, wenn der Kunde einen Ad-Blocker verwendet? Language: de Es gibt keine solche Garantie. Das serverseitige Senden des Kaufs erfordert eine zuvor gespeicherte Attribution, einschließlich Sitzungsdaten, sowie eine aktuelle Analyse-Einwilligung. Das Blockieren von Skripten, fehlende Einwilligung, fehlerhafte Konfiguration oder Einschränkungen seitens Google können die Messung verhindern oder einschränken. ### Wie verarbeitet das Modul vollständige Rückerstattungen? Language: de Für eine vollständige Rückerstattung wählt der Administrator separate Status aus, die die Rückerstattung auslösen. Das Modul erfordert einen früheren Kauf, der in seinem Protokoll als sent registriert wurde, sowie einen früheren Zahlungsstatus. Das erneute Setzen desselben Status sendet keine weitere vollständige Rückerstattung, und abgerechnet wird ausschließlich der nach früheren Rückerstattungen verbleibende Wert. ### Unterstützt das Modul teilweise Rückerstattungen und Korrekturen in PrestaShop? Language: de Das Modul unterstützt neue PrestaShop-Gutschriften mit gespeicherten Positionen, die die Voraussetzungen erfüllen, darunter die Erstattung eines Teils der Produktmengen, sofern zuvor ein Kauf als sent gespeichert wurde und ein qualifizierender Kaufstatus vorhanden ist. Dies umfasst nicht jede Gutschrift: Datensätze mit dem technischen Flag partial != 0 und andere Typen als 0 oder 2 werden abgelehnt; Typ 2 wird nur als eindeutige Erstattung ausschließlich der Versandkosten unterstützt. Ebenso werden nicht eindeutig zuordenbare frei festgelegte Beträge und inkonsistente Positionen abgelehnt. Eine Teilerstattung von Mengen ist nicht dasselbe wie das Flag partial. Historische Gutschriften aus der Zeit vor der Aktivierung dieser Funktion werden nicht nachträglich verarbeitet. ### Wird das Modul nach der Installation oder Aktualisierung alte Käufe und Rücksendungen senden? Language: de Es gibt keine automatische Nachverarbeitung der Historie. Die Aktualisierung speichert Grenzwerte für bestehende Bestellungen, Statushistorien und Gutschriften und setzt die vorhandenen Flags für die Ereignisübermittlung nicht zurück. Bei einer älteren Bestellung muss der früheste qualifizierende Eintrag des Kaufstatus neuer als die gespeicherte Grenze der Historie sein; außerdem sind ein erhaltener Warenkorbeintrag mit order\_send=0 und das Fehlen einer früheren Ereignisübermittlung erforderlich. Das bloße erneute Setzen eines Status reicht nicht aus, wenn der frühere qualifizierende Eintrag vor dieser Grenze liegt. ### Wiederholt das Modul automatisch einen fehlgeschlagenen oder unsicheren Versand? Language: de Es gibt keine automatische Warteschlange, keinen CRON und keine Schaltfläche, die einen erneuten Versuch eines finanziellen Vorgangs erzwingt. Ein nicht gesendeter Vorgang im Zustand pending kann beim nächsten geeigneten Auslöser, etwa einem qualifizierenden Status oder der Bestätigungsseite, erneut versucht werden, sofern er alle Voraussetzungen erfüllt. Der Zustand sending nach einer Unterbrechung und unknown bei einem ungewissen Transportergebnis blockieren automatische Wiederholungen, um das Risiko von Duplikaten zu begrenzen. Sie werden nicht wie ein noch nicht gesendeter Vorgang im Zustand pending behandelt. ### Wie verhindert das Modul das doppelte Senden von purchase und refund? Language: de Das Modul kontrolliert seine eigenen finanziellen Vorgänge über ein dauerhaftes Protokoll mit einem einzigen Vorgangsschlüssel und einer Sperre gegen gleichzeitige Verarbeitung derselben Bestellung. Für Kauf und Erstattung werden Beträge, Währung und Positionen gespeichert; Erstattungen sind auf den Wert des zuvor gesendeten Kaufs begrenzt. Ein ungewisser Zustand wird nicht automatisch als nicht gesendet behandelt. Diese Mechanismen entfernen keine Duplikate, die unabhängig durch GTM oder andere Module gesendet werden. ### Kann man zwei Google Analytics 4-IDs eingeben? Language: de Ja. Die Konfiguration enthält die Haupt-Measurement-ID sowie optional eine zweite Measurement-ID. Das Browser-Tag initialisiert beide konfigurierten IDs, was zum Beispiel der parallelen Messung in einem zweiten GA4-Dienst dienen kann. Die serverseitigen purchase- und refund-Ereignisse werden an den Hauptdatenstream gesendet, der für die Attribution verwendet wird. ### Wie kann die Produktkennung item\\\_id konfiguriert werden? Language: de Zur Auswahl stehen: Produkt-ID, Produkt-ID mit durch einen Bindestrich getrennter Kombinations-ID, Produkt-ID mit durch einen Unterstrich getrennter Kombinations-ID, Produktreferenz sowie EAN. Die Variante Referenz oder EAN verwendet den Wert der Kombination, sofern dieser verfügbar ist. Das gewählte Format sollte dem im Katalog oder Produktfeed verwendeten Identifikator entsprechen. ### Übermittelt das Modul Rabattcodes an GA4? Language: de Bei unterstützten Browserereignissen kann das Modul den Namen und den Code der angewendeten Warenkorbregel als Gutscheininformation übermitteln. In Version 1.4.2 enthält das serverseitige purchase, das über Measurement Protocol gesendet wird, weder das Feld coupon noch Gutscheincodes bei den Positionen. Das Modul erstellt keine Rabatte, Warenkorbregeln oder Aktionscodes in PrestaShop. ### Wozu dient die Option Benutzer-ID? Language: de Nach Aktivierung von User ID übermittelt das Modul im Browser die technische Kennung des angemeldeten Kunden und bei serverseitigen Ereignissen die Kennung des Bestellkunden. Version 1.4.2 erfordert die Einwilligung analytics\_storage von PD Cookie Pro, das im jeweiligen Shop im Live-Modus mit Consent Mode v2 und einer übereinstimmenden aktuellen Einwilligungsversion aktiv ist. User ID ist unabhängig von den von Nutzern bereitgestellten Daten, ist kein E-Mail-Hash und ersetzt keine Kontaktdaten. ### Welche Benutzerdaten kann das Modul an das Google-Tag und das Measurement Protocol übermitteln? Language: de Nach Aktivierung der entsprechenden Option kann das Modul die in PrestaShop gespeicherte E-Mail-Adresse sowie optional die Telefonnummer und Adressdaten verwenden. Die korrekte E-Mail-Adresse allein ist ausreichend; Telefonnummer und Adresse sind zusätzliche Daten, sofern sie die Validierungsbedingungen erfüllen. Das Modul liest keine nicht gespeicherten, im Formular eingegebenen Felder und auch keine E-Mail-Adressen aus dem Seiteninhalt aus. ### Werden die den Kunden identifizierenden Daten gehasht? Language: de Ja. E-Mail, Telefon, Vor- und Nachname werden vor der Übermittlung normalisiert und mit SHA-256 gehasht. Für den Versand über das Measurement Protocol wird auch der Hash der Straße unterstützt, und Postleitzahl, Land sowie optional die Stadt haben das von Google geforderte Format. Daten und Hashes werden weder dem Transaktionsprotokoll noch der Modulkonfiguration hinzugefügt. ### Welche Einwilligungen sind für die Weitergabe von Nutzerdaten erforderlich? Language: de Von Nutzern bereitgestellte Daten erfordern die aktuelle Einwilligung ad\_user\_data von PD Cookie Pro, das im jeweiligen Shop im Live-Modus mit Consent Mode v2 und einer übereinstimmenden aktuellen Einwilligungsversion aktiv ist. User ID und der serverseitige Versand über Measurement Protocol erfordern die Einwilligung analytics\_storage. Der Widerruf von analytics\_storage setzt User ID im Tag zurück; der Widerruf von ad\_user\_data setzt user\_data zurück. Dadurch werden bereits an Google übermittelte Daten nicht gelöscht. Vor dem Versand finanzieller Ereignisse liest das Modul den gespeicherten Einwilligungsstatus und dessen Version erneut aus; es stützt sich nicht auf die Cookies des Zahlungs-Callbacks. ### Reicht die Aktivierung der Option im Modul aus, um die vom Benutzer übermittelten Daten oder erweiterte Conversions zu verwenden? Language: de Nein. Der Shopinhaber muss die Erfassung der vom Nutzer übermittelten Daten in GA4 und in den Einstellungen seines Google-Tags aktivieren. Erweiterte Conversions erfordern eine separate Konfiguration auf der Seite von Google Ads. Das Modul hat keinen Zugriff auf die Einstellungen des Google-Kontos und kann diese nicht automatisch aktivieren. ### Wie funktioniert dynamisches Remarketing in Google Ads? Language: de Nach der Aktivierung der Funktion und der Konfiguration der Google Ads Conversion-ID übermittelt das Modul Remarketing-Daten an das Tag auf den Shop-Seiten: Produktkennungen, Seitentyp und Warenkorbwert. Diese Daten können bei der Konfiguration des dynamischen Remarketings in Google Ads verwendet werden. Das Modul erstellt keine Kampagnen, Zielgruppen oder Anzeigen im Google Ads-Konto. ### Sendet das Modul die direkte Kaufkonversion an Google Ads? Language: de Im aktuellen Kaufmodus werden je nach Zahlungsstatus purchase und refund über das Measurement Protocol an GA4 gesendet. Der Modulcode sendet in diesem Modus keine direkte browserseitige Google-Ads-Kauf-Conversion. Die Google-Ads-ID wird u. a. für die Tag-Konfiguration und das dynamische Remarketing verwendet. ### Werden Käufe und Erstattungen an den zweiten GA4-Datenstream gesendet? Language: de Nein. In Version 1.4.2 dient die zweite Measurement ID dem parallelen Betrieb des Tags im Browser. Serverseitige purchase und refund werden über Measurement Protocol ausschließlich an den primären Datenstream gesendet, der mit den gespeicherten Attributionsdaten verknüpft ist. Das API Secret muss zu diesem primären Datenstream gehören. Die Konfiguration einer zweiten Measurement ID dupliziert serverseitige Käufe und Erstattungen nicht in der zweiten GA4-Property. ### Wozu dienen der Debugging-Modus und die GA4 DebugView? Language: de Der Debug-Modus protokolliert Browserereignisse in der Konsole und setzt für sie debug\_mode, das von GA4 DebugView verwendet wird. In Version 1.4.2 fügt der Schalter dieses Flag nicht zu serverseitigen purchase und refund hinzu und aktiviert nicht den Validierungsendpunkt von Measurement Protocol. Finanzielle Ereignisse müssen separat im Modulprotokoll sowie in der richtigen GA4-Property und deren Berichten geprüft werden; eine HTTP-2xx-Antwort bestätigt nicht die Verarbeitung des Ereignisses. Der Modus sollte nach Abschluss der Diagnose deaktiviert werden. ### Was zeigt das Statuspanel und das Finanzprotokoll des Moduls? Language: de Das Statuspanel zeigt an, ob GA4, Google Ads und das Measurement Protocol konfiguriert sind, ob der Debug-Modus aktiv ist sowie den letzten Kauf mit einer HTTP-2xx-Antwort. Das Finanzprotokoll ist schreibgeschützt und bietet Filterung, Sortierung sowie Paginierung der Einträge purchase und refund. Es gibt keine API-Geheimnisse, Browser-Identifikatoren oder rohe Payloads preis. ### Funktioniert das Modul mit dem One-Page-Checkout? Language: de Der Modulcode unterstützt die Standard-Bestellseite sowie die von beliebten One-Page-Checkout-Lösungen verwendeten Abläufe, und in der Konfigurationsbeschreibung wurden u. a. TheCheckout, SuperCheckout und STEasyCheckout genannt. Da Browser-Ereignisse vom tatsächlichen HTML und JavaScript des Checkouts abhängen, sollte nach der Installation der gesamte Ablauf Warenkorb–Zahlung–Bestellstatus im verwendeten Theme getestet werden. ### Kann man das automatische page\\\_view deaktivieren? Language: de Ja. In der Konfiguration befindet sich ein Schalter für das automatische page\_view. Dieser kann deaktiviert werden, wenn Seitenaufrufe bereits über den Google Tag Manager oder ein anderes Tool erfasst werden, um keine doppelte Messung von Seitenaufrufen zu erzeugen. Das Deaktivieren von page\_view entfernt nicht die übrigen Ereignisfunktionen des Moduls. ### Gewährleistet das Modul die rechtliche Konformität, die Vollständigkeit der Daten und die Ergebnisse der Kampagne? Language: de Nein. Das Modul übermittelt technisch die konfigurierten Daten an die Google-Dienste, ersetzt jedoch weder die Implementierung von Einwilligungen noch die rechtliche Analyse oder die Konfiguration der GA4- und Google-Ads-Konten. Der Shopbetreiber ist für die Rechtsgrundlage der Datenverarbeitung, den Inhalt der Einwilligungen und die Einstellungen der Google-Dienste verantwortlich. Die Vollständigkeit der Daten sowie die Kampagnenergebnisse hängen auch von den Einwilligungen der Nutzer, dem Browser, dem Theme, dem Checkout und den Google-Systemen ab. ## Customer reviews - Average rating: 4.50/5 - Public reviews: 4 - Source: iqitreviews