Czym GA4 jest, a czym nie jest: model zdarzeń kontra księgowość

W GA4 nie ma „sprzedaży”. Jest zdarzenie purchase z parametrami value, currency, transaction_id i items. Wszystko inne to pochodne: sesje, użytkownicy, źródła ruchu, ścieżki zakupowe. Kwota, którą widzisz w raporcie Monetization → E-commerce purchases, to liczba przesłana przez frontend sklepu. GA4 jej z niczym nie uzgadnia i nie zweryfikuje — nie ma dostępu do bazy zamówień ani do bramki płatności. To nie usterka, to definicja narzędzia behawioralnego.

Czego GA4 nie zna: faktur i korekt, zwrotów i reklamacji, chargebacków, stawek VAT, kosztu dostawy jako odrębnej pozycji, statusu płatności ani tego, czy zamówienie zostało anulowane trzy dni po złożeniu. Zdarzenie purchase wysłane raz zostaje w raporcie na zawsze.

Przykład. Produkt kosztuje 100 zł netto (123 zł brutto), klient użył rabatu 10% na cały koszyk, dostawa 15 zł. Typowa implementacja wysyła do GA4 value = 110,70 + 15 = 125,70 zł (brutto, z dostawą). W panelu sklepu i w ERP zobaczysz 90 zł netto ze sprzedaży towarów, a dostawę zaksięgowaną odrębnie. Różnica sięga 35% i nie świadczy o błędzie — to dwa różne pojęcia przychodu.

Dlatego ustal, która warstwa jest źródłem prawdy dla konkretnego pytania:

Dlaczego liczby z GA4 nie zgadzają się z panelem sklepu: 8 najczęstszych przyczyn

Zanim zaczniesz szukać błędu w GA4, sprawdź te osiem miejsc. W praktyce wdrożeń odpowiadają za znakomitą większość rozjazdów między raportem a panelem sklepu.

• Zgody i Consent Mode v2. Bez zgody na analytics_storage zdarzenia e-commerce zwykle nie są wysyłane, a GA4 nie zapisuje cookie _ga. Consent Mode modeluje część konwersji, ale nie odtworzy danych z order-confirmation. Test: w GTM Preview sprawdź, czy po akceptacji banera event purchase ma consent granted.
• Adblocki, tryb prywatny, ITP/ECI. Safari ogranicza trwałość cookie ustawianych skryptem, Firefox domyślnie blokuje znane trackery. Nie ma jednego wiarygodnego odsetka dla polskiego e-commerce — sprawdź u siebie: porównaj sesje z GA4 z liczbą wejść w logu serwera (nginx/apache) z tego samego dnia.
• Cross-device i cross-domain. Koszyk na telefonie, płatność na desktopie, powrót z domeny Przelewy24, PayU lub InPost Pay jako nowa sesja. Purchase zostanie przypisany do (direct)/(none), nie do kampanii.
• Zwroty, anulowania, zamówienia testowe. GA4 zapisał purchase w sekundzie zdarzenia. Panel sklepu pokazuje już stan po anulowaniu. Zamówienia testowe z produkcji najczęściej nie są nigdzie oznaczone.
• Sposób liczenia przychodu. Brutto czy netto, z dostawą czy bez, w jakiej walucie. Jeśli w parametrze currency jest błąd, GA4 przeliczy kwotę po swojemu lub potraktuje ją jak walutę property.
• Duplikaty purchase. Odświeżenie strony potwierdzenia i tag GTM odpalany jednocześnie na page view i na zdarzeniu. GA4 nie deduplikuje zdarzeń po transaction_id — duplikat wejdzie do raportu.
• Boty i ruch wewnętrzny. Znane boty są filtrowane, reszta nie. Ruch wewnętrzny wykluczasz w Admin → Data streams → Configure tag settings → Define internal traffic, ale definicja opiera się na IP — a to zmienia się przy zmianie operatora.
• Strefy czasowe. Property w GA4, PHP serwera sklepu (sprawdź przez date_default_timezone_get()) i bramka płatności mogą siedzieć w trzech różnych strefach. Zamówienie o 23:40 czasu polskiego wpadnie do GA4 z datą następnego dnia.

PrestaShop: gdzie najczęściej gubią się transakcje

