Po czym poznać, że wdrożenie GA4 w sklepie jest skonfigurowane źle

Zamiast zgadywać, sprawdź pięć objawów. Każdy ma jedną, powtarzalną przyczynę.

1. Brak zdarzenia purchase. Składasz zamówienie, a w DebugView nic się nie pojawia. W raporcie „Zakupy e-commerce” widzisz zero albo kilka zdarzeń, choć sklep ma kilkadziesiąt zamówień tygodniowo. Typowe przyczyny: purchase odpala się dopiero przy statusie „zakończone”, zdarzenie gubi się przy przekierowaniu na zewnętrzną bramkę płatności albo tag nie jest podpięty do strony potwierdzenia. W WooCommerce warto najpierw ustalić, przy jakich statusach zamówienia wysyłane jest zdarzenie — statusy opisuje dokumentacja WooCommerce.
2. Zaniżony przychód względem panelu. GA4 pokazuje 48 000 zł, panel sklepu 52 000 zł. To 7,7% różnicy — za dużo. Część zamówień nie dochodzi do GA4 (przekierowania, blokady skryptów, błędy JS), część dolicza się podwójnie po odświeżeniu strony potwierdzenia.
3. Brak item_id w raportach. W raportach „Wyświetlone elementy” i „Zakupy e-commerce” zamiast produktów widzisz „(not set)”. Bez item_id nie zbudujesz odbiorców remarketingowych ani raportu sprzedaży per SKU.
4. Ruch płatny wpadający do Direct/None. Kampanie Google Ads i Meta lądują w kanale Direct. Przyczyna: brak parametrów UTM w linkach, przekierowanie międzydomenowe bez konfiguracji albo zgoda (consent) odcinająca parametry.
5. Brak rozbicia na pozycje zamówienia. purchase wysyła tylko value i currency, bez tablicy items. Widzisz przychód, ale nie wiesz, co się sprzedało.

Kryterium akceptacji: różnica między przychodem w GA4 a panelem sklepu w ujęciu tygodniowym nie powinna przekraczać 2–5%. Wyższa wartość oznacza błąd wdrożenia, a nie „normalne odchylenie”.

Test diagnostyczny w 10 minut: włącz DebugView (rozszerzenie GA Debugger, Tag Assistant lub parametr debug_mode), złóż jedną transakcję testową na najtańszym produkcie i sprawdź w DebugView, czy purchase ma currency=PLN, value, transaction_id oraz pełną tablicę items z item_id. Potem zajrzyj do raportu Czas rzeczywisty — obejmuje 30 minut. Zamówienie testowe anuluj i dopisz swoje IP do filtra ruchu wewnętrznego, żeby nie zanieczyszczało danych.

Jak działa ścieżka danych e-commerce w GA4 od zdarzenia do raportu

Zanim cokolwiek sprawdzisz, uporządkuj model danych. W GA4 ścieżka wygląda tak: zdarzenie w przeglądarce → parametry (część z nich item-scoped) → oznaczenie zdarzenia jako konwersji → raport. Każdy etap psuje się niezależnie od pozostałych.

Warstwa wysyłki. Masz trzy drogi. gtag.js — snippet wstawiony w motyw, najprostszy, ale każda zmiana wymaga wdrożenia na produkcję. Google Tag Manager — kontener z tagami i wyzwalaczami, wersjonowanie, tryb podglądu i audyt; standard przy sklepie z kilkoma integracjami. Measurement Protocol — wysyłka z backendu, np. z ERP po zmianie statusu zamówienia; wymaga api_secret oraz poprawnego client_id i session_id. Bez nich zdarzenie wpadnie jako nowy użytkownik i rozbije atrybucję. Zasada praktyczna: nie wysyłaj purchase dwiema drogami jednocześnie — jeśli musisz, transaction_id odfiltruje duplikat.

