6 czerwca 2026
GA4 w e-commerce — błędy wdrożenia, które fałszują Twoje dane
Wyobraź sobie, że przez rok podejmujesz decyzje budżetowe na podstawie danych o przychodach zawyżonych o kilkanaście procent. Albo że Twoje raporty pokazują ułamek rzeczywistej liczby użytkowników, bo wszystkie niezalogowane sesje w aplikacji skleiły się w GA4 w jedną osobę — przez jeden błąd w przekazywaniu identyfikatora użytkownika. Albo że zbierasz dziesiątki parametrów o produktach — merchant, coupon, delivery_type — ale w raportach widzisz tylko (not set), bo nikt nie zarejestrował tych parametrów w interfejsie GA4.
To nie są scenariusze z akademickiego podręcznika. To błędy wdrożenia GA4 e-commerce, które regularnie wychodzą podczas audytów — zarówno w warstwie webowej, jak i aplikacjach mobilnych.
Błędów może być znacznie więcej niż te opisane poniżej. Artykuł nie jest wyczerpującym przewodnikiem — to zestaw przypadków, z którymi spotkałem się w praktyce i które mają największy wpływ na jakość danych decyzyjnych.
1. Zdarzenie purchase odpala się przed potwierdzeniem płatności
To jeden z najpoważniejszych błędów pod względem wpływu biznesowego. Zdarzenie purchase powinno odpalić się po faktycznym potwierdzeniu zamówienia przez backend — nie na stronie płatności ani po kliknięciu “Zamawiam”.
Skutek: każda porzucona płatność (błąd karty, timeout, zmiana decyzji) jest liczona jako zrealizowana transakcja. GA4 raportuje przychód, którego nie ma. Rozbieżność rośnie proporcjonalnie do współczynnika porzuceń na etapie płatności.
Dlaczego deweloperzy implementują to błędnie: zewnętrzna bramka płatności (PayU, Przelewy24, Stripe) robi redirect z powrotem na /order-confirmation, gdzie przeglądarka dostaje tylko ?order_id=123 w URL. Koszyk wyczyszczony. Deweloper nie ma skąd zaciągnąć items, value, transaction_id — więc cofa event na etap przed płatnością, gdzie dane jeszcze są dostępne. Logiczne, ale technicznie błędne.
Prawidłowe podejścia:
- Backend renderuje dataLayer na stronie potwierdzenia — serwer właśnie przetworzył zamówienie i dysponuje wszystkimi danymi. Renderuje je do
dataLayerprzy budowaniu strony thank-you. Wymaga zaangażowania backendu, ale jest właściwą architekturą. - Measurement Protocol server-side — backend wysyła event
purchasebezpośrednio do GA4 przy potwierdzeniu zamówienia, bez udziału przeglądarki. Odporny na ad-blockery i utratę sesji — pokrewne podejście do tego, które opisałem w tekście o server-side GTM.
Jak to wykryć: porównaj liczbę transakcji GA4 z zamówieniami w systemie backend za ten sam okres. Rozbieżność powyżej 3–5% wymaga weryfikacji triggera i strony URL, na której odpala się event.
2. User ID = "none" dla niezalogowanych użytkowników
GA4 umożliwia łączenie sesji tego samego użytkownika na różnych urządzeniach i platformach dzięki parametrowi user_id. Problem pojawia się gdy implementacja wysyła wartość zastępczą — "none", "null", "undefined", "0", "guest" — dla każdego użytkownika niezalogowanego. Setki tysięcy anonimowych sesji dostaje jeden, identyczny user_id = "none".
Co GA4 z tym zrobi, zależy od tożsamości raportowania (Reporting Identity) ustawionej dla usługi — i to rozstrzyga, w którą stronę psują się dane:
- Blended / oparta na User-ID (domyślna):
user_idjest kluczem nadrzędnym. Wszystkie sesje zuser_id = "none"skleją się w jednego użytkownika. Efekt: drastyczne zaniżenie liczby użytkowników — raport pokazuje ułamek rzeczywistego audytorium. To poważniejszy, częściej spotykany wariant. - Oparta na urządzeniu:
user_idjest ignorowany, liczenie idzie po urządzeniu. Wtedy z kolei brak działającej deduplikacji zawyża liczbę użytkowników (reinstalacja aplikacji, drugie urządzenie = nowy “użytkownik”).
W obu przypadkach atrybucja kanałów dla niezalogowanych sesji jest niewiarygodna. Błąd jest szczególnie powszechny w aplikacjach mobilnych, gdzie user_id ustawia się globalnie — bez warunku sprawdzającego, czy użytkownik jest faktycznie zalogowany.
Prawidłowa implementacja: user_id wysyłaj wyłącznie gdy użytkownik jest zalogowany i masz jego faktyczny identyfikator. Dla niezalogowanych — nie wysyłaj parametru wcale (nie wartość zastępczą). gtag('set', { user_id: userId }) obuduj warunkiem.
3. Niespójny schemat zdarzeń między web a aplikacją mobilną
GA4 oferuje ujednolicone raportowanie web i app w ramach jednej właściwości — ale tylko wtedy, gdy oba kanały używają tego samego schematu zdarzeń. Klasyczny scenariusz: warstwa webowa wdrożona zgodnie z aktualną specyfikacją GA4 (zdarzenia purchase, add_to_cart, view_item z tablicą items), a aplikacja mobilna korzysta ze starego schematu Firebase — zdarzenie ecommerce_purchase, brak tablicy produktów, własne nazwy parametrów.
Powodem jest najczęściej historia: aplikacja była implementowana zanim Firebase wprowadził wsparcie dla tablicy produktów w jednym zdarzeniu. Rozwiązaniem tymczasowym było wysyłanie osobnych zdarzeń dla każdego produktu i osobno dla transakcji. To “rozwiązanie” często żyje latami.
Skutek: analiza ścieżki zakupowej na poziomie produktu jest niemożliwa między platformami. Funnel web vs app nie jest porównywalny. W jednym projekcie e-commerce podczas audytu naliczono ponad 400 unikalnych nazw zdarzeń w aplikacji — z czego znaczna część to warianty tego samego zdarzenia dla różnych produktów.
Wskaźnik ostrzegawczy: jeśli liczba unikalnych nazw zdarzeń w aplikacji przekracza kilkadziesiąt, prawdopodobnie masz zdarzenia generowane dynamicznie zamiast parametrów.
4. Parametry zbierane, ale niedostępne w raportach
Deweloper zaimplementował dziesiątki parametrów niestandardowych: merchant_id, coupon_text, delivery_type, is_subscription, product_categories. Dane lecą do GA4. Ale w raportach każda próba segmentacji po tych parametrach daje (not set).
Przyczyna: GA4 wymaga jawnego zarejestrowania każdego parametru niestandardowego jako wymiar niestandardowy (Custom Dimension) lub metryka niestandardowa w interfejsie administracyjnym (Admin → Custom Definitions). Dane nierejestrowane są przez GA4 ignorowane na potrzeby raportów — trafiają do BigQuery (jeśli jest skonfigurowane), ale UI ich nie pokazuje.
Powszechny wariant tego błędu: parametry są zarejestrowane, ale pod złą nazwą lub ze złym zakresem. Parametr zakresu event nie będzie dostępny na poziomie produktu (item). Zakres item jest dostępny dopiero od pewnej wersji GA4 i tylko dla konkretnych zdarzeń e-commerce.
Audyt: sprawdź Admin → Custom Definitions i porównaj z parametrami faktycznie wysyłanymi w dataLayer. Każdy parametr który chcesz analizować w raportach musi mieć swój wpis.
5. Consent Mode zaimplementowany błędnie
Zgodnie z wymogami prawnymi (i regulaminem Google) żadne dane identyfikujące użytkownika nie powinny trafiać do systemów analitycznych i reklamowych bez jego zgody. Google Consent Mode v2 jest mechanizmem informującym tagi GA4 i Google Ads o stanie zgód użytkownika.
Dwa najczęstsze błędy implementacyjne:
Na stronie webowej: zdarzenia wysyłane są do GA4 zanim użytkownik podejmie decyzję w banerze zgód — bez ustawionego parametru analytics_storage. Brak domyślnego stanu (gtag('consent', 'default', {...})) przed załadowaniem GTM powoduje, że pierwsze hity trafiają do Google bez żadnego oznaczenia.
W aplikacji mobilnej: domyślny stan zgody ustawiony jest na granted dla wszystkich typów (wartość G111 w parametrze gcs — pierwszy znak po G1 to ad_storage, drugi analytics_storage) — niezależnie od faktycznego wyboru użytkownika. Aplikacja traktuje każdego jako kogoś, kto zgodził się na wszystko.
Skutki wykraczają poza analitykę. Bez prawidłowo przekazywanych sygnałów zgody tracisz remarketing i listy odbiorców dla użytkowników z EOG oraz modelowanie konwersji w Google Ads, a w skrajnych przypadkach narażasz się na ograniczenia w korzystaniu z usług reklamowych Google. To nie jest wyłącznie problem techniczny — to ryzyko prawne i biznesowe.
6. Skażone źródła ruchu — błędy atrybucji
Atrybucja kanałów marketingowych jest tak dobra jak dane o źródłach ruchu. Trzy kategorie błędów które regularnie pojawiają się w audytach:
Self-referrals: domeny pośredniczące w ścieżce zakupowej — przede wszystkim zewnętrzne bramki płatności (przelewy24.pl, payu.com, stripe.com) — nie dodane do listy wykluczeń odsyłaczy. Po powrocie z bramki GA4 widzi nową sesję ze źródłem przelewy24.pl / referral i nadpisuje oryginalną atrybucję kampanii. Sesja z Google Ads ląduje jako “referral”, a konwersja przypisuje się bramce płatności zamiast realnemu źródłu. (Same subdomeny tej samej domeny GA4 zwykle obsługuje poprawnie — współdzielą cookie; problemem są domeny zewnętrzne i błędna konfiguracja cross-domain.)
Brak filtrowania ruchu wewnętrznego: ruch pracowników, testów QA i stagingu wchodzi do produkcyjnych danych. W małych firmach może to istotnie zaburzyć wskaźniki konwersji i zachowania na ścieżce zakupowej.
Niespójne UTM: utm_source=Google i utm_source=google to dwa różne źródła w GA4. Kampanie tagowane niejednolicie rozpadają się na kilka wierszy w raportach, utrudniając agregację.
UTM na linkach wewnętrznych nadpisujące źródło: to częsty błąd o odwrotnym mechanizmie niż się wydaje. Każde kliknięcie linku z parametrem utm_ resetuje atrybucję sesji — więc tagowanie linków wewnętrznych (banery onboardingu, “polecane produkty”) UTM-ami kasuje oryginalne źródło, z którego użytkownik przyszedł. Linki wewnętrzne nie powinny mieć UTM-ów. Osobny, przeciwny problem dotyczy linków wychodzących do aplikacji: deep linki i banery kierujące do Google Play często gubią oryginalne UTM-y i gclid, przez co instalacja z kampanii trafia do ruchu organicznego.
Każdy z tych błędów z osobna może prowadzić do mylących wniosków. Razem budują obraz narzędzia, które wygląda na działające, ale dostarcza danych którym nie można ufać. Audyt GA4 — szczególnie przed ważnymi decyzjami budżetowymi lub migracją platformy — powinien być standardowym elementem procesu, nie działaniem reagującym na zauważoną rozbieżność.