Jeśli masz złe dane, otrzymasz złe odpowiedzi. Najczęstsze błędy w konfiguracji Google Analytics, które psują Twoje dane

Jest takie powiedzenie: „śmieci na wejściu – śmieci na wyjściu” („garbage in – garbage out”). Oznacza to, że jeśli gromadzisz błędne dane, to decyzje, które na ich podstawie podejmiesz, również będą błędne. Podzielę się z Tobą kilkoma radami, jak zminimalizować czynniki zniekształcające dane w Google Analytics.

1. Niepoprawna instalacja kodu śledzącego

Do poprawnego zbierania danych w Google Analytics potrzebujesz kodu śledzącego, który powinien zostać umieszczony w sekcji head każdej podstrony Twojego serwisu. Możesz go wygenerować na swoim koncie Analytics w tym miejscu: „Administracja” → „Usługa” → „Informacje o śledzeniu” → „Kod śledzenia”. Każda witryna otrzymuje własny kod śledzący. Upewnij się, że ten, który implementujesz, jest właściwy.

Brak kodu śledzącego na jakiejś podstronie spowoduje, że ruch z niej nie będzie raportowany w Google Analytics, czyli śledzenie ścieżki użytkownika zostanie zaburzone.

Słuchaj „Marketer+” Podcast

Zadbaj o to, aby kod został wczytany tylko raz na każdej podstronie. Jego podwójne wywołanie zniekształci Twoje dane, przykładowo współczynnik odrzuceń spadnie do nienaturalnie niskiego poziomu. Jego typowa wartość jest dwucyfrowa (np. 70%), więc jeśli nagle będzie to jedna cyfra, koniecznie sprawdź implementację kodu śledzącego.

Miejsce instalacji kodu śledzącego

Źródło: Google Analytics

Pamiętaj, że nie jesteśmy w stanie poprawić danych, które zostały już wysłane do Google Analytics, ani też uzupełnić raportów o informacje niewysłane w wyniku błędnej implementacji (np. braku kodu na jakiejś podstronie).

Przeskanuj swoją witrynę pod kątem błędów w rozmieszczeniu kodu śledzącego, np. za pomocą narzędzia GAChecker.com.

2. Brak oznaczenia zdarzeń bez interakcji

Pewnie słyszałeś o zdarzeniach w Google Analytics. Czy wiesz, że występują w dwóch odmianach? Są to:

• zdarzenia z interakcją, czyli służące do śledzenia działań (interakcji) użytkowników na stronie, takich jak kliknięcie w przycisk, pobranie pliku, wysłanie formularza, obejrzenie filmu czy scrollowanie strony,
• zdarzenia bez interakcji, czyli tzw. pasywne, niezależne od interakcji użytkowników, uruchamiane zazwyczaj po załadowaniu strony, takie jak wyskakujące okienko czatu czy automatyczne uruchomienie filmu.

Domyślnie każde zdarzenie jest traktowane jako interakcja użytkownika, a więc ma wpływ na obliczenie współczynnika odrzuceń (odrzucenie to wizyta z tylko jedną interakcją). Jeśli śledzisz w witrynie zdarzenia pasywne (automatyczne), musisz je samodzielnie oznaczyć jako zdarzenia bez interakcji. W przeciwnym razie współczynnik odrzuceń Twojej witryny będzie bliski zera i stanie się wówczas bezużyteczną miarą.

W praktyce takie oznaczenie jest dość proste i polega na dodaniu jednego parametru do kodu zbierającego dane o zdarzeniach. Metody konfiguracji będą różne w zależności od wykorzystywanej wersji Google Analytics oraz sposobu implementacji zdarzenia.

Przykład oznaczenia zdarzenia bez interakcji wdrożonego za pośrednictwem Google Tag Managera

Źródło: Google Tag Manager

3. Śledzenie ruchu z innych domen

Twój kod śledzenia GA jest widoczny dla każdego, kto zajrzy do źródła strony. Każdy może więc go skopiować i wywołać w swojej witrynie, a tym samym popsuć Twoje dane w Google Analytics. Tę możliwość często wykorzystują spamerzy. Liczbę ich działań możesz sprawdzić w raporcie: „Odbiorcy → „Technologia” → Sieć”, po wyborze wymiaru podstawowego nazwa hosta. W takim raporcie powinna się znaleźć wyłącznie Twoja własna domena, ewentualnie domeny z nią powiązane
(np. strony obsługujące płatności).

Na szczęście łatwo możesz zapobiec temu problemowi przez konfigurację w widoku raportowania filtra, który uwzględni w statystykach ruch tylko z Twojej domeny. Przejdź do sekcji: „Administracja” → „Widok” → „Filtry” → „Dodaj filtr”.

Przykładowe ustawienia filtra uwzględniającego nazwę hosta

Źródło: Google Analytics

Jeśli nie widzisz opcji dodawania nowego filtra, oznacza to, że nie masz odpowiednich uprawnień na koncie Analytics (potrzebujesz dostępu do edycji na poziomie konta). Filtr pozwoli wyeliminować również błędy ludzkie, czyli np. sytuacje, w których inny użytkownik przypadkowo zaimplementuje na swojej stronie kod śledzący z Twoim identyfikatorem. To bardzo rzadki przypadek, niemniej warto się przed nim zabezpieczyć.

4. Śledzenie własnych sesji

Domyślnie każda wizyta na stronie złożona przez Ciebie lub Twoich pracowników jest rejestrowana w Google Analytics. Zakłóca to dane, ponieważ osoby na co dzień związane z serwisem nie zachowują się jak jego typowi użytkownicy. Możesz to naprawić przez wykluczenie ze statystyk ruchu wewnętrznego.

Jest na to kilka sposobów, z czego najprostszy to użycie filtra wykluczającego adres IP. Jeśli nie znasz swojego adresu IP, wpisz w wyszukiwarce zapytanie „mój adres IP” – powinien to być pierwszy wynik. Przejdź do sekcji: „Administracja” → „Widok” → „Filtry” → „Dodaj filtr”. Wklej swój adres IP w ustawieniach filtra.

Przykładowe ustawienia filtra wykluczającego ruch wewnętrzny

Źródło: Google Analytics

Ten filtr nie zadziała, jeśli masz dynamiczny (zmienny) adres IP. Możesz wówczas skorzystać .

5. Różnice w liczbie transakcji

Najlepszym źródłem informacji o transakcjach jest CRM sklepu. Zanim więc zaczniesz analizować dane o sprzedaży w Google Analytics, porównaj je z liczbami ze swojego CRM. Pewnie nie będą się zgadzać w 100%, ale rozbieżność nie powinna być bardzo duża.

Za mało transakcji w Google Analytics

Z reguły Analytics rejestruje mniej transakcji – przyjmuje się, że akceptowalna jest rozbieżność na poziomie ok. 15%. Skąd bierze się ta różnica?

Wiele serwisów rejestruje transakcję dopiero po jej opłaceniu – na stronie podziękowania za zakup. Problem polega na tym, że niektórzy użytkownicy po przeniesieniu do zewnętrznego systemu płatności nie wracają później na stronę podziękowania, na której umieszczony jest kod transakcji. Takie operacje nie są więc wysyłane do Analytics.

Jeśli obserwujesz duże rozbieżności w swoich danych, spróbuj umieścić kod śledzący transakcje jeszcze przed przekierowaniem do zewnętrznego serwisu płatności. Co prawda może się zdarzyć, że klient ostatecznie nie zapłaci (a jego transakcja zostanie mimo to zaraportowana w GA), jednak z reguły dotyczy to niewielkiej liczby użytkowników.

Musisz jednak wiedzieć, że nawet idealna konfiguracja nie wyeliminuje rozbieżności. Część użytkowników korzysta z programów do blokowania reklam oraz skryptów śledzących i w konsekwencji nie jest w ogóle śledzona przez Analytics, a co za tym idzie: jej transakcje nie są raportowane (ale pojawiają się w CRM).

Za dużo transakcji w Google Analytics

Być może obserwujesz w swoich raportach odwrotny problem, czyli transakcji w Google Analytics jest u Ciebie więcej niż w CRM. Przyczyną błędu okazuje się zazwyczaj wielokrotne wywoływanie kodu transakcji. Może się to zdarzyć np. wtedy, gdy użytkownik odświeży stronę podziękowania za zakup lub na nią powróci. Każde wczytanie tej strony spowoduje ponowne załadowanie umieszczonego na niej kodu transakcji – w rezultacie dane o sprzedaży zostaną wysłane do Analytics kolejny raz.

Możesz szybko sprawdzić, czy dotyczy Cię ten problem. Przejdź do sekcji „Konwersje” → „E-commerce” → „Przegląd” i sprawdź łączną liczbę transakcji zaraportowanych przez Analytics.

Sprawdzanie, ile transakcji zaraportował Google Analytics (było ich 144)

Źródło: Google Analytics

Następnie w raporcie „Konwersje” → „E-commerce” → „Transakcje” porównaj te dane z liczbą unikatowych identyfikatorów transakcji (każda z nich zawsze otrzymuje własne ID).

Raport ma 135 wierszy, czyli takiej liczbie transakcji zostało nadane ID. Zduplikowano więc dziewięć transakcji

Źródło: Google Analytics

Jeśli widzisz, że Twoje dane są zduplikowane, musisz wprowadzić zmiany w wywoływaniu kodu transakcji. Zadbaj o to, aby strona z podziękowaniem za zakup ładowała się tylko raz gdy zachodzi faktyczna transakcja. Każda kolejna próba uzyskania dostępu do tej strony powinna przekierować użytkownika gdzie indziej, np. do szczegółów zamówienia (właśnie ich prawdopodobnie szuka klient).

6. Transakcje przypisywane do bramek płatniczych

Google Analytics przypisuje transakcje do ostatniego znanego (niebezpośredniego) źródła ruchu. Może to rodzić problemy, jeśli sprzedajesz w swojej witrynie produkty i korzystasz z zewnętrznego operatora płatności, np. PayU czy Dotpaya.

Załóżmy, że użytkownik odwiedza Twoją witrynę z reklamy Google Ads i decyduje się na zakup jakiegoś produktu. Wychodzi ze sklepu, aby dokonać płatności online, np. za pośrednictwem serwisu Dotpay.pl, a następnie powraca na stronę z podziękowaniem za zakup. Analytics odnotowuje wówczas nową sesję. Źródłem ruchu będzie odesłanie z serwisu Dotpay (dotpay.pl/referral), do którego przypisana zostanie transakcja. W efekcie otrzymasz zniekształcone dane o skuteczności źródeł ruchu, bo przecież Dotpay w rzeczywistości nic nie sprzedał.

Rozwiązaniem problemu jest dodanie banków i operatorów płatności do listy wykluczeń witryn odsyłających. Znajdziesz ją tutaj: „Administracja” → „Usługa” → „Informacje o śledzeniu” → „Lista wykluczeń witryn odsyłających”. Lista używa dopasowywania „zawiera” – jeśli np. wykluczysz mbank.pl, będzie to dotyczyło również ruchu z subdomeny online.mbank.pl.

Przykładowa lista wykluczeń witryn odsyłających

Źródło: Google Analytics

Wracając do przykładu: gdyby Dotpay.pl znajdował się na liście wykluczeń witryn odsyłających, transakcja zostałaby przypisana do pierwotnego źródła ruchu, którym była reklama Google Ads.

Na liście wykluczeń powinna znaleźć się też Twoja własna domena. Pozwala to uniknąć odnotowywania samodzielnych odesłań, które mogą zdarzać się w kilku sytuacjach, np. w wyniku:

• braku kodu śledzącego na niektórych podstronach,
• braku aktywności użytkownika na stronie przez 30 min, co powoduje zakończenie sesji i nawiązanie nowej po powrocie tej osoby,
• aktywności o północy, kiedy wszystkie aktywne sesje są kończone i rozpoczynane na nowo.

7. Niewłaściwe użycie lub pominięcie parametrów UTM

Parametry UTM to specjalne znaczniki dołączane do adresu URL, które pozwalają Google Analytics określić, w jaki sposób użytkownik trafił do Twojej witryny.

To standardowy adres URL bez kodów UTM:

„https://data.rocks”.

A to ten sam adres URL z dodanymi kodami UTM:

„https://data.rocks/?utm_source=ewp.pl&utm_medium=prasa_online&utm_campaign=bledy_w_konfiguracji_ga&utm_content=link_w_artykule”.

Wszystkie informacje po znaku „?” w podanym przykładzie są wykorzystywane przez Google Analytics do określenia, skąd pochodzi wizyta w witrynie.

Kody UTM możesz dodawać do adresów URL ręcznie albo wykorzystać do tego darmowe narzędzie od Google’a – Campaign URL Builder.

Przykład użycia narzędzia Campaign URL Builder

Źródło: Campaign URL Builder

Kiedy użytkownik kliknie w otagowany link, dane z parametrów UTM zostaną wysłane do Google Analytics. Znajdziesz je w raporcie „Pozyskiwanie” → „Cały ruch” → „Źródło/Medium”.

Dlaczego używanie kodów UTM jest takie ważne? Bo pozwalają one dokładniej określać ruch przychodzący, a przede wszystkim rozszyfrowywać ruch direct. Mówiąc o tym drugim, myślimy najczęściej o odwiedzających, którzy wpisują adres strony WWW w pasek przeglądarki. To faktycznie prawda, niestety niecała. Do kanału direct zaliczany jest cały ruch, którego Google Analytics nie jest w stanie rozpoznać, m.in.:

• linki umieszczone w dokumentach offline (PDF, np. ulotkach),
• linki skrócone przez niektóre narzędzia do skracania,
• przekierowania z witryn z protokołem https (jeśli Twój blog zawiera http),
• linki w wiadomościach e-mailowych, jeśli kliknięte zostaną w programie pocztowym
  (np. Thunderbird, Outlook),
• ruch z niektórych aplikacji mobilnych.

• Analytics automatycznie śledzi Twoje kampanie Google Ads, jeśli konto jest połączone z kontem Ads i włączona została funkcja automatycznego tagowania. Nie musisz wówczas oznaczać adresów URL w reklamach Ads tagami UTM.
• Nie dodawaj tagów UTM do wewnętrznych banerów czy linków kierujących do podstron w obrębie Twojej witryny. Utracisz wówczas informację o oryginalnym źródle ruchu.

8. Brak scalenia tych samych źródeł ruchu

Być może zauważyłeś, że w zapisywaniu niektórych źródeł ruchu panuje duży bałagan. Najczęstszym przykładem jest ruch odsyłający z Facebooka zapisywany na różne sposoby – jako domena główna facebook.com oraz subdomeny (np. facebook.com, l.facebook.com, m.facebook.com itp.).

W raporcie źródeł ruchu może to wyglądać w taki sposób jak na ilustracji poniżej.

Ruch z Facebooka widoczny w Google Analytics

Źródło: Google Analytics

Źródła odesłań zawierające subdomenę z literą „l” oznaczają ruch z Facebooka, który przeszedł przez tzw. Link Shim. Portal używa ich ze względów bezpieczeństwa i prywatności, gdy link kierujący poza niego jest identyfikowany jako niebezpieczny. Z punktu widzenia analizy danych ważne jest źródło ruchu, którym w tym przypadku jest Facebook, nie ma natomiast znaczenia, czy link odsyłający przeszedł kontrolę Link Shim.

Aby poprawić sposób prezentowania danych, użyj filtra, który scali wszystkie odesłania z Facebooka. Analogiczne działania możesz zastosować w przypadku innych „rozbitych” źródeł ruchu, np. Instagrama, Messengera, YouTube’a czy Pinteresta.

Przykładowe ustawienia filtra do scalenia ruchu odsyłającego z Facebooka

Źródło: Google Analytics

9. Brak wykluczenia parametrów zapytania

W adresach URL Twojej witryny mogą występować parametry przekazujące dodatkowe informacje o użytkowniku i jego sesji. Są one zawsze poprzedzone znakiem „?” lub „&” i mogą wyglądać tak: „www.mojadomena.pl?page=2&session_id=1234&x=a009”.

Parametry nie utrudniają odwiedzającym korzystania z serwisu i przez wielu z nich pewnie w ogóle nie są zauważane. W Google Analytics jednak powstaje przez nie lekkie zamieszanie, bo ten domyślnie traktuje adresy z różnymi parametrami jako osobne strony. Dzieli ten sam adres URL na wiele wierszy, co prowadzi do rozbicia danych.

Użyj filtra raportu, aby sprawdzić, czy w Twoich adresach URL pojawiają się parametry. Przejdź do raportu „Zachowanie” → „Zawartość witryny” → „Wszystkie strony”. W pasku wyszukiwania wpisz „?” i naciśnij enter. Spowoduje to wyświetlenie wszystkich adresów URL zawierających ciągi zapytań.

Przykład adresów URL z parametrami zapytania w raporcie Analytics

Źródło: Google Analytics

Następnie wyklucz parametry, których nie chcesz widzieć w swoich raportach – te, które nie wskazują unikatowej treści i/lub duplikują adres, do jakiego są przypisane. Możesz to zrobić tu: „Administracja” → „Widok” → „Ustawienia widoku”. Wypisz po przecinku parametry, które pojawiają się w Twoich adresach URL, a których nie chcesz widzieć w raportach. Upewnij się, że nie wykluczasz żadnych ciągów zawierających przydatne informacje, a do listy dodajesz tylko niepotrzebne rekordy.

Wykluczenie parametrów zapytania

Źródło: Google Analytics

10. Niepoprawna struktura widoków raportowania

To błąd nie tyle w śledzeniu, ile w organizacji danych. W Google Analytics nie ma możliwości odzyskania danych utraconych przez błędną konfigurację. Jeśli zdarzy Ci się zastosować filtr, który „wytnie” z raportów część danych – już ich nie odzyskasz.

Aby chronić swoje dane, utwórz na koncie Analytics co najmniej trzy widoki raportowania:

• główny – będziesz używać go do analizy swoich danych i w nim spędzisz najwięcej czasu, tutaj ustawisz filtry, cele i inne niestandardowe konfiguracje,
• testowy – posłuży Ci jako środowisko testowe, możesz tu eksperymentować z filtrami i innymi modyfikacjami, zanim zastosujesz je w głównym widoku,
• czysty – to kopia zapasowa Twoich danych, tutaj będziesz zbierać nieprzetworzone dane, nigdy nie filtruj ani nie edytuj go w żaden sposób.

Przykład takiej struktury widoków raportowania znajdziesz poniżej.

Przykład struktury widoków raportowania

Źródło: Google Analytics

Podsumowanie

Nieważne, jak dużo masz danych w raportach Google Analytics. Liczy się to, czy możesz im ufać. Trafne decyzje biznesowe możesz podejmować tylko na podstawie rzetelnych informacji. Zadbaj o nie!

Chcesz kompleksowo sprawdzić swoją konfigurację Google Analytics?  Wykorzystaj .