Parametry, które decydują o raportach. Zdarzenia e-commerce niosą tablicę items z parametrami item-scoped: item_id, item_name, price, quantity, item_brand, item_category. Obok nich parametry zdarzenia: currency, value, transaction_id, coupon, shipping. Najważniejsza jest spójność z panelem sklepu — jeśli w panelu liczycie brutto, w GA4 też brutto. Mieszanie netto i brutto daje różnice rzędu 20% i więcej.

Co jest wymagane, a co tylko rekomendowane. Krytyczne jest wyłącznie purchase — bez niego nie ma przychodu w raportach. view_item, add_to_cart, begin_checkout, view_item_list, select_item i add_payment_info są rekomendowane: zasilają ścieżkę zakupową, grupy odbiorców i remarketing, ale ich brak nie zeruje przychodu. Wdrożenie zaczynaj od purchase, dopiero potem dodawaj resztę — nie odwrotnie.

Weryfikacja konfiguracji: co sprawdzić zanim uruchomisz testy

Zanim uruchomisz testy, zamknij konfigurację. Błędy w tych pięciu miejscach psują dane niezależnie od jakości wdrożenia w sklepie.

Strefa czasowa i waluta. Administracja → Ustawienia usługi → Informacje o usłudze. Ustaw strefę Europe/Warsaw — przy innym ustawieniu zamówienie z 31 sierpnia, 23:40 trafi do innego dnia, a tygodniowe zestawienie przestanie zgadzać się z panelem sklepu o kilka procent. Walutę wybierasz raz przy tworzeniu usługi i nie da się jej później zmienić; przy sklepie w PLN musi być PLN.

Przechowywanie danych. Administracja → Ustawienia zbierania danych → Przechowywanie danych. Domyślnie GA4 trzyma dane zdarzeniowe i użytkowników 2 miesiące, maksimum to 14 miesięcy. Przy dłuższym cyklu zakupowym (B2B, meble, części zamienne) zostawienie 2 miesięcy oznacza, że za kwartał nie policzysz nic wstecz. Ustaw 14 miesięcy od razu.

Filtry ruchu wewnętrznego. Administracja → Strumienie danych → Konfiguruj ustawienia tagu → Zdefiniuj ruch wewnętrzny: dodaj IP biura, agencji, VPN-a i serwera testowego. Potem Administracja → Ustawienia zbierania danych → Filtry danych → Ruch wewnętrzny i zmień status z „Testowy” na „Aktywny”. Zostawienie filtra w trybie testowym to najczęstszy błąd — wygląda na włączony i nic nie robi.

Definicje konwersji. Administracja → Zdarzenia: purchase musi mieć włączony przełącznik „Oznacz jako konwersję”. Sprawdź, czy nie masz dwóch definicji purchase z różnych strumieni. add_to_cart i begin_checkout możesz oznaczyć jako konwersje pomocnicze, ale nie wliczaj ich do raportów przychodu.

Strumień, potok danych i BigQuery. Sprawdź konfigurację domen (subdomeny sklepu, koszyk na innej domenie), połączenie z Google Ads i eksport do BigQuery, jeśli chcesz trzymać surowe dane dłużej niż 14 miesięcy — pamiętaj o kosztach zapytań. Przy wdrożeniu po stronie sklepu punktem wyjścia jest dokumentacja dla deweloperów PrestaShop, która opisuje natywne hooki i moduły.

Weryfikacja wdrożenia krok po kroku: DebugView, Tag Assistant i Realtime

Kolejność testów ma znaczenie: najpierw Tag Assistant w trybie Preview, potem DebugView, na końcu Realtime. Odwrotna kolejność zwykle kończy się zgadywaniem, czy problem siedzi w tagu, czy w danych.

1. Tag Assistant (Podgląd w GTM). Klikasz Podgląd, wklejasz adres sklepu i przechodzisz pełną ścieżkę: produkt, dodanie do koszyka, koszyk, dane, płatność, potwierdzenie. W panelu po lewej widzisz zdarzenia Data Layer w kolejności. Sprawdzasz dwie rzeczy: czy view_item faktycznie poprzedza add_to_cart oraz czy tag purchase jest wyzwalany przez Custom Event, a nie przez Page View. Ten drugi błąd jest najczęstszy — purchase odpala się wtedy przy każdym odświeżeniu potwierdzenia zamówienia.