W PrestaShopie purchase można wysłać na dwa sposoby: modułem analitycznym dystrybuowanym ze sklepem albo własnym dataLayer w GTM. Różnica nie jest kosmetyczna — dotyczy momentu wysyłki i kompletności danych. Punkt wyjścia do własnej implementacji znajdziesz w dokumentacji deweloperskiej PrestaShop.

• Moduł kontra ręczny dataLayer. Moduł odpala tag zwykle od razu po wejściu na stronę potwierdzenia. Własny dataLayer daje kontrolę nad tym, kiedy event leci i co zawiera — ale trzeba go utrzymywać przy aktualizacjach sklepu i motywu.
• Order-confirmation zamiast potwierdzenia płatności. Strona potwierdzenia (kontroler OrderConfirmationController) wyświetla się po złożeniu zamówienia, także gdy płatność jest jeszcze „oczekująca” — przelew tradycyjny, nieudana transakcja Przelewy24, porzucony PayU. Efekt: 30 zamówień w GA4, 24 w panelu po odfiltrowaniu nieopłaconych. Rozwiązanie: wysyłka server-side przez Measurement Protocol z hooka actionOrderStatusPostUpdate, po statusie „Płatność zaakceptowana”.
• Redirect na domenę bramki i powrót. Wyjście do Przelewy24, PayU czy InPost Pay zamyka sesję. Klient wraca jako nowa sesja, z utraconym session_id i źródłem kampanii. W raportach atrybucji taka sprzedaż ląduje w (direct) — winą za słabe wyniki kampanii obciążasz reklamę, a nie przekierowanie.
• Brak unikalnego transaction_id. Częsty błąd: branie cart_id zamiast referencji zamówienia. Numer koszyka bywa zmieniany, a powtórne wejście na potwierdzenie generuje kolejny purchase z tym samym lub pustym identyfikatorem. GA4 tego nie zdeduplikuje.
• Sklep wielowalutowy i wielojęzyczny. Jeśli moduł nie przekazuje parametru currency, GA4 przypisze kwotę do waluty property — 100 EUR policzy jako 100 PLN. Przy multistore z jednym measurement ID dane kilku sklepów się zlewają, a wersje językowe (/pl/, /en/) warto rozdzielić parametrem, jeśli raportujesz je osobno.

WooCommerce: typowe pułapki konfiguracji pomiaru

W PrestaShop pomiar siada zwykle na modułach i kontrolerach. W WooCommerce najczęściej na tym, że dwie wtyczki robią to samo albo żadna nie robi tego, czego potrzebujesz. Zanim zaczniesz porównywać liczby, ustal, kto u Ciebie wysyła zdarzenia.

Wtyczka czy GTM. Oficjalna wtyczka Google Analytics for WooCommerce (dawniej WooCommerce Google Analytics Integration) po wpisaniu Measurement ID sama wysyła view_item, add_to_cart, begin_checkout i purchase. GTM nie wysyła nic sam — to kontener, do którego trafia dataLayer, a tag GA4 zamienia go na event. Wtyczka to szybsze wdrożenie i mniej wiedzy; GTM to kontrola nad parametrami i możliwość wykluczenia np. zamówień B2B. Nie uruchamiaj obu równolegle: podwójny purchase to najczęstszy duplikat w audytach. Dokumentacja WooCommerce opisuje, co robi wtyczka i jak ją skonfigurować.

Czego nie robi żadna z nich: nie zna statusu płatności, nie wycofuje zdarzenia po failed, nie wysyła refundów, nie widzi zamówień dodanych ręcznie z panelu, nie koryguje korekt i chargebacków.

Kiedy ma polecieć purchase. Domyślnie przy wejściu na stronę potwierdzenia. Jeśli bramka przekierowuje poza sklep i klient nie wróci (zamknięta karta, timeout), eventu nie będzie. Przy przelewie tradycyjnym ze statusem pending event poleci, choć pieniędzy jeszcze nie ma, a przy failed też mógł już polecieć. Poprawna konfiguracja: wysyłka przez Measurement Protocol po zmianie statusu na processing lub completed, z pominięciem failed i cancelled.

HPOS. Zamówienia trzymane w tabelach wc_orders i wc_orders_meta, nie w postmeta. Integracje czytające _order_total przez get_post_meta zwracają null — event leci z wartością 0 albo nie leci wcale. Przed włączeniem HPOS sprawdź deklarację zgodności każdej wtyczki pomiarowej.

