Czym jest moduł GA4 dla PrestaShop i jak wstrzykuje pomiar

„Moduł GA4” to w praktyce trzy różne rzeczy, które klienci opisują jedną nazwą. Zanim zaczniesz diagnozować braki w danych, ustal, który wariant masz na sklepie — od tego zależy, gdzie szukać kodu.

• Oficjalny moduł z PrestaShop Addons — instalowany przez back office, konfigurowany formularzem, skrypt ładowany z hooka displayHeader. Najprostszy scenariusz, ale też najbardziej ograniczony.
• Kontener GTM wstawiony w szablon — „modułem” jest wtedy tag w Google Tag Managerze, a PrestaShop tylko renderuje <script> w headerze. Zdarzenia e-commerce buduje się w Data Layerze, nie w module.
• Custom moduł z hookiem displayHeader — własny kod agencji lub programisty wstrzykujący gtag.js bezpośrednio. Tu najczęściej nikt nie wie, kto co dopisał i kiedy.

Typowy moduł siedzi na czterech hookach: displayHeader (biblioteka gtag.js i konfiguracja), displayFooter (skrypty doczepiane na dole strony, np. śledzenie koszyka), hookDisplayOrderConfirmation (purchase liczony na stronie potwierdzenia) oraz hookActionValidateOrder (purchase po stronie serwera, także przez Measurement Protocol). Jeśli Twoje zdarzenia nie łapią się w żadnym z nich, ktoś dopisał kod w motywie — i aktualizacja szablonu go usunie.

Wymagania: PrestaShop 1.7.x to szablony Smarty (.tpl), 8.x to Twig (.twig) — moduł pisany pod 1.7 nie zawsze zadziała w 8.x bez zmian w szablonie. PHP: 1.7.8+ wymaga 7.4, PrestaShop 8 zaleca 8.1.

W konfiguracji wpisujesz Measurement ID (format G-XXXXXXX), nie Stream ID. Stream ID to liczba widoczna w GA4 → Administracja → Strumienie danych — wklejona w pole modułu nie zadziała i pomiar nie ruszy.

Nazewnictwo hooków i strukturę modułów opisuje dokumentacja dla deweloperów PrestaShop.

Pełna mapa: event GA4 → etap sprzedaży → miejsce w PrestaShop

Poniższa tabela odpowiada wprost na pytanie z tytułu. Trzecia kolumna mówi, gdzie w kodzie szukać zdarzenia — to punkt startowy do weryfikacji w GA4 DebugView.

Trzy zdarzenia wypadają najczęściej: select_item (klik w kafelek produktu z listy), view_promotion (banner czy slider na stronie głównej) i add_payment_info (wybór metody płatności). Gotowe moduły traktują checkout jako jeden krok, więc rozdzielenie dostawy i płatności trzeba dopisać ręcznie.

Zwroty to osobny temat: refund pojawi się tylko wtedy, gdy moduł nasłuchuje hookActionOrderStatusPostUpdate i reaguje na status „Zwrócone”. Domyślnie nikt tego nie robi.

Co realnie mierzy oficjalny moduł, a co jest luką

Po instalacji oficjalnego modułu dostajesz pięć zdarzeń: view_item_list, view_item (z parametrem item_list), add_to_cart, begin_checkout i purchase z tablicą items[]. To poprawny, ale niekompletny zestaw — obejmuje górę lejka i jego koniec, pomijając środek.

Najważniejszy brak to add_shipping_info i add_payment_info. Moduł nie rozdziela kroków checkoutu, więc w GA4 widzisz jedno begin_checkout i po nim purchase. Skutek jest policzalny: jeśli ze 100 rozpoczętych zamówień kończysz 40, nie wiesz, czy przepadło 30 osób na wyborze kuriera, czy 30 na wyborze płatności. W Funnel exploration masz dziurę i nie załatasz jej żadnym segmentem — brakuje danych źródłowych.