2. DebugView. W GA4: Administracja, potem DebugView. Zdarzenia z sesji w trybie podglądu mają parametr debug_mode i pojawiają się w kilka sekund. Rozszerz kolumnę parametrów i sprawdź, czy przy purchase jest pełna tablica items: item_id, item_name, price, quantity. Jeśli items jest puste, GA4 policzy przychód, ale raporty produktowe zostaną zerowe. Zwróć uwagę na czas: zdarzenie wpadające po 30–60 sekundach to najczęściej efekt Consent Mode albo blokowania beaconów.

3. Realtime. purchase z wartością transakcji powinien pojawić się w ciągu 1–2 minut. Brak zdarzenia przy jednocześnie działającym DebugView oznacza, że ruch idzie do innego strumienia niż ten, który oglądasz.

Staging czy produkcja? Testowe zamówienie na strumieniu produkcyjnym zawyża przychód. Jeśli musisz testować na produkcji, użyj GTM Preview — debug_mode dotyczy tylko Twojej przeglądarki. Na stagingu ustaw osobny strumień GA4 i osobny kontener GTM, żeby dane testowe nie mieszały się z raportami sprzedaży. Traktuj to jako stały element configuration and implementation verification, nie jednorazową akcję.

Weryfikacja wdrożenia w PrestaShop - moduły, hooki, kanał zamówienia

W PrestaShop prawie każdy problem z GA4 sprowadza się do trzech miejsc: hooków, kolejności modułów i strony potwierdzenia zamówienia.

Hooki. Moduł analityczny wstrzykuje kod w displayHeader (GTM lub gtag), a zdarzenie purchase w displayOrderConfirmation. W panelu Moduły, Pozycje filtruj po nazwie hooka i sprawdź, czy moduł GA4 tam jest oraz czy nie stoi za modułem, który zwraca false lub rzuca wyjątek — wtedy kolejne moduły w tym hooku nie wykonają się. W 1.7 i 8.x działa dodatkowo displayBeforeBodyClosingTag; jeśli kod siedzi tam, a wyzwalacz w GTM czeka na Data Layer z displayHeader, kolejność może się rozjechać.

Podwójne liczenie. Najczęstszy scenariusz: aktywny moduł GA4 i jednocześnie gtag wklejony w header.tpl motywu albo w polu z własnym kodem szablonu. Efekt to dwa purchase w DebugView i przychód wyższy o 100%. Drugie źródło duplikatów to odpalanie purchase przy zmianie statusu zamówienia (na przykład z „Płatność zaakceptowana” na „Wysłane”). Zostaw jeden kanał zamówienia: albo moduł, albo GTM, nigdy oba jednocześnie.

Strona potwierdzenia. Wejdź na order-confirmation (adres zawiera id_order, id_cart i key) i odśwież ją 2–3 razy. Jeśli po odświeżeniu leci kolejne purchase, brakuje deduplikacji po transaction_id i liczba transakcji w GA4 będzie zawyżona. W 1.6 kontroler przekazuje do hooka tablicę z id_order, w 1.7 i 8.x obiekt zamówienia i inny szablon (checkout/order-confirmation), więc snippet napisany pod 1.6 po aktualizacji po cichu przestaje działać. Szczegóły hooków opisuje dokumentacja dla deweloperów PrestaShop.

Weryfikacja wdrożenia w WooCommerce - wtyczki, HPOS i checkout blokowy

W WooCommerce najwięcej błędów wynika z tego, że zdarzenie purchase odpala więcej niż jedno narzędzie.