Testy, kupony, waluty. Zamówienia testowe właściciela i zakupy na 100% rabacie zawyżają raport — filtruj je po adresie e-mail albo wykluczaj wewnętrzne IP. Wartość purchase ma być kwotą faktycznie zapłaconą, po rabacie i po zwrotach częściowych; GTM często bierze subtotal z dataLayer i zawyża o wartość kuponu. Przy kilku walutach GA4 sumuje kwoty bez przeliczania — dodaj wymiar Currency, inaczej PLN i EUR zleją się w jedną bezsensowną liczbę.

Jak rozliczyć GA4 z backendem sklepu: procedura krok po kroku

Procedura jest jedna i zajmuje około godziny. Warunek: porównujesz zamknięty okres, najlepiej pełny miesiąc zakończony minimum trzy dni temu — GA4 dociąga dane z opóźnieniem, a zamówienia zmieniają statusy.

1. Ujednolić strefę czasową. W GA4: Admin → Ustawienia usługi → Strefa czasowa. Serwer bazy często chodzi na UTC. Jeśli GA4 ma Europe/Warsaw, a baza UTC, ostatnie dwie godziny doby wypadną poza zakres i wygenerują sztuczną różnicę.
2. Eksport z GA4. Explorations → Freeform. Wymiary: Transaction ID, Date, Currency. Metryki: Event count, Purchase revenue. Filtr: Event name = purchase. Zakres: dokładnie 1.–31. poprzedniego miesiąca. Eksport do CSV.
3. Eksport z backendu. Zapytanie do tabeli wp_wc_order_stats (istnieje również przy HPOS) o order_id, date_created, status, total_sales, z filtrem status IN ('wc-completed','wc-processing'). Nazwy kolumn sprawdź w swojej wersji WooCommerce.
4. Dopasowanie po transaction_id. Nie po sumie salda. Uwaga: przy wtyczkach numeracji sekwencyjnej numer zamówienia to nie order_id — upewnij się, że po obu stronach leci ten sam identyfikator. Dopasowanie po dacie i kwocie stosuj tylko jako awaryjne, bo produkt za 49 zł trafi się kilka razy dziennie.
5. Policz trzy liczby: liczbę transakcji w GA4, liczbę w backendzie, sumę wartości w obu źródłach. Dopiero te trzy liczby razem mówią, gdzie leży problem.

Tolerancja. 3–10% braków w liczbie transakcji w skali miesiąca to norma przy Consent Mode i adblockach. 15–20% i więcej albo różnica systematycznie rosnąca oznacza błąd implementacji. Zgodna liczba transakcji przy innej kwocie to prawie zawsze rabat, wysyłka, podatek lub waluta — nie tracking.

Consent Mode v2 i RODO: ile danych realnie ucieka i jak to liczyć

Od 10 listopada 2024 w Polsce obowiązuje Prawo komunikacji elektronicznej, które zastąpiło art. 173 Prawa telekomunikacyjnego. Zgoda na cookies analityczne i marketingowe nie jest dobrą wolą właściciela sklepu, a Consent Mode v2 to mechanizm, który przekazuje tę zgodę do Google.

Co dzieje się z eventem bez zgody. Gdy analytics_storage = denied, tag GA4 nie zapisuje cookie _ga i nie wysyła identyfikatora użytkownika. Wysyła tzw. cookieless ping: zdarzenie dociera do Google, ale nie pojawia się w standardowych raportach i nie da się go przypisać do użytkownika ani sesji. purchase z takiego pingu nie wejdzie do raportu sprzedaży. Przy ad_storage = denied i ad_user_data = denied Google Ads nie dostaje sygnałów konwersji, a przy ad_personalization = denied nie zbuduje remarketingu.

Modelowanie konwersji. GA4 potrafi oszacować konwersje użytkowników, którzy odmówili — pod warunkiem wystarczającego wolumenu danych i włączonego modelowania w ustawieniach usługi. Odtwarza liczbę konwersji na poziomie zagregowanym. Nie odtwarza ścieżek użytkownika, lejka na poziomie produktu, zdarzeń niestandardowych, retencji, danych demograficznych ani przypisania do konkretnego transaction_id. Nie odzyskasz z niego listy brakujących zamówień.

Skala ucieczki danych. Typowo 20–40% odmów w banerze (silnie zależy od CMP i sposobu prezentacji) plus 5–15% adblocków, więcej w publice technicznej. Efekt: GA4 pokazuje 55–80% transakcji. To nie awaria, to definicja narzędzia.

