Zdarzenia e-commerce w GA4: lista kontrolna wdrożenia dla PrestaShop i WooCommerce, z testowym zamówieniem

Jeśli moduł GA4 w Twoim sklepie wysyła zakupy, to jeszcze nie znaczy, że raporty e-commerce działają. Jeśli przychodzi bez waluty, bez identyfikatora transakcji albo bez pozycji koszyka, GA4 pokazuje puste albo błędne przychody, a w panelu sklepu wszystko wygląda dobrze. Zanim przed Black Friday ustawisz budżety na podstawie raportów z GA4, sprawdź, co Twój moduł naprawdę wysyła. Wystarczy lista z tego tekstu i jedno zamówienie testowe.

Piszę z perspektywy sklepu, a nie wdrożeniowca. Nie interesuje mnie, jak moduł jest zbudowany, tylko czy dane, na których podejmuję decyzje, są kompletne. Przed sezonem to jest konkretne pytanie: na podstawie GA4 decydujesz, które produkty promować, które kampanie dostaną więcej budżetu i gdzie w zamówieniu klienci rezygnują. Jeśli dane są niepełne, każda z tych decyzji opiera się na zgadywaniu.

Dlaczego zakup to za mało

Google w dokumentacji Measure ecommerce (aktualizacja 14 października 2026 r.) opisuje zdarzenia dla całej ścieżki: wyświetlenie listy i karty produktu, dodanie do koszyka, rozpoczęcie płatności, zakup i zwrot. Raporty e-commerce składają się z tych zdarzeń i z tablicy items, czyli listy produktów w zdarzeniu. Każda pozycja w tej tablicy wymaga identyfikatora (item_id) albo nazwy (item_name). Google zaleca podawanie obu.

Jeśli moduł wysyła tylko zakup, nie zobaczysz w GA4, na którym etapie klienci odpadają. Jeśli wysyła zakup bez pozycji koszyka, raporty produktowe będą puste. Gdy GA4 nie pokazuje przychodów albo pokazuje inne niż sklep, zacznij od odpowiedzi na pytania dlaczego GA4 nie pokazuje przychodów i dlaczego GA4 pokazuje inne przychody niż sklep.

Lista kontrolna: zdarzenie, parametry, jak sprawdzić

Poniżej zdarzenia w kolejności ścieżki zakupu. Nazwy i parametry pochodzą z dokumentacji Google. Przy każdym podaję, co sprawdzić w zamówieniu testowym.

• view_item_list, wyświetlenie listy produktów. Parametr: items z produktami z listy. Sprawdź: zdarzenie pojawia się na stronie kategorii i ma pozycje.
• view_item, wyświetlenie karty produktu. Parametry: items, a przy wartości currency i value. Sprawdź: zdarzenie na karcie ma identyfikator produktu zgodny z katalogiem.
• add_to_cart, dodanie do koszyka. Parametry: items, currency, value. Sprawdź: ilość w items zgadza się z tym, co dodałeś.
• begin_checkout, rozpoczęcie zamówienia. Parametry: items, currency, value. Sprawdź: zdarzenie pojawia się raz, po przejściu z koszyka do zamówienia.
• add_shipping_info, wybór dostawy. Parametr: shipping_tier, czyli wybrana forma dostawy. Sprawdź: w parametrze jest nazwa dostawy, którą wybrałeś.
• add_payment_info, wybór płatności. Parametr: payment_type, czyli wybrana metoda płatności. Sprawdź: w parametrze jest wybrana metoda.
• purchase, zakup. Parametry: transaction_id, value, currency, items. Sprawdź: numer transakcji zgadza się z numerem zamówienia w panelu sklepu, a pozycje z koszykiem.
• refund, zwrot. Parametr: transaction_id zakupu, którego dotyczy zwrot. Sprawdź: czy moduł w ogóle wysyła zwroty. Jeśli tego zdarzenia nie ma, zwroty nie trafiają do GA4.

Jeśli moduł pomija etapy dostawy i płatności, nie widzisz, czy klienci odpadają przy wyborze dostawy, czy przy płatności, a to są dwie różne poprawki.

Waluta i wartość

Według dokumentacji zdarzeń (aktualizacja 16 września 2026 r.) value to suma iloczynów ceny i ilości wszystkich pozycji w items, bez dostawy i podatku. Gdy ustawiasz value, parametr currency jest wymagany, żeby GA4 poprawnie liczył przychód. Waluta to trzyliterowy kod ISO 4217, dla złotego PLN.

To zalecenie jest ważniejsze, niż wygląda. Jeśli moduł wysyła wartość brutto albo z dostawą, przychód w GA4 zawiera podatek albo dostawę, których Google zaleca nie wliczać. Nie musisz od razu przestawiać modułu. Musisz wiedzieć, co wysyła, zanim porównasz liczby z panelem sklepu. Przykład z WooCommerce opisałem przy Site Kit, który liczy wartość brutto z dostawą.