Kolejne luki: remove_from_cart (rzadko implementowane), select_item i view_promotion (praktycznie nigdy). Bez nich nie sprawdzisz, które produkty z listy faktycznie przyciągają kliknięcia, ani czy baner na stronie głównej generuje ruch do karty produktu.

Osobno zwroty. Jeśli moduł nie reaguje na zmianę statusu zamówienia, refund nigdy nie trafi do GA4 — raporty przychodu są zawyżone o wartość zwrotów, co przy sklepie z 5–10% zwrotów realnie zniekształca ROI kampanii.

Pułapka wdrożeniowa: gdy purchase leci jednocześnie z hookDisplayOrderConfirmation i z Measurement Protocol, zamówienie policzy się dwa razy. Wybierz jedno źródło.

Zanim dopiszesz brakujące zdarzenia, sprawdź zakres modułu i jego ograniczenia w PrestaShop oraz pozostałe wdrożenia PrestaShop — część modułów da się rozszerzyć konfiguracją, część wymaga własnego kodu.

Jak w 15 minut sprawdzić, które etapy mierzy Twój moduł

Zamiast czytać opis na marketplace, uruchom trzy testy. Wszystkie zmieszczą się w 15 minut, jeśli masz dostęp do GA4 i do sklepu — najlepiej na kopii stagingowej. Testy rób w jednej sesji i notuj każdy event, który zobaczysz.

Test 1 — DebugView + GA Debugger. W Chrome włącz rozszerzenie Google Analytics Debugger, otwórz sklep i przejdź ścieżkę: lista produktów → karta produktu → koszyk → checkout. Równolegle trzymaj otwarte w GA4: Administracja → DebugView. Powinieneś zobaczyć kolejno view_item_list, view_item, add_to_cart, begin_checkout. Kliknij nazwę zdarzenia, żeby rozwinąć parametry — interesują Cię items[] oraz item_id, item_name, price, quantity.

Test 2 — Realtime z filtrem po nazwie. GA4 → Raporty → Realtime → „Zdarzenia”. Widok pokazuje tylko ostatnie 30 minut, więc testuj punktowo: dodaj produkt do koszyka i sprawdź, czy licznik add_to_cart właśnie się zwiększył. Jeśli event jest w DebugView, a nie ma go w Realtime, sprawdź stan filtrów danych — nowy filtr domyślnie działa w trybie testowym.

Test 3 — zamówienie testowe. Utwórz produkt „Test produkt” i kod rabatowy TEST-INTERNAL. Złóż zamówienie najtańszą metodą płatności i w DebugView kliknij purchase. Sprawdź transaction_id, value, currency oraz pełną tablicę items[]. Brak currency albo value oznacza puste raporty przychodu mimo poprawnie wysłanego zdarzenia.

Higiena danych. W Administracja → Strumienie danych → Ustawienia tagów zdefiniuj IP biura jako internal traffic, a w Administracja → Filtry danych przełącz filtr ruchu wewnętrznego z „Testowanie” na „Aktywne”. Filtr działa dopiero od momentu włączenia — nie usunie niczego wstecz. Zamówienie testowe anuluj w PrestaShop i opisz w komentarzu, żeby nikt nie policzył go w sprzedaży.

Wynik testu to lista zdarzeń, które faktycznie poleciały — porównaj ją z tabelą z kolejnej sekcji. Więcej o konfiguracji modułów GA4 dla PrestaShop zebraliśmy w jednym miejscu.

Pięć pułapek, które psują pomiar nawet gdy moduł działa

Moduł może wysyłać zdarzenia poprawnie, a raporty i tak kłamią. Poniżej pięć sytuacji, które najczęściej widzimy przy audytach pomiaru w sklepach na PrestaShop.

1. Duplikacja purchase po odświeżeniu strony „Zamówienie przyjęte”. Wejdź na order-confirmation i odśwież ją dwa razy. W DebugView zobaczysz dwa purchase. Jeśli oba mają ten sam transaction_id, GA4 zwykle je zdeduplikuje w raportach. Jeśli transaction_id nie ma wcale — oba wejdą do przychodu i nie dowiesz się o tym z żadnego ostrzeżenia.

