Skąd się biorą różnice w danych o konwersjach i transakcjach?

Dzień jak co dzień z życia marketera/analityka: robiąc raport w Google Ads, dane o konwersjach/transakcjach są diametralnie inne, niż te, które obserwujemy w GA4. Jeżeli porównamy je z innymi narzędziami marketingowymi lub (co gorsza) z firmowym CRMem, może się okazać, że każde narzędzie raportuje “po swojemu”. Z czego wynikają te różnice w danych? Które liczby są prawidłowe i jak nie zwariować w takim rozgardiaszu? Jako analitycy danych, często borykamy się, z problemem rozbieżności w liczbach konwersji i transakcji. Niniejszy artykuł, ma na celu wyjaśnienie podstawowych przyczyn tych różnic. Skupię się na różnicach GA4 vs Google Ads vs CRM, ale większość wniosków jest uniwersalna także dla innych narzędzi. Kolejność nie odzwierciedla ważności poszczególnych powodów.  

Spis treści

Różne raporty w GA4 = różnice w danych 

Zacznijmy od kluczowego problemu – już w ramach jednego narzędzia – Google Analytics 4 mamy kilka koncepcji związanych z danymi. Różne raporty pokazują diametralnie inne liczby.  

Przykładowo inną liczbę użytkowników z Google Ads zobaczymy w raporcie pozyskanie użytkowników (który mówi nam o liczbie NOWYCH użytkowników których przyniosło dane źródło/kanał na stronę), inną w pozyskanie ruchu (pokazuje liczbę sesji, które przyniosło dane źródło). Jeszcze inną liczbę zobaczymy w zakładce reklamy, które pokazuje dane na poziomie eventu.  

Na koniec – inne wyniki zobaczymy w eksploracjach, które oprócz tego, że będą miały inny zakres zbierania (maksymalnie 14 miesięcy w wersji bezpłatnej) to pobierają dane z innego zbioru – wcześniej wstępnie zagregowanego, żeby przyspieszyć generowanie raportu. Przeczytaj więcej o raportach niestandardowych w GA4 w naszym artykule: Raporty niestandardowe w GA4 – czyli czym jest sekcja eksploracji.

Jeżeli dodamy do tego różne wyniki, jeżeli dane pobierzemy przez API a jeszcze inne w BQ, gdzie widzimy surowe dane, robi się nam niemałe zamieszanie. Pamiętajmy w tym miejscu – jest to zupełnie normalne (chociaż nieintuicyjne). Różnice między danymi w ramach GA4 i BQ, dobrze pokazuje artykuł TUTAJ.

Różne modele atrybucji = różnice w danych

Narzędzia mogą stosować różne modele atrybucji, co oznacza, że ​​konwersja może być przypisywana, różnym kampaniom/kanałom marketingowym/reklamom czy słowom kluczowym. W GA4 możemy w ustawieniach wybrać pomiędzy atrybucją Data Driven oraz atrybucją w modelu Last click. 

UWAGA: mimo zmiany ustawień niektóre raporty, będą korzystały z innych modeli. Przykładem może być tutaj raport pozyskanie użytkowników (w uproszczeniu model first click) czy pozyskanie ruchu (w uproszczeniu model last click). Model atrybucji możemy ustawić w administracji. Zmiana ta działa retroaktywnie co oznacza, że możemy wybrać inny model, zobaczyć historyczne dane, a następnie wrócić do poprzednich ustawień.  

W Google Ads zliczanie konwersji działa inaczej. Funkcjonują one w oparciu, o dane dotyczące wyświetleń i kliknięć w reklamy. Jeżeli klient wejdzie na stronę z reklamy z kampanii A, następnie wróci na stronę z kampanii B, a finalnie skonwertuje z newslettera, to w Google Ads konwersja zostanie przypisana: 

–  do kampanii A i B (przy modelu data driven – proporcje zostaną przypisane przez algorytmy),

– tylko do kampanii B w modelu last click.  

Zauważ, że w Google Analytics konwersja zostanie przypisana diametralnie inaczej (uwzględniając w różnych proporcjach – w zależności od modelu atrybucji także kampanie e-mail marketingową). W systemie Google Ads, w ustawieniach tych konwersji mamy 2 możliwe ustawienia – data driven oraz last click. Co ważne nie działają one retroaktywnie. Jeżeli zmienimy ustawienia, będziemy musieli poczekać ponownie, aż zbiorą się dane.  

Więcej o atrybucji w Google Ads przeczytasz TUTAJ.

Różnice w danych a dzień przypisania konwersji  

GA4 przypisuje konwersję i transakcję do dnia, w którym nastąpiła. Inaczej jest w Google Ads – tam konwersja przypisana jest, do dnia kliknięcia w reklamę. Innymi słowy, jeżeli klient kliknie w poniedziałek w reklamę, następnie wróci w środę z innego źródła (np. z wyników organicznych) to w Google Ads konwersja zostanie przypisana do poniedziałku, w GA4 do środy.

Różne będą też źródła – Ads przypisze konwersje do danej kampanii, która wygenerowała kliknięcie w poniedziałek – w GA4 w zależności od raportu konwersja może być przypisana do Google Ads (raport pozyskania użytkowników), Google/organic – raport pozyskanie ruchu lub częściowo do Google Ads częściowo do SEO (raport konwersje lub niektóre eksploracje).   

A teraz najlepsze – w CRMie/CMSie sklepu, transakcja może być przypisywana zupełnie inaczej. Spotkałem się z sytuacją, w której była ona przypisywana: po akceptacji przez Clint Service, po otrzymaniu potwierdzenia płatności, bezpośrednio po złożeniu do systemu, po zmianie statusu transakcji – to niektóre z przypadków. Nie muszę mówić, jak wpływa to na finalny wynik porównania.  

Ustawienia zliczania konwersji 

W GA4 możemy wybrać jedną z dwóch metod zliczania konwersji. Ustawienia te pozwalają nam śledzić konwersję: raz na zdarzenie lub raz na sesję. Przykładowo jeżeli celem, jest dla nas wejście na stronę kontaktu, warto podczas sesji zliczyć 1 takie zdarzenie (w większości przypadków nie ma znaczenia czy użytkownik wejdzie na daną podstronę 5 razy podczas sesji). Inaczej jest w przypadku np. wysłania formularza/transakcji – tutaj chcielibyśmy wiedzieć o wszystkich wysłanych formularzach czy wszystkich transakcjach – wybierzmy opcję raz na zdarzenie. 

Analogiczne ustawienia możemy znaleźć w Google Ads. Należy upewnić się, że ustawienia konkretnych konwersji, są zgodne w obu narzędziach. 

Aspekty techniczne mierzenia konwersji  

To kiedy zliczamy (w GTM albo za pomocą kodu) daną konwersję może mieć znaczenie. Często konwersja do Google Ads wysyłana jest w innym momencie niż do GA4. Przykładowo konwersja na wysłanie formularza, może być wysyłana po kliknięciu w przycisk wyślij, po przejściu walidacji lub po wyświetleniu strony podziękowania. Często nawet z pozoru mała różnica, może powodować duży rozjazd w danych.  

Konwersje mogą obejmować oprócz konkretnych zdefiniowanych działań, także inne mierzone np. na YouTube – przykładem mogą być tutaj konwersje polegające na subskrybcji kanału na YT (więcej TUTAJ).

Dodatkowo różne systemy marketingowe, jako konwersje mogą liczyć też dodatkowe akcje np. polubienie posta/share na FB – może to powodować, że w kolumnie konwersje w narzędziu zobaczymy liczbę akcji zdefiniowanych przez nas oraz dodatkowe aktywności, ni jak nie odpowiadające temu co widzimy w GA4.   

Różnice w danych przy różnych ustawieniach tożsamości w GA4

Jeszcze jedno ustawienie – tym razem wewnątrz narzędzia, które może wpłynąć na liczby i nasze porównania. Jest nim tożsamość na potrzeby raportowania. W zależności czy wybierzemy tożsamość opartą o urządzenie, mieszaną, obserwowaną, Google w różny sposób, będzie rozpoznawał użytkowników, różnie będzie też podchodził do tematu modelowania danych (czyli dodawania na podstawie sztucznej inteligencji takich danych, które nie zostały zebrane z uwagi na brak zgód w naszym narzędziu CMP).  

Ustawienie to działa retroaktywnie – możemy sprawdzać, jak wpływają zmiany tożsamości na dane i wrócić do poprzedniej wersji. Od razu powiem, że każda z nich ma swoje plusy i minusy więcej można przeczytać TUTAJ.  

Polecamy także stworzyć mini dokument z „warunkami do analizy” i uwzględnić w nim ustawienia, jakie należy sprawdzić przed startem analiz. Dzięki temu osoby, które raportują będą miały te same ustawienia narzędzia, co wpłynie na jakość danych.   

Consent mode a różnice w danych

Najbardziej hot słowo w analityce w 2024: dane modelowane i Consent Mode v2. Prawo narzuca na właścicieli stron i sklepów obowiązek zbierania zgód na przetwarzanie danych. W przypadku braku zgody użytkownika na śledzenie, GA4 może wysyłać anonimowe pingi do swoich serwisów, aby to na co nie zgodzili się użytkownicy wymodelować za pomocą AI. 

Nie muszę mówić, że modelowane dane mogą być naszym sprzymierzeńcem (więcej danych dla innych algorytmów, które na ich podstawie mogą lepiej rozumieć potencjalnych użytkowników i wyświetlić im bardziej adekwatne reklamy). Mogą także wpłynąć na zwiększenie liczby konwersji / transakcji w GA4. Niestety nie możemy sprawdzić, które transakcje są modelowane. Możemy to częściowo obejść, przełączając tożsamość na potrzeby raportowania i analizując różnice.    

Procesowanie danych 

Dane które zostaną zliczone muszą zostać przesłane do serwera i przeprocesowane. Trwa to od kilku do nawet 48 godzin (w wersji GA4 360 dane procesowane są znacznie szybciej). Niestety w narzędziu nie widzimy, kiedy była data ostatniej synchronizacji, czy wszystkie dane zostały poprawnie przeprocesowane.  

W związku z tym jeżeli prowadzimy porównania z ostatnich 2 dni, możemy natchnąć się na rozbieżności wynikające z faktu, że część danych jest już przeprocesowana i widoczna w raporcie, a część jeszcze nie. Rozwiązaniem tego problemu jest oczywiście nieuwzględnianie ostatnich 2 dni w analizach. 

Porównanie między rynkami  

Dla firm działających na kilku rynkach, problem mogą generować także, porównania danych między rynkami. Sprawdzenie danych w CRM i Google Analytics może pokazać, że rozbieżności między rynkami są duże. Bierze się to z faktu, że do takich porównań wykorzystujemy wymiar domyślny Kraj. Google rozpoznaje lokalizację użytkownika na podstawie adresu IP oraz innych sygnałów świadczących o lokalizacji użytkownika. W niektórych przypadkach lokalizacja ta może być niedokładana.  

Rozwiązaniem jest tutaj przekazywanie do warstwy danych parametru niestandardowego „rynek” co pozwoli uniezależnić się od tego, w jaki sposób Google rozpoznaje lokalizację użytkownika i przypisać konkretne sesje, a w dalszej kolejności także konwersje do odpowiedniego rynku.  

Technologia, przeglądarki i adblocki 

Tagi GA4 oraz Google Ads (ale często też innych narzędzi marketingowych) działają w oparciu o kody wstrzykiwane na stronę za pomocą Java Script. Technologiczne uwarunkowania mogą powodować problemy z prawidłowym zliczaniem każdej aktywności użytkownika.  

Przykładowo użytkownicy korzystający z przeglądarki Brave, lub z różnego rodzaju adblocków mogą blokować skrypty JS, a w przypadku niektórych z nich (adblock plus) także cały kontener GTM. Oczywiście w takiej sytuacji żadne dane nie zostaną przekazane do narzędzi śledzących, podczas gdy transakcje/konwersje mogą zostać prawidłowo wysłane do CRM. W takim wypadku, warto przekazywać informacje o przeglądarce do CRM – tak żeby mieć później możliwość porównania ich do danych GA4.  

Bramki płatności a różnice w danych

Użytkownicy po płatności często nie wracają na stronę podziękowania za transakcje. Dodatkowo niektóre formy płatności wyprowadzają użytkownika poza domenę – może to wiązać się z problemami:  

• ruch po powrocie z bramki zostanie przypisany do innego źródła (np. do źródła refferal konkretnego banku),  

• transakcja może nie zostać prawidłowo zanotowana.  

Rozwiązaniem może być odpalenie dodatkowego zdarzenia: zakup bez płatności, które uruchomi się przed przejściem do bramki płatności. Oczywiście rozwiązanie to spowoduje, że będziemy mieć informacje o przejściu całego procesu a nie finalnej transakcji – często odnotujemy kilka procent więcej realizacji takiego celu, niż finalnie zostanie dokonanych.  

Ustawienia GTM i błędy w konfiguracji 

Celowo ostatni błąd – bardziej częsty to… błędy w konfiguracji. Dane które wczoraj pojawiały się w warstwie danych zostają usunięte, zablokowane przy kolejnych zmianach na stronie, w aplikacji czy w systemie. Inną kategorią błędów będą zmiany w identyfikatorach, klasach, widocznych elementach, selektorach html – jeżeli na nich oparliśmy swoje wdrożenie, tym bardziej może okazać się ono nieodporne na zmiany strony.  

Ostatnią podkategorią są zmiany w samych narzędziach: GA4 i GTM  czy innych narzędziach marketingowych. One także mogą powodować, że niektóre elementy przestana być prawidłowo zliczane.  

Cykliczne sprawdzanie konfiguracji, poprawności warstwy danych, testowanie scenariuszy, reguł, zmiennych w GTM – to podstawa. Utrzymanie wdrożenia to jeden z kluczowych elementów poprawnego zliczania danych i skutecznej analityki.  

Podsumowanie

Różnice w danych o liczbach konwersji i transakcji między narzędziami analitycznymi mogą być… całkiem normalną sprawą. Często różnice nie wynikają z błędów w konfiguracji.  

Żeby zachować spójność w analizach warto przygotować: 

• Założenia raportowania – dokument pokazujący, które raporty będą kluczowe do oceny poszczególnych sytuacji. Możemy w nim zaznaczyć, że kampanie Google Ads oceniamy na podstawie konwersji z panelu Google Ads, a liczbę nowych użytkowników wyciągamy z raportu pozyskanie użytkownika. Spisanie ustawień narzędzi/poszczególnych raportów, pomoże nam oszczędzić masę czasu na tłumaczenie oraz na sprawdzanie przyczyn rozbieżności.  

• Definicje konkretnych raportów/metryk/wymiarów – tak aby konkretne osoby wiedziały co one oznaczają, gdyż często nazwy konwersja w różnych narzędziach oznaczają diametralnie coś innego. Baza definicji to przydatne narzędzie każdego data teamu.   

• Proces utrzymania wdrożenia – upewnijmy się i sprawdzajmy wdrożenie, żeby coś co działało wczoraj miało też prawo zadziałać jutro, a co ważniejsze żebyśmy dowiedzieli się jeżeli działać przestanie. Do procesu przydatna będzie dokumentacja wdrożeniowa – czyli opis tego jak skonfigurowaliśmy narzędzie.  

Inną sprawą jest wyszukiwanie błędów w konfiguracji i miejsc gdzie te błędy się pojawiają. Często taka zagadka jest poszukiwaniem przysłowiowej igły w stogu siana – w kolejnym artykule opiszę, jak podejść do tego problemu i jak ustrukturyzować poszukiwania tej igły.  

Dodatkowe materiały 

Zmiany w Google Ads i Google Analytics 2024 | Bluerank

Jak policzyć atrybucję w GA4 – Model Markowa | Bluerank

Google Analytics 4 w pytaniach i odpowiedziach | Bluerank

https://support.google.com/analytics/answer/12233314?hl=pl

https://support.google.com/google-ads/answer/7457111?hl=pl