Kiedy firma pokazuje mi trzy raporty z trzema wynikami, w większości przypadków nie znajduję tam żadnej usterki technicznej. Znajduję pięć definicji konwersji, dwa momenty księgowania transakcji i arkusz, w którym ktoś kiedyś dodał ręczny filtr i nikt już nie pamięta dlaczego. To nie jest problem GA4. To brak zarządzania danymi: nie ma właściciela metryki, nie ma mapy źródeł i nie ma reguły, kiedy patrzymy na analitykę, a kiedy na system finansowy.
Różne liczby nie oznaczają automatycznie błędu. Problem zaczyna się wtedy, gdy organizacja nie potrafi wyjaśnić, dlaczego się różnią i która liczba służy do konkretnej decyzji.
Co naprawdę oznacza rozjazd liczb
Różnica między systemami nie jest błędem sama w sobie. GA4 rejestruje zachowanie w przeglądarce, CRM stan pracy handlowej, ERP rozliczenie. Te trzy światy nie mają powodu zgadzać się co do złotówki i nigdy się nie zgodzą. Kłopot pojawia się dopiero wtedy, gdy wszystkie trzy liczby nazywają się tak samo i trafiają na jedno spotkanie bez żadnego opisu.
Dla osoby zarządzającej e-commerce ma to bezpośrednie konsekwencje. Na podstawie liczby konwersji ustala się budżet performance, ocenia agencję, planuje zatowarowanie i przyznaje premie. Jeśli w poniedziałek ROAS z GA4 wygląda dobrze, a w środę raport sprzedaży pokazuje co innego, decyzja albo zostaje odłożona, albo zapada na podstawie liczby, której nikt nie rozumie do końca. Pierwsze kosztuje czas, drugie budżet.
Pięć źródeł różnicy, które widać najczęściej
Zanim ktokolwiek zacznie poprawiać tagi, warto przejść listę typowych przyczyn. W praktyce mieszczą się w pięciu obszarach.
- Definicja - dla GA4 konwersją bywa wysłanie formularza, dla sprzedaży zaakceptowana oferta, dla finansów opłacona faktura.
- Moment księgowania - analityka widzi zdarzenie natychmiast, ERP dopiero po płatności, a zwrot pojawia się tydzień później.
- Zgody i prywatność - Consent Mode, bannery CMP, ograniczenia przeglądarek i adblocki sprawiają, że część ruchu nie jest mierzona jeden do jednego.
- Brak wspólnego identyfikatora - jeśli transaction_id albo customer_id nie przechodzi stabilnie między stroną, sklepem i systemem zamówień, łączenie danych staje się zgadywaniem.
- Warstwa ręczna - arkusz, w którym mieszkają niejawne filtry, korekty i wyjątki.
Większość firm ma po trochu z każdego obszaru. Dlatego pojedyncza poprawka rzadko zamyka temat. Trzeba zobaczyć całość, a nie jeden tag.
Diagnoza, którą da się zrobić w jedno popołudnie
Nie potrzeba do tego projektu BI. Wystarczą dwie, trzy godziny i ludzie z marketingu, sprzedaży, e-commerce, finansów oraz ktoś od strony technicznej przy jednym stole. Celem nie jest wskazanie winnego, tylko ustalenie, co właściwie porównujemy.
- do jakiej decyzji służy metryka,
- który system rozstrzyga wynik finansowy,
- skąd bierze ją analityka,
- jaki identyfikator łączy systemy,
- jakie wyjątki trzeba wykluczyć: zwroty, testy, B2B, marketplace,
- kto może zatwierdzić definicję.
Po tym ćwiczeniu zwykle okazuje się, że firma nie ma problemu z GA4, tylko trzy różne metryki o jednej nazwie. To wygodniejsza sytuacja, niż się wydaje, bo definicje da się uzgodnić znacznie szybciej niż przebudować architekturę.
Przykład: jeden sklep, cztery wartości sprzedaży
Sklep robi 500 tys. zł miesięcznie według ERP. GA4 pokazuje 430 tys., CRM dla kampanii leadowych raportuje 610 tys. wartości szans, a arkusz na zarząd 470 tys. po ręcznych korektach. Każda z tych liczb jest poprawna, bo każda odpowiada na inne pytanie. GA4 mówi, ile sprzedaży przypisano do sesji i kampanii. CRM mówi, ile potencjału jest w lejku. ERP mówi, ile zostało rozliczone. Arkusz mówi, jak zarząd chce widzieć wynik po poprawkach, których zwykle nikt nie spisał.
Konflikt rodzi się w jednym punkcie: wszystkie cztery wartości nazywają się sprzedaż i nikt nie dopisał kontekstu. Zarządzanie danymi nie polega na wybraniu jednej prawdziwej liczby, tylko na nazwaniu każdej tak, żeby było wiadomo, do czego służy i kto za nią odpowiada.
Trzy poziomy raportu i jedna zasada
Porządek wprowadza prosty podział:
- Operacyjny - GA4 i dashboard dzienny, czyli szybka reakcja na kampanie i awarie.
- Zarządczy - BI z uzgodnionymi definicjami, czyli decyzje tygodniowe i miesięczne.
- Finansowy - ERP, faktury, marża i zwroty, czyli wynik firmy.
Zasada jest jedna: GA4 nie musi zgadzać się z ERP, żeby było użyteczne. Musi być jasne, do jakich decyzji wystarczy, a kiedy trzeba sięgnąć po dane finansowe. Na tym polega różnica między analityką jako narzędziem pracy a analityką jako źródłem cotygodniowej kłótni.
Jak to uporządkować bez dużego projektu
Sekwencja, która sprawdza się w mniejszych i średnich firmach, jest dość przewidywalna. Najpierw zatrzymujemy chaos definicji: wybieramy kilka kluczowych KPI, spisujemy ich znaczenie, przypisujemy właściciela i oznaczamy, które raporty są operacyjne, a które finansowe. Dobrym testem jest prześledzenie dwudziestu, pięćdziesięciu transakcji od strony aż po ERP, bo to pokazuje, gdzie naprawdę gubią się dane.
W drugim kroku łączymy identyfikatory i reguły: stabilizujemy transaction_id między GA4, CRM i sklepem, ustalamy, jak traktujemy testy, anulacje i zwroty, i dopisujemy do dashboardu krótki słownik KPI. Warto też z góry ustalić, jaką różnicę między GA4 a systemem finansowym uznajemy za normalną, bo bez tego każde odchylenie wywołuje alarm.
Dopiero na końcu buduje się rytm: comiesięczny przegląd metryk z udziałem biznesu, monitoring odchyleń powyżej ustalonego progu i dokumentowanie zmian w tagach, formularzach i integracjach. To moment, w którym zarządzanie danymi przestaje być akcją ratunkową i staje się procesem.
Co z tego powinien zobaczyć zarząd
Zarząd nie potrzebuje listy osiemdziesięciu eventów. Potrzebuje wiedzieć, którym liczbom można ufać i jak je czytać. Dobra notatka mieści się na jednej stronie: zatwierdzone definicje kluczowych KPI, źródło prawdy dla każdej z nich, znane różnice między systemami wraz z przyczyną oraz obszary ryzyka, czyli brak ID, zgody, duplikaty i ręczne korekty.
Efekt jest mierzalny. Rozmowa przestaje brzmieć „czy GA4 kłamie”, a zaczyna „czy ta liczba jest wystarczająco wiarygodna do tej decyzji”. Da się też policzyć, ile kosztował dotychczasowy bałagan: jeśli zespół traci kilkanaście godzin miesięcznie na ręczne uzgadnianie raportów, sama ta praca to kilka tysięcy złotych, zanim w ogóle policzymy źle ulokowany budżet kampanii.
Consent i atrybucja, czyli skąd zwykle bierze się największa luka
Jeśli GA4 pokazuje systematycznie mniej niż system zamówień, w pierwszej kolejności patrzę na zgody i atrybucję, nie na tag zakupu. Po wejściu w życie modeli zgody część użytkowników nie wyraża zgody na pomiar, a wtedy GA4 albo modeluje konwersje, albo ich nie widzi. W zależności od branży i konfiguracji bannera potrafi to dać kilka, kilkanaście procent różnicy, zanim w ogóle dotkniemy jakości tagowania. To nie jest awaria, tylko wbudowane ograniczenie pomiaru po stronie przeglądarki.
Druga warstwa to atrybucja. GA4 przypisuje sprzedaż do kampanii według własnego modelu i okna konwersji, a system zamówień po prostu rejestruje fakt zakupu. Dlatego suma sprzedaży po kampaniach w GA4 prawie nigdy nie zgadza się z sumą zamówień w ERP. Mieszanie tych dwóch perspektyw na jednym slajdzie to najprostszy sposób, żeby spotkanie skończyło się bez decyzji.
Kiedy różnica jest sygnałem, a nie szumem
Nie każde odchylenie wymaga reakcji. Stała, przewidywalna różnica między GA4 a systemem finansowym jest normalna i można ją skwitować jednym zdaniem w dokumentacji. Reakcji wymaga zmiana zachowania. Jeśli relacja GA4 do ERP przez pół roku trzymała się na poziomie około 85 procent, a nagle spadła do 60, to nie jest temat na filozoficzną dyskusję o jakości danych. To zwykle konkretny incydent: zmiana w bannerze zgód, przebudowa checkoutu, podmieniony tag, nowa bramka płatności albo wdrożenie, które rozjechało dataLayer.
Dlatego najtańsza forma nadzoru to nie kolejny dashboard, tylko jeden próg alertu. Ustalasz akceptowalny zakres różnicy i pilnujesz, kiedy z niego wychodzi. Większość kosztownych błędów w raportowaniu to nie systematyczne 10 procent, do którego firma się przyzwyczaiła, ale nagła zmiana, której nikt nie zauważył przez trzy tygodnie.
Od czego zacząć
Najszybszy sposób, żeby sprawdzić, czy problem jest jednostkowy czy systemowy, to przejść checklistę Data Governance. Jeśli w firmie nie ma wspólnego słownika KPI, właścicieli metryk i mapy źródeł, te podstawy warto uporządkować przed kolejną inwestycją w dashboardy. Praktyczny wzorzec opisałem w sekcji Data Governance w analityce marketingowej, a gdy rozjazdy wpływają na budżet i decyzje zakupowe, sensowna jest diagnoza AS-IS w ramach konsultingu Data Governance.