Mariusz Michalczuk – wywiad po semKRK#24 BIG

W pierwszym tygodniu nie zaczynałbym od budowania dashboardów, tylko od ustalenia, jakie decyzje biznesowe mają być podejmowane na podstawie danych. Jeśli firma „ma dane i nic z nimi nie robi”, problem zwykle nie leży w samym braku raportu, tylko w chaosie: za dużo metryk, brak właścicieli, rozproszone źródła i niska pewność co do jakości danych.
Konkretnie zacząłbym tak:

Dzień 1–2: rozmowy z biznesem i spisanie najważniejszych celów, KPI oraz decyzji, które dziś są podejmowane „na czuja”

Dzień 2–3: inwentaryzacja źródeł danych: GA4, CRM, Google Ads, e-commerce, arkusze, BI, hurtownia, ręczne raporty

Dzień 3–4: szybki audyt jakości: które dane są zaufane, które są rozproszone, gdzie są luki i gdzie ludzie widzą „dziwne liczby”

Dzień 5: wybór jednego obszaru o największym wpływie, np. sprzedaż, leady albo koszt pozyskania, i zbudowanie prostego KPI tree

Kluczowe jest zawężenie zakresu. Lepiej uporządkować 20% najważniejszych danych, które realnie wpływają na decyzje, niż próbować od razu „ogarnąć wszystko”. Dopiero potem ma sens automatyzacja raportowania, DataOps, dashboardy czy bardziej zaawansowana analityka.

GA4 nie jest najlepszym miejscem do analizy naprawdę ogromnych serwisów, jeśli chcesz robić głęboką, powtarzalną analitykę biznesową. Problemem nie jest samo zbieranie danych, tylko sposób ich późniejszego używania: interfejs GA4 jest dobry do podstawowych raportów, ale przy dużej skali szybko pojawiają się ograniczenia raportowe, trudność w budowaniu niestandardowych analiz i zależność od gotowego modelu danych Google. Naturalną alternatywą jest BigQuery z eksportem danych z GA4, ale tu jest ważna pułapka: samo podłączenie surowego eksportu GA4 do Looker Studio może być kosztowne i nieefektywne. Dane z GA4 w BigQuery są surowe, zagnieżdżone i wymagają sensownego modelowania - inaczej każde odświeżenie dashboardu może przeliczać duże wolumeny danych od nowa.

Dlatego rekomendowane podejście to nie „GA4 albo BigQuery”, tylko:
- GA4 jako źródło zbierania danych
- BigQuery jako hurtownia danych
- warstwa DataOps / model raportowy pomiędzy surowymi danymi a dashboardami
- Looker Studio podpięte do gotowych tabel raportowych, a nie bezpośrednio do surowego eksportu GA4

W praktyce chodzi o to, żeby z ogromnej tabeli eventów budować mniejsze, biznesowe tabele pod konkretne raporty: sprzedaż, źródła ruchu, lejki, retencję czy segmenty użytkowników. To daje większą kontrolę, niższe koszty zapytań i stabilniejsze raportowanie.

Raczej nie zaczynałbym od jednego „ogólnego raportu dla wszystkich”. Dobry raport powinien odpowiadać na konkretne decyzje, które dana osoba ma podejmować — inne pytania ma zarząd, inne marketing manager, inne osoba od performance, e-commerce czy CRM.

W praktyce często robi się jeden wspólny fundament danych, ale kilka widoków lub sekcji raportu dopasowanych do odbiorców:
- zarząd potrzebuje syntetycznych KPI i sygnałów typu „check business”
- marketing potrzebuje źródeł ruchu, kampanii, kosztów i konwersji
- e-commerce patrzy na przychód, koszyk, produkty i lejek zakupowy
- analityk potrzebuje możliwości głębszej diagnostyki

Omawianie raportu też jest ważne, bo sam dashboard nie zawsze odpowiada na pytanie „dlaczego coś się wydarzyło”. Raport ma sygnalizować problem albo szansę, a rozmowa z analitykiem pomaga zdiagnozować przyczynę i przełożyć dane na decyzję.