Konflikt wtyczek. Trzy typowe źródła: wtyczka Google Analytics dla WooCommerce, GTM4WP oraz ręczny kod w functions.php lub child theme. Test: w DebugView policz zdarzenia purchase po jednym zamówieniu i porównaj transaction_id. Dwa zdarzenia z tym samym identyfikatorem to duplikat do wycięcia. Wybierz jedno źródło prawdy i wyłącz pozostałe — nie „ukrywaj” ich w GTM, bo dane i tak polecą do GA4.

HPOS. Po włączeniu High-Performance Order Storage (WooCommerce, Ustawienia, Zaawansowane, Funkcje) zamówienia nie są już wpisami w postmeta. Stare snippety czytające get_post_meta($order_id, '_order_total', true) zwracają puste wartości — w DebugView purchase jest, ale bez value i bez items. Prawidłowo: $order = wc_get_order($order_id), a dalej $order->get_total() i $order->get_items(). HPOS zmienia też moment dostępu do zamówienia: woocommerce_thankyou działa, ale woocommerce_checkout_order_processed może odpalić się przed zapisem metadanych. Punkt odniesienia znajdziesz w dokumentacji WooCommerce.

Checkout blokowy. Blok kasy działa na Store API i nie emituje zdarzeń jQuery (updated_checkout, checkout_error), na których opiera się część wtyczek. Efekt: begin_checkout nie odpala się wcale. Przetestuj oba warianty kasy — klasyczny shortcode [woocommerce_checkout] i blok — bo wyniki potrafią się różnić.

Cache. Wyklucz z cache koszyk, kasę, stronę potwierdzenia i konto (/cart, /checkout, /order-received, /my-account) oraz zapytanie wc-ajax=get_refreshed_fragments. W WP Rocket to pole „Never cache these URLs”, w LiteSpeed Cache sekcja wykluczeń. Karta produktu może być cache'owana, kasa nigdy.

Pułapki, które psują dane - i jak je wykryć

Najczęstszy błąd to zdarzenie purchase odpalane dwa razy. Typowe źródło: tag wisi na stronie „zamówienie przyjęte”, do której klient może wrócić z maila albo ją odświeżyć. Drugie źródło: wtyczka sklepu wysyła transakcję z hooka woocommerce_thankyou, a równolegle robi to kontener GTM. W panelu sklepu jest jedno zamówienie, w GA4 dwa.

Test: wykonaj jedno prawdziwe zamówienie testowe i policz zdarzenia purchase w DebugView. Potem wejdź w raport Zarabianie > Zakupy e-commerce i porównaj liczbę transakcji z liczbą zamówień. GA4 deduplikuje zdarzenia po transaction_id, ale tylko wtedy, gdy to pole jest wysyłane i stałe. Jeśli identyfikator jest pusty albo generowany na nowo przy każdym odświeżeniu, duplikat wejdzie do raportów i zawyży przychód. Kolejność hooków zamówienia po stronie sklepu opisuje dokumentacja WooCommerce.

Drugi problem: VAT. Ustal jedną politykę i zapisz ją w notatce wdrożeniowej. Albo value to kwota brutto, albo netto plus podatek w polu tax w items. Zamówienie na 1 230 zł brutto to 1 000 zł netto. Jeśli GA4 liczy netto, a koszt kampanii porównujesz z kwotą brutto, ROAS wychodzi zaniżony i wyłączasz kampanię, która się zwraca. Odwrotny błąd przeszacowuje rentowność.

Trzeci: brak item_id lub item_name. Raporty sprzedaży pokazują wtedy (not set) i nie rozbijesz wyniku na produkty, kategorie ani marki. Naprawa jest tania: item_id = SKU, item_name = nazwa bez wariantu, do tego item_category.

Czwarty: Consent Mode v2. Po wejściu RODO licznik zdarzeń spada, bo tagi pracują w trybie bez plików cookie, a część danych jest modelowana. To nie awaria GA4, tylko skutek konfiguracji banera. Sprawdź sygnały analytics_storage, ad_user_data i ad_personalization w DebugView, osobno po akceptacji i po odrzuceniu zgody.

