Wersja 1.4.2 wymaga co najmniej PHP 7.2.5 ze względu na dołączone biblioteki HTTP; wersja PHP musi także spełniać wymagania używanej wersji PrestaShop. Serwerowe zakupy i zwroty wymagają dodatkowo aktywnego PD Cookie Pro w trybie live z Consent Mode v2, zgodnej rewizji zgody, zgody analitycznej oraz zapisanej atrybucji klienta i sesji. Sam API Secret nie wystarcza.
Najważniejsze cechy i funkcjonalności
- 15 nazwanych zdarzeń e-commerce i konta:
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 i login.
- Opcjonalny
page_view: administrator może pozostawić automatyczny pomiar odsłon w module albo wyłączyć go, gdy obsługę odsłon prowadzi Google Tag Manager lub inne rozwiązanie.
- Zakup po skonfigurowanym statusie: wersja 1.4.2 wysyła purchase z serwera po zapisaniu w historii zamówienia statusu wybranego przez administratora jako potwierdzający zapłatę i spełnieniu pozostałych warunków. Moduł nie weryfikuje samodzielnie rozliczenia u operatora płatności.
- Measurement Protocol dla operacji finansowych: do wysłania
purchase i refund potrzebne są: główny Measurement ID, API Secret, zapisane dane atrybucji/sesji oraz aktualna zgoda analityczna.
- Kontrolowane zwroty: moduł obsługuje pełny zwrot po wybranym statusie oraz nowe korekty PrestaShop, w tym korekty częściowe, wyłącznie gdy wcześniej zarejestrowano kwalifikujący zakup.
- Dziennik operacji finansowych: trwały rejestr i blokada dla zamówienia kontrolują własne zakupy i zwroty modułu; panel udostępnia widok tylko do odczytu z filtrowaniem, sortowaniem i stronicowaniem. Nie usuwa to duplikatów zdarzeń wysyłanych niezależnie przez GTM lub inne moduły.
- Dwa identyfikatory Measurement ID: można skonfigurować główny oraz opcjonalny drugi identyfikator GA4 dla zdarzeń wysyłanych z tagu w przeglądarce.
- Pięć sposobów budowania
item_id: ID produktu, ID produktu z ID kombinacji rozdzielone myślnikiem, ID produktu z ID kombinacji rozdzielone podkreśleniem, referencja albo EAN.
- Dane katalogowe przy zdarzeniach: moduł przekazuje m.in. identyfikator, nazwę, wariant, markę, kategorie, cenę, rabat, ilość, walutę oraz dane listy produktów, jeśli są dostępne w PrestaShop.
- Kupony rabatowe: obsługiwane zdarzenia przeglądarkowe mogą zawierać nazwę i kod zastosowanej reguły koszyka. W wersji 1.4.2 serwerowy purchase wysyłany przez Measurement Protocol nie zawiera kodów kuponów.
- User ID dla zalogowanego klienta: po włączeniu opcji moduł przekazuje techniczny identyfikator klienta do GA4 przy zgodzie
analytics_storage; nie zastępuje to danych kontaktowych.
- Dane przekazywane przez użytkownika: po włączeniu opcji i przy aktualnej zgodzie
ad_user_data moduł może przekazać e-mail oraz dostępny telefon lub adres w formacie wymaganym przez Google; dane identyfikujące normalizuje i hashuje SHA-256.
- Dynamiczny remarketing Google Ads: po włączeniu funkcji i podaniu identyfikatora Google Ads tag otrzymuje identyfikatory produktów, typ strony oraz wartość koszyka.
- DebugView i diagnostyka: tryb debugowania zapisuje zdarzenia przeglądarkowe w konsoli i dodaje do nich flagę debug_mode dla GA4 DebugView. Nie dodaje tej flagi do serwerowych purchase i refund. Panel pokazuje stan konfiguracji i ostatni zakup z odpowiedzią HTTP 2xx; zdarzenia finansowe należy sprawdzać w dzienniku oraz raportach GA4.
- PrestaShop 1.7.x, 8.x i 9.x: taki zakres deklaruje wersja 1.4.2, ale nie jest to gwarancja działania na każdej wersji PHP, motywie lub checkoutcie. Kod zawiera ścieżki standardowego checkoutu i wybranych modułów one-page checkout; sprawdzenia wymaga rzeczywisty proces zamówienia w danym sklepie.
Jakie etapy sprzedaży mierzy moduł GA4 dla PrestaShop?
| Etap w sklepie |
Zdarzenia przekazywane przez moduł |
Zakres danych |
| Listy i karta produktu |
view_item_list, select_item, view_item |
Produkt, wariant, marka, kategorie, cena, rabat i pozycja na liście. |
| Koszyk |
add_to_cart, remove_from_cart, view_cart |
Pozycje koszyka, ilości, wartości, waluta i dostępny kupon. |
| Checkout |
begin_checkout, add_shipping_info, add_payment_info |
Skład koszyka i informacje wybierane podczas procesu zamówienia. |
| Zakup i zwrot |
purchase, refund |
Zapis danych transakcji lub zwrotu spełniających warunki wysyłki przez Measurement Protocol. |
| Wyszukiwanie i konto |
search, view_search_results, sign_up, login |
Wyszukiwane hasło, wyniki wyszukiwania lub zdarzenie utworzenia konta i logowania. |
Pomiar zakupów i zwrotów przez Measurement Protocol
W aktualnym trybie finansowym moduł nie uznaje kliknięcia przycisku ani samej strony potwierdzenia za dowód zapłaty. Zdarzenie purchase powstaje po zapisaniu w historii zamówienia jednego z wybranych statusów płatności. Dla zwrotu moduł najpierw sprawdza, czy dla tego zamówienia istnieje wcześniejszy zakup zapisany jako wysłany w dzienniku; następnie rozlicza wyłącznie pozostałą, niezwróconą wartość. Pełny zwrot może uruchamiać wybrany status, a nowe korekty PrestaShop są obsługiwane niezależnie, także częściowo.
Stan sent w dzienniku oznacza odpowiedź HTTP 2xx, czyli przyjęcie żądania przez endpoint Measurement Protocol. Nie jest to potwierdzenie, że zdarzenie zostało już przetworzone lub pokazane w raportach Google Analytics. Moduł nie odtwarza historycznych zakupów ani zwrotów po aktualizacji i nie ma automatycznej kolejki, CRON-a ani przycisku wymuszającego ponowienie niepewnej wysyłki.
GA4, Google Ads, zgody i dane użytkownika
Moduł może inicjować tag GA4 dla jednego lub dwóch Measurement ID. Dla dynamicznego remarketingu Google Ads wymaga dodatkowo identyfikatora w formacie AW-…. W obecnym trybie zakupu po statusie płatności zdarzenia purchase i refund trafiają do GA4 przez Measurement Protocol; moduł nie wysyła w tym trybie bezpośredniej przeglądarkowej konwersji zakupu do Google Ads.
Opcja danych przekazywanych przez użytkownika wymaga aktywnego PD Cookie Pro z Consent Mode v2 i bieżącej zgody ad_user_data. Dodatkowo właściciel sklepu musi włączyć zbieranie takich danych w usłudze GA4 oraz w ustawieniach tagu Google; konfiguracja konwersji rozszerzonych w Google Ads jest odrębnym zadaniem po stronie konta Google. Cofnięcie zgody usuwa dane identyfikujące z konfiguracji tagu, a serwerowa wysyłka operacji finansowych ponownie sprawdza aktualną zgodę przed wysłaniem. User ID i dane przekazywane przez użytkownika również wymagają aktywnego PD Cookie Pro w trybie live, Consent Mode v2 i aktualnej wersji zgody. Cofnięcie analytics_storage zeruje User ID w tagu, a cofnięcie ad_user_data zeruje user_data. Nie usuwa to danych już przesłanych do Google.
Konfiguracja i weryfikacja wdrożenia
- Wpisz główny Measurement ID GA4, a drugi identyfikator tylko wtedy, gdy jest potrzebny.
- Dla zakupów i zwrotów podaj API Secret Measurement Protocol oraz wybierz statusy, które rzeczywiście potwierdzają opłacenie i pełny zwrot zamówienia w danym sklepie.
- Dobierz format
item_id do identyfikatora stosowanego w katalogu lub feedzie produktowym.
- Włącz tylko potrzebne funkcje Google Ads, User ID i danych przekazywanych przez użytkownika, po sprawdzeniu ustawień oraz zgód w narzędziach Google.
- Do testu użyj trybu debugowania i GA4 DebugView, a dla operacji finansowych sprawdź dziennik modułu. Test należy wykonać na rzeczywistej ścieżce zakupu i właściwym statusie zamówienia.
Zakres modułu i ważne ograniczenia
- Moduł przekazuje dane do skonfigurowanych usług Google; nie zakłada ani nie administruje kontem GA4, Google Ads, Merchant Center czy kampaniami reklamowymi.
- Nie zastępuje konfiguracji zgód ani analizy prawnej sklepu. Właściciel sklepu odpowiada za podstawę przetwarzania danych, treść zgód i ustawienia kont Google.
- Blokowanie skryptów, brak zgody, brak zapisanej atrybucji, błędne identyfikatory lub ustawienia Google mogą ograniczyć pomiar. Moduł nie deklaruje gwarancji kompletności danych.
- Wysłanie danych z API Secret wymaga poprawnej konfiguracji GA4. Odpowiedź HTTP 2xx należy traktować jako potwierdzenie odbioru żądania, a nie jako dowód widoczności transakcji w raportach.
Wymagania toru serwerowego w wersji 1.4.2
Serwerowe purchase nie jest wysyłane dla zamówień z płatnym pakowaniem, ponad 200 wierszami produktów lub pustą referencją/EAN, gdy wybrano taki format item_id. Korekty muszą mieć spójne kwoty i pozycje; odrzucane są rekordy z partial != 0 oraz typy bonów. Typ 2 jest obsługiwany tylko jako jednoznaczny zwrot samej dostawy. Częściowy zwrot ilości produktów nie jest tym samym co techniczna flaga partial.
Przed połączeniem źródeł zdarzeń przeczytaj porównanie architektury GA4 przez moduł i GTM. Gdy zakup lub jego przypisanie budzi wątpliwości, skorzystaj z poradnika diagnozy sprzedaży w GA4.
Zasady licencji, kopii testowej i aktualizacji znajdziesz w §7 Regulaminu sklepu.
Zanim porównasz raport z zamówieniami
Ustal definicję zakupu, źródło zdarzenia oraz warunki zgód. Przy jednoczesnym GTM sprawdź, czy drugi tag nie tworzy tego samego purchase. Porównanie rozwiązań znajdziesz w poradniku GA4 czy GTM.
Co sprawdzić przed uruchomieniem?
- Sprawdź konfigurację identyfikatora pomiaru i wymagań toru serwerowego wymienionych w opisie oraz FAQ.
- Dla kontrolowanego zdarzenia porównaj transaction_id, walutę, wartość i pozycje. Potwierdzenie wysyłki z modułu nie jest jeszcze dowodem poprawnego przypisania w raportach GA4.
- Sprawdź odmowę zgody, ponowne otwarcie potwierdzenia i przewidziany proces zwrotu w środowisku testowym.