Dlaczego trend zostaje użyteczny. Jeśli baner i CMP się nie zmieniają, wskaźnik zgody jest w miarę stały, więc porównania tydzień do tygodnia i miesiąc do miesiąca w procentach mają sens. Uwaga: podmiana CMP albo dodanie „akceptuj wszystko” na pierwszym planie podnosi wskaźnik zgody o kilkanaście punktów procentowych i łamie serię — oznacz to w raporcie jako zmianę metodyki.

Praktyka raportowania. W raporcie wewnętrznym podawaj udział kanałów w konwersjach w procentach, konwersję jako konwersje do zakończonych sesji oraz AOV i przychód z panelu sklepu. Z GA4 bierz wyłącznie wskaźniki względne i kierunek trendu. Kwoty w złotych zawsze z systemu, który wystawia dokumenty.

Co GA4 mówi naprawdę: 7 metryk, na których możesz podejmować decyzje

Zamiast pytać „czy GA4 pokazuje prawdę”, zapytaj „na jakie pytanie odpowiada”. Odpowiada na siedem, a każda odpowiedź przekłada się na konkretną decyzję w sklepie.

1. Lejek zdarzeń: view_item → add_to_cart → begin_checkout → purchase. Przykład z życia: 40 000 sesji, 3 200 wyświetleń karty produktu, 1 200 add_to_cart, 480 begin_checkout, 300 purchase. Jeśli begin_checkout → purchase spada z 62% do 30%, problem jest w płatnościach lub koszcie dostawy, a nie w kampanii Google Ads. Najpierw naprawiasz checkout, potem zwiększasz budżet.
2. Skuteczność źródeł i kampanii w ujęciu względnym. Konwersja sesji wg source/medium, koszt na sesję i przybliżony ROAS (przychód z GA4 / koszt z platformy reklamowej). „Przybliżony”, bo GA4 nie zna zwrotów ani korekt.
3. Wyświetlenia produktów (view_item). Produkt z 50 wyświetleniami miesięcznie nie ma problemu z ceną — ma problem z widocznością.
4. Stosunek add_to_cart do purchase per produkt. 180 dodania do koszyka i 12 zakupów (6,7%) to sygnał ceny, kosztu dostawy albo niedostępności rozmiaru. Porównuj do mediany sklepu, nie do „rynku”.
5. Nowi vs powracający. Powracający kupują 2–3× częściej. Spadek udziału powracających to zwykle problem z obsługą posprzedażową, nie z reklamą.
6. Urządzenie. Konwersja mobile 40% niższa niż desktop przy tym samym ruchu = do naprawy formularz, nie kreacja.
7. Kanał. Ustalasz, gdzie naprawiać lejek: płatna kampania z wysokim begin_checkout i niskim purchase kontra organiczne z niskim add_to_cart.

Gdzie jest granica: każda z tych metryk jest względna i pomiarowa. GA4 nie zna faktur, korekt, zwrotów i chargebacków. W momencie pytania „ile faktycznie zarobiłem na kampanii X” wychodzisz z GA4 i sięgasz do panelu sklepu lub ERP — tam jest prawda finansowa, tu jest prawda behawioralna.

GA4 zepsute czy źle skonfigurowane: diagnostyka w 30 minut

Zanim ktoś zleci przepisanie implementacji od zera, warto sprawdzić cztery rzeczy w ustalonej kolejności. Całość zajmuje około 30 minut.

1. 0–5 min: Realtime. Wejdź na sklep w oknie incognito, odwiedź trzy podstrony, sprawdź, czy rośnie liczba aktywnych użytkowników i pojawia się page_view. Brak jakiegokolwiek zdarzenia oznacza problem z tagiem bazowym, consent mode albo blokadą skryptu — nie z e-commerce.
2. 5–15 min: DebugView. Administracja → DebugView, z włączonym debugowaniem (rozszerzenie Google Analytics Debugger lub parametr debug_mode w GTM). Sprawdź, czy zdarzenia niosą parametry items, value, currency, transaction_id. Zdarzenie bez parametrów to jeszcze nie sukces.
3. 15–22 min: Tag Assistant. Sprawdź, czy tag konfiguracji GA4 odpala się raz, czy trigger purchase wisi na stronie potwierdzenia zamówienia (a nie na podsumowaniu koszyka) i czy nie masz dwóch tagów purchase — jednego z GTM, drugiego z wtyczki.
4. 22–30 min: BigQuery. Przy włączonym eksporcie sprawdź w tabeli events_intraday_* liczbę zdarzeń purchase i count distinct transaction_id z ostatnich 24 godzin. To jedyne miejsce z danymi surowymi, bez próbkowania.

