Zamówienia są, a GA4 ich nie widzi? Pomiar sprzedaży w PrestaShop

Zamówienie jest w PrestaShop, płatność została przyjęta, a Google Analytics 4 nie pokazuje zakupu. Zanim uznasz kampanię za nieskuteczną, sprawdź, czy sklep przekazuje do GA4 właściwe zdarzenia i kiedy to robi. Sam kod śledzący na stronie nie wystarcza do pomiaru sprzedaży. Znaczenie mają także sposób finalizacji zamówienia, identyfikatory transakcji, zgody klienta i kwoty wysyłane do raportów.

Dlaczego w GA4 widać odwiedziny, ale nie widać sprzedaży?

Odsłona strony i zakup to osobne zdarzenia. Żeby GA4 otrzymał informacje o sprzedaży, integracja musi wysłać purchase z danymi transakcji i produktów. Google opisuje ten mechanizm w instrukcji konfiguracji zdarzenia zakupu. Obecność użytkowników w raporcie czasu rzeczywistego potwierdza więc tylko część wdrożenia.

Druga częsta pułapka to porównywanie różnych danych. W panelu sklepu możesz liczyć wszystkie utworzone zamówienia, a w analityce rejestrować zakup dopiero po określonym statusie. Zacznij od jednej konkretnej transakcji: ustal jej numer, status, wartość i moment, w którym powinna trafić do GA4.

Co mierzyć między wejściem na produkt a zakupem?

Zdarzenia e-commerce pozwalają sprawdzić, na którym etapie urywa się ścieżka zakupowa. Praktyczny zestaw obejmuje:

Takie zdarzenia przewiduje dokumentacja e-commerce GA4 i obsługuje Google Analytics 4 Pro. Raport lub eksplorację ścieżki przygotowujesz w Google Analytics. Duży spadek między etapami jest wskazówką do sprawdzenia sklepu: może wynikać zarówno z zachowania klientów, jak i z brakującego zdarzenia w niestandardowym checkoutcie.

Klient nie wrócił z płatności. Czy zakup trafi do GA4?

Jeżeli pomiar uruchamia się dopiero na stronie potwierdzenia, klient musi ją otworzyć. Zamknięcie karty po płatności może przerwać ten scenariusz, mimo że zamówienie istnieje w sklepie. Dlatego sposób wysyłania zakupu trzeba dopasować do rzeczywistego przebiegu płatności.

Google Analytics 4 Pro dla PrestaShop udostępnia trzy tryby:

1. Strona potwierdzenia zamówienia. Zdarzenie jest przygotowywane po wejściu klienta na potwierdzenie. Przy skonfigurowanym API Secret moduł może dodatkowo wysłać zakup z serwera.
2. Zmiana statusu zamówienia. Moduł wysyła zakup przez Measurement Protocol po przejściu na jeden z wybranych statusów. Ten mechanizm nie wymaga ponownego otwarcia strony przez klienta; wymaga konfiguracji API i wcześniej zapisanego identyfikatora klienta GA4.
3. Kliknięcie przycisku potwierdzającego zamówienie. To wariant zależny od działania formularza zakupowego. Samo kliknięcie nie potwierdza otrzymania pieniędzy, dlatego trzeba sprawdzić także scenariusz nieudanej płatności.

Jeśli chcesz mierzyć opłacone zamówienia, wybierz statusy odpowiadające przyjęciu płatności. Dla pobrania ustal osobną zasadę: przyjęcie zamówienia i późniejsze rozliczenie należności to różne momenty.

Czy Measurement Protocol rozwiązuje problem adblocków?

Measurement Protocol umożliwia wysyłanie zdarzeń z serwera sklepu bezpośrednio do Google Analytics. Może ograniczyć zależność pomiaru zakupu od skryptu w przeglądarce. Google przedstawia go jako uzupełnienie standardowego zbierania danych.

W Google Analytics 4 Pro wysyłka serwerowa wymaga również identyfikatora client_id zapisanego przy zamówieniu. Moduł pobiera go z ciasteczka _ga. Gdy takiego identyfikatora nie ma, kod pomija wysyłkę przez API. Dodatkowo zapasowa wysyłka w trybie strony potwierdzenia nadal wymaga otwarcia tej strony. Dla problemu z brakiem powrotu z płatności znaczenie ma zatem tryb zmiany statusu. Żaden z tych mechanizmów nie daje podstaw do obietnicy pomiaru każdego zamówienia.

Dlaczego kwota w GA4 różni się od kwoty zamówienia?

Sprawdź, co porównujesz. Według specyfikacji zdarzenia purchase parametr value powinien odpowiadać sumie cen produktów pomnożonych przez ich ilości, bez podatku i dostawy. Pola tax i shipping są osobne. Przy przekazywaniu wartości potrzebna jest również waluta, np. PLN.

Przykład: dwa produkty po 100 zł netto dają value = 200. Kwota zapłacona przez klienta będzie wyższa, jeśli doliczono VAT i dostawę. Porównanie tych 200 zł z pełną kwotą brutto zamówienia samo w sobie nie dowodzi utraty przychodu.