2. Płatności przekierowujące (Przelewy24, PayU, tpay). Klient kończy płatność na obcej domenie. Kiedy zamknie kartę albo nie wróci na stronę potwierdzenia, purchase nie poleci. Obejście: zdarzenie wysyłane z webhooka płatności przez Measurement Protocol, z transaction_id i value, plus wersja awaryjna po powrocie do sklepu. Sprawdź, ile zamówień z opłaconym statusem nie ma odpowiadającego purchase w GA4.

3. Brak currency i value oraz niepełne items[]. Objaw: zdarzenia są, a raporty przychodu i „Ecommerce purchases” świecą pustkami. W DebugView kliknij purchase i zweryfikuj, czy na poziomie zdarzenia jest currency i value, a w items[] — item_id, price i quantity dla każdej pozycji.

4. Consent Mode v2. Od marca 2024 brak wdrożonego trybu zgody obniża skuteczność modelowania konwersji u odbiorców w EEA. Efekt praktyczny: rozjazd między GA4 a statystykami PrestaShop sięgający kilkunastu procent — tyle zjada brak zgody, blokery i niedokończone powroty z płatności. Porównuj liczbę zamówień, nie sesje.

5. Zamówienia poza sklepem. B2B, zapytania ofertowe, zamówienia telefoniczne, przelew z odroczonym terminem — klient nie przechodzi checkoutu, więc w GA4 go nie ma. Rozwiązanie: zdarzenie offline przez Measurement Protocol, wysyłane przy zmianie statusu zamówienia w back office.

Jak uzupełnić brakujące etapy: własny moduł kontra GTM

Jeśli test z pierwszej sekcji pokazał braki, masz dwie realne drogi. Wybór sprowadza się do tego, kto będzie robił zmiany i jak często.

Wariant GTM. Wstawiasz warstwę dataLayer w szablonach i hookach, a tagi GA4 Event konfigurujesz w kontenerze. 8–16 godzin pracy. Zmiany robisz bez deployu — marketing sam doda parametr albo nowy event. Minusy: zależność od kontenera, dodatkowy JS na stronie i ryzyko podwójnych tagów, gdy ktoś doda event „na zapas”.

Wariant własnego modułu. Wykorzystujesz hookActionCartSave (dodanie do koszyka), hookDisplayOrderConfirmation (purchase) i hookActionOrderStatusPostUpdate (zmiany statusu, w tym zwroty) plus własną walidację danych przed wysyłką. 12–24 godziny. Zero zależności od zewnętrznych wtyczek i subskrypcji, kod zostaje u Ciebie — ale każda zmiana wymaga wdrożenia. Listę hooków znajdziesz w dokumentacji dla deweloperów PrestaShop, a sposób pracy opiszemy w materiale o generatorze modułów PrestaShop.

add_shipping_info i add_payment_info. Najprościej przez nasłuch AJAX-a na stronie zamówienia: zmiana przewoźnika i zmiana metody płatności. PrestaShop odświeża te sekcje asynchronicznie, więc podpinamy się pod samo zdarzenie zmiany, nie pod wyświetlenie strony.

Refundy. Gdy zamówienie przechodzi w status zwrotu, wyślij event refund z transaction_id i wartością zwrotu. Bez tego przychód w GA4 zostaje zawyżony o każdą reklamację.

Kiedy wystarczy darmowy moduł: do ~30 zamówień miesięcznie, jeden kanał sprzedaży, detal, jedna płatność online. Kiedy warto dopłacić: B2B, kilka kanałów, płatności odroczone, zamówienia obsługiwane poza sklepem.

Jak czytać te etapy w raportach GA4 (i porównać z PrestaShop)