Większy skok zwykle nie przychodzi z samego „dopieszczenia” danych do perfekcji ani z działania na czymkolwiek, co akurat jest pod ręką. Największa różnica pojawia się wtedy, gdy dane są wystarczająco wiarygodne, żeby biznes zaczął im ufać, a proces pracy z nimi jest na tyle poukładany, że analizy nie są jednorazową ręczną akcją.

Czyli najpierw trzeba usunąć największe ryzyka: błędne konwersje, niespójne definicje KPI, braki w danych, problemy z kampaniami czy źródłami ruchu. Bez tego szybkie decyzje mogą tylko przyspieszyć złe decyzje. Ale z drugiej strony czekanie miesiącami na „idealny model danych” też zabija wartość, bo biznes potrzebuje odpowiedzi teraz.

Najlepszy efekt daje podejście iteracyjne:
- najpierw stabilizujesz fundamenty danych, żeby były używalne decyzyjnie,
- potem szybko dowozisz pierwsze analizy i rekomendacje,
- równolegle poprawiasz jakość, automatyzację i powtarzalność procesu.

KPI wyznaczam od decyzji biznesowej, a nie od raportu w GA4. Najpierw trzeba ustalić, jaki wynik firma chce poprawić: sprzedaż, marżę, liczbę leadów, retencję, koszt pozyskania albo efektywność kampanii. Dopiero potem dobiera się metryki, które pokazują, czy idziemy w dobrą stronę.

W praktyce rozdzieliłbym to na trzy poziomy:
- KPI biznesowe – np. przychód, liczba zamówień, wartość leadów, koszt pozyskania klienta
- metryki sterujące – np. współczynnik konwersji, liczba sesji z wartościowych kanałów, udział użytkowników wracających
- metryki diagnostyczne – np. błędy pomiaru, drop-off w lejku, problemy z consentem, rozbieżności między systemami

Problem „realne dane vs Google Analytics” rozwiązuję przez ustalenie źródła prawdy. Dla sprzedaży zwykle będzie to backend, CRM, system zamówień albo fakturowanie, a nie GA4. GA4 jest świetne do analizy zachowań, kanałów i trendów, ale nie powinno być traktowane jako księgowy rejestr rzeczywistości. Kluczowe jest nie to, czy GA4 pokazuje identyczną liczbę jak system transakcyjny, tylko czy jest trafne: jeśli w realnym systemie rośnie sprzedaż, to przy niezmienionych założeniach podobny kierunek powinien być widoczny w narzędziu analitycznym. Dokładność jest ważna, ale najpierw sprawdzam, czy dane nadają się do podejmowania decyzji.

Do takiego klienta nie podchodziłbym przez „dokładanie kolejnych raportów”, tylko przez zaakceptowanie, że przychód jest dla niego głównym KPI. To jest dobry punkt startu, ale problem polega na tym, że przychód na koniec miesiąca jest metryką opóźnioną — mówi, co się stało, ale nie mówi wystarczająco wcześnie, dlaczego się stało.

Dlatego sensownym podejściem jest rozbicie przychodu na kilka prostych driverów, np. ruch, konwersję, średnią wartość koszyka, koszty pozyskania czy marżowość — zależnie od biznesu. Nie chodzi o to, żeby klient zaczął kochać dane, tylko żeby zobaczył, że te 2-4 metryki pomagają szybciej zrozumieć, czy miesięczny przychód jest zagrożony.

Kluczowe jest też ograniczenie zakresu. Zamiast budować ogromny dashboard, lepiej zrobić małe drzewo KPI i ustalić, które dane naprawdę wpływają na wynik biznesowy. W materiale mocno wybrzmiewa zasada, że często wystarczy skupić się na najważniejszych 20% śledzenia, które daje większość efektu, zamiast robić „przepastne” wdrożenia analityczne.

Tak — ale nie traktowałbym server-side jako sposobu na „zebranie jak największej ilości danych za wszelką cenę”. Sensowniejsze podejście to: zebrać właściwe dane, zgodne z celami klienta, zgodami użytkownika i realnymi decyzjami biznesowymi, które mają być na tych danych podejmowane.
GTM Server-Side może pomóc w poprawie jakości danych w GA4, bo daje większą kontrolę nad tym, co trafia do narzędzi analitycznych i marketingowych. W materiałach omawiamy m.in. to, że server-side pozwala filtrować lub anonimizować dane po stronie serwera, ograniczać wpływ części blokad oraz poprawiać trwałość identyfikatorów/cookies — szczególnie tam, gdzie duży udział mają Safari i iOS.

Najważniejsze korzyści są zwykle takie:
- lepsza jakość i ciągłość pomiaru, szczególnie przy dłuższych ścieżkach zakupowych,
- większa kontrola nad danymi, zanim trafią do GA4 lub innych narzędzi,
- potencjalnie lepsza wydajność strony, bo część logiki przenosisz poza przeglądarkę,
- lepsze podstawy pod marketing i atrybucję, ale nadal w granicach zgód użytkownika.

Kluczowa pułapka: server-side nie zwalnia z Consent Mode ani z myślenia o tym, jakie dane naprawdę są potrzebne. Jeśli klient nie ma uporządkowanych KPI, zdarzeń i definicji konwersji, to samo wdrożenie server-side nie rozwiąże problemu — tylko szybciej i czyściej będzie zbierać dane, które mogą nadal być źle zaprojektowane.

Sens metodyki KPI Tree jest bardzo szeroki: uporządkować cele, punkty styku z klientem i metryki tak, żeby zespół wiedział, na które dane patrzeć i jak podejmować decyzje.

Bardziej niż branża ograniczeniem jest sytuacja, w której firma nie potrafi określić głównego celu biznesowego albo nie ma sensownie opisanej ścieżki klienta. KPI Tree opiera się na rozbiciu wyniku na elementy: główne KPI, touchpointy w Customer Journey oraz warstwę Goals, Signals, Measures. Jeśli tego nie da się nazwać lub zmierzyć, metodyka będzie trudniejsza do wdrożenia — ale to zwykle problem dojrzałości analitycznej, a nie samej branży.

W praktyce KPI Tree najlepiej działa tam, gdzie są powtarzalne procesy, mierzalne interakcje i potrzeba uporządkowania chaosu raportowego.

Ruch ze sztucznej inteligencji warto analizować podobnie jak osobne źródło pozyskania, ale z jedną ważną różnicą: AI może pojawiać się w danych jako referral, organic, direct albo nawet (not set), zależnie od narzędzia i sposobu przejścia użytkownika na stronę.
W GA4 najlepiej zacząć od raportów pozyskania i sprawdzić źródło / medium dla domen związanych z narzędziami AI, np. ChatGPT, Perplexity, Copilot, Gemini czy Claude. Kluczowe jest zbudowanie reguły, która wyłapie te źródła i pozwoli analizować je jako jedną grupę ruchu AI.

Na co warto patrzeć:
- udział ruchu AI w całym ruchu na stronie,
- jakość sesji — zaangażowanie, czas, konwersje,
- landing pages — które treści są najczęściej polecane przez AI,
- zmianę w czasie — czy AI zaczyna przejmować część ruchu organicznego.

Jeśli transakcja jest mierzona dopiero na thank you page, to przy płatnościach typu BLIK lub zewnętrznych bramkach płatności masz klasyczny problem: użytkownik może zapłacić, ale nie wrócić do serwisu. Wtedy biznesowo sprzedaż istnieje, ale GA4 jej nie widzi, bo zdarzenie purchase nigdy się nie odpaliło.

Podejście rekomendowane w materiale jest takie, żeby nie uzależniać rejestracji transakcji wyłącznie od powrotu użytkownika z płatności. W praktyce oznacza to przesunięcie momentu wysłania transakcji bliżej końca checkoutu — tuż przed wyjściem do zewnętrznej płatności — bo prawdopodobieństwo, że użytkownik dojdzie do tego punktu, jest większe niż to, że wróci potem na thank you page.

Trzeba jednak uważać na jedną rzecz: takie podejście może zmniejszyć niedoszacowanie transakcji w GA4, ale wymaga świadomego porównywania z danymi backendowymi lub systemem płatności, żeby rozumieć ewentualne różnice. GA4 nie powinien być traktowany jako system księgowy — bardziej jako narzędzie do analizy marketingu i zachowań użytkowników.

Dla klienta, który „nie rozumie danych”, nie rekomendowałbym klasycznego raportu pełnego tabel, wykresów i metryk. Lepiej sprawdzi się dashboard menedżerski, czyli raport zaprojektowany jak zestaw kontrolek ostrzegawczych w samochodzie: ma szybko pokazać, czy biznes działa dobrze, czy gdzieś „zapalił się check engine”.

Taki raport powinien być maksymalnie decyzyjny, a nie analityczny. Zamiast pokazywać wszystko, warto wybrać kilka kluczowych KPI, np.:
- czy realizujemy cel biznesowy,
- który kanał dowozi wynik,
- gdzie wynik spada względem poprzedniego okresu,
- co wymaga reakcji klienta lub zespołu.

Dobrą praktyką jest też dodanie prostych sygnałów: kolory, odchylenia procentowe, komentarze i krótkie rekomendacje. Klient nie powinien sam interpretować danych od zera — raport ma mu powiedzieć, co się dzieje i czy trzeba działać.

Najlepiej edukować właścicieli firm przez pokazanie zależności między metrykami, a nie przez dokładanie kolejnych wykresów. Przychód jest ważny, ale sam nie mówi, czy biznes zarabia zdrowo: może rosnąć razem z kosztami reklam, rabatami, zwrotami albo obsługą klienta.

Dobrym podejściem jest zbudowanie prostego „drzewa KPI”, które pokazuje, co wpływa na wynik biznesowy:
- Przychód – ile firma sprzedaje
- Koszt pozyskania ruchu i klienta – ile trzeba zapłacić za sprzedaż
- Marża / rentowność – ile realnie zostaje po kosztach
- Retencja i powracający klienci– czy firma zarabia tylko na pierwszej transakcji, czy buduje wartość klienta w czasie

W rozmowie z właścicielem warto zacząć od pytania: „Czy wolimy większy przychód, czy większy zysk?”. To często otwiera oczy, bo kampania z wysokim przychodem może być słabsza od mniejszej kampanii, która generuje lepszą marżę lub przyciąga bardziej wartościowych klientów.

Kluczowe jest też ograniczenie raportu do kilku metryk decyzyjnych. Jeśli właściciel dostaje 40 wskaźników, zwykle wraca do jednego najprostszego — przychodu. Jeśli pokażesz mu 4–6 KPI ułożonych logicznie od celu biznesowego do działań marketingowych, łatwiej będzie mu zrozumieć, że dane służą do decyzji, a nie tylko do „patrzenia na wynik”.

Dla zupełnie początkujących najlepszym wyborem będzie Looker Studio. To narzędzie ma niski próg wejścia, jest darmowe w podstawowym użyciu i dobrze łączy się z ekosystemem Google, np. GA4, Google Ads czy arkuszami Google.

Na start warto potraktować dashboard nie jako „ładny raport”, tylko jako zestaw tablic ostrzegawczych dla biznesu. Początkujący użytkownik powinien szybko zobaczyć, czy coś działa dobrze, czy wymaga reakcji — bez przekopywania się przez dziesiątki tabel.

Najważniejsze na początku:
- prostota — kilka kluczowych KPI zamiast przeładowanego raportu,
- czytelna struktura — sekcje typu sprzedaż, ruch, kampanie, konwersje,
- kontekst biznesowy — porównania do poprzedniego okresu, celu albo planu,
- automatyzacja — dane aktualizują się same, zamiast ręcznego składania raportów.

Jeśli ktoś dopiero zaczyna, nie rekomendowałbym od razu cięższych narzędzi BI typu Power BI czy Tableau, chyba że firma ma już bardziej zaawansowane potrzeby i kompetencje analityczne.