Dlaczego Google Analytics nie pokazuje przychodu?

Otwierasz pulpit GA4 po udanym dniu sprzedażowym i widzisz to: 0 złotych. Zero przychodu. Nic. Znam to uczucie aż za dobrze. Zamówienia były, płatności spłynęły, klienci dostali potwierdzenia, a Google Analytics 4 twierdzi, że nic się nie wydarzyło.

Jeśli prowadzisz sklep na Shopify, WooCommerce albo innej platformie i wpadłeś w tę samą pułapkę, mam dobrą wiadomość. To nie jest usterka bez rozwiązania. To jeden z kilku konkretnych, powtarzalnych błędów. Widziałem je już dziesiątki razy u różnych klientów i niemal zawsze chodzi o te same pięć rzeczy.

To nie jest problem kosmetyczny. Gdy GA4 nie widzi przychodu, tracisz coś więcej niż ładny wykres. Tracisz wiedzę o tym, czy kampanie reklamowe w ogóle się zwracają. To jak jazda samochodem z zaklejonym licznikiem paliwa.

Przejdźmy więc po kolei przez najczęstsze przyczyny.

Czy wysyłasz wszystkie potrzebne parametry zakupu?

Zacznijmy od podstaw, bo to tutaj najczęściej tkwi problem.

Żeby GA4 w ogóle zarejestrował przychód, potrzebuje trzech konkretnych informacji przy zdarzeniu zakupu:

1. transaction_id – unikalny identyfikator dla każdego zamówienia;

2. value – wartość liczbowa, bez żadnych symboli walut;

3. currency – kod waluty w formacie ISO, na przykład PLN, USD czy EUR.

Brzmi prosto. W praktyce wystarczy pominąć jeden z tych parametrów albo przesłać go w złym formacie, a GA4 nie zaliczy przychodu. Widziałem sklepy, które wysyłały wartość jako „599.99 zł” zamiast czystej liczby „599.99”. GA4 traktuje taki zapis jako błędne dane i po prostu je ignoruje. Widziałem też konfiguracje, w których pole „currency” w ogóle nie istniało. Ktoś zapomniał je dodać na etapie wdrożenia i przez tygodnie nikt tego nie zauważył.

Jeśli korzystasz z integracji przez Google Tag Manager albo z gotowych pikseli w Shopify, sprawdź dokładnie warstwę danych (dataLayer) oraz schemat zdarzeń. To tam najczęściej dzieje się „magia”, albo jej brak. Upewnij się też, że dane na poziomie produktu (item_id, item_name, price, quantity) są przekazywane i poprawnie mapowane na zmienne w tagu.

Szybki test, który możesz zrobić od razu. Otwórz w GA4 widok DebugView, dokonaj testowego zakupu na swojej stronie i sprawdź w czasie rzeczywistym, czy wszystkie te wartości faktycznie się pojawiają. Jeśli czegoś brakuje, masz namierzony problem w kilka minut, bez zgadywania.

Czy poprawnie nazywasz zdarzenie transakcji?

To jeden z tych błędów, które brzmią błaho, a potrafią kosztować tygodnie brakujących danych. Zdarzenie odpowiedzialne za rejestrowanie przychodu w GA4 musi nazywać się dokładnie „purchase”. Nie „completed_purchase”. Nie „orderSuccess”. Żadna kreatywna wariacja. GA4 jest tu bezwzględny. Jeśli nazwa się nie zgadza co do litery, system nie rozpozna zdarzenia jako zakupu, niezależnie od tego, jak poprawne dane w nim wysyłasz.

Pomagałem klientom naprawiać śledzenie dokładnie w ten sposób. Samą zmianą nazwy zdarzenia w GTM albo w konfiguracji tagu serwerowego. Czasem to pięć minut pracy, które odblokowuje tygodnie zaległych, „niewidzialnych” przychodów.

Jest jeszcze pułapka związana z timingiem. Zdarzenie musi zostać wywołane po pełnym załadowaniu dataLayer albo strony. Jeśli wystrzeli za wcześnie, niektóre parametry mogą jeszcze nie istnieć w momencie wysyłki.

Sposoby wdrożenia GA4 na stronie mogą się różnić. dataLayer bywa generowany przez gotową wtyczkę albo dodawany ręcznie przez programistę. Warto, żebyś wiedział, jak to wygląda w Twoim serwisie. Zwróć też uwagę, że dataLayer może mieć format ze starszej wersji Universal Analytics albo format właściwy dla GA4. Tagi GA4 poradzą sobie z odwołaniem do danych w obu formatach, ale tylko wtedy, gdy w tagu wskażesz właściwe pole. W drugą stronę to nie zadziała.

Zanim zaczniesz szukać bardziej egzotycznych przyczyn, upewnij się, że:

1. dataLayer w ogóle jest obecny na stronie;

2. przekazuje poprawne, kompletne dane;

3. prawidłowo przechwytujesz te dane do zmiennych w GTM;

4. Twoje tagi GA4 mają dodane właściwe parametry zdarzenia.

Czy poprawnie wdrożyłeś baner cookies?

Czasem cała konfiguracja techniczna jest bez zarzutu, a przychód i tak nie chce się pojawić. Wtedy warto spojrzeć w zupełnie inną stronę: na zgody użytkownika.

Banery cookies mogą blokować wysyłkę zdarzenia GA4, dopóki użytkownik nie wyrazi zgody na śledzenie. Jeśli ta zgoda nigdy nie zostanie udzielona (a zdarza się to częściej, niż myślisz), zdarzenie „purchase” po prostu nigdy się nie uruchomi. Nie zniknie gdzieś po drodze. Ono nigdy nie zaistnieje.

Jest to szczególnie dotkliwe, gdy Tryb zgody Google w wersji drugiej (Consent Mode v2) nie jest skonfigurowany poprawnie. To narzędzie ma pomagać w modelowaniu danych nawet przy braku pełnej zgody, ale przy niekompletnym wdrożeniu efekt bywa odwrotny. Zamiast częściowych danych, nie masz żadnych.

Czy posiadasz odpowiednie uprawnienia?

Do tego wszystkiego dochodzi kwestia uprawnień na koncie GA4. Twoje konto może nie mieć włączonej widoczności danych o przychodach i kosztach. To osobne ustawienie, niezależne od tego, czy śledzenie działa technicznie poprawnie. Sprawdź to w ustawieniach uprawnień albo poproś o to administratora usługi. W praktyce chodzi o dwa checkboxy na dole listy uprawnień. Powinny być odznaczone, żebyś mógł zobaczyć dane kosztowe i przychodowe.

Opóźnienia w raportowaniu transakcji

I jeszcze jedna rzecz, o której warto pamiętać, zanim wpadniesz w panikę. Raporty GA4 nie działają w czasie rzeczywistym. Standardowe raporty o przychodach mogą pojawić się dopiero po 24, a nawet 48 godzinach od zdarzenia. Jeśli więc sprawdzasz dane godzinę po zakupie testowym i widzisz pustkę, to niekoniecznie oznacza błąd. Użyj w takiej sytuacji DebugView oraz raportów Realtime, żeby potwierdzić, czy śledzenie w ogóle się uruchamia, zanim zaczniesz szukać winy w kodzie.

Czy poprawnie wdrożyłeś śledzenie serwerowe?

Tagowanie po stronie serwera (server-side tagging) to świetne rozwiązanie, ponieważ poprawia wydajność strony, omija część blokad przeglądarkowych i zwiększa dokładność danych. Ale ma też swoją cenę. Źle skonfigurowane, potrafi ukryć przychody równie skutecznie jak baner cookies bez zgody.

Jeśli korzystasz z konfiguracji serwerowej, sprawdź trzy rzeczy.

Po pierwsze, znacznik czasu zdarzenia musi mieścić się w dozwolonym przez GA4 przedziale. Zwykle jest to 72 godziny. Dane z opóźnieniem większym niż ten limit GA4 może po prostu odrzucić.

Po drugie, kluczowe parametry, czyli value, currency, transaction_id, muszą zostać jednoznacznie przekazane w konfiguracji serwerowej. To, że działały poprawnie po stronie klienta, nie gwarantuje, że tak samo trafią przez serwer. To dwie osobne ścieżki, każdą trzeba zweryfikować osobno.

Po trzecie, upewnij się, że zdarzenia nie duplikują się jednocześnie po stronie klienta i serwera. Duplikacja to problem odwrotny do zerowego przychodu. Zamiast go nie widzieć, widzisz go podwójnie.

Jeśli korzystasz z gotowej wtyczki do tagowania serwerowego, część z tych przypadków bywa obsługiwana automatycznie. Jeśli sam hostujesz swój serwer GTM albo korzystasz z platform typu Stape, odpowiedzialność za poprawne przekazywanie parametrów spoczywa w całości na Twojej konfiguracji.

Czy korzystasz z prawidłowych zmiennych w GTM?

To sedno sprawy, do którego prędzej czy później dochodzi niemal każdy przypadek zerowego przychodu. Chodzi o zmienne w Google Tag Managerze.

Załóżmy, że konfiguracja tagów w GTM i sam dataLayer wyglądają poprawnie. Skąd więc wciąż brak danych przychodowych? Najczęściej powodem jest brak pola currency wśród parametrów w tagu zdarzenia purchase.

Warto zrozumieć, dlaczego to akurat stało się problemem. W starszej wersji Universal Analytics tagi samodzielnie przechwytywały kod waluty (currencyCode) z dataLayer, a jeśli go zabrakło, system automatycznie stosował walutę z ustawień widoku. To był swego rodzaju bezpiecznik.

W GA4 ten mechanizm zniknął. Musisz ręcznie zdefiniować pole currency w tagu i przekazać do niego odpowiednią wartość (w formacie trzyliterowego kodu waluty, np. „PLN”). Żadnego automatycznego bezpiecznika już nie ma.

Jeśli Twój sklep sprzedaje wyłącznie w jednej walucie, teoretycznie możesz wpisać wartość statyczną wprost w tagu. Zadziała, ale odradzam takie rozwiązanie. Jest sztywne i pierwsza zmiana w ofercie albo ekspansja na inny rynek sprawi, że dane znów się posypią. Lepszym podejściem jest przekazywanie kodu waluty w dataLayer, a następnie wyciągnięcie go do zmiennej typu „Zmienna warstwy danych” (lub „Data Layer Variable”) w GTM.

Tu pojawia się szczegół, o którym łatwo zapomnieć: nazwa zmiennej różni się w zależności od formatu dataLayer, z którego korzystasz.

1. Jeśli Twój dataLayer pochodzi jeszcze z ery Universal Analytics (GA3), pole to nazywa się „ecommerce.currencyCode”.

2. Jeśli dataLayer jest już w formacie natywnym dla GA4, poszukasz go pod nazwą „ecommerce.currency”.

Oczywiście zawsze istnieje możliwość, że w Twoim konkretnym wdrożeniu pole z kodem waluty nazywa się inaczej. dataLayer można zbudować na wiele sposobów. W takim przypadku musisz dopasować nazwę zmiennej w GTM do rzeczywistej struktury danych na Twojej stronie, a nie kopiować schemat z tutoriala jeden do jednego.

Jak sprawdzić to wszystko krok po kroku?

Zamiast zgadywać, który z powyższych punktów dotyczy Twojego sklepu, przejdź przez prosty, powtarzalny proces diagnostyczny. Ja stosuję go za każdym razem, gdy dostaję zgłoszenie „GA4 nie pokazuje przychodów” i zwykle znajduję źródło problemu w kilkanaście minut.

1.Zrób testowy zakup na swojej stronie.

2. Sprawdź w DebugView, czy widzisz zdarzenie purchase z parametrami value, currency i transaction_id.

3. Otwórz Chrome DevTools, wejdź w zakładkę Sieć i przefiltruj żądania po frazie collect?v=2.

4. Sprawdź, czy w tych żądaniach faktycznie znajdują się poprawne parametry przychodowe.

5. Na koniec porównaj liczby z GA4 z rzeczywistą liczbą zamówień w panelu swojego sklepu.

Jeśli DebugView wygląda poprawnie, ale standardowe raporty pozostają puste, najprawdopodobniej masz do czynienia z opóźnieniem w przetwarzaniu danych albo z zablokowaną zgodą użytkownika, a nie z błędem technicznym w samej konfiguracji.

Najczęściej zadawane pytania

Dlaczego GA4 nie wykazuje przychodów, mimo że mam sprzedaż? Zwykle chodzi o brakujące lub nieprawidłowe parametry (value, transaction_id), błędnie nazwane zdarzenie albo brak uprawnień na koncie.

Czy tagowanie po stronie serwera może zakłócić śledzenie przychodów? Tak, jeśli nie przekażesz wymaganych parametrów albo wyślesz dane poza dopuszczalnym zakresem znacznika czasu.

Jak długo trzeba czekać, aż przychody pojawią się w GA4? DebugView pokazuje dane niemal natychmiast, standardowe raporty potrzebują 24–48 godzin.

Podsumowanie

Śledzenie przychodów w GA4 jest potężnym narzędziem, ale też rygorystycznym. Jeden drobny błąd, jedna literówka w nazwie zdarzenia, jedno brakujące pole currency, i możesz stracić dni albo tygodnie wiarygodnych danych.

Nie pozwól, żeby zerowy raport przychodowy zaczął wypaczać Twoje decyzje biznesowe. Przejdź po kolei przez pięć punktów z tego artykułu: parametry zdarzenia, nazwa zdarzenia, zgody użytkownika, konfiguracja serwerowa i zmienne w GTM. W zdecydowanej większości przypadków, z którymi się spotkałem, problem tkwił dokładnie w jednym z nich.