Funnel exploration to jedyne miejsce w GA4, w którym widzisz ścieżkę, a nie sumy zdarzeń. Kroki: Eksploracje → Funnel exploration → Konfiguracja → Steps. W każdym kroku wybierz „Event name” i wpisz kolejno: view_item, add_to_cart, begin_checkout, purchase. Ustaw Funnel type: Closed — wtedy GA4 policzy tylko tych użytkowników, którzy przeszli całą ścieżkę, a nie sumy niezależnych zdarzeń. Time dimension zostaw na 1 dzień; dłuższy okres rozmywa ścieżkę, bo użytkownik wraca po tygodniu z innego urządzenia. Rozbicie włączasz w sekcji „Breakdown”: dodaj „Device category” (mobile vs desktop) albo „Session source/medium”. Uwaga praktyczna: rozbicie na źródła dzieli ruch na małe próbki — wnioski zaczynają się od kilkuset sesji na segment, wcześniej widzisz szum.

Proporcje między krokami to najszybszy sposób znalezienia dziury w lejku:

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Wersja PrestaShop i PHP — Zapisz numer wersji z back office. Od tego zależy, czy pracujesz na Smarty (1.7.x), czy na Twig (8.x) i czy moduł w ogóle deklaruje zgodność.
• Wariant pomiaru: moduł z Addons, GTM czy custom hook — Sprawdź listę modułów w back office, a potem źródło strony. Jeśli nie widzisz żadnej z tych trzech rzeczy, nie masz pomiaru GA4.
• Poprawne Measurement ID (G-XXXXXXX) — Porównaj wartość z konfiguracji modułu z GA4 → Administracja → Strumienie danych. Sprawdź to przed każdym testem.
• Karta produktu — view_item — Wejdź na produkt z aktywnym DebugView. Zdarzenie powinno pojawić się razem z parametrami item_id i item_name.
• Lista kategorii — view_item_list — Wejdź na kategorię z minimum kilkoma produktami. Sprawdź, czy zdarzenie zawiera listę itemów, a nie tylko jeden produkt.
• Klik w produkt z listy — select_item — Kliknij produkt z listy kategorii i sprawdź DebugView. Ten event jest jednym z najczęściej brakujących w gotowych modułach.
• Dodanie do koszyka — add_to_cart — Dodaj produkt z karty produktu i z listy kategorii. Sprawdź, czy zdarzenie leci w obu miejscach i czy klik „do koszyka” nie gubi parametrów.
• Strona koszyka — view_cart — Otwórz /koszyk i odśwież stronę. Sprawdź, czy zdarzenie pojawia się przy każdym wejściu, a nie tylko po dodaniu produktu.
• Usunięcie z koszyka — remove_from_cart — Usuń produkt z koszyka i sprawdź DebugView. W wielu modułach to zdarzenie nie istnieje, bo koszyk działa na AJAX-ie.
• Start checkoutu — begin_checkout — Wejdź na stronę zamówienia. Zdarzenie powinno zawierać items[] i value zgodne z zawartością koszyka.
• Wybór dostawy — add_shipping_info — Wybierz kuriera (InPost, DPD, DHL) i sprawdź DebugView. Brak tego zdarzenia to najczęstsza luka w module.
• Wybór płatności — add_payment_info — Wybierz metodę płatności i sprawdź DebugView. Jeśli event nie leci, nie rozróżnisz w raportach porzucenia na dostawie od porzucenia na płatności.
• Zamówienie testowe — purchase i refund — Złóż zamówienie z produktem „Test produkt” i kodem TEST-INTERNAL, sprawdź items[], value i currency, a potem ustaw status zwrotu i sprawdź, czy poleciał refund.
• Filtr ruchu wewnętrznego — Wyklucz swoje IP i oznacz testy jako internal traffic jeszcze przed pierwszą analizą. Weryfikacja: Twoja wizyta nie pojawia się w raportach po 24-48 godzinach.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – dane strukturalne
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów
• Google Ads – dokumentacja API