Dlaczego GA4 pokazuje inne przychody niż sklep internetowy? 12 najczęstszych przyczyn.

Przychód w sklepie internetowym wynosi 500 000 zł. W GA4 widzisz 430 000 zł. W panelu reklamowym jeszcze inną wartość. W raporcie dla zarządu pojawia się pytanie: "Które dane są prawdziwe?"

To bardzo częsta sytuacja w e-commerce. Różnice między GA4 a platformą sklepową nie są niczym wyjątkowym. W wielu przypadkach wynikają z naturalnych ograniczeń narzędzi analitycznych: zgód użytkowników, adblocków, opóźnień w raportowaniu, różnic w definicji przychodu, błędów atrybucji albo sposobu, w jaki GA4 przetwarza event purchase.

Problem polega na tym, że bez audytu trudno powiedzieć, czy różnica jest normalna, czy oznacza poważny błąd we wdrożeniu. A to ma znaczenie biznesowe:

• Jeśli GA4 zaniża sprzedaż, możesz niesłusznie ograniczyć budżet kampanii.
• Jeśli GA4 zawyża sprzedaż, możesz inwestować w kanał, który tylko pozornie wygląda dobrze.
• Jeśli GA4 źle przypisuje przychód do kanałów, cały raport marketingowy może prowadzić do błędnych decyzji.

Dlatego pytanie nie brzmi: "Dlaczego GA4 nie zgadza się ze sklepem?". Lepsze pytanie brzmi: czy wiemy, skąd bierze się różnica i czy ma ona wpływ na decyzje biznesowe?

1. GA4 i sklep internetowy mierzą różne rzeczy

Sklep jest systemem transakcyjnym. GA4 jest systemem analitycznym. Nie służą do tego samego.

W sklepie masz dane operacyjne:

• zamówienie, status płatności, status wysyłki,
• zwroty, anulacje, faktury,
• rabaty, koszty dostawy, dane klienta.

W GA4 masz dane analityczne:

• eventy użytkownika, źródła ruchu, sesje,
• konwersje, event purchase, ścieżki zakupowe,
• produkty w tablicy items, atrybucję marketingową.

GA4 nie jest systemem księgowym i nie powinno być traktowane jak źródło prawdy o finansach sklepu. Źródłem prawdy o zamówieniach jest platforma e-commerce lub system ERP. GA4 ma pomagać zrozumieć, skąd przyszła sprzedaż, jak zachowywali się użytkownicy i które elementy ścieżki zakupowej wymagają poprawy.

2. Różnica może wynikać ze zgód użytkowników i Consent Mode

Nie każdy użytkownik wyraża zgodę na analitykę. Część danych może nie zostać zebrana bezpośrednio. GA4 może pokazywać dane obserwowane i modelowane, jeśli spełnione są warunki dla modelowania behawioralnego.

• Użytkownik akceptuje cookies → eventy mogą być mierzone normalnie.
• Użytkownik odrzuca cookies → część danych może być ograniczona.
• Advanced Consent Mode może wysyłać cookieless pingi.
• Raporty GA4 mogą zawierać dane modelowane, a sklep nadal widzi zamówienie, bo operacyjnie ono istnieje.

Sklep widzi zamówienie, bo użytkownik je złożył. GA4 może go nie widzieć w ten sam sposób, bo pomiar analityczny zależy od zgód, identyfikatorów, cookies i konfiguracji Consent Mode. To jedna z podstawowych przyczyn, dla których GA4 i system sklepu nie będą identyczne.

Warto też sprawdzić ustawienie Reporting Identity w GA4. Do wyboru są trzy opcje:

• Blended (ustawienie domyślne) - kolejność: user-ID, Google Signals, Device ID, a na końcu modelowanie. Może uwzględniać dane modelowane.
• Observed - opiera się wyłącznie na danych obserwowanych, wyklucza modelowanie.
• Device-based - korzysta tylko z Device ID.

Ponieważ Blended jest domyślne, wiele usług modeluje dane, często nieświadomie. Przy porównaniu GA4 ze sklepem trzeba więc wiedzieć nie tylko, jakie eventy są wysyłane, ale też jak GA4 prezentuje dane w raportach.

