Problemy z GA4 e-commerce – debug tracking i naprawa 2026

Zanim zaczniemy szukać błędów, ustalmy co w ogóle powinno być śledzone. GA4 używa jednolitego modelu eventów – każda akcja w lejku zakupowym to osobne zdarzenie z ustalonym zestawem parametrów. Nie ma już podziału na "Enhanced Ecommerce" i "Standard Ecommerce" jak w Universal Analytics – wszystko leci przez gtag/GTM jako events z tablicą `items`.

Poniżej lista eventów, które składają się na pełny lejek e-commerce. Jeśli któregoś brakuje, tracisz widoczność na odpowiednim etapie ścieżki klienta – i nie zobaczysz tego w standardowych raportach, bo GA4 po prostu wyświetli "0" bez ostrzeżenia.

W sklepach WooCommerce najczęściej brakuje `view_cart`, `add_payment_info` i `remove_from_cart` – wtyczki typu Site Kit implementują tylko podstawową trójkę (view_item, add_to_cart, purchase), więc cały środek lejka jest dla Ciebie niewidzialny. To jeden z powodów, dla których analityka e-commerce w WooCommerce wymaga solidnej konfiguracji, a nie byle wtyczki z repo. W praktyce warto też zestawić najlepsze rozwiązania analityczne dla sklepu, zanim zdecydujesz się na konkretny stack.

Na poziomie produktu w tablicy `items[]` musisz przekazać minimum: `item_id` (SKU), `item_name`, `price`, `quantity`. Opcjonalnie dochodzi `item_brand`, `item_category`, `item_variant`, `discount`, `coupon`. Im więcej parametrów wypełnisz, tym lepsze raporty dostaniesz w zakładce Monetyzacja › Zakupy według produktu.

Najczęstszy przypadek, z jakim trafiają do nas klienci: "GA4 pokazuje zakupy, ale wartość 0 zł". Otwierasz Monetyzację, widzisz 150 transakcji i 0,00 zł przychodu. Powód? Event `purchase` odpala się, ale bez kompletu parametrów.

GA4 wymaga w evencie purchase konkretnego zestawu pól – jeśli jednego zabraknie, raport nie pokaże wartości albo nie przypisze produktów do transakcji. Lista obowiązkowych parametrów wygląda tak:

• transaction_id – unikalny ID zamówienia (numer z panelu sklepu, np. "WC-12453"). Brakuje tego, GA4 liczy każde odświeżenie jako osobną transakcję.
• value – wartość zamówienia liczbowo, bez waluty w stringu. Najczęstszy błąd: `"value": "1234 zł"` zamiast `"value": 1234.00`.
• currency – kod ISO 4217, np. "PLN", "EUR", "USD". Bez tego GA4 wyświetli "(not set)" w raporcie waluty i nie przeliczy na domyślną walutę property.
• items – tablica produktów z `item_id`, `item_name`, `price`, `quantity`. Pusta tablica = 0 zł w produktach, mimo że value się zgadza.

Dodatkowo GA4 rozróżnia value od tax + shipping. Jeśli wrzucisz całą brutto kwotę do value i jednocześnie wypełnisz tax oraz shipping, dostaniesz podwójne liczenie. Poprawny model w Polsce (ceny brutto zgodnie z ustawą o prawach konsumenta): `value` = kwota netto produktów, `tax` = VAT, `shipping` = koszt wysyłki. Suma value + tax + shipping powinna równać się temu, co klient zapłacił.

Jeśli już widzisz 0 zł w raportach, sprawdź event w DebugView. Trzy najczęstsze patologie: value jako string, przecinek zamiast kropki w liczbie (Europa lubi "1234,50") i brak item_id w tablicy items. Zanim zaczniesz grzebać w kodzie, zerknij też czy wtyczka e-commerce, której używasz, nie ma swoich ustawień dotyczących formatu value – typowe problemy z integracją BaseLinker też generują błędy w trackingu. Jeśli wolisz delegować diagnostykę, zamów pełny audyt cyfrowy sklepu – w pakiecie dostajesz raport z DebugView, checklistę GTM oraz plan naprawy. Masz pilny temat? Zadzwoń na +48 604 939 140 albo napisz przez formularz kontaktowy.

Klient dokonuje zakupu, trafia na stronę "Dziękujemy za zamówienie", odświeża ją (F5) albo wraca strzałką wstecz – i GA4 liczy ten sam purchase ponownie. W raporcie widzisz 180 transakcji, a w panelu sklepu 120. Różnica 50% – i to nie są różnice techniczne, tylko czysta duplikacja.