Piąty: server-side GTM i Measurement Protocol. To warstwa zgodności i odporności na blokery, nie zamiennik poprawnej konfiguracji. Źle wysłana wartość zostanie źle wysłana także z serwera, tylko trudniej ją złapać — zdarzeń z Measurement Protocol nie zobaczysz w DebugView tak jak zdarzeń z przeglądarki, do walidacji służy osobny endpoint walidacyjny. Zbierz te punkty w jeden przegląd — to właśnie elementy configuration and implementation verification.

Weryfikacja po wdrożeniu: monitoring, dane referencyjne i audyt kwartalny

Weryfikacja po wdrożeniu to cotygodniowy nawyk, nie jednorazowa akcja. Ustal jeden dzień (np. poniedziałek rano) i porównaj przychód z ostatnich 7 dni w trzech miejscach: GA4, panel sklepu, Google Ads. Jeśli masz ERP lub system magazynowy, dołóż czwarte źródło — faktury i stan wysyłek są twardszym punktem odniesienia niż jakikolwiek panel marketingowy.

Zanim uznasz różnicę za błąd, wyklucz trzy rzeczy: strefę czasową usługi GA4 (musi zgadzać się ze strefą sklepu), walutę i zwroty. Zwroty zrealizowane poza sklepem, np. przelewem, nie pojawią się jako korekta w GA4, jeśli nie wysyłasz zdarzenia refund.

Ustaw progi alertowe. Odchylenie przychodu powyżej 5% tydzień do tygodnia to sygnał do sprawdzenia. Brak zdarzenia purchase przez 24 godziny to alert krytyczny — przy normalnym ruchu oznacza zerwany tag, nie brak sprzedaży. Nagły spadek wszystkich zdarzeń o ponad 20% dzień do dnia najczęściej oznacza zmianę w banerze zgód albo wdrożenie Consent Mode bez testu.

Audyt rób co kwartał i zawsze po większej zmianie. Lista do przejścia: nowy szablon checkoutu, aktualizacja wtyczek e-commerce, aktualizacja platformy, nowa wtyczka płatności, zmiana konfiguracji zgód, nowy rynek lub waluta. Po aktualizacji sprawdź też nadpisania szablonu zamówienia — dokumentacja dla deweloperów PrestaShop opisuje strukturę override'ów, które najczęściej odpowiadają za zdublowany tag.

Samodzielna weryfikacja wystarcza, gdy różnice są mniejsze niż 5%, umiesz wejść w DebugView i masz jedno źródło zamówień. Deweloper jest potrzebny, gdy różnica przekracza 5% i utrzymuje się dwa tygodnie, gdy zmienił się checkout, gdy sprzedajesz na kilku platformach albo gdy po każdej aktualizacji dane znów się rozjeżdżają.

Co dalej z konfiguracją - checklista przed kolejną kampanią

Trzy kroki na najbliższe 48 godzin. Pierwszy: porównaj przychód z GA4, panelu sklepu i Google Ads za ostatnie 7 dni, w jednej tabeli. Zapisz różnice procentowe dla każdej pary. Drugi: wykonaj jedno zamówienie testowe o znanej wartości i sprawdź w DebugView cztery rzeczy — czy purchase odpalił się raz, czy transaction_id jest wypełniony, czy value odpowiada przyjętej polityce VAT i czy item_id oraz item_name mają wartości. Trzeci: ustaw alert. Wystarczy zaplanowany raport porównawczy wysyłany mailem raz w tygodniu albo prosty arkusz z progiem 5%.

Jeśli któryś z tych kroków zajmuje Ci więcej niż godzinę, to też jest informacja — o stanie dokumentacji wdrożenia. Warto wtedy mieć zapisane, gdzie stoi kontener, kto ma do niego dostęp i jaka jest przyjęta polityka VAT w danych.