Przy wdrożeniu sprawdź także rabat, kupon, ilości i walutę. Osobnej kontroli wymaga koszyk z rabatem obejmującym całe zamówienie: wartość transakcji i suma pozycji muszą być ze sobą uzgodnione.

Skąd biorą się podwójne zakupy i nieuwzględnione zwroty?

Sprawdź, czy purchase nie wysyłają jednocześnie moduł, Google Tag Manager i dodatkowy kod w motywie. GA4 dla strumienia internetowego korzysta z transaction_id, aby usuwać powtórzenia zakupów tego samego użytkownika. Każda transakcja powinna mieć własny, niepusty identyfikator, zachowany przy ponownej wysyłce tego samego zakupu.

W trybie potwierdzenia i wysyłce serwerowej Google Analytics 4 Pro używa referencji zamówienia jako transaction_id. Mimo to po połączeniu kilku integracji sprawdź rzeczywiste zdarzenia: inne identyfikatory tego samego zakupu mogą zaburzyć wynik.

Moduł obsługuje również refund po zmianie zamówienia na wybrany status zwrotu. Ta wysyłka wymaga API Secret oraz zapisanego client_id i obejmuje pełną wartość oraz pozycje zamówienia. Przy częściowym zwrocie, np. jednej z trzech sztuk, potrzebna jest osobna obsługa właściwych kwot i ilości. Przypisanie statusu zwrotu w tym module nie rozlicza automatycznie dowolnej częściowej korekty.

Co ze zgodami i Consent Mode v2?

Consent Mode przekazuje tagom Google informacje o zgodach użytkownika. Potrzebuje współpracy z banerem lub innym mechanizmem zbierania decyzji. Dokumentacja Google rozróżnia tryb podstawowy i zaawansowany, w których wysyłanie danych przed zgodą i po odmowie działa inaczej.

Moduł GA4 nie zastępuje konfiguracji zgód. W jego integracji z PD Cookie Pro zapisano obsługę sygnałów reklamowych ad_user_data i ad_personalization dla wysyłki serwerowej. Zachowanie całego pomiaru trzeba jednak sprawdzić z banerem działającym w danym sklepie. Włączenie API Secret nie oznacza zgody użytkownika na analitykę lub reklamę.

Jak sprawdzić pomiar na jednym zamówieniu?

1. Sprawdź miejsce docelowe danych. Identyfikator G-… w module powinien odpowiadać strumieniowi internetowemu, który oglądasz w GA4. Ustal też, jakie inne integracje wysyłają zdarzenia.
2. Przejdź ścieżkę zakupową. Otwórz produkt, dodaj go do koszyka i rozpocznij zamówienie. Moduł ma tryb debugowania zdarzeń przeglądarkowych; parametry możesz oglądać w DebugView. Kontrolę przeprowadź przy udzielonej zgodzie na analitykę, a zachowanie po odmowie sprawdź osobno.
3. Zweryfikuj zakup. Porównaj transaction_id, value, currency i items z zamówieniem. Uwzględnij produkty z wariantem i rabatem.
4. Sprawdź wybrany moment wysyłki. W trybie statusu zmień go na skonfigurowany status zakupu. Osobno przejdź płatność bez powrotu do sklepu i płatność nieudaną.
5. Sprawdź powtórzenie i zwrot. Odśwież potwierdzenie, skontroluj liczbę transakcji i zweryfikuj pełny zwrot. Wynik zdarzeń serwerowych potwierdź osobno w GA4: przełącznik debugowania w module dotyczy tagu w przeglądarce.

Raporty standardowe potrzebują czasu na przetworzenie danych. Google podaje, że może to potrwać 24–48 godzin. Brak zakupu w raporcie chwilę po teście nie przesądza jeszcze o błędzie.

GA4 w PrestaShop: częste pytania

Czy Google Tag Manager jest wymagany?

Nie. Google Analytics 4 Pro ładuje tag Google i wysyła zdarzenia przez gtag.js. Jeśli sklep korzysta już z GTM, ustal zakres obu wdrożeń, aby nie wysyłały tych samych zakupów niezależnie.

Czy wszystkie zamówienia powinny zgadzać się jeden do jednego?

Porównuj najpierw ten sam okres, statusy, walutę i sposób liczenia kwot. Różnice mogą wynikać także ze zgód, blokowania pomiaru i opóźnień przetwarzania. GA4 służy analizie zachowania i sprzedaży; rozliczenie zamówień opieraj na danych sklepu i płatności.

Od czego zacząć, jeśli raporty są puste?

Od sprawdzenia identyfikatora GA4 i jednego zakupu. Ustal, czy zdarzenie powstaje, zawiera produkty oraz wartość i trafia do właściwego strumienia. Dopiero potem porównuj zbiorcze raporty kampanii.

Google Analytics 4 Pro pozwala wdrożyć zdarzenia e-commerce w PrestaShop i dobrać sposób rejestrowania zakupów do działania sklepu. Zacznij od tej konfiguracji i jednej sprawdzonej transakcji: wtedy łatwiej ustalisz, czy niski wynik kampanii wynika ze sprzedaży, czy z braków w pomiarze.