Test zakupu od początku: wejście z UTM, dodanie do koszyka, przejście przez płatność, powrót na stronę sklepu. purchase powinien pojawić się w DebugView w kilkadziesiąt sekund (raporty standardowe mają 24–48 h opóźnienia). Sprawdź, czy transaction_id jest unikalny i niepusty — wartość „undefined” albo identyfikator sesji to klasyka. Ustal też, czy value zawiera VAT i dostawę, i czy dokładnie ta sama kwota leci do Google Ads.

Wina sklepu: redirect po płatności na domenę bramki, gdzie nie ma GTM; strona potwierdzenia renderowana po POST; purchase odpalany przy statusie „oczekujące na płatność”. Warto przejrzeć, jak zmieniają się statusy zamówień w dokumentacji WooCommerce — purchase powinien odpowiadać statusowi opłacenia, nie złożenia.

Wina kontenera: brak „Once per event”, dwa tagi purchase, trigger na wszystkich stronach, nieuzupełnione mapowanie pól dataLayer.

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

Lista kontrolna do odklikania

• Wybierz zamknięty okres porównania — Najlepiej pełny poprzedni miesiąc kalendarzowy, co najmniej 7 dni po jego zakończeniu — żeby zwroty i korekty zdążyły się zaksięgować.
• Zapisz definicję przychodu — Ustal, czy porównujesz kwoty brutto czy netto, z dostawą czy bez, w jakiej walucie — i zapisz to w notatce przed pierwszym porównaniem.
• Ujednolić strefę czasową — Sprawdź strefę w ustawieniach usługi GA4, w bazie sklepu i w bramce płatności. Rozjazd o godzinę przesunie zamówienia z przełomu miesiąca.
• Wyeksportuj transakcje z GA4 — W Explorations zbuduj raport z transaction_id, datą, wartością i źródłem — eksport do CSV, nie zrzut ekranu.
• Wyeksportuj transakcje z backendu sklepu — Panel PrestaShop lub WooCommerce albo bezpośrednio z bazy: numer zamówienia, data, status płatności, kwota, waluta.
• Połącz zbiory po identyfikatorze transakcji — W arkuszu użyj transaction_id jako klucza. Transakcje bez pary pokażą, gdzie dokładnie gubią się dane.
• Odfiltruj zamówienia nieopłacone — Usuń z backendu statusy pending, failed i on-hold — one nie powinny mieć odpowiednika w GA4, a jeśli mają, to sygnał błędu w tagu.
• Odejmij zwroty i anulowania — Sprawdź, czy zwroty zostały zaksięgowane w okresie. GA4 zapisał purchase w dniu zakupu, panel sklepu pokaże korektę później.
• Policz duplikaty purchase — W eksporcie z GA4 sprawdź, czy któryś transaction_id występuje więcej niż raz. Duplikat oznacza podwójne odpalenie tagu.
• Oszacuj udział ruchu bez zgody — Porównaj sesje z GA4 z sesjami z logów serwera. Różnica to użytkownicy bez zgody analitycznej, z adblockiem i w trybie prywatnym.
• Wyklucz ruch wewnętrzny i boty — Zweryfikuj filtr IP w GA4 i w GTM. Sprawdź też, czy zamówienia testowe nie trafiły do zbioru.
• Sprawdź obsługę domeny płatności — Jeśli bramka przekierowuje na inną domenę, upewnij się, że zwrot do sklepu zachowuje sesję i źródło kampanii. Inaczej transakcja trafi do innego kanału.
• Zweryfikuj walutę i wielowalutowość — Przy sklepie w wielu walutach sprawdź, w jakiej walucie GA4 zapisuje wartość i czy przelicznik jest zgodny z panelem sklepu.
• Ustal próg tolerancji i zapisz wynik — Zapisz wynik porównania i przyjęty próg (np. 10–15% różnicy uznajemy za normalną). Kolejne porównania rób według tej samej procedury.

Najczęściej zadawane pytania

Źródła i materiały

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