Audyt Google Analytics

Marketing oparty na danych (data-driven marketing) od pewnego czasu staje się jednym z najgłośniejszych tematów branżowych, ponieważ daje możliwość (albo ułudę możliwości) zbadania i zmierzenia wszystkich prowadzonych działań. Korzyści wydają się oczywiste – optymalizacja kosztów, dotarcie do klienta z precyzyjnym komunikatem czy dokładne prognozy marketingowe. Skoro marketing ma być oparty na danych, to koniecznie należy zadbać o to, aby ich źródło działało bezbłędne.

Najpopularniejszym źródłem wiedzy o klientach odwiedzających Twoją stronę WWW jest bez wątpienia narzędzie Google Analytics (GA), które potrafi dostarczyć niemałych niespodzianek zarówno podczas instalacji, jak i interpretacji danych. W trakcie swojej pracy zawodowej nauczyłem się zawsze sprawdzać, czy strona, którą biorę pod opiekę, posiada prawidłowo zainstalowane i skonfigurowane GA. Zaniedbanie w tym zakresie jest niezwykle bolesne i może utrudnić pracę nawet kilka lat po naprawie błędów. Dlatego warto przeprowadzić audyt Google Analytics.

Błędy w ustawieniach aplikacji

Błędy w ustawieniach Google Analytics mogą się pojawić zarówno przy instalacji kodu śledzącego na stronie, jak i w ustawieniach samej aplikacji. Rozprawię się najpierw z tymi drugimi.

Słuchaj „Marketer+” Podcast

Jeżeli po raz pierwszy loguję się do Google Analytics nowej strony, to zawsze zaczynam od sekcji Administracja. Przede wszystkim sprawdzam, w jaki sposób została rozwiązana struktura widoków danych.

Bardzo często zdarza się, że Widok jest tylko jeden, główny. Generuje to później wiele problemów, z uwagi na fakt, że raz utraconych danych nie można już odzyskać. Prawidłowo powinien być ustawiony jeden widok bez jakichkolwiek filtrów lub modyfikacji, dopiero na jego bazie powinien powstać kolejny, który modyfikuje się zgodnie z potrzebami.

Niedawno popełniłem prosty błąd przy ustawieniu filtrów wykluczających boty i w konsekwencji przez kilka godzin nie zbierały się dane z całej witryny. Gdybym nie miał widoku bez tego filtra, nigdy bym tych danych nie odzyskał.

Zawsze warto stworzyć sobie minimum 2-3 widoki, aby mieć zabezpieczone wszystkie dane. Widoki mogą być różne, np. w zależności od źródła pozyskania klienta, aczkolwiek odchodzi się od interpretowania źródeł ruchu osobno.

A skoro już o botach mowa. Boty co do zasady powinny być blokowane zarówno przez serwer (np. plik .htaccess), jak i mechanizmy wbudowane w Google Analytics.

Jeżeli jednak to nie wystarcza i np. w raporcie Źródło/medium widać nietypową domenę, to nie pozostaje nic innego jak taką domenę wykluczyć. Służą do tego odpowiednie filtry.

W panelu Administracja, we właściwym widoku znajduje się panel Filtry. Po wciśnięciu przycisku „Dodaj filtr” otwiera się okno, w którym można wykluczyć odpowiednie źródła kampanii (czyli źródła ruchu). Tutaj małe ostrzeżenie. Pomiędzy poszczególnymi domenami stawia się znak „|”, który jest odpowiednikiem polskiego słowa „lub”. Nigdy jednak nie wolno kończyć ciągu domen tym znakiem, spowoduje to wykluczenie ruchu ze wszystkich domen.

W sieci można znaleźć całe listy domen do wykluczenia, ale ja z reguły wykluczam ruch tylko z tych, z których faktycznie zauważyłem wejścia w ciągu np. ostatnich sześciu miesięcy.

Przy okazji filtrów warto wspomnieć o niepisanej zasadzie, która mówi, że nie testuje się filtrów na głównym widoku (tym z którego codziennie się korzysta). W wypadku pomyłki można bezpowrotnie stracić dane i utrudnić sobie ich późniejszą interpretację.

W ustawieniach widoku zdarzają się także bardziej trywialne błędy.

Źle ustawiona godzina może powodować wadliwe ustawienie kampanii AdWords. Jedną z metod optymalizacji kampanii AdWords jest podwyższenie/obniżenie stawek CPC (Cost Per Click) w zależności od pory dnia. Jeżeli w GA widać, że najlepsza konwersja jest o 12, ale strefa czasowa jest źle ustawiona, to można niepotrzebnie podwyższyć sobie koszt reklamy w niewłaściwej godzinie. Warto przy okazji upewnić się, czy dobrze ustawiona jest także waluta.

Korzystając z okazji, warto sprawdzić, czy w raporcie Zachowanie/Zawartość witryny/Strony docelowe nie pojawia się jednocześnie strona oznaczona znakiem „/” oraz strony index.php lub index.html. Taka sytuacja oznacza dwie rzeczy – ruch ze strony głównej jest rozbity na dwa adresy – trudniej go interpretować. Może to również oznaczać, że nie zostało ustawione odpowiednie przekierowanie. Dodatkowo w panelu Administracja/Ustawienia widoku można takie wyniki scalić, wpisując odpowiednią wartość w pole Strona domyślna.

Błędy w instalacji kodu

Instalacją samego kodu Google Analytics najczęściej zajmuje się dział IT, chyba że wybór padł na Google Tag Managera i aplikację instaluje marketer. Sklepy internetowe z reguły wykorzystują moduł e-commerce, który wymaga większej wiedzy programistycznej do instalacji, ale daje też spore korzyści. Dla mnie ten moduł jest praktycznie niezbędny w codziennej pracy.

Kilka lat temu Google zmienił sposób działania aplikacji i wymusił migrację z Google Analytics na Universal Analytics. Pomijając zmiany w funkcjonowaniu samego programu, całkowicie zmienił się kod wywołujący aplikację, a także pliki cookie, z których aplikacja korzysta. Jeżeli w źródle strony, w zainstalowanym kodzie widać odwołanie do pliku „ga.js”, to najwyższy czas na zmianę. Aplikacja może działać w losowy sposób lub nie działać wcale. Należy pobrać właściwy kod śledzący z panelu Administracja i dokonać reinstalacji.

Inny popularny błąd to instalacja tego samego kodu na kilku różnych stronach np. stronie firmowej i stronie sklepu internetowego. Taka sytuacja powoduje całkowite pomieszanie danych i uniemożliwia ich późniejszą interpretację.

Możliwa jest też sytuacja odwrotna – na jednej stronie mamy zainstalowane dwie lub więcej wersji Google Analytics. Jeżeli nie było to działanie celowe i kod śledzenia nie został odpowiednio zmodyfikowany to dane będą zbierane losowo.

Najlepiej użyć wtyczki do przeglądarki Chrome o nazwie Google Tag Assistant lub Ghostery. Obie pokażą, czy na stronie wykorzystywany jest więcej niż jeden kod śledzący Google Analytics. Ghostery dodatkowo pokazuje wszystkie aplikacje zbierające dane ze strony.

Inny błąd to występowanie stron w serwisie bez wpiętego kodu. Google Analytics powinno być zainstalowane na każdej podstronie sklepu . Jeżeli pominięty został jakiś typ stron, np. strony statyczne, aplikacja nie będzie zbierać z nich danych, co może mieć różne skutki.

Klient przed dokończeniem zamówienia chce sprawdzić warunki zwrotu z regulaminu. Jeżeli kod GA nie został zainstalowany na statycznej stronie z regulaminem, to po wejściu na tę stronę Google Analytics „straci go z oczu”, a po powrocie do koszyka zanotuje nowe wejście.

Wreszcie ciekawy błąd może wywołać programista lub dział IT, który prawdopodobnie posiada wersję developerską sklepu, będącą dokładną kopią głównej strony. Jak nietrudno zgadnąć, kod śledzący Google Analytics na takiej stronie również został skopiowany.

Niedawno przypadkowo natrafiłem na pewnie zamówienie, które zostało złożone kilka razy w ciągu tygodnia. Jak się okazało składał je programista, który testował koszyk zakupowy na wersji developerskiej. Przed taką sytuacją można się uchronić, blokując wykonywanie kodu śledzącego na wersji developerskiej. Programista musi dopisać odpowiedni warunek lub wyłączyć odpowiedni adres IP filtrem.

Błędy w instalacji kodu związane z modułem e-commerce

Czas zająć się teraz bardziej skomplikowanymi błędami, związanymi przede wszystkim z modułem e-commerce. Jego najważniejszą funkcją jest zbieranie informacji o transakcjach, ich źródle i najważniejszych parametrach. Właściciele sklepów często pytają mnie, dlaczego liczba transakcji w Google Analytics odbiega od tej, która realnie została złożona. Problem jest złożony, ale przyjąłem, że jeżeli różnica jest wyższa niż 5-10%, to należy się bacznie przyjrzeć, czy w instalacji kodu śledzącego nie ma błędów.

Dla modułu e-commerce kluczowa jest strona podziękowania za zamówienie, tzw. thank you page. To na tej stronie ostatecznie wysyłane są wszystkie informacje o zamówieniu, zarówno do systemu CRM sklepu internetowego, jak i do Google Analytics.

Kod śledzący na thank you page powinien zostać wywołany tylko raz dla danego numeru ID zamówienia. Jeżeli będzie inaczej, to dane zamówienie będzie miało niewłaściwą wartość i niepoprawną liczbę produktów. Na schemacie ścieżki zakupowej naniosłem najczęstsze sytuacje, gdy klient ma możliwość ponownego wejścia na stronę podziękowania i istnieje ryzyko wtórnego wywołania kodu śledzącego.

Rozwiązania tego problemu

Można każdemu klientowi, który złożył zamówienie, przypisać plik cookie, a wywołanie kodu śledzącego (lub wysłanie zamówienia) uzależnić od tego, czy taki plik nie istnieje. Inna metoda polega na dopisaniu do adresu URL odpowiedniego parametru. Jeżeli tego parametru nie będzie to kod śledzący nie zostanie wywołany. Przykładowo po kliknięciu przycisku „Kupuję” klient zostanie przekierowany na stronę o adresie „purchase.php?zam=ok”, a w e-mailu wysłanym do klienta adres linku do strony podsumowania będzie zawierał tylko „purchase.php”.

Obie te metody nie rozwiązują problemu ze stronami płatności online. Na schemacie ścieżki zakupowej zamieściłem specjalną stronę przejściową, która wyświetla się klientowi na kilka sekund, w trakcie których wysyłane są niezbędne informacje, a później następuje przekierowanie na stronę płatności.  O wiele lepszym rozwiązaniem jest jednak taka konstrukcja strony podziękowania za zamówienie, która wyświetli się klientowi, a następnie w osobnym oknie zostanie otwarta strona płatności. Z reguły po dokonaniu płatności klient jest przekierowany z powrotem na stronę podziękowania, więc także w tej sytuacji kod śledzący nie powinien zostać uruchomiony.

Oprócz powielenia zamówień można wywołać jeszcze inny błąd – Google Analytics przypisze zamówienie do ostatniego źródła pozyskania klienta przed dokonaniem transakcji, tzw. last click. W powyższym przykładzie będzie to strona płatności online.

Oprócz samego modułu e-commerce warto poprawnie ustawić także Cele. Zwłaszcza raport Wizualizacja ścieżek pokazuje, na którym etapie ścieżki zakupowej dochodzi do jej opuszczenia przez klienta (lejek zakupowy). Dzięki temu można przeprowadzić dokładniejszą analizę danego kroku i poprawić zastosowane tam rozwiązania. Poniżej pokazuję przykładowy lejek zakupowy, który został wadliwie przygotowany – strona podziękowania za zamówienie pojawia się dwa razy.

Oznacza to, że podobnie jak w przypadku transakcji z modułu e-commerce także w tym wypadku kod śledzący został wywołany więcej niż 1 raz dla danej transakcji. Rozwiązanie jest identyczne.

Błędy w interpretacji wyników

Błędy w interpretacji wyników Google Analytics to temat na osobny artykuł. Wspomnę tutaj jednak o dwóch parametrach, które mogą wprowadzać w błąd, a wynikają z funkcjonowania samej aplikacji.

Współczynnik odrzuceń (bounce rate)

Jednym z tych parametrów jest Współczynnik odrzuceń (bounce rate). W skrócie jest to procent sesji z odrzuceniem (czyli takich, w których użytkownicy odwiedzili tylko jedną podstronę sklepu, a następnie opuścili stronę sklepu) względem wszystkich sesji.

Jak czytamy w dokumentacji: „W Analytics do odrzuceń zalicza się konkretnie te sesje, podczas których zostało uruchomione tylko jedno żądanie do serwera Analytics […]”. Oznacza to, że każde wejście klienta na stronę (sesja) zakończone na tej stronie zostanie uznane za odrzucenie. A przecież takie odwiedziny mogły trwać kilka minut, podczas których klient zapoznał się dokładnie z produktem i np. kupił go jakiś czas później.

Czy wysoki Współczynnik odrzuceń jest automatycznie powodem do wprowadzenia zmiany na stronie lub usunięcia produktu z oferty? Nie, może stanowić tylko pewną wskazówkę. Strony blogowe w szczególności będą miały wysoki współczynnik odrzuceń – klient przeczyta informację i zamknie stronę, ponieważ uzyskał to, po co przyszedł. Osobiście patrzę na Współczynnik odrzuceń na zasadzie porównania, jeżeli dla pewnej podstrony jest zdecydowanie wyższy niż dla innych podobnych, to wtedy warto sprawie przyjrzeć się bliżej. Podobnie robię w wypadku źródeł ruchu, jeżeli jedno odbiega od średniej, to staje się obiektem mojego zainteresowania.

Istnieją też metody, by Współczynnik odrzuceń był bliższy prawdzie. Na stronach o niewielkim ruchu wystarczy stworzyć zdarzenie (event), które uruchomi się w ciągu np. 10 sekund od wyświetlania strony. Będzie to sygnał dla Google Analytics, że sesja trwała dłużej niż 0 sekund i taka wizyta nie zostanie oznaczona jako odrzucenie. Metoda ta nie zadziała na dużych witrynach ze względu na limit zdarzeń, które można wysyłać do Google Analytics w ciągu doby.

Google/organic i direct/none

Drugi parametr, który warto poprawić to sposób interpretacji dwóch źródeł pozyskania ruchu – google/organic i direct/none. W tym drugim wypadku Google Analytics powinien zaliczać wizyty tych klientów, którzy już znają sklep i weszli do niego, wpisując adres w przeglądarkę. A co, jeżeli klient zamiast w pasku przeglądarki wpisał nazwę sklepu w wyszukiwarkę Google? Moim zdaniem taka wizyta również powinna zostać oznaczona jako direct (wizyta bezpośrednia), ponieważ klient zna sklep i jedynie chciał posłużyć się wyszukiwarką, żeby przypomnieć sobie pełen adres lub zrobił to po prostu przez pomyłkę.

Google Analytics posiada wbudowaną funkcję, która pozwoli w prosty sposób naprawić to drobne niedopatrzenie.

Wystarczy w panelu Lista wykluczeń wyszukiwanych haseł wpisać odpowiednie słowa – od tego momentu aplikacja będzie zliczała je na poczet wejść bezpośrednich (direct). Skąd wziąć taką listę? Najlepiej z Google Search Console – prezentowane są tam zwroty, które wpisali klienci w wyszukiwarkę Google w związku z daną stroną.

Audyt Google Analitics – podsumowanie

Liczba możliwych błędów w tak złożonej aplikacji jak Google Analytics jest oczywiście o wiele większa. W moim odczuciu powyższa lista wyczerpuje jednak te, z którymi stykam się najczęściej. Ich usunięcie na pewno poprawi jakość danych, które podlegają interpretacji i pozwoli na wyciąganie dużo bardziej precyzyjnych wniosków. A stąd już prosta droga do zwiększenia zysków.

Warto doczytać:

1. R. Lennon, „What Is Data-Driven Marketing?–Definition, Examples and Case Studies”,

2. Widoki w Google Analitycs.