GA4 vs CRM: skąd rozbieżności w danych i której liczbie ufa zarząd

Aktualizacja: 30 września 2026 · Autor: Szymon Sanecznik, SEMownia

Na spotkaniu zarządu dział sprzedaży pokazuje przychód z CRM, marketing przychód z GA4, a finanse kwotę z faktur. Trzy liczby, żadna się nie zgadza. Po kwadransie dyskusja przestaje dotyczyć biznesu i zaczyna krążyć wokół tego, czyj raport jest „prawdziwy”, a z mojego doświadczenia najczęściej kończy się to utratą zaufania do analityki i decyzjami podejmowanymi na wyczucie.

Pokazuję tu, skąd biorą się rozbieżności między GA4 a CRM, jak je sklasyfikować bez nakładania się przyczyn i jak zbudować matrycę uzgodnienia, którą można pokazać zarządowi. Dostajesz symulację mostu od CRM do GA4, tabelę „która liczba do której decyzji” i listę kontrolną do wdrożenia w dwa tygodnie. W symulacji GA4 pokazuje 302 tys. zł, a CRM 316 tys. zł netto, i ta różnica 4,5% wygląda niewinnie, choć stoją za nią błędy rzędu 150 tys. zł, które przypadkiem się wzajemnie znoszą.

Dlaczego GA4 pokazuje inne dane niż CRM?

GA4 pokazuje inne dane niż CRM, bo mierzy zachowanie w przeglądarce w momencie zakupu, zależnie od zgód i działania tagów, a CRM rejestruje zamówienia po stronie serwera i śledzi ich dalszy los: płatność, anulację, zwrot i fakturę. Rozbieżność jest normalna. Problemem jest dopiero rozbieżność, której nie umiesz wyjaśnić.

GA4 jest narzędziem analitycznym, nie księgowym: dostaje zdarzenie purchase wysłane przez tag w chwili wyświetlenia strony podziękowania i na tym jego wiedza się kończy. Nie wie, że klient nie opłacił przelewu, zwrócił połowę zamówienia albo że faktura wyszła w innym miesiącu. CRM wie to wszystko, ale zwykle nie wie, czy klient trafił na stronę z reklamy na Instagramie, czy z wyszukiwarki.

Kto więc ma rację? To źle postawione pytanie. Właściwe brzmi: która liczba odpowiada na które pytanie i czy różnicę między nimi da się rozłożyć na znane przyczyny.

A jaka rozbieżność jest normalna? Jednej poprawnej wartości nie ma, bo zależy ona od odsetka zgód, struktury płatności i definicji przychodu, dlatego bardziej niż sam poziom interesuje mnie to, czy różnicę umiesz wyjaśnić konkretnymi przyczynami i czy jest stabilna w czasie.

Pięć grup przyczyn rozbieżności

Dzielę przyczyny na pięć rozłącznych grup według tego, na jakim etapie powstaje różnica: czy zdarzenie w ogóle zostało zmierzone, czy zostało zmierzone poprawnie, co oznacza jego wartość, kiedy zostało zaliczone i komu zostało przypisane. Każda konkretna przyczyna należy do jednej grupy.

1. Widoczność: GA4 nie widzi części zamówień

• Brak zgody na cookies analityczne. Przy analytics_storage='denied' GA4 nie zapisuje identyfikatorów. W trybie podstawowym Consent Mode zakup nie jest widoczny wcale, w zaawansowanym może być częściowo modelowany, o ile usługa spełnia progi. Mechanikę opisuję w tekście o Consent Mode v2 i modelowaniu konwersji.
• Blokery reklam i ochrona prywatności w przeglądarkach. Część użytkowników korzysta z blokerów reklam lub przeglądarek z wbudowaną ochroną przed śledzeniem. Część blokerów odcina GA4 domyślnie, choć nie wszystkie, więc ich udział warto oszacować na własnym ruchu, porównując zamówienia w CRM z transakcjami w GA4.
• Safari i ITP. Mechanizm Intelligent Tracking Prevention usuwa pliki cookie zapisane przez JavaScript po 7 dniach bez interakcji ze stroną, a gdy wejście nastąpiło z domeny uznanej za śledzącą z parametrami w adresie (link decoration), skraca ten czas do 24 godzin. Powracający klient bywa widziany jako nowy, co psuje ścieżki i atrybucję.

2. Integralność zdarzeń: zakup zmierzony źle

• Duplikaty. GA4 usuwa duplikaty zakupów z tym samym transaction_id, ale tylko w strumieniach internetowych. Jeśli tag wysyła inny identyfikator przy odświeżeniu strony podziękowania albo zakup trafia raz z przeglądarki, raz z serwera bez wspólnego ID, powstaje duplikat.
• Pusty lub stały transaction_id. Google ostrzega, że przy pustym ciągu GA4 potraktuje wszystkie zakupy jako duplikaty i znacząco zaniży konwersje.
• Zakupy, które nie wracają na stronę podziękowania. Klient płaci w bramce i zamyka kartę. Jeśli tag purchase jest tylko na stronie powrotu, zamówienie nie zostanie zmierzone.

3. Definicja wartości: ta sama transakcja, inna liczba

• VAT i dostawa. GA4 dostaje taką wartość, jaką wpisze tag, a to często kwota brutto z dostawą, podczas gdy finanse raportują netto i bez dostawy.
• Anulacje, nieopłacone zamówienia i zwroty. GA4 zapisuje zakup w chwili złożenia zamówienia. Zwrot pojawi się w GA4 tylko wtedy, gdy wyślesz zdarzenie refund, np. przez Measurement Protocol.
• Waluty. GA4 przelicza wartości na walutę usługi po kursie z dnia poprzedzającego transakcję. CRM i księgowość stosują własne kursy, więc przy sprzedaży zagranicznej różnice są nieuniknione. Brak parametru currency przy value psuje metryki przychodu.
• Rabaty i karty podarunkowe. Czy wartość jest przed rabatem, czy po nim? I czy płatność kartą podarunkową to przychód?

4. Czas: ta sama transakcja w innym dniu

• Strefa czasowa usługi GA4 różna od strefy serwera sklepu przesuwa zamówienia z końca dnia i miesiąca.
• Data zamówienia, płatności i faktury to trzy różne momenty: GA4 liczy moment zakupu, CRM często datę opłacenia, a finanse datę faktury.
• Opóźnienia przetwarzania sprawiają, że dane z ostatnich 24–48 godzin w GA4 mogą być niepełne, a atrybucja może się zmieniać do 7 dni po konwersji.

5. Przypisanie źródła: przychód się zgadza, kanały nie

• Nadpisywanie źródła przez bramki płatności. Klient wraca z serwisu płatności na stronę sklepu, a GA4 widzi to jako nową wizytę z odesłaniem, przez co sprzedaż trafia na „bramka.pl / referral” zamiast do kampanii, która ją wygenerowała. Rozwiązanie: domeny bramek na liście niechcianych odesłań, którą znajdziesz w ustawieniach strumienia danych, w konfiguracji tagu (do 50 domen na strumień).
• Różne modele atrybucji. CRM zapisuje zwykle pierwsze lub ostatnie źródło (UTM w formularzu), GA4 domyślnie stosuje model oparty na danych. Szczegóły w tekście o atrybucji opartej na danych i last click.
• Wiele urządzeń i kanałów offline, czyli telefon, showroom czy handlowiec. CRM zna klienta. GA4 widzi anonimową przeglądarkę.

Most uzgodnienia: od CRM do GA4 w liczbach

Policzmy to na jednym miesiącu w sklepie internetowym. Liczby są symulacją na moich założeniach, bez danych klienta, i dobrze pokazują, dlaczego porównywanie samych sum jest ryzykowne.

Założenia: sklep w Polsce, w miesiącu złożono zamówienia o wartości 450 000 zł brutto (z dostawą). Tag GA4 wysyła wartość brutto z dostawą. 30% wartości zamówień pochodzi z sesji bez zgody na cookies analityczne, a usługa nie spełnia progów modelowania. Blokery i ograniczenia przeglądarek odcinają 5% pozostałych zakupów. 2% zakupów trafia do GA4 podwójnie (różne transaction_id). 1% wartości przesuwa strefa czasowa. W CRM 6% zamówień jest anulowanych lub nieopłaconych, a 8% pozostałych wartości wraca jako zwroty. VAT 23%.

Krok	Ścieżka GA4	Ścieżka CRM / finanse
Zamówienia złożone (brutto z dostawą)	450 000 zł	450 000 zł
Brak zgody na analitykę (30%)	−135 000 zł	—
Blokery, ITP (5% pozostałych)	−15 750 zł	—
Duplikaty zakupów (+2%)	+5 985 zł	—
Strefa czasowa (−1%)	−3 052 zł	—
Anulowane i nieopłacone (6%)	—	−27 000 zł
Zwroty (8% pozostałych)	—	−33 840 zł
VAT 23%	—	−72 770 zł
Wynik w raporcie	302 183 zł	316 390 zł netto

GA4 pokazuje 95,5% przychodu netto z CRM. Na slajdzie dla zarządu wygląda to jak „analityka działa, różnica 4,5%”. W rzeczywistości GA4 nie widzi 150 750 zł zamówień (brak zgód i blokery), a jednocześnie zawyża wartość o VAT, anulacje i zwroty, więc błędy o przeciwnych znakach przypadkowo się znoszą i na slajdzie nikt ich nie zauważy.

Jakie wnioski wyciągam z tego mostu?

• Zgodność sum to nie dowód poprawności. Wystarczy, że zmieni się odsetek zgód albo tag zacznie wysyłać wartość netto, i „zgodne” dane rozjadą się o kilkadziesiąt procent.
• Uzgadniaj po numerze zamówienia. Eksport transaction_id z GA4 (lub z BigQuery) zestawiony z numerami zamówień w CRM pokazuje, które zamówienia brakują, które są zdublowane i jakie mają wartości.
• Porównuj wskaźnik pokrycia, nie przychód. Odsetek zamówień z CRM, które mają odpowiednik w GA4, śledzony tydzień po tygodniu, szybciej wykryje awarię tagu niż porównanie przychodu.

Matryca uzgodnienia dla zarządu: która liczba do której decyzji?

Zamiast wybierać jeden „prawdziwy” system, przypisz każdemu pytaniu zarządczemu źródło danych i sposób interpretacji; dane modelowane GA4 (tożsamość raportowania „Mieszana”) traktuj jako szacunek do oceny trendów i kanałów, a dane fakturowe z CRM jako twardą podstawę rozliczeń.

Pytanie zarządu	Źródło prawdy	Rola drugiego systemu	Jak interpretować różnicę
Ile sprzedaliśmy i zarobiliśmy?	CRM / faktury (netto, po zwrotach)	GA4 — tylko kontrolnie	różnica opisana mostem uzgodnienia
Które kanały przyprowadzają klientów?	GA4 (model oparty na danych) + UTM zapisane w CRM	CRM — weryfikacja wartości i jakości klientów	udziały kanałów, nie kwoty bezwzględne
Czy kampania jest rentowna?	CRM (marża) + koszty z platform	GA4 / Google Ads — przypisanie do kampanii	ROAS z paneli korygowany współczynnikiem pokrycia
Czy strona konwertuje gorzej niż miesiąc temu?	GA4 (dane obserwowane)	CRM — kontrola liczby zamówień	trend ważny tylko przy stałym banerze i konfiguracji
Czy pomiar działa?	zestawienie po transaction_id	oba systemy	wskaźnik pokrycia zamówień, alert przy spadku

Jeśli łączysz dodatkowo dane z Meta i Google Ads, suma przypisanych konwersji z platform będzie większa niż sprzedaż w CRM, bo każda platforma przypisuje sobie tę samą transakcję. Architekturę jednego źródła prawdy i import konwersji offline opisuję w tekście o łączeniu danych z Meta, Google i CRM.

Jak ograniczyć rozbieżności technicznie?

Czy wszystkie różnice da się usunąć? Nie. Część jest nieusuwalna (zgody, zwroty), ale wiele wynika z konfiguracji. Najczęstsze poprawki, w kolejności od najtańszej:

1. Unikalny transaction_id równy numerowi zamówienia w CRM, nigdy pusty, bez danych osobowych.
2. Stała definicja value: najlepiej netto, bez dostawy, po rabatach, zapisana w dokumentacji i zgodna z tym, co raportują finanse. Zawsze z parametrem currency.
3. Lista niechcianych odesłań z domenami bramek płatności, systemów ratalnych i dostawców logowania.
4. Zgodne strefy czasowe GA4, Google Ads i systemu sklepu.
5. Zdarzenia refund wysyłane z systemu sklepu przez Measurement Protocol, jeśli GA4 ma pokazywać przychód po zwrotach.
6. Zapis źródła w CRM: parametry UTM i identyfikatory kliknięć (np. gclid) zapisywane przy zamówieniu, co pozwala na import konwersji offline do Google Ads.
7. Tagowanie po stronie serwera, które zmniejsza wpływ części blokerów i ITP. Nie zastępuje zgody użytkownika i nie „odzyskuje” danych osób, które odmówiły.

Po każdej zmianie odnotuj datę w adnotacjach GA4 i w raporcie zarządczym, bo bez tego za trzy miesiące nikt nie będzie wiedział, czy skok przychodu w GA4 to efekt kampanii, czy nowej definicji value.

Uzgodnienie GA4 i CRM w 2 tygodnie: kolejność, którą stosuję

Dni 1–3: definicje. Spisz, co każdy system nazywa „przychodem”: brutto czy netto, z dostawą czy bez, data zamówienia czy płatności, przed zwrotami czy po. Uzgodnij jedną definicję raportu zarządczego.

Dni 4–6: zestawienie po zamówieniach. Wyeksportuj transaction_id i wartości z GA4 za pełny miesiąc oraz numery zamówień z CRM. Policz wskaźnik pokrycia, duplikaty i różnice wartości.

Dni 7–9: źródła. Sprawdź udział ruchu z odesłań z domen bramek płatności i wejść bezpośrednich przy zakupach. Uzupełnij listę niechcianych odesłań.

Dni 10–12: poprawki. Wdróż poprawki techniczne z poprzedniej sekcji, zaczynając od transaction_id i definicji wartości.

Dni 13–14: most dla zarządu. Przygotuj jednostronicowy most uzgodnienia: od przychodu w CRM do przychodu w GA4, z kwotą każdej przyczyny. Ustal próg alarmowy dla wskaźnika pokrycia.

Checklista:

• jedna pisemna definicja przychodu dla raportu zarządczego,
• wskaźnik pokrycia zamówień monitorowany co tydzień,
• bramki płatności na liście niechcianych odesłań,
• strefy czasowe i waluty zgodne we wszystkich systemach,
• most uzgodnienia aktualizowany co miesiąc.

Jeśli przejmujesz konto reklamowe po innej osobie, zacznij od szybkiego audytu konta Google Ads, bo błędy konwersji to jeden z pierwszych punktów do sprawdzenia.

Mini-słownik pojęć

• transaction_id — identyfikator transakcji w GA4, powinien być równy numerowi zamówienia.
• Most uzgodnienia — zestawienie kroków od przychodu w jednym systemie do przychodu w drugim, z kwotą każdej przyczyny różnicy.
• Wskaźnik pokrycia — odsetek zamówień z CRM, które mają odpowiednik w GA4.
• Lista niechcianych odesłań — ustawienie GA4, które wyklucza wskazane domeny jako źródło ruchu.
• ITP (Intelligent Tracking Prevention) — mechanizm Safari ograniczający czas życia plików cookie.
• Measurement Protocol — interfejs do wysyłania zdarzeń do GA4 z serwera, np. zwrotów.
• Tożsamość raportowania „Mieszana” — ustawienie GA4 łączące dane obserwowane i modelowane.

Źródła

• Google Analytics Help: deduplikacja zakupów po transaction_id
• Google Analytics Help: Identify unwanted referrals — lista niechcianych odesłań
• Google Analytics Help: Currency reference — przeliczanie walut
• Google Analytics Help: Behavioral modeling for consent mode
• Google Analytics Help: Get started with attribution
• WebKit: Tracking Prevention in WebKit