Identyfikator transakcji i podwójny zakup

Parametr transaction_id jest w zdarzeniu zakupu wymagany. Dokumentacja Google pisze, że pomaga uniknąć zdublowanych zdarzeń zakupu. Jeśli moduł wysyła zakup bez numeru albo z numerem innym niż numer zamówienia, nie da się porównać GA4 ze sklepem zamówienie po zamówieniu.

Podwójny zakup pojawia się na przykład wtedy, gdy zakup wysyłają dwa źródła, na przykład moduł sklepu i kontener Google Tag Managera. Jak to rozpoznać, opisałem we wpisie GA4 pokazuje więcej zamówień niż sklep.

Testowe zamówienie w DebugView krok po kroku

Według pomocy Google Analytics DebugView pokazuje zdarzenia z Twojego urządzenia w czasie rzeczywistym. Najpierw trzeba włączyć tryb debugowania. Na własnym urządzeniu robi się to rozszerzeniem Tag Assistant (tagassistant.google.com) albo trybem podglądu. Tag Assistant dodaje do adresu strony parametr, który włącza tryb debugowania. Więcej o obu narzędziach jest w haśle Tag Assistant i DebugView.

Test wygląda tak:

1. Włącz tryb debugowania w Tag Assistant i otwórz sklep.
2. Przejdź całą ścieżkę: kategoria, karta produktu, koszyk, zamówienie, dostawa, płatność, zakup.
3. W DebugView kliknij każde zdarzenie i porównaj parametry z listą kontrolną wyżej.
4. Zapisz numer zamówienia testowego i sprawdź, czy ten sam numer jest w transaction_id.
5. Anuluj zamówienie w panelu sklepu, żeby nie liczyć go jako sprzedaży.

Jeśli któregoś zdarzenia w DebugView nie widać, nie zgaduj przyczyny z raportów. Najpierw ustal, czy moduł w ogóle ma to zdarzenie w ustawieniach, a dopiero potem szukaj błędu w konfiguracji. Wynik testu zapisz: listę zdarzeń, które przyszły, i tych, których brakuje. Z taką listą rozmowa z wykonawcą modułu jest krótka i konkretna.

PrestaShop i WooCommerce: co sprawdzić w module albo wtyczce

Na obu platformach zdarzenia wysyła zwykle jedno z trzech rozwiązań: moduł platformy, wtyczka albo kontener Google Tag Managera z warstwą danych. Nazwy nie mają tu znaczenia. W każdym przypadku zadaj te same trzy pytania:

• Czy wysyła całą ścieżkę, czy tylko zakup? Sprawdzisz to w teście wyżej.
• Czy zakupu nie wysyła też drugie źródło? Częsty przypadek to moduł sklepu i tag w kontenerze Google Tag Managera (GTM), które działają jednocześnie. Przed sezonem warto też sprawdzić, czy Google nie połączył tagów w kontenerze.
• Jaką wartość wysyła? Netto czy brutto, z dostawą czy bez, i czy to zgadza się z zaleceniem Google.

Jeśli rozważasz przeniesienie wysyłki zdarzeń na serwer, przeczytaj najpierw wpis o Server-Side GTM w sklepie. Od tego wpisu warto zacząć cały temat pomiaru po stronie serwera.

Gdy sklep nie ma jeszcze analityki

Ta lista to krok drugi. Jeśli w sklepie nie ma jeszcze GA4 albo zgód, zacznij od odpowiedzi na pytanie od czego zacząć, gdy sklep nie ma analityki. Kolejność jest tam opisana: najpierw zgody i konto GA4, potem zakup z wartością i walutą, potem kroki przed zakupem, a na końcu połączenie z kontami reklamowymi.

Co robić w najbliższym kwartale

1. Przed Black Friday zrób jedno zamówienie testowe w DebugView i przejdź listę kontrolną.
2. Sprawdź, czy purchase ma transaction_id zgodny z numerem zamówienia, currency i items.
3. Ustal, jaką wartość wysyła moduł, i zapisz to obok raportów, żeby każdy, kto je czyta, wiedział, co porównuje.
4. Sprawdź, czy zakup nie idzie z dwóch źródeł.
5. Porównaj liczbę zakupów w GA4 z liczbą zamówień w panelu sklepu za ostatni tydzień.
6. Jeśli liczby z Google Ads i GA4 się różnią, przeczytaj, dlaczego Google Ads i GA4 pokazują różne konwersje i jak przesyłać konwersje z zaplecza sklepu.

Jeśli chcesz sprawdzić, czy raporty e-commerce w GA4 Twojego sklepu są kompletne, umówmy się na rozmowę.