Kiedy zlecić audyt na zewnątrz? Gdy nie masz wewnętrznego dewelopera, który wejdzie w warstwę danych. Gdy sprzedajesz na kilku platformach i każde zamówienie ma inną drogę. Gdy po każdej aktualizacji sklepu liczby znów się rozjeżdżają. Gdy przed kampanią świąteczną nie masz czasu na testy. Gdy różnica w przychodzie utrzymuje się powyżej 5% przez dwa kolejne tygodnie i nie wiesz, od czego zacząć.

Jeśli chcesz, żeby ktoś wziął na siebie pilnowanie tych liczb — kontener, wtyczki, consent, aktualizacje — odezwij się do nas. Powiemy wprost, co da się posprzątać zdalnie, ile to zajmie i czego nie da się zagwarantować. Bez zobowiązania do stałej umowy: czasem wystarczy jednorazowy audyt i lista poprawek, którą zrealizuje Twój wykonawca.

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

Lista kontrolna do odklikania

• Strefa czasowa i waluta — Administracja GA4 > Ustawienia strumienia danych. Sprawdź Europe/Warsaw i PLN (lub faktyczną walutę sprzedaży) zaraz po wdrożeniu – później dane historyczne pozostaną niespójne.
• Data Retention — Administracja > Zbieranie danych. Domyślnie 2 miesiące, maksymalnie 14 miesięcy. Sprawdź przed pierwszym porównaniem danych rok do roku.
• Filtry wewnętrznego ruchu — Zdefiniuj adresy IP biura i agencji oraz reguły wykluczające. Sprawdź po każdej zmianie dostawcy internetu, bo IP może się zmienić.
• Definicje konwersji — Administracja > Zdarzenia > Oznacz jako konwersję. Upewnij się, że purchase jest konwersją, a zdarzenia pomocnicze (add_to_cart, begin_checkout) nie zaburzają raportów.
• Liczba strumieni danych — Jeden sklep = jeden strumień web. Sprawdź, czy nie ma zdublowanego strumienia z tym samym identyfikatorem pomiaru, bo to najprostsza droga do zdublowanych zdarzeń.
• Parametr currency w każdym zdarzeniu — Sprawdź w DebugView, czy każde zdarzenie e-commerce ma currency i czy jest zgodne z panelem sklepu. Brak waluty unieważnia porównanie przychodu.
• transaction_id — Musi być unikalny i niepusty. Sprawdź na stronie potwierdzenia – brak transaction_id oznacza brak deduplikacji i podwójne liczenie po odświeżeniu strony.
• item_id i item_name — Sprawdź obecność w każdym zdarzeniu z tablicą items[]. Bez tego nie zobaczysz rozbicia na produkty ani nie połączysz danych z feedem reklamowym.
• Tag Assistant w trybie Preview — Sprawdź kolejność tagów i wyzwalaczy, czy Data Layer zawiera potrzebne zdarzenia i czy tag GA4 odpala się po ustaleniu danych transakcji.
• DebugView — Filtruj po debug_mode, zmierz czas pojawienia się zdarzenia i rozwiń parametry item-scoped. To najszybszy sposób na sprawdzenie kompletności danych.
• Realtime — Po transakcji testowej potwierdź purchase i wartość w ciągu 1–2 minut. Jeśli zdarzenie nie pojawia się w Realtime, nie pojawi się też w raportach.
• Strona potwierdzenia zamówienia — Otwórz order-confirmation, sprawdź jedno odpalenie purchase i odśwież stronę, żeby upewnić się, że zdarzenie nie mnoży się przy ponownym wejściu.
• Kolejność modułów i hooków (PrestaShop) — Sprawdź displayHeader i displayOrderConfirmation oraz to, czy moduł GA4 wykonuje się po ustaleniu danych zamówienia. Zła kolejność to najczęstsza przyczyna braku wartości transakcji.
• Cache koszyka i checkoutu — W WooCommerce i PrestaShop wyklucz koszyk, checkout i stronę potwierdzenia z cache. Sprawdź to po każdej zmianie wtyczki cache lub reguł serwera.

Najczęściej zadawane pytania

Źródła i materiały

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