Rozwiązanie jest jedno: deduplikacja po transaction_id. GA4 od 2023 roku ma wbudowany mechanizm wykrywania duplikatów – jeśli wyśle się event purchase z tym samym transaction_id w ciągu kilku godzin, Analytics odrzuci drugi. Ale to działa tylko wtedy, gdy faktycznie przekazujesz ten sam transaction_id.

Najczęstsze błędy, przez które deduplikacja nie działa:

1. Brak transaction_id w ogóle – event purchase leci bez tego parametru, GA4 nie ma jak rozpoznać duplikatu.
2. Różne transaction_id dla tego samego zamówienia – np. wtyczka generuje ID na podstawie timestamp, więc odświeżenie daje nowy numer.
3. Event odpalany w skrypcie strony, nie w dataLayer.push – przy odświeżeniu skrypt uruchamia się ponownie i wysyła kolejny hit.
4. Server-side tracking bez idempotency key – hook na status "completed" w WooCommerce odpala się przy każdej zmianie statusu.

Fix jest prosty: w GTM/gtag przekazuj `transaction_id` równy ID zamówienia z bazy sklepu (nie z sesji, nie z timestamp). W WooCommerce to jest `$order->get_id()`, w Shopify `checkout.order_id`, w PrestaShop `Order::getIdByCartId`. Po wprowadzeniu poprawki sprawdź w DebugView, że przy odświeżeniu strony "Thank You" event się nie powiela.

Dodatkowa warstwa zabezpieczenia: sessionStorage flag. Po wysłaniu purchase ustawiasz w przeglądarce flagę "purchase_sent_ORDERID" i przed kolejnym wysłaniem sprawdzasz, czy flaga istnieje. To nie zastępuje deduplikacji po transaction_id, ale chroni przed błędami w samym skrypcie. Problemy z konwersjami w Ads mają często tę samą przyczynę – więcej w artykule o problemach z konwersją w Google Ads, a o tym jak poprawnie skonfigurować śledzenie konwersji Google Ads piszemy w osobnym poradniku.

Trzeci klasyk: GA4 pokazuje 120 000 zł przychodu, a w panelu sklepu widzisz 98 000 zł. Różnica 22% – za duża na ad blockery, za mała na poważne luki w trackingu. Zwykle to efekt źle wydzielonych wartości podatku i wysyłki w evencie purchase.

GA4 ma trzy osobne pola finansowe w `purchase`:
- value – wartość towarów (powinno być netto lub brutto, ale konsekwentnie)
- tax – kwota podatku (VAT) osobno
- shipping – koszt wysyłki osobno

Jeśli wrzucisz brutto z wysyłką do `value` i jednocześnie wypełnisz `tax` oraz `shipping` liczbami, GA4 w raporcie Monetyzacja policzy to jako `value + tax + shipping`, czyli potroi część kwoty. Skutki: zawyżony ROAS w Google Ads (bo GA4 eksportuje wartość do Ads), błędne decyzje o skalowaniu budżetów, fałszywe średnie AOV.

Polski sklep w 99% przypadków operuje na cenach brutto (bo tak wymaga UOKiK dla B2C). Dlatego w polskich wdrożeniach najczęściej stosujemy dwa modele:

Model A – brutto bez rozbicia (najprostszy):

value = total_order_brutto
tax = 0
shipping = 0

Model B – brutto z rozbiciem (pełny):

value = suma_cen_produktów_brutto
tax = VAT_na_produktach
shipping = koszt_wysyłki_brutto

Która opcja lepsza? Dla większości sklepów – Model A. Daje prawdziwe liczby w raportach i nie wymaga gimnastyki przy pierwszej reklamacji od działu księgowości. Jeśli chcesz dokładnej analizy marży, lepiej zrobić to w BigQuery niż w GA4 UI. Dla platform typu Shopify warto sprawdzić, jak WooCommerce wypada w porównaniu z Shopify pod kątem trackingu – różne platformy różnie liczą podatki w payloadzie. Analogiczne rozbieżności widać w zestawieniu WooCommerce vs PrestaShop, gdzie każda z platform ma własny format eventu purchase.

DebugView to zakładka w GA4 (Administracja › DebugView), która pokazuje wydarzenia w czasie rzeczywistym, z pełnymi parametrami, dla konkretnej sesji oznaczonej flagą debug. To jest absolutna podstawa diagnostyki – bez DebugView grzebiesz po omacku.

Żeby włączyć tryb debug w przeglądarce, masz trzy opcje:

1. Chrome extension "GA Debugger" – najszybsze, jeden klik i lecimy.
2. Ręczne dodanie parametru `debug_mode: true` w konfiguracji gtag – działa tylko na Twojej sesji.
3. GTM Preview Mode – włączasz Preview w GTM, Twoja sesja automatycznie leci do DebugView.

Co konkretnie sprawdzać w DebugView przy problemach e-commerce:

• Czy event `purchase` się pojawia po zakończeniu zamówienia? Jeśli nie – problem z triggerem w GTM albo z gtag na stronie "Thank You".
• Czy ma wszystkie parametry (transaction_id, value, currency, items)? Kliknij event, rozwiń, zobacz co faktycznie przyszło.
• Czy value jest liczbą, nie stringiem? DebugView pokazuje typ – powinno być "number", nie "string".
• Czy tablica items nie jest pusta? Przy złej konfiguracji dataLayer często leci `items: []`.
• Czy user_id się przekazuje (dla zalogowanych klientów)? Pomaga w cross-device.

Poza DebugView warto mieć też Realtime (Raporty › Czas rzeczywisty) – tam zobaczysz zdarzenia ze wszystkich sesji. Realtime nie pokazuje jednak parametrów, więc do debugu konkretnego błędu używasz DebugView, do monitorowania ruchu – Realtime.

Trzecie narzędzie: GA4 Tag Assistant (tagassistant.google.com). Wklejasz URL, uruchamiasz sesję, klikasz przez lejek zakupowy – Tag Assistant pokazuje każdy event z parametrami. Dobra alternatywa, jeśli nie masz dostępu do panelu Analytics klienta. Jeśli to porównanie dla Ciebie za techniczne, zerknij do poradnika SEO vs PPC w sklepie internetowym – tam pokazujemy, jak interpretować raporty Akwizycja w kontekście budżetu reklamowego.

Najczęstsze pytanie na spotkaniach: "Dlaczego GA4 pokazuje 850 zamówień, a sklep 1020?". Odpowiedź: bo tak ma być. Różnica 10–20% między danymi z GA4 a panelem sklepu to normalna, oczekiwana rozbieżność, nie bug do naprawienia.

Powody, dla których GA4 zawsze pokaże mniej niż panel sklepu:

Dla sklepów B2C z polskim ruchem typowa rozbieżność to 12–18%. Jeśli widzisz więcej, szukaj błędu w konfiguracji (najczęściej: brak purchase na Thank You, duplikacja, brak fallbacku server-side). Jeśli mniej niż 5% – prawdopodobnie nie masz Consent Mode i łapiesz też użytkowników, którzy odrzucili ciasteczka (co od 2024 jest niezgodne z RODO).

Co zrobić, jeśli rozbieżność przekracza 25%:

1. Sprawdź DebugView po symulowanym zakupie – czy purchase się w ogóle odpala.
2. Zweryfikuj, czy nie filtrujesz IP biura albo własnego developmentu w Administracji › Filtry danych.
3. Upewnij się, że tag GA4 ładuje się na Thank You Page (często problem przy custom checkout).
4. Porównaj dane z Google Ads – jeśli Ads też pokazuje mniej konwersji, problem jest po stronie GA4.
5. Porównaj z Meta Pixel – to inny system, ale powinien pokazywać podobną kohortę ruchu.

Server-side tracking (GTM Server Container) rozwiązuje około 60% problemów z ad blockerami, ale kosztuje 20–80 $/mies. za hosting i kilka godzin wdrożenia. Ma sens przy sklepach robiących >500 zamówień/mies. Jeśli nie wiesz, od czego zacząć diagnostykę, umów konsultację lub napisz do nas – w 30 minut zidentyfikujemy, czy to kwestia trackingu czy realny spadek sprzedaży.

Najczęstszy dylemat właścicieli sklepów WooCommerce: iść w gotową wtyczkę (typu GTM4WP, CookieYes, PixelYourSite) czy wdrożyć Google Tag Manager Server Container? Obie opcje działają, ale sprawdzają się w innych scenariuszach.

Wtyczka e-commerce dla WordPress (client-side)

Plusy:
- Wdrożenie 30 minut, konfiguracja w admin panelu
- Koszt: darmowa lub 49–99 $/rok za Pro
- Obsługa out-of-the-box: WooCommerce, Easy Digital Downloads, WPForms
- Nie wymaga zewnętrznego hostingu

Minusy:
- Blokowana przez ad blockery (5–15% strat)
- Wszystko leci z przeglądarki – wolniejsze ładowanie strony
- Problemy z Safari ITP (cookie 7 dni)
- Ograniczona kontrola nad payloadem

Rekomendacja: GTM4WP + własny kontener GTM (darmowe). Wtyczka przekazuje wszystkie eventy e-commerce do dataLayer, Ty w GTM robisz tagi GA4 i Meta Pixel. To jest standard, który polecamy dla 80% sklepów WooCommerce. Przy konfiguracji warto sprawdzić też, czy nie masz równolegle problemów z Meta Pixel i konwersjami Facebooka – często jeden tag "zjada" drugiemu eventy.

GTM Server Container (server-side)

Plusy:
- Omija większość ad blockerów (dane lecą z serwera, nie przeglądarki)
- Własna subdomena dla trackingu (np. `m.twojsklep.pl`)
- Pełna kontrola nad danymi wysyłanymi do Google/Meta
- Obchodzi Safari ITP (long-lived cookies first-party)
- Lepsza wydajność strony (mniej JS client-side)

Minusy:
- Koszt hostingu: 20–80 $/mies. (Google Cloud, Stape, CustomGTM)
- Wdrożenie: 8–20 godzin pracy developera
- Trzeba znać GTM Server-side (to nie to samo co klasyczny GTM)
- Utrzymanie – monitoring, aktualizacje

Kiedy przejść na server-side? Gdy sklep robi >500 zamówień/mies., masz budżet reklamowy >10 000 zł/mies. i widzisz, że rozbieżność GA4 vs sklep przekracza 20% mimo poprawek w client-side. Dla małego sklepu robiącego 30 zamówień/mies. to overkill – koszty przewyższą korzyści. Jeśli szukasz profesjonalnej pomocy przy sklepie internetowym, warto od razu zaplanować architekturę trackingu. Zobacz też nasz przewodnik po problemach z Google Analytics w sklepie internetowym – tam opisujemy scenariusze migracji z UA.

Consent Mode v2 to mechanizm Google pozwalający na zbieranie danych analitycznych zgodnie z RODO, z poszanowaniem zgód użytkowników. Od marca 2024 jest obowiązkowy dla każdego, kto używa Google Ads z danymi z EU – bez niego nie zbudujesz audience'ów remarketingowych i nie odpalisz Enhanced Conversions.

Jak działa CMP v2:

1. Użytkownik wchodzi na stronę, pojawia się banner cookies (CookieBot, CookieYes, Cookiebot, Usercentrics).
2. Przed wyborem zgody do GA4 leci event z flagami `ad_storage=denied`, `analytics_storage=denied`, `ad_user_data=denied`, `ad_personalization=denied`.
3. Po wyborze flagi się aktualizują – jeśli zaakceptuje wszystko, wszystkie wartości zmieniają się na `granted`.
4. Google używa modelowania (behavioral modeling), żeby "dopowiedzieć" dane od użytkowników, którzy odrzucili cookies – bez naruszania ich prywatności.

Cztery flagi zgody:
- analytics_storage – Google Analytics, Tag Manager
- ad_storage – Google Ads cookies, konwersje
- ad_user_data – przekazywanie danych użytkownika do Ads
- ad_personalization – personalizacja reklam

Typowe błędy wdrożeniowe:

1. Brak default values przed banner cookies – jeśli nie ustawisz `consent default` zanim załaduje się CMP, pierwsze eventy lecą bez flag i nie będą modelowane.
2. Zły region (region: ['EU']) – CMP v2 musi mieć ustawiony region EU dla polskich użytkowników.
3. CMP nie aktualizuje gtag po wyborze zgody – banner pokazuje "zaakceptowano", ale do gtag nie leci `consent update`. Sprawdź w DebugView, czy event `consent_update` się pojawia po kliku w banner.
4. Brak flag `ad_user_data` i `ad_personalization` – to są nowe w v2, starsze implementacje mają tylko `ad_storage` i `analytics_storage`.

Warto też pamiętać, że Consent Mode v2 łączy się bezpośrednio z Customer Match w Google Ads – bez niego nie zrobisz list remarketingowych z danych o zakupach. Szczegóły w artykule o Customer Match w Google Ads. Prawidłowa konfiguracja consent mode i śledzenia konwersji w Google Ads to fundament skalowania budżetów reklamowych.

GA4 ma wbudowaną darmową integrację z Google BigQuery – możesz eksportować surowe dane eventów (raw data) do hurtowni danych i analizować je w SQL, PowerBI, Looker Studio albo własnych dashboardach. Dla wielu sklepów to zmiana jakości analityki, ale nie wszyscy tego potrzebują.

Co dostajesz z BigQuery export:

• Surowe eventy bez samplingu – w GA4 UI przy dużym ruchu widzisz próbkowane dane, w BigQuery masz komplet.
• Dostęp do parametrów user-level – pełny profil klienta, cross-device, custom dimensions bez limitów.
• Dłuższa historia – GA4 przechowuje eventy 14 miesięcy, BigQuery tak długo jak Ty zapłacisz za storage.
• Custom attribution – nie jesteś zamknięty w modelach Google'a, robisz własne Markov Chain albo Shapley Value.
• Integracja z CRM – łączysz dane zakupowe z danymi o klientach (sesje × wartość LTV × kanał akwizycji).

Koszty:

Dla sklepu robiącego 100 000 eventów/mies. (około 200 zamówień) realny koszt to 5–15 $/mies. Dla 1 mln eventów/mies. (około 2000 zamówień) – 30–80 $/mies.

Kiedy BigQuery export ma sens:

• Powyżej 100 000 eventów/mies. – standardowy próg.
• Używasz zaawansowanej atrybucji albo łączysz dane z CRM.
• Masz dedykowanego analityka (in-house lub agencyjnego).
• Audyty księgowe / wewnętrzne wymagają dłuższej historii danych.

Kiedy nie warto: mały sklep <50 zamówień/mies., brak kompetencji SQL w zespole, nie masz budżetu na analityka. W takim wypadku lepsze są gotowe rozwiązania analityczne dla sklepu – dashboard w Looker Studio podpięty bezpośrednio do GA4 UI załatwia 80% potrzeb za 0 zł.

Model atrybucji decyduje, któremu kanałowi przypisać konwersję, gdy klient miał wiele touch pointów przed zakupem. Klient kliknął w Twoją reklamę na Facebooku, potem przeszedł przez Google Ads, potem wrócił z newslettera i dopiero wtedy kupił – który kanał dostaje zasługę? To nie jest akademicka debata, to decyduje o alokacji budżetu reklamowego.

GA4 w 2026 oferuje cztery modele atrybucji:

1. Data-driven attribution (DDA) – domyślny od 2023. Algorytm ML Google'a rozdziela konwersję po touch pointach na podstawie ich faktycznego wpływu na zakup.
2. Last-click (paid and organic) – 100% dla ostatniego klikniętego kanału (pomija direct).
3. First-click – 100% dla pierwszego touch pointu w 30-dniowym oknie.
4. Cross-channel rules – legacy linear, time-decay, position-based (stare modele z UA).

Co wybrać? W 95% przypadków – data-driven. Google Ads od 2023 i GA4 od 2024 automatycznie migrują stare modele na DDA, bo pokazuje realny obraz lejka. Problem z last-click polega na tym, że faworyzuje kanały zamykające (brand search, retargeting), a deprecjonuje kanały akwizycji (display, YouTube, Facebook). Efekt: wyłączasz Display, bo "nie generuje konwersji", a tak naprawdę to on napędza ruch do brand search, który potem zbiera zasługi.

Kiedy last-click jest OK:
- Prosty lejek jednokanałowy (np. tylko SEO lub tylko Google Ads).
- Mały wolumen konwersji (<50/mies.) – DDA potrzebuje min. 300 konwersji/mies. żeby się "nauczyć".
- Chcesz porównywać dane z przeszłości vs teraz (spójność metody).

Kiedy pierwszy klik:
- Analiza kanałów akwizycji (nie sprzedażowych).
- Raporty marketingowe skupione na świadomości marki.
- Benchmark wobec modeli dystrybucji wydatków.

Ważne: zmiana modelu atrybucji nie zmienia faktycznej sprzedaży, tylko jej podział. Jeśli przełączysz z last-click na DDA, suma konwersji zostaje taka sama, ale rozkład po kanałach się zmieni (zwykle: mniej dla brand search i retargetingu, więcej dla display, YouTube i socials).

W GA4 atrybucję zmieniasz w Administracji › Ustawienia atrybucji. Okno konwersji: 30–90 dni dla kliku, 1 dzień dla view-through. Model wybrany tutaj wpływa na raporty Akwizycja i Monetyzacja – nie wpływa na dane w Google Ads (tam jest osobne ustawienie atrybucji).

Decyzje oparte o złą atrybucję potrafią położyć cały kanał reklamowy. Jeśli widzisz, że Facebook Ads "nie działa", zanim wyłączysz kampanie, sprawdź w modelu data-driven, ile tak naprawdę wniósł do lejka. Często okazuje się, że odpowiada za 15-20% całkowitych konwersji przez assisted paths, a last-click tego nie pokazywał. Więcej o tym, jak atrybucja konwersji w Google Ads wpływa na decyzje budżetowe, piszemy osobno. Jeśli chcesz porównać GA4 z alternatywami, rzuć okiem na Google Analytics 4 vs Matomo – Matomo bywa lepszy dla sklepów w EU ze względu na własny hosting danych.