Fraud Blocker Nawet o 50% mniej transakcji w GA4 niż w CRM. Jak to naprawiliśmy? | Case study Analityka - mbridge

Nawet o 50% mniej transakcji w GA4 niż w CRM. Jak to naprawiliśmy? | Case study Analityka

Gdy dane sprzedażowe w CRM i raporty w Google Analytics 4 pokazują zupełnie inny obraz rzeczywistości, trudno mówić o skutecznej optymalizacji działań marketingowych. W przypadku jednego z naszych Klientów skala rozbieżności pomiędzy tymi danymi sięgała nawet 50%, co podważało wiarygodność analityki i utrudniało podejmowanie trafnych decyzji biznesowych.

Problem nie wynikał jednak z oczywistego błędu we wdrożeniu. Aby znaleźć jego rzeczywistą przyczynę, przeanalizowaliśmy dane, zweryfikowaliśmy implementację zdarzeń i przetestowaliśmy cały proces zakupowy. Dzięki temu udało się ustalić, dlaczego część transakcji nie trafiała do GA4 i wskazać rozwiązanie, które szybko poprawiło spójność danych oraz przywróciło Klientowi zaufanie do raportowania.

Sytuacja wyjściowa

Wraz z naszym Klientem widzieliśmy, że liczba transakcji raportowanych w CRM konsekwentnie odbiega od danych widocznych w Google Analytics 4. Brak spójności między systemami utrudniał nie tylko analizę wyników sprzedażowych, ale też codzienną pracę na danych – od oceny skuteczności kampanii, przez optymalizację budżetów, po wyciąganie trafnych wniosków dotyczących całego procesu zakupowego. Kluczowym wyzwaniem było więc ustalenie, skąd biorą się rozbieżności i czy ich źródłem jest błąd pomiaru, problem techniczny, czy może sam przebieg ścieżki zakupowej.

Działania

Aby ustalić, skąd biorą się rozbieżności między danymi z CRM a raportami w GA4, rozpoczęliśmy od szczegółowej analizy obu źródeł oraz weryfikacji samego procesu pomiaru transakcji.
arrow-violet
W pierwszej kolejności przeanalizowaliśmy dane sprzedażowe w CRM i zestawiliśmy je z danymi rejestrowanymi w Google Analytics 4, aby potwierdzić skalę oraz powtarzalność rozbieżności.
arrow-violet

Następnie zweryfikowaliśmy implementację zdarzenia purchase w Google Tag Managerze. Samo wdrożenie było poprawne – tag wywoływał się prawidłowo, a od strony technicznej nie było widać błędów, które mogłyby tłumaczyć tak dużą różnicę w liczbie raportowanych transakcji.

arrow-violet
Kolejnym krokiem było sprawdzenie, czy na zaniżone wyniki w GA4 mogą wpływać zgody na śledzenie. Wzięliśmy pod uwagę scenariusz, w którym część użytkowników nie wyraża zgody na cookies, a tym samym ich transakcje nie są rejestrowane w analityce. Ten czynnik miał wpływ na dane, ale nie tłumaczył skali problemu.
Dlatego przeprowadziliśmy także testy transakcji i dokładnie przyjrzeliśmy się całemu procesowi zakupowemu. Analiza przebiegu ścieżki pozwoliła nam spojrzeć szerzej – nie tylko na samą konfigurację analityki, ale również na sposób, w jaki użytkownik finalizuje zakup. To właśnie na tym etapie pojawiły się przesłanki, że źródło problemu może leżeć nie w błędnym tagowaniu, lecz w konstrukcji procesu płatności i zachowaniu użytkowników po dokonaniu opłaty.

Hipoteza

Na podstawie przeprowadzonej analizy wysunęliśmy hipotezę, że problem nie leży w samej implementacji zdarzenia purchase, ale w sposobie domykania procesu zakupowego. Wszystko wskazywało na to, że część transakcji nie była rejestrowana w GA4, ponieważ użytkownicy po dokonaniu płatności nie wracali na stronę potwierdzenia zakupu, na której następowało wywołanie zdarzenia.
W przypadku tego Klienta proces płatności zależny od zewnętrznego operatora zawierał więcej etapów niż przeciętnie. To oznaczało, że kupujący musiał wykonać wiele kroków, a między samym opłaceniem zamówienia a powrotem na thank you page pojawiało się dodatkowe ryzyko utraty części użytkowników. W efekcie transakcja była widoczna w CRM, ale nie zawsze trafiała do Google Analytics 4.

Rozwiązanie

Po zidentyfikowaniu źródła problemu skupiliśmy się na wskazaniu rozwiązań, które Klient mógł wdrożyć, biorąc pod uwagę zaplecze techniczne i możliwości czasowe. Zależało nam na tym, aby rekomendacje były uporządkowane według dwóch kryteriów: skuteczności oraz łatwości implementacji.
Zaproponowaliśmy kilka możliwych kierunków działania:
arrow-violet
uproszczenie procesu płatności i ograniczenie liczby etapów, tak aby użytkownik mógł szybciej dokonać transakcji oraz poprawnie wracał na stronę potwierdzenia zakupu,
arrow-violet
wdrożenie zmian w logice procesu zakupowego, by zmniejszyć zależność pomiaru od zachowania użytkownika po płatności,
arrow-violet

zamiana operatora płatności, jako najszybsze i najmniej obciążające rozwiązanie.

arrow-violet
zamiana operatora płatności, jako najszybsze i najmniej obciążające rozwiązanie.
To właśnie ostatnia z rekomendacji została wskazana jako najlepszy pierwszy krok. Była relatywnie prosta do wdrożenia, a jednocześnie dawała dużą szansę na szybkie ograniczenie skali problemu bez konieczności przebudowy całego procesu zakupowego.

Efekty

Zmiana operatora płatności przyniosła szybki i wyraźny efekt. Użytkownicy wracali na thank you page częściej i szybciej, dzięki czemu odnotowaliśmy:
arrow-violet
wzrost odsetka użytkowników wracających na thank you page do 80%,
arrow-violet
znacznie większą spójność danych sprzedażowych między GA4 a CRM,
arrow-violet
ograniczenie skali niedorejestrowanych transakcji w analityce,
arrow-violet
odzyskanie zaufania do danych wykorzystywanych w ocenie skuteczności działań marketingowych.
Dzięki temu Klient mógł ponownie korzystać z GA4 jako realnego wsparcia w analizie efektywności kampanii, zespół odzyskał bardziej wiarygodną podstawę do optymalizacji budżetów i działań marketingowych, a dane analityczne znów zaczęły wspierać decyzje biznesowe, zamiast je komplikować.

W projektach analitycznych bardzo łatwo zatrzymać się na poziomie samej implementacji i szukać błędu wyłącznie w tagach czy konfiguracji narzędzi. Ten case pokazał, że źródło problemu może leżeć znacznie głębiej - w logice procesu zakupowego i sposobie, w jaki użytkownik finalizuje transakcję. Dopiero połączenie analizy danych, testów i zrozumienia całej ścieżki klienta pozwala odzyskać wiarygodny obraz sprzedaży i podejmować decyzje w oparciu o dane, którym naprawdę można ufać.

Wnioski

Ten projekt pokazał, że rozbieżności w danych sprzedażowych nie zawsze wynikają z błędnej implementacji analityki. Czasem źródło problemu znajduje się znacznie głębiej – w samej konstrukcji procesu zakupowego i w tym, jak użytkownik przechodzi przez jego końcowe etapy.

Najważniejsze wnioski z projektu:

arrow-violet
poprawnie wdrożone tagi nie gwarantują jeszcze pełnego i wiarygodnego pomiaru,
arrow-violet
analiza jakości danych powinna obejmować nie tylko konfigurację narzędzi, ale też realny przebieg ścieżki użytkownika,
arrow-violet
problemy analityczne często mają źródło procesowe, a nie wyłącznie techniczne,
arrow-violet
czasem najskuteczniejsze rozwiązanie nie wymaga skomplikowanego wdrożenia, tylko trafnej diagnozy.
Z perspektywy biznesowej kluczowe było to, że udało się nie tylko ograniczyć problem z raportowaniem, ale też przywrócić Klientowi możliwość podejmowania decyzji w oparciu o dane, którym można zaufać.

Dziękujemy za przesłanie formularza kontaktowego.

Poświęć nam jeszcze 20 sekund!

Zanim przejdziemy do konkretów, mamy do Ciebie krótką prośbę. Odpowiedz na 3 szybkie pytania, które bardzo nam pomogą.