Zacznij od rozróżnienia: brak sesji, brak zdarzenia czy brak transakcji w raporcie

Zanim dotkniesz kodu, ustal, którą z trzech warstw naprawiasz. Triage zajmuje około 5 minut i wymaga jednego zamówienia testowego oraz otwartego GA4.

Krok 1 – czy w ogóle jest sesja. Wejdź w Raporty > Realtime i otwórz sklep w drugiej karcie. Brak page_view w ciągu 30 minut oznacza, że tag nie wystartował: baner consentu (Consent Mode v2) blokuje gtag do momentu zgody, kontener GTM nie został opublikowany, w kodzie siedzi stary identyfikator UA albo polityka CSP blokuje domenę googletagmanager.com.

Krok 2 – czy jest zdarzenie purchase. Sesje są, ale w Realtime nie pojawia się purchase? Otwórz Administracja > DebugView i przejdź ścieżkę zakupu na zamówieniu testowym. Brak purchase to wina sklepu: hook, szablon, dataLayer. To najczęstszy przypadek i nim zajmują się kolejne sekcje.

Krok 3 – czy purchase jest, ale nie w raportach. DebugView pokazuje purchase, a Raporty > Monetyzacja > Zakupy e-commerce świecą pustkami? Sprawdź Administracja > Filtry danych (wykluczanie ruchu wewnętrznego po IP potrafi zjeść wszystkie Twoje testy), próg danych przy włączonych sygnałach Google, zakres dat oraz to, czy patrzysz na właściwą usługę i strumień. Standardowe opóźnienie agregacji to 24–48 godzin – świeże dane mogą jeszcze nie być w raportach.

Testuj bezpiecznie. Zamówienie testowe na produkcji zabrudzi dane. Lepiej: kopia na stagingu albo filtr ruchu wewnętrznego po IP plus debug_mode=1 w GTM. Pamiętaj, że GA4 deduplikuje purchase po transaction_id – powtórzone zdarzenie z tym samym numerem nie zdubluje transakcji. Jeśli wolisz mieć porządek w pomiarze raz na zawsze, robimy to w ramach opieki nad sklepami internetowymi.

Jak PrestaShop w ogóle wysyła purchase do GA4 – trzy drogi i ich słabe punkty

Zanim zaczniesz szukać usterki, ustal, którą drogą purchase trafia do GA4. W praktyce spotykamy trzy i każda psuje się inaczej.

1. Oficjalny moduł Google Analytics 4 (gtag.js). Moduł wstrzykuje gtag na stronach sklepu i sam odpala purchase na potwierdzeniu zamówienia. Słabe punkty: moduł wyłączony po aktualizacji, wersja nieobsługująca nowych parametrów, konflikt z innym modułem ładującym gtag – podwójne ładowanie daje zdublowane lub odrzucone zdarzenia.
2. Własny tag w Google Tag Manager. Purchase musi dostać dane z dataLayer wypchniętego z szablonu. Jeśli push nie istnieje, tag nie ma czego wysłać i w GTM zdarzenie w ogóle się nie pojawi.
3. Measurement Protocol po stronie serwera. Wysyłka z kontrolera lub crona, odporna na blokery reklam i porzucenie strony. Słaby punkt: brak naturalnego powiązania z sesją – bez client_id i ga_session_id z ciasteczka _ga transakcja wpadnie jako nowa sesja bez źródła.

Miejsce odpalania jest wspólne dla wariantu 1 i 2: hook displayOrderConfirmation (oraz displayOrderConfirmationTop) wywoływany z szablonu templates/checkout/order-confirmation.tpl, obsługiwanego przez OrderConfirmationController. W PrestaShop 1.7 i 8 kontroler znajdziesz w controllers/front/OrderConfirmationController.php – warto sprawdzić, jakie zmienne przypisuje do szablonu, bo tam siedzą id_order, wartość koszyka i waluta.