3. Adblocki i ograniczenia przeglądarek mogą blokować część pomiaru

Narzędzia analityczne działające po stronie przeglądarki są podatne na blokady. Sklep nadal zarejestruje zamówienie, ale event analityczny może nie zostać wysłany.

Jeżeli użytkownik blokuje skrypty analityczne, sklep nadal może przyjąć zamówienie, ale GA4 może nie otrzymać pełnej informacji o zdarzeniu purchase. Dlatego różnica między sklepem a GA4 nie musi oznaczać błędu w samym sklepie. Może oznaczać ograniczenie pomiaru po stronie przeglądarki.

W bardziej dojrzałych wdrożeniach część danych zakupowych można przekazywać również przez Server-Side GTM albo Measurement Protocol. Takie podejście może ograniczyć część strat wynikających z pomiaru wyłącznie po stronie przeglądarki, ale wymaga bardzo dobrej kontroli nad deduplikacją, zgodami, transaction_id i definicją przychodu. Server-side nie naprawia złych danych. Może jedynie lepiej obsłużyć dobrze zaprojektowany pomiar.

4. Event purchase może uruchamiać się w złym momencie

Różnica w przychodach może wynikać nie z GA4 jako narzędzia, ale z błędnego wdrożenia eventu purchase. Typowe błędy:

• purchase wysyłany przed finalizacją płatności,
• brak purchase po niektórych metodach płatności,
• ponowne wysłanie po odświeżeniu strony,
• brak działania na mobile,
• brak działania po przekierowaniu z bramki płatniczej,
• purchase wysyłany przez kilka integracji jednocześnie.

Jeśli purchase uruchamia się za wcześnie, GA4 może zawyżać przychód. Jeśli nie uruchamia się po części płatności lub po powrocie z bramki płatniczej, GA4 może przychód zaniżać. Dlatego przy dużych różnicach pierwszym krokiem powinno być sprawdzenie, kiedy dokładnie wysyłany jest event zakupowy.

5. Brak lub błędny transaction_id utrudnia porównanie danych

Bez transaction_id nie da się dobrze porównać GA4 ze sklepem. Problemem może być:

• brak identyfikatora,
• identyfikator zmienny lub inny niż w sklepie,
• pusty transaction_id,
• jeden ID dla wielu zakupów,
• brak możliwości porównania zamówienie po zamówieniu.

Jeśli nie masz stabilnego transaction_id, porównujesz tylko sumy. A sumy często ukrywają prawdziwy problem. Dopiero porównanie zamówień po identyfikatorze pokazuje, które transakcje zostały zmierzone, które zniknęły, a które zostały zdublowane.

Osobno warto zwrócić uwagę na pusty identyfikator. GA4 deduplikuje razem wszystkie eventy purchase, które mają transaction_id="", więc niepowiązane zamówienia zostają sklejone w jedno, a sprzedaż jest aktywnie zaniżana.

6. GA4 może deduplikować część zakupów, ale nie naprawi złego wdrożenia

Deduplikację warto rozumieć, ale nie należy traktować jej jako strategii pomiaru. Tu trzeba być precyzyjnym, bo teoria i praktyka się rozjeżdżają.

Dokumentacja Google mówi wprost, że GA4 deduplikuje eventy purchase z tym samym transaction_id. W praktyce specjaliści regularnie raportują, że interfejs GA4 nie deduplikuje takich eventów w sposób spójny i przychód potrafi się dublować. Najbezpieczniejsze założenie: mechanizm jest dokumentowany, ale jego działanie bywa niespójne i zależne od konkretnego wdrożenia - nie buduj na nim raportowania.

Deduplikacja wymaga poprawnego, stabilnego identyfikatora transakcji. Czego nie zrobi za Ciebie:

• nie naprawi pustego, zmiennego lub niespójnego transaction_id,
• nie naprawi błędnej wartości value,
• nie naprawi wysyłania zakupów z różnych integracji bez kontroli,
• nie zastąpi testów w GTM Preview, DebugView i BigQuery.

