Google Analytics i rozbieżności w danych – skąd się biorą?

Niektórzy wymagają od Google Analytics czegoś niemożliwego – czyli idealnych danych. W końcu skoro jesteśmy w świecie cyfrowym, to wszystko da się dokładnie zmierzyć, prawda? No nieprawda.

W tym artykulę wyjaśnię, co sprawia, że dane w Google Analytics 4 nie są i nigdy nie będą idealnie zbieżne z rzeczywistością.

Rozbieżności liczby transakcji w Google Analytics

Najczęściej pytania o rozbieżności w danych pomiędzy Google Analytics 4 a rzeczywistością dotyczą raportowanego przychodu czy liczby transakcji. Nic w tym dziwnego – w końcu w e-commerce to kluczowe statystyki.

Zazwyczaj GA4 pokazuje niższą sprzedaż, niż platforma sklepowa. Rozbieżności w okolicach 5-20% to norma.

Dlaczego w GA4 widzisz mniej danych o transakcjach?

Na początku skupmy się na przypadku sklepów internetowych i raportowania sprzedaży w Google Analytics. Mamy tutaj trzy główne powody rozbieżności i – co istotne – każdy z nich zazwyczaj da się rozwiązać.

Nie zawsze jest to trywialne, ale przynajmniej coś możesz z tym zrobić. Bo – jak dowiesz się z drugiej części artykułu – istnieją też mechanizmy ograniczające śledzenie, na które wpływu już nie masz.

Powód #1: Brak powrotu na stronę podziękowania

Rozbieżności w danych transakcyjnych wynikają ze sposobu, w jaki są zbierane. Zazwyczaj zdarzenie purchase jest wysyłane na stronie podziekowania za złożone zamówienie.

Co musi zrobić użytkownik, żeby na taką podstronę trafić? Oczywiście wrócić ze strony banku tudzież pośrednika płatności. Nie każdy użytkownik to robi. Niektórzy zamykają kartę przeglądarki, zanim nastąpi przekierowanie, a zatem zanim tag śledzący transakcję ma w ogóle szansę się uruchomić.

Ten problem zazwyczaj nie dotyczy zamówień z płatnością za pobraniem lub przelewem.

Powód #2: Zbyt duży rozmiar hita

Hity wysyłane do Google Analytics nie mogą przekroczyć określonego rozmiaru. Jeśli są zbyt duże, to nie zostaną wysłane.

W Universal Analytics maksymalny rozmiar hita to 8192 bajty. W Google Analytics 4 limit jest dwukrotnie wyższy i wynosi 16 384 bajty.

W praktyce problem ze zbyt dużym rozmiarem hita dla kluczowego zdarzenia Purchase dotyczy sklepów internetowych, gdzie występują zamówienia z wysoką liczbą unikalnych produktów kupowanych jednocześnie.

Co przychodzi do głowy?

• Hurtownie wszelkiego typu
• Sklepy internetowe skierowane do B2B kupującego „drobnicę” (np. kilkadziesiąt różnych artykułów biurowych w jednym zamówieniu)

Wpływ na rozmiar hita ma nie tylko sama liczba unikalnych produktów, ale także wymiary niestandardowe. Zależność jest prosta – im więcej linijek i parametrów, tym większy hit.

Drugim zdarzeniem podatnym na zbyt duży rozmiar jest productImpressions (UA) i view_item_list (GA4), czyli dane o produktach wyświetlonych na listingu. Jeśli lista produktów jest długa i zawiera górne kilkadziesiąt lub więcej pozycji, to istnieje duże ryzyko, że zdarzenie nie zmieści się w limicie. Występowanie takiej sytuacji warto potestować ręcznie na listingach z wieloma produktami, odpalając konsolę i szukając błędu.

Powód #3: Błędy i braki w konfiguracji śledzenia

Ile platform sklepowych i wtyczek do dataLayer / GA / GTM, tyle potencjalnych problemów z jakością danych.

Aby dać Ci przykład, popularnym problemem na platformie Presta Shop jest kompatybilność wtyczek do dataLayer z wtyczkami obsługującymi różnych pośredników płatności internetowych.

Sęk w tym, że każdy operator płatności ma w sklepie na Presta oddzielny adres URL dla strony podziękowania. A wtyczka do dataLayer „widzi” tylko ten ogólny i nie jest w stanie dodać dataLayer do stron podziękowania generowanych przez wtyczunie do płatności.

Tego typu problemy się zdarzają, więc jeśli widzisz sporo brakujących transakcji, to warto przeprowadzić audyt konfiguracji Google Analytics. Kluczowe jest przejście procesu zakupowego na wszystkie sposoby, czyli przetestowanie każdej formy płatności i finalizowania transakcji (z rejestracją, z logowaniem, jako gość, za pobraniem, etc.).

Jak rozwiązać te problemy?

Powody rozbieżności w danych wymienione powyżej to czysto techniczne wyzwania związane z implementacją Google Analytics. Przy odpowiednich umiejętnościach i cierpliwości można je wyeliminować.

• Użytkownicy nie wracają na stronę podziękowania? Wysyłaj zdarzenie purchase przez Measurement Protocol, z poziomu platformy sklepowej. Można nawet pokusić się o rozwiązanie, które wysyła zdarzenie dopiero, gdy przesyłka zostanie wysłana do klienta. Unikniesz wtedy nieopłaconych i anulowanych zamówień w Google Analytics.
• Rozmiar hita jest zbyt duży? Wyrzuć niepotrzebne wymiary – to szybkie rozwiązanie. Docelowo warto napisać skrypt, który podzieli hit na dwa oddzielne, jeśli produktów w zdarzeniu purchase będzie zbyt dużo.
• Błędy i braki w konfiguracji śledzenia? Zrób audyt konfiguracji Google Analytics, a następnie napraw znalezione błędy. Czasem wymaga to zmian po stronie systemu sklepowego. Nikt nie mówił, że będzie lekko

Ograniczanie śledzenia

Większość stron internetowych przy implementacji Google Analytics 4 polega na Google Tag Manager w tradycyjnym, „webowym” wydaniu. Co za tym idzie, wszelkie requesty do serwerów takich narzędzi, jak GA4, Facebook czy Google Ads, są wysyłane z poziomu przeglądarki użytkownika.

W praktyce oznacza to, że użytkownik może wpłynąć na wysyłanie danych. Świadomie (instalując wtyczki blokujące śledzenie czy czyszcząc ciasteczka) bądź nieświadomie (bo przeglądarka samoistnie włączy blokady lub ograniczy żywotność ciastek).

Przyjrzyjmy się konkretnym problemom.

Problem #1: AdBlocki i inne wtyczki tego typu

Nie będę tutaj analizować wszystkich dostępnych na rynku AdBlocków i wtyczek ograniczających działanie skryptów śledzących, bo jest ich po prostu zbyt wiele. Natomiast bezpiecznie można założyć, że przynajmniej część użytkowników Internetu blokuje w ten sposób śledzenie Google Analytics, a nawet Google Tag Managera.

Tutaj masz związane ręce, bo możesz sobie konfigurować do woli tagi śledzące w Google Tag Manager, ale finalnie są one zamieniane na request do domeny google-analytics.com, którą AdBlock zna i taki request zablokuje.

Koniec zabawy… no chyba, że zdecydujesz się na Google Tag Manager w wydaniu server-side, dzięki któremu możesz ominąć AdBlocki, ponieważ requesty do serwerów Google nie będą wysyłane z przeglądarki użytkownika.

Problem #2: Ograniczanie śledzenia przez przeglądarki

~70% rynku przeglądarek należy do Google Chrome, który jest najmniej restrykcyjny. Ale już w przypadku Safari, Firefox czy Brave Browser tak wesoło nie jest.

O szczegółach dotyczących rozwiązań dbających o prywatność użytkowników w kontekście przeglądarek można by napisać spory elaborat, ale pozwól, że podam Ci jeden mało znany przykład.

Safari automatycznie skraca żywotność ciasteczek Google Analytics do zaledwie 7 dni. Czyli jeśli odwiedzę dzisiaj stronę i wrócę na nią za 10 dni, to dla GA będe już nowym użytkownikiem. Brzmi strasznie? To pa tera.

Jeśli w adresie URL w momencie wejścia na stronę znajdują się parametry, np. ?gclid czy ?fbclid, Safari dokręca śrubę i ciasteczko „żyje” tylko 24 godziny.

W efekcie jeśli sprawdzisz dane dla Safari w swoim GA4, to najprawdopodobniej % nowych użytkowników dla tej przeglądarki będzie bliski 100%.

Na marginesie dodam, że Brave Browser w domyślnej konfiguracji idzie o wiele, wiele dalej. Nie ogranicza czasu wygasania ciasteczka. Po prostu blokuje Google Tag Managera. Tak, dobrze przeczytałeś. GTMa.

Problem #3: Użytkownik to ciasteczko, a nie człowiek

W tym puncie uczepię się na chwilę nie tyle łącznej liczby zbieranych zdarzeń, ale ich przypisania do konkretnych użytkowników.

Błędne przekonanie, z którym można się spotkać, to stawianie znaku równości między liczbą Użytkowników w Google Analytics, a faktyczną liczbą osób (takich z krwi i kości), odwiedzających stronę.

De facto metryka powinna się nazywać Przeglądarki, a nie Użytkownicy i w większości przypadków miałoby to jak najbardziej sens (wyjątkiem jest tutaj stosowanie User ID czy Google Signals, ale to temat na oddzielny artykuł).

W uproszczonym świecie, gdzie Google Analytics 4 w kwestii identyfikacji Użytkowników bazuje na ciasteczku first-party i zawartym w nim identyfikatorze (który jest losowym ciągiem znaków), zawsze liczba użytkowników w GA4 jest wyższa, niż liczba faktycznych osób wchodzących na stronę.

Dlaczego liczba użytkowników w GA4 nie odzwierciedla rzeczywistości?

• Korzystamy z różnych urządzeń. Laptop prywatny, laptop służbowy, smartfon. Jeśli nawet na każdym z nich korzystamy z tylko jednej przeglądarki (i nigdy w trybie incognito), to mamy na dzień dobry 3 różnych userów w GA4.
• Różne przeglądarki na tym samym laptopie. Osobiście regularnie korzystam z Chrome i Brave Browser. Do tego często odpalam tryb incognito przy zakupach w sieci (żeby zobaczyć popup z rabatem za maila, który zamknąłem w zwykłym trybie – wiadomo). Albo żeby zweryfikować, czy linie lotnicze nie zawyżają mi ceny ;-). I już zamieniam się w kilku użytkowników w GA4.
• Tryb incognito – tutaj to już w ogóle jest ciekawie. Każde otwarcie trybu incognito = nowe ciasteczko GA4. Wchodzę na stronę – dostaję ciasteczko XYZ. Zamykam tryb incognito, otwieram go ponownie, znowu wchodzę na stronę – dostaję ciasteczko FHG.
• Przeglądarki in-app na smartfonach – mój ulubiony przypadek. Jak pewnie zauważyłeś, gdy w aplikacji klikniesz w link do strony internetowej, to zazwyczaj nie otwiera się ona w zwykłej, tylko takiej dziwnej, jakby ograniczonej przeglądarce. To tak zwana „in-app browser” – dzięki takiemu rozwiązaniu twórcy aplikacji mają większe szanse na utrzymanie użytkownika, bo interfejs jest okrojony, a najjaśniejszym punktem tej przeglądarki jest opcja powrotu do aplikacji. Konsekwencje dla śledzenia są istotne, bo każda in-app browser to oddzielny byt. A zatem jeśli otworzysz moją stronę, wchodząc najpierw w link w apce Facebooka, później na LinkedIn, a na końcu z wyników wyszukiwania (i to wszystko na tym samym telefonie!), to mój Google Analytics 4 zarejestruje trzech różnych użytkowników.

Problem #4: Brak zgody na śledzenie

W 2022 roku coraz częściej mówi się o ochronie prywatności w sieci. Chodzi tutaj o banery ze zgodami na przechowywanie danych (głównie chodzi o ciasteczka). Dopóki użytkownik świadomie nie udzieli zgody na śledzenie, nie powinniśmy tworzyć ciasteczek czy zapisywać informacji w localStorage / sessionStorage.

A skoro Google Analytics 4 (i masa innych narzędzi) opiera się o ciasteczka pod kątem identyfikacji użytkowników, to… tak, jest problem.

Na szczęście dla GA4 i Google Ads dostępny jest tak zwany Consent Mode (tryb uzyskiwania zgody). Dzięki niemu można ograniczyć wpływ braku zgód na śledzenie, ale pamiętajmy, że nadal trzeba liczyć się z tym, że pewien odsetek użytkowników nie pojawi się w naszych raportach.

Przy włączonym Consent Mode zbierasz też dane „anonimowe” od użytkowników, którzy nie wyrazili zgody na przechowywanie danych Brzmi dobrze, ale jest tu sporo ograniczeń.

To, co zbierasz, to pojedyncze zdarzenia, których nie da się nawet połączyć w jedną wizytę, nie mówiąc o wielu wizytach tego samego użytkownika. GA4 wycina też takie wymiary, jak chociażby źródło, medium czy kampanię.

Jak sobie z tym poradzić?

Podsumowując, problemy z identyfikacją użytkownika na różnych urządzeniach i przeglądarkach sprawiają, że jakość danych na przykład o ścieżkach konwersji i modelach atrybucji jest co najmniej dyskusjna.

To prowadzi też do rozważań o tym, w jaki sposób podejść do analizy danych w dobie cross-device, blokowania ciasteczek i konieczności otrzymania zgody na śledzenie. W kategorii „Ograniczanie śledzenia” poza włączeniem Consent Mode i zaprojektowaniem banera ze zgodami w taki sposób, aby zachęcał do ich akceptacji, niewiele da się zrobić (w kontekście zbierania danych).

Podsumowanie

Sposoby na odnalezienie się w świecie coraz mniej dokładnych danych to temat na obszerny artykuł bądź nawet ich serię.

Zdradzę tylko, że nie jest aż tak źle, jak może się wydawać. Google Analytics zawsze był narzędziem do obserwowania trendów (a nie do szczegółowej analizy finansowej), więc ze swojej roli nadal będzie w stanie się wywiązać. Trzeba tylko trochę zmodyfikować swoje podejście.

Oczywiście warto dbać o to, aby konfiguracja Google Analytics 4 była najlepsza, jak to tylko możliwe. Jak dowiedziałeś się z artykułu, część braków w danych można wyeliminować.