Dlaczego begin_checkout i add_payment_info zwykle działają, a purchase nie? Bo pierwsze dwa odpalają się w standardowym przepływie koszyka, na stronach, których prawie nikt nie nadpisuje. Purchase odpala się dokładnie raz, na stronie potwierdzenia – po przekierowaniu z bramki płatniczej, często po powrocie z innej domeny, na szablonie modyfikowanym przez motyw. Jeden brakujący hook i cały łańcuch się urywa, choć reszta pomiaru wygląda zdrowo. Kolejność hooków i strukturę szablonów opisuje dokumentacja dla deweloperów PrestaShop – to najszybszy sposób, żeby sprawdzić, czy Twój motyw w ogóle wywołuje właściwe miejsce.

Przyczyna 1: nadpisany szablon lub brak hooka na stronie potwierdzenia

To najczęstsza przyczyna, jaką znajdujemy w sklepach po wdrożeniu nowego wyglądu. Motyw child albo szablon kupiony od agencji nadpisuje templates/checkout/order-confirmation.tpl i gubi wywołanie {hook h='displayOrderConfirmation'}. Strona potwierdzenia renderuje się poprawnie, klient widzi numer zamówienia, a gtag nigdy się nie odpala. Panel PrestaShop nie zgłasza braku hooka jako błędu, więc usterka potrafi siedzieć w sklepie miesiącami.

Drugi wariant to cache. Moduły pełnego cache stron i wbudowane opcje wydajności potrafią serwować zapisany HTML strony potwierdzenia bez skryptu pomiarowego. Sprawdź Zaawansowane > Wydajność: „Smart cache for JavaScript”, „Minify HTML” oraz „Move JavaScript to the end”. Minifikacja inline'owego gtag i przestawianie kolejności skryptów to klasyczne źródło błędów. Każdy test rób na wyczyszczonym cache i w trybie incognito – cache przeglądarki dokłada trzecią warstwę złudzeń.

Test palca. Otwórz stronę potwierdzenia na zamówieniu testowym i zrób dwie rzeczy. Po pierwsze: podgląd źródła (Ctrl+U) i wyszukaj „gtag”, „dataLayer” oraz „purchase”. Brak tych ciągów oznacza problem w szablonie, nie w GA4. Po drugie: DevTools > Network, filtr „collect” (lub „g/collect”), złóż zamówienie i szukaj requestu z parametrem en=purchase oraz tid=G-XXXXXXX. Brak requestu = GA4 nic nie dostało i szukanie przyczyny w raportach nie ma sensu. Response 204 oznacza, że zdarzenie przyjęto; 400 wskazuje na błędne parametry, np. brak currency albo ujemną wartość.

Pułapka na koniec: blokery reklam. Popularne listy filtrów blokują domenę google-analytics.com, więc na Twoim komputerze test może „nie działać”, a u klientów wszystko będzie w porządku. Wyłącz adblock albo sprawdź stronę w czystym profilu przeglądarki. Jeśli motyw był niedawno aktualizowany, zajrzyj też do materiału o PrestaShop AutoUpgrade – po aktualizacji nadpisania szablonów często wskazują na nieaktualne pliki.

Przyczyna 2: Consent Mode v2 i CMP blokujące analytics_storage

Masz w GA4 sesje i zdarzenia, ale nie ma purchase. Pierwsze pytanie nie brzmi „czy tag jest wpięty”, tylko „czy w chwili zakupu zgoda na analitykę była aktywna”. Od marca 2024 Google wymaga w EEA czterech sygnałów Consent Mode v2: ad_storage, ad_user_data, ad_personalization i analytics_storage. Dla sprzedaży liczy się jeden — analytics_storage. Bez niego GA4 nie zapisze identyfikatora, a hit z potwierdzenia zamówienia pójdzie jako ping bez cookies.

Objaw jest mylący: widać sesje i część zdarzeń, ruch potrafi być modelowany, a transakcji nie ma. Powód jest prozaiczny — purchase odpala się na stronie potwierdzenia, czyli zwykle po powrocie z bramki płatności, długo po pierwszej wizycie. Jeśli użytkownik odrzucił baner albo CMP ustawiło analytics_storage = denied, purchase nie zostanie policzony. Kliknięcie „Akceptuję” po fakcie nic nie naprawi wstecz: zgoda działa od momentu aktualizacji, nie od początku sesji. To najczęstszy powód sytuacji „u mnie w DebugView działa, w raportach nie”.

Druga pułapka to sam CMP. Baner z jedną kategorią „Marketing i analityka” sprawia, że analytics_storage dostaje zgodę tylko wtedy, gdy użytkownik zaakceptuje wszystko. Sprawdź w panelu CMP, czy analityka jest osobnym przełącznikiem i czy nie jest zaznaczona domyślnie.

• Otwórz DebugView i zakładkę Consent — zobaczysz stan każdego z czterech sygnałów osobno, bez zgadywania.
• Zaakceptuj w banerze wyłącznie kategorię analityczną i sprawdź, czy w DebugView pojawiło się zdarzenie aktualizacji zgody (consent update).
• Powtórz test od zera w trybie incognito: dodaj produkt, przejdź do płatności, zapłać, wróć na potwierdzenie. Purchase musi pojawić się już po aktualizacji zgody.
• W żądaniu sieciowym porównaj parametr gcs przed i po akceptacji — najczęściej zmienia się z G1-- na G111.

Jeśli baner, tagi i sklep wdrażasz równolegle, uporządkuj to na etapie wdrożenia sklepu internetowego — poprawianie zgód po starcie kampanii kosztuje więcej niż konfiguracja od początku.

Przyczyna 3: przekierowania bramek płatności i gubione hity

Polska specyfika: większość zamówień nie kończy się na stronie sklepu, tylko w aplikacji banku albo w bramce. Przelewy24, PayU, Tpay czy BLIK jako metoda płatności działają przez przekierowanie — użytkownik wychodzi z domeny sklepu i wraca na stronę potwierdzenia. Dla GA4 to dwa różne wejścia, nie jedno.

Skutek pierwszy: powrót generuje nową sesję, a źródłem ruchu staje się domena bramki. Transakcja jest, ale wisi pod „referral / przelewy24.pl”, więc kampania w Google Ads nie dostaje konwersji, a raport kanałów kłamie. Naprawa jest tania: Admin → Data streams → Configure tag settings → List unwanted referrals i dodaj domeny bramek oraz stron płatności. Wtedy referral nie nadpisze źródła. Sprawdź też, czy nie wykluczasz przy okazji własnej domeny — to częsty błąd przy kopiowaniu listy.

Skutek drugi, gorszy: hit purchase wysyłany w chwili opuszczania strony. Jeśli moduł robi to w handlerze beforeunload, przeglądarka może ubić żądanie, zanim wyjdzie ono na zewnątrz. Na desktopie z dobrym łączem zwykle przejdzie, na mobile w roamingu — nie. Dlatego statystyki „brakuje 5% transakcji” biorą się głównie z telefonów.

• Ustaw transport_type: 'beacon' dla zdarzenia purchase — przeglądarka wyśle je w tle, nawet po opuszczeniu strony.
• Odroczenie przekierowania o 300–500 ms (setTimeout przed window.location) daje podobny efekt i jest prostsze do wdrożenia w module.
• Alternatywa dla upartych przypadków: Measurement Protocol i zdarzenie wysłane serwerowo po potwierdzeniu płatności webhookiem.

Uwaga na pułapkę Measurement Protocol: bez session_id i client_id zdarzenie trafi do GA4 jako nowy użytkownik bez atrybucji. Zapisz oba identyfikatory w zamówieniu jeszcze przed przekierowaniem do bramki.

Przyczyna 4: filtry, ruch wewnętrzny i mapowanie statusów zamówienia

Bywa, że purchase dochodzi, tylko nie widać go w raportach. Zanim zaczniesz szukać błędu w module, wejdź w Admin → Ustawienia danych → Filtry danych. Dwa filtry potrafią wyciąć transakcje: Developer traffic (zdarzenia z parametrem debug_mode) oraz Internal traffic (ruch z IP oznaczonych jako wewnętrzne). Liczy się kolumna stanu: filtr ustawiony na Testing nic nie wycina, Active wycina z raportów. W DebugView zdarzenia nadal będą widoczne, bo DebugView pokazuje strumień, a nie raport — stąd wrażenie, że „dane są, tylko ich nie ma”.

• Lista ruchu wewnętrznego: Data streams → Configure tag settings → Define internal traffic. Sprawdź, czy nie ma tam IP biura, agencji, VPN-a i serwera testowego. Jeśli testujesz zakupy z firmowego Wi-Fi, a filtr jest aktywny, te transakcje nigdy nie wejdą do raportu.
• Developer traffic: jeśli na produkcji ktoś zostawił włączony debug_mode (parametr _dbg, podgląd GTM), purchase'y z tych sesji są filtrowane automatycznie.

Druga warstwa jest po stronie sklepu. W PrestaShop każdy status zamówienia ma flagi paid, logable i shipped, ustawiane w Shop parameters → Order settings → Statuses. Moduł GA4 wysyła purchase tylko dla statusów zaznaczonych w jego konfiguracji — domyślnie bywa to „Płatność zaakceptowana” (w czystej instalacji ID 2, ale w Twojej może być zupełnie inne). Jeśli doszedł własny status „Opłacone – Przelewy24” albo „BLIK potwierdzony”, a nie ma go na liście modułu, transakcje z tej bramki nie pojawią się nigdy. Strukturę statusów opisuje dokumentacja deweloperska PrestaShop. Osobno sprawdź, czy moduł nie dubluje się z tagiem w GTM — GA4 deduplikuje po transaction_id, ale tylko gdy identyfikator jest identyczny w obu źródłach.

Na koniec oddziel błędy od świadomych wyjątków: zamówienia testowe, płatność za pobraniem (pieniądze dopiero przy odbiorze) i zamówienia anulowane. To nie awaria pomiaru, tylko decyzja — zapisz ją, żeby za pół roku nikt nie „naprawiał” czegoś, co ma działać właśnie tak.

Przyczyna 5: duplikaty, transaction_id i rozjazd z panelu PrestaShop

GA4 traktuje transaction_id jak klucz idempotencji: dwa zdarzenia purchase z tym samym identyfikatorem policzą się raz. Kłopot zaczyna się, gdy identyfikator przestaje być stały. Najczęstszy scenariusz: moduł GA4 w PrestaShop dokleja prefiks (PS-1042), a równolegle tag w GTM wysyła czysty numer (1042). Jedno zamówienie, dwa purchase w raporcie. Drugi scenariusz: klient odświeża stronę potwierdzenia albo wraca z bramki płatności, a skrypt generuje identyfikator od nowa zamiast odczytać go z zamówienia — każde wejście to kolejna transakcja. Identyfikator bierz z obiektu zamówienia (hook displayOrderConfirmation, opisany w dokumentacji dla deweloperów PrestaShop), nigdy z koszyka ani z timestampu.

Druga grupa błędów to parametry, które przechodzą przez walidację, ale psują raporty:

• value i shipping jako tekst. "129,99" z przecinkiem nie jest liczbą — GA4 pokaże zero albo pominie wartość. Wysyłaj typ number z kropką dziesiętną.
• Brak tablicy items. Transakcja się liczy, ale raporty produktowe i porównanie z katalogiem są puste. item_id musi być spójne z id_product + id_product_attribute.
• Waluta niezgodna z ustawieniem sklepu. currency to kod ISO („PLN”), nie „zł”. Przy multistore z walutami w różnych kontekstach sumy przestają się zgadzać z panelu.

Uzgodnienie rób zawsze na tych samych widełkach czasowych i tylko na statusach zamówień, które uznajesz za opłacone — nie na „wszystkich zamówieniach”.

Checklista naprawy: kolejność działań od 5 minut do 2 dni

Kolejność jest ważna, bo każdy krok zawęża obszar. Nie zaczynaj od kodu motywu.

1. DebugView (5 min). GA4 → Administruj → DebugView, odpal testowe zamówienie w trybie testowym bramki. Widzisz purchase? Przechodzisz do uzgodnień. Nie widzisz — idziesz dalej.
2. Źródło strony potwierdzenia (10 min). Ctrl+U na order-confirmation. Szukasz dataLayer.push z transakcją. Jeśli w HTML-u nic nie ma, a dane pojawiają się dopiero po JS — sprawdź, czy moduł nie ładuje się asynchronicznie po zdarzeniu DOM-ready.
3. Request collect w konsoli (15 min). Network → filtr collect. Sprawdź en=purchase, ep.transaction_id, epn.value, cu=PLN, pr1… Status 204 = serwer przyjął. Brak requestu = tag nie wystartował. Status 4xx/5xx = WAF lub mod_security po stronie hostingu.
4. GTM Preview (20 min). Czy trigger odpalił, czy tag odpalił, czy nie zablokowała go zgoda.
5. CMP (15 min). Sprawdź, w jakiej kategorii siedzi tag purchase i czy advanced consent mode nie zamienia danych na modelowane.
6. Konfiguracja serwera (1 h – 2 dni). Cache pełnostronicowy serwujący stronę potwierdzenia z kopii, kolejność hooków, blokady na endpoint /g/collect.

Docelowo warto uniezależnić pomiar od przeglądarki: kontener server-side na własnej subdomenie (np. measure.twojsklep.pl) albo Measurement Protocol wysyłany webhookiem z bramki płatności po potwierdzeniu transakcji. Pamiętaj wtedy o zapisaniu client_id z cookie _ga przy składaniu zamówienia — bez niego zdarzenie trafi do puli „unassigned”.

Audyt zewnętrzny ma sens, gdy motyw jest mocno zmodyfikowany, jest kilka wariantów płatności albo sklep działa w multistore. To zadanie łączymy zwykle z utrzymaniem i wdrożeniami sklepów internetowych. Widełki poniżej to nasze własne szacunki, nie rynkowy standard — pytaj o nie przed startem prac.

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

Lista kontrolna do odklikania

• Ustal warstwę problemu — Zacznij od Realtime: 0 użytkowników = tag lub consent, użytkownicy bez purchase = hook lub szablon, purchase w DebugView bez raportów = filtry lub opóźnienie.
• Sprawdź, czy tag GA4 w ogóle się ładuje — Podgląd źródła strony i filtr sieci na „collect”. Brak requestów do GA4 oznacza problem z implementacją, nie z raportowaniem.
• Sprawdź stan zgody w Consent Mode — W DebugView otwórz zakładkę Consent i zobacz, czy analytics_storage przyjmuje wartość granted po akceptacji banera analitycznego.
• Zweryfikuj cztery sygnały Consent Mode v2 — ad_storage, ad_user_data, ad_personalization i analytics_storage – wszystkie powinny być ustawiane przez CMP, nie domyślnie puste.
• Sprawdź hook na stronie potwierdzenia — W motywie child lub custom theme poszukaj wywołania displayOrderConfirmation w order-confirmation.tpl; brak = purchase nigdy nie wystartuje.
• Sprawdź, czy strona potwierdzenia nie jest cache’owana — Wyłącz na chwilę moduł pełnego cache i powtórz zamówienie testowe – jeśli purchase wraca, problem jest w cache.
• Ustaw filtr ruchu wewnętrznego — Wyklucz po IP (stacjonarnie i mobilnie, z VPN) albo testuj na stagingu – zrób to przed pierwszym zamówieniem testowym.
• Uruchom test z parametrem debug_mode — Dopisanie parametru do URL pozwala śledzić zdarzenia w DebugView bez czekania na przetworzenie raportów.
• Zrób zamówienie testowe z realnym przepływem płatności — Przejdź całą ścieżkę łącznie z powrotem z bramki – tylko wtedy sprawdzisz, czy przekierowanie nie gubi hitu purchase.
• Sprawdź kolejność wysyłki purchase — Hit powinien wyjść przed opuszczeniem strony; na mobile sprawdź, czy nie jest gubiony przy page unload.
• Przejrzyj filtry danych — Administracja > Filtry danych – filtr wewnętrznego ruchu działający na produkcji odcina też Twoje testy i potrafi ukryć poprawne zdarzenia.
• Sprawdź ustawienia progu danych — Przy małym wolumenie GA4 może ukrywać część danych w raportach – porównaj liczby z systemem zamówień, nie z pamięci.
• Odczekaj 24–48 h przed werdyktem — Przetwarzanie danych w GA4 nie jest natychmiastowe; wczesne wnioski prowadzą do naprawiania działającej konfiguracji.
• Porównaj liczbę transakcji z systemem sklepu — Zestaw liczbę zamówień z PrestaShop z raportem Zakupy e-commerce – różnica w procentach mówi, czy problem jest systemowy, czy dotyczy wybranych kanałów.

Najczęściej zadawane pytania

Źródła i materiały

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