Deduplikacja nie jest strategią pomiaru. To mechanizm ochronny. Jeżeli sklep wysyła błędne eventy zakupowe, problem trzeba naprawić u źródła: w dataLayer, GTM, wtyczce, kodzie sklepu albo integracji server-side.

7. Przychód w GA4 może być liczony według innej definicji

To jeden z najważniejszych punktów, bo "przychód" nie zawsze znaczy to samo. Różnice mogą wynikać z:

• ujęcia brutto vs netto,
• z VAT lub bez VAT,
• z dostawą lub bez dostawy,
• po rabacie lub przed rabatem,
• z kodami rabatowymi lub bez,
• sposobu liczenia anulacji i zwrotów,
• relacji między value, tax, shipping i sumą items.

Często problem nie polega na tym, że GA4 źle liczy przychód. Problem polega na tym, że firma nie wie, jaką definicję przychodu wysyła do GA4. Jeżeli sklep raportuje wartość brutto z dostawą, a GA4 otrzymuje wartość netto bez dostawy, oba systemy będą pokazywać inne liczby - i oba mogą być poprawne w ramach swojej definicji.

W sklepach działających na wielu rynkach dochodzi jeszcze kwestia VAT. Inaczej może wyglądać sprzedaż raportowana dla Polski, inaczej dla Niemiec czy Czech, zwłaszcza jeśli raporty porównują wartości brutto, netto albo dane po przeliczeniu waluty. Dlatego przy audycie trzeba ustalić nie tylko wartość zamówienia, ale też to, czy value zawiera VAT i czy definicja jest spójna między rynkami.

8. Waluta może być źle przekazywana albo przeliczana

W sklepach multi-country i multi-currency różnice mogą wynikać z waluty i przeliczeń:

• brak parametru currency,
• błędna waluta,
• sklep raportuje PLN, a property GA4 ma EUR lub USD,
• różne kursy walut,
• porównywanie lokalnych przychodów z raportem w jednej walucie.

Różnice w przychodach mogą wynikać nie z błędu sprzedaży, ale z przeliczania walut. Dlatego przy audycie trzeba sprawdzić nie tylko value, ale też currency i ustawienia waluty w samej usłudze GA4.

9. Rabaty i kody promocyjne mogą być inaczej traktowane

Promocje są częstym źródłem różnic:

• sklep pokazuje cenę po rabacie, a GA4 dostaje cenę przed rabatem,
• brak parametru coupon,
• rabat rozłożony na produkty vs rabat liczony na poziomie koszyka,
• darmowa dostawa jako promocja,
• raportowanie rabatów bez uwzględnienia marży.

Jeżeli sklep intensywnie korzysta z promocji, kodów rabatowych i dynamicznych zniżek, brak konsekwentnego przekazywania rabatów do GA4 może mocno zniekształcić analizę sprzedaży. Przychód może wyglądać poprawnie na poziomie całego zamówienia, ale analiza produktu, kategorii albo kampanii będzie niepełna.

10. Zwroty i anulacje zwykle nie są widoczne w GA4 tak jak w sklepie

System sklepu żyje po transakcji. GA4 najczęściej mierzy moment zakupu.

• GA4 rejestruje purchase w chwili zakupu.
• Zwrot może nastąpić po kilku dniach, anulowanie po płatności.
• Sklep aktualizuje status zamówienia, GA4 nie zawsze jest korygowane o zwroty.
• Bez importu lub eventów refund różnice będą naturalne.

Sklep wie, że zamówienie zostało zwrócone albo anulowane. GA4 często widzi tylko pierwotny event purchase. Jeżeli zwroty nie są raportowane do GA4 albo nie są analizowane oddzielnie, przychód w GA4 i przychód operacyjny sklepu będą się różnić.

11. Bramki płatności mogą zaburzać atrybucję sprzedaży

To nie zawsze zmienia całkowity przychód, ale może zmienić źródło przychodu i sposób liczenia sesji. Użytkownik wychodzi do operatora płatności (PayU, Przelewy24, PayPal, Stripe, Klarna), a po powrocie na stronę podziękowania GA4 może:

• przypisać sprzedaż do bramki płatniczej (problem unwanted referrals),
• utworzyć nową sesję po powrocie z płatności,
• zaburzyć kontekst cross-domain, _gl i server-side tagging.

Warto odróżnić dwa problemy: sumę przychodu i przypisanie przychodu do źródła. Bramki płatności często nie zmieniają łącznej wartości sprzedaży w GA4, ale mogą zmienić informację o tym, który kanał marketingowy tę sprzedaż wygenerował. A to wystarczy, żeby źle ocenić kampanię.

Problem z bramką może dotyczyć też sesji. Jeśli powrót od operatora płatności zostanie potraktowany jako nowe wejście, GA4 może stworzyć dodatkową sesję. Wtedy zniekształcona jest nie tylko atrybucja, ale również metryki sesyjne, w tym współczynnik konwersji liczony na poziomie sesji.

12. Różnice mogą wynikać z opóźnień i zakresu raportowania

Czas, strefy czasowe, zakres raportu i świeżość danych mają znaczenie. Częste pułapki:

• różne strefy czasowe,
• opóźnienia w raportach,
• porównywanie "dziś vs wczoraj",
• raportowanie po dacie zakupu vs dacie zaksięgowania płatności,
• eksport BigQuery vs raporty UI,
• filtry i segmenty w raportach.

Zanim uznasz, że GA4 pokazuje błędny przychód, upewnij się, że porównujesz ten sam okres, tę samą strefę czasową, tę samą definicję zamówienia i ten sam typ danych. W praktyce wiele "błędów GA4" okazuje się błędami w samym porównaniu.

Trzeba też uważać na świeżość danych. Dane w raportach GA4 mogą zmieniać się jeszcze przez 24-48 godzin, ponieważ Analytics przetwarza zdarzenia, źródła ruchu, atrybucję i mechanizmy związane z prywatnością. Dlatego audytu różnic nie warto robić na danych "z dziś" ani często nawet "z wczoraj". Bezpieczniej analizować okres sprzed kilku dni, kiedy dane są już bardziej kompletne.

Jak praktycznie diagnozować różnice między GA4 a sklepem

Nie zaczynaj od pytania: "Dlaczego GA4 się nie zgadza?". Zacznij od pytania: "Na których zamówieniach dokładnie się nie zgadza?". Dopiero zejście z poziomu sum do poziomu transaction_id pozwala odróżnić naturalną różnicę od błędu wdrożeniowego.

Proponowana procedura:

1. Ustal, która liczba jest źródłem prawdy finansowej - zwykle sklep lub ERP.
2. Sprawdź, co dokładnie oznacza przychód w sklepie.
3. Sprawdź, co dokładnie wysyłasz w value.
4. Porównaj transakcje po transaction_id.
5. Policz procent pokrycia transakcji.
6. Zidentyfikuj zamówienia brakujące w GA4.
7. Zidentyfikuj zamówienia zdublowane w GA4.
8. Sprawdź metody płatności, które powodują najwięcej różnic.
9. Sprawdź urządzenia i przeglądarki.
10. Sprawdź wpływ zgód i Consent Mode.
11. Sprawdź Reporting Identity: Blended, Observed czy Device-based.
12. Sprawdź bramki płatności jako referral.
13. Sprawdź, czy powrót z płatności nie tworzy nowej sesji.
14. Sprawdź dane w BigQuery.
15. Wykonaj testowe zamówienia end-to-end.

W praktycznym audycie warto policzyć procent pokrycia transakcji, czyli jaki procent zamówień ze sklepu ma odpowiadający transaction_id w GA4. Jeśli sklep ma 1000 zamówień, a w GA4 odnajdujesz 930 unikalnych transaction_id, pokrycie wynosi 93%. Sama liczba nie mówi jeszcze, czy wdrożenie jest dobre, ale pozwala ocenić skalę problemu i monitorować ją w czasie.

Test end-to-end powinien obejmować pełną ścieżkę z bramką płatności: wejście z oznaczonej kampanii UTM, dodanie produktu do koszyka, przejście przez checkout, wybór płatności online, przekierowanie do operatora, powrót na stronę potwierdzenia i wysłanie eventu purchase. Dopiero taki test pokazuje, czy problem dotyczy samego eventu zakupowego, powrotu z płatności, utraty źródła ruchu, stworzenia nowej sesji czy błędnego przekazania wartości transakcji.

Przykładowe zapytania SQL do BigQuery

W standardowym eksporcie GA4 do BigQuery dane transakcyjne są dostępne w natywnym rekordzie ecommerce, między innymi jako ecommerce.transaction_id, ecommerce.purchase_revenue i ecommerce.total_item_quantity. Dlatego przy analizie transakcji warto w pierwszej kolejności korzystać z tych pól, a nie wyłącznie z event_params.

Ważna uwaga: dane modelowane (te, które GA4 dolicza przy Reporting Identity = Blended) nie są eksportowane do BigQuery. Przy ustawieniu Blended panel GA4 może pokazywać więcej użytkowników i konwersji niż BigQuery, nawet jeśli wdrożenie jest poprawne. BigQuery to surowe dane zdarzeń, więc traktuj go jako źródło "obserwowanej" prawdy o eventach, a nie jako lustro raportów z interfejsu.

Zapytanie 1: lista transakcji z GA4

SELECT
  event_date,
  event_timestamp,
  ecommerce.transaction_id,
  ecommerce.purchase_revenue AS revenue,
  ecommerce.total_item_quantity
FROM `project.dataset.events_*`
WHERE event_name = 'purchase'
  AND _TABLE_SUFFIX BETWEEN '20260101' AND '20260131'
  AND ecommerce.transaction_id IS NOT NULL;

To zapytanie pobiera listę transakcji z natywnego rekordu ecommerce. Dzięki temu można porównać transaction_id i przychód z GA4 z eksportem zamówień ze sklepu. Jeśli ecommerce.transaction_id jest puste, a identyfikator zamówienia znajduje się wyłącznie w event_params, warto sprawdzić, czy event purchase jest poprawnie wysyłany zgodnie ze schematem e-commerce GA4.

Zapytanie 2: duplikaty transakcji

SELECT
  ecommerce.transaction_id,
  COUNT(*) AS purchase_events,
  SUM(ecommerce.purchase_revenue) AS total_revenue
FROM `project.dataset.events_*`
WHERE event_name = 'purchase'
  AND _TABLE_SUFFIX BETWEEN '20260101' AND '20260131'
  AND ecommerce.transaction_id IS NOT NULL
GROUP BY ecommerce.transaction_id
HAVING COUNT(*) > 1
ORDER BY purchase_events DESC;

To zapytanie pokazuje transaction_id, które pojawiają się w eksporcie GA4 więcej niż raz. BigQuery pokazuje dane eventowe bardziej surowo niż raporty w interfejsie GA4, więc taki wynik powinien być punktem startowym do diagnozy, a nie automatycznym dowodem na zawyżenie sprzedaży w raportach.

Zapytanie 3: procent pokrycia transakcji

Ten fragment wymaga dwóch źródeł: tabeli z zamówieniami ze sklepu (np. shop_orders) oraz tabeli lub widoku z transakcjami z GA4 (np. ga4_purchases). Eksportujesz listę zamówień ze sklepu z kolumną order_id, wyciągasz listę transaction_id z GA4 i porównujesz oba zbiory.

SELECT
  COUNT(DISTINCT shop.order_id) AS shop_orders,
  COUNT(DISTINCT ga4.transaction_id) AS matched_ga4_orders,
  SAFE_DIVIDE(
    COUNT(DISTINCT ga4.transaction_id),
    COUNT(DISTINCT shop.order_id)
  ) AS ga4_coverage_rate
FROM `project.dataset.shop_orders` AS shop
LEFT JOIN `project.dataset.ga4_purchases` AS ga4
  ON CAST(shop.order_id AS STRING) = ga4.transaction_id;

Zanim zaufasz wynikowi, sprawdź, czy identyfikatory faktycznie da się dopasować. W praktyce sklep i GA4 często formatują je inaczej (np. 1234 vs #1234, prefiks rynku, wiodące zera). Jeśli formaty się różnią, najpierw znormalizuj order_id i transaction_id po obu stronach (TRIM, usunięcie prefiksów, ujednolicenie typu), inaczej pokrycie będzie sztucznie zaniżone.

Sam wynik nie odpowiada jeszcze na pytanie, czy GA4 jest "dobre" albo "złe". Pokazuje skalę pokrycia. Jeśli pokrycie wynosi 97%, sytuacja wygląda inaczej niż przy 62%. Dopiero potem warto sprawdzić, które zamówienia wypadają z pomiaru i czy łączy je wspólny wzorzec: konkretna metoda płatności, urządzenie, przeglądarka, rynek albo status zgody.

Checklista: dlaczego GA4 pokazuje inne przychody niż sklep?

1. Czy porównujesz ten sam zakres dat?
2. Czy GA4 i sklep mają tę samą strefę czasową?
3. Czy porównujesz dane wystarczająco dojrzałe, a nie dane z dziś lub wczoraj?
4. Czy porównujesz przychód brutto czy netto?
5. Czy przychód zawiera koszt dostawy?
6. Czy przychód uwzględnia rabaty?
7. Czy przychód uwzględnia VAT w taki sam sposób?
8. Czy sklep uwzględnia zwroty i anulacje?
9. Czy GA4 otrzymuje event purchase dla wszystkich metod płatności?
10. Czy event purchase nie uruchamia się za wcześnie?
11. Czy purchase nie dubluje się po odświeżeniu strony?
12. Czy każda transakcja ma poprawny transaction_id?
13. Czy żaden purchase nie jest wysyłany z pustym transaction_id?
14. Czy transaction_id w GA4 da się połączyć z zamówieniem w sklepie (po normalizacji formatu)?
15. Czy znasz procent pokrycia transakcji między sklepem a GA4?
16. Czy value i currency są poprawnie przekazywane?
17. Czy rabaty i coupon są wysyłane konsekwentnie?
18. Czy dane produktowe w items są kompletne?
19. Czy Consent Mode ogranicza część pomiaru?
20. Czy w raportach mogą być dane modelowane?
21. Czy sprawdzono Reporting Identity: Blended, Observed czy Device-based?
22. Czy adblocki lub ograniczenia przeglądarek mogą wpływać na pomiar?
23. Czy bramki płatności nie zaburzają atrybucji?
24. Czy powrót z bramki płatności nie tworzy nowej sesji?
25. Czy rozróżniasz problem sumy przychodu od problemu atrybucji?
26. Czy dane w BigQuery potwierdzają dane z panelu GA4 - i czy pamiętasz, że dane modelowane nie trafiają do BQ?
27. Czy wykonano testowe zamówienie end-to-end?
28. Czy różnica jest stabilna, czy pojawia się tylko w konkretnych scenariuszach?

Podsumowanie

Różnice między GA4 a sklepem internetowym są normalne. Problemem nie jest sama różnica. Problemem jest brak wiedzy, skąd ta różnica się bierze.

GA4 nie powinno być traktowane jako system księgowy ani źródło prawdy o finansach e-commerce. Od tego jest platforma sklepu, ERP albo system transakcyjny. GA4 ma inne zadanie: pomóc zrozumieć zachowanie użytkowników, skuteczność kanałów marketingowych i jakość ścieżki zakupowej.

Dlatego nie chodzi o to, żeby GA4 zawsze zgadzało się ze sklepem co do złotówki. Chodzi o to, żeby dane były wystarczająco wiarygodne do podejmowania decyzji:

• Jeżeli różnica wynika ze zgód użytkowników, modelowania, adblocków, opóźnień w przetwarzaniu albo świadomej definicji przychodu - można ją opisać i uwzględnić w raportowaniu.
• Jeżeli wynika z błędnego eventu purchase, braku transaction_id, duplikacji transakcji, złej waluty albo problemu z bramką płatności - trzeba ją naprawić.

Bo w e-commerce niebezpieczne nie są dane, które różnią się od siebie. Niebezpieczne są dane, którym ufamy, mimo że nie rozumiemy, jak powstały.