Wielu osobom wydaje się, że dane, które pozyskują przez Google Analytics to prawdziwa żyła złota. I na nich opierają ważne decyzje biznesowe. Tymczasem okazuje się, że raporty generowane przez to narzędzie mogą być polem minowym. Dlatego w tym artykule porozmawiamy sobie o najczęstszych błędach w konfiguracji i wdrażaniu Google Analytics. Fakt, mogą przytrafić się każdemu. Ale jeśli zapoznasz się z poniższymi radami – Tobie nie muszą.

Takie są fakty…

Doświadczenie pokazało mi, że każda nowo powstała strona już na starcie ma przynajmniej kilka błędów związanych z konfiguracją Google Analytics. Obserwuję to zwłaszcza na www firm, które obecność w sieci traktują jak zło konieczne. I o ile z niektórymi defektami można żyć, o tyle spora ich cześć sprawia, że działy marketingu opierają swoje analizy i decyzje o nieprawdziwe dane. A one finalnie mogą prowadzić do błędnych wniosków. I już ta informacja powinna skłonić każdego marketingowca do zweryfikowania, jak wdrożono Google Analytics na firmowej stronie. Bo może się okazać, że strategię działań trzeba będzie zmienić o 180 stopni…

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

Parametry UTM dodawane do adresów URL służą do identyfikacji i oceny skuteczności kampanii reklamowych. Link otagowany „uteemem” dostarcza informacji choćby o tym, gdzie został on opublikowany, albo jaką treść promował. Typowy UTM składa się z minimum dwóch parametrów, ale do dyspozycji jest ich więcej:

  • campaign ID – odpowiada za określenie kampanii reklamowej, pomaga przy bardziej złożonych działaniach promocyjnych. Może mieć postać alfanumeryczną i przypisywać ruch do konkretnej kampanii reklamowej. Składnia: utm_id=
  • campaign source* – pierwszy z dwóch obowiązkowych parametrów. Jego przeznaczenie polega na przypisaniu źródła pozyskania. Najczęściej spotkać można go w źródle google/facebook/direct. Wskazuje miejsce, z którego pochodzi ruch. Składnia: utm_source=
  • campaign medium* – drugi obowiązkowy parametr. Pomaga zidentyfikować medium rozumiane najczęściej jako rodzaj działania np.: email, organic, cpc, social, display czy referral. Umożliwia określenie typu kampanii/kreacji, która wygenerowała ruch. Składnia: utm_medium=
  • campaign name – obecność w UTM tego parametru dowodzi, że po drugiej stronie mamy do czynienia z kimś, kto już całkiem nieźle zna się na marketingu i na Analytics. Campaign Name zwykle służy do przekazywania informacji o nazwie kampanii np. „black week” czy „lato2020”. Spora część działań reklamowych i promocji prowadzona jest wielokanałowo i na wiele sposobów. Zatem UTM przydaje się, aby zebrać dane o wynikach np. newslettera, kampanii pcc czy aktywności w socialach i ich szybkiego zgrupowania. Składnia: utm_campaign
  • campaign term – wykorzystywany tak na dobrą sprawę tylko w płatnych wyszukiwaniach. Przekazuje informacje o słowie kluczowym, które doprowadziło użytkownika do strony. Składnia: utm_term=
  • campaign content – praktykowany w testach A/B, ale zdarza się też obserwować go przy głębokiej analizie kampanii. To taki duży worek, do którego marketerzy wrzucają masę informacji o kanale, treści reklamy, jej formacie… Można tu upchnąć dowolny zakres informacji. Składnia: utm_content

Dane użyte do utworzenia UTM można sprawdzić w Google Analytics w sekcji Pozyskanie -> cały Ruch -> Źródło/Medium. Z kolei budowa samych parametrów może odbywać się na różne sposoby. Najprościej zacząć od dedykowanego temu narzędziu: Google Campaign URL Builder.

Co fajnego jest w UTM?

Dzięki nim masz możliwość zbadać efektywność każdego linka, publikacji, reklamy, kodu QR – wszystkiego, co można kliknąć i co finalnie prowadzi do wizyty na stronie www. Drugim dobrym argumentem jest to, że Google samo próbuje te dane dla Ciebie zebrać, ale niestety niekoniecznie sobie z tym radzi. W efekcie do Direct zwykle trafia wszystko to, co było uznane za kliknięcie linku. I nieważne czy odbyło się ono w mailu z ofertą wysłanym do już pozyskanego klienta, czy był to klik linku np. w ofercie w PDF, a w skrajnych przypadkach nawet ruch przekierowany z bloga przy niepoprawnej konfiguracji wersji http/https i www.

Jak widzisz, bardzo łatwo strzelić sobie samobója i nabijać niczym nieuzasadnione statystyki.

Na uwagę zasługuje też fakt, że śledzenie kampanii Google Ads odbywa się w sposób automatyczny. Oczywiście, jeśli wcześniej dokonało się połączenia obu kont (Ads i Analytics) oraz wybrało opcję automatycznego tagowania linków w kampaniach. Ułatwia to trochę życie, ale z drugiej strony może być niespójne z przyjętą w większych organizacjach strukturą oznaczania kampanii.

No i jeszcze jedna bardzo ważna obserwacja. Za dodanie UTM do linków wewnętrznych przewidziana jest kara zbliżona dotkliwością do oblania smołą i obsypania puchem. To najprostszy sposób do pozbawienia się danych o ruchu i przekłamywania nt ilości sesji oraz źródeł pozyskania. UTM bowiem nadpisuje się i jeśli Twój slider z nieuzasadnionych powodów oznaczyłeś jako UTM, to ruch pochodzący z Google Ads po kliknięciu w slajd zamieni się w ruch pozyskany ze slidera. Prawda, że bzdura totalna?

Moja rada? Nie rób sobie krzywdy i zapomnij o UTM w linkowaniu wewnętrznym. Jeśli już musisz, wymyśl sobie zdarzenia albo własne zmienne i to za ich pomocą przekazuj informacje takie jak np. ta, który slajd kliknął użytkownik. No ale jak już wspomniałem: tylko jeśli musisz. Bo prawda jest taka, że można to zrobić znacznie efektywniej. Podyskutujemy o tym w innym wpisie.

Śledzenie własnych sesji

Warto zacząć od tego, że Google Analytics nie wie, że Twoi pracownicy są Twoimi pracownikami. Dlatego w panelu rejestrowane jest każde ich wejście na stronę. Potrafię sobie wyobrazić sytuację, w której masz jakiś system sprzedaży bazujący na domenie sklepu (w zasadzie każdy panel administracyjny od Woocommerce po Prestashop tak ma). Zatrudniasz kilka osób i każda z nich przez 8 godzin dziennie (będąc zalogowanym w adminie) napędza średni czas sesji, liczbę podstron czy ogólnie efektywność kanału direct. No nie ma to sensu.

Czy można temu zaradzić?

Owszem, a nawet się powinno. Sposobów jest kilka. Najprościej możesz tego dokonać, jeśli Twoja firma posługuje się stałym adresem IP. Wtedy po prostu wystarczy wykluczyć przy pomocy filtra to konkretne IP i dane zbierane przez GA stają się nagle bliższe prawdy.

Jeśli IP jest dynamiczne, trzeba trochę bardziej się namęczyć. Można np. oprzeć filtr o ten fragment adresu URL, który wskazuje na bycie zalogowanym w panelu administracyjnym (na przykład wp-admin w WordPress). W ostateczności można też spreparować link z parametrami UTM, który posłuży do logowania i filtr wykluczający ruch z analizy zbudować na tych właśnie parametrach. 

WAŻNE! Większość popularnych CMS-ów i wtyczek do integracji kodu Google Analytics ma opcje, które pozwalają na wykluczenie zalogowanych użytkowników i administratorów ze zbierania danych.

Brak oznaczenia zdarzeń

Ten temat wiąże się z celami, które mają być zrealizowane przez witrynę i tego, co chcemy na niej mierzyć. Co do zasady zdarzenia można podzielić na dwa rodzaje:

  • zdarzenia z interakcją, czyli takie, które służą wprost śledzeniu interakcji użytkownika. Jest to np. wysłanie formularza, pobranie pliku czy kliknięcie określonego przycisku.
  • zdarzenia bez interakcji, czyli takie, które dzieją się niezależnie od działalności użytkownika. Zalicza się tu np. załadowanie strony, wywołanie okna pop-up czy automatyczne odtworzenie filmu. 

Co ważne: określenie zdarzeń ma istotny wpływ na współczynnik odrzuceń. Zdarzenia bez interakcji mogą bardzo mocno zaburzać tę metrykę (obniżając ją do zera). Prosty przykład mamy w sytuacji, kiedy użytkownik otwiera stronę, pokazuje mu się pop-up i stronę zamyka. W klasycznej metodzie liczenia Bounce Rate odrzucenie nie miało tu miejsca, ponieważ Analytics odnotował dwa zdarzenia (załadowanie witryny i wywołanie okna pop-up). W praktyce jednak BR miało miejsce. Aby temu zaradzić, należy przy określaniu zdarzeń wybrać wartość „działanie niezwiązane z interakcją” jako prawda. W ten sposób mierzymy to, co chcemy, bez fałszowania danych.

Niepoprawna instalacja kodu śledzącego

Jest to notoryczny błąd. Najczęściej można spotkać się z podwójnym wysłaniem kodu, wysłaniem kodu tylko w części podstron witryny albo w ogóle z brakiem instalacji. Każde z tych uchybień ma ogromne konsekwencje w kontekście gromadzonych danych: od ich podwojenia, przez losową multiplikację, aż po brak danych o wizytach. A więc musisz jak najszybciej upewnić się, że Twój kod jest zainstalowany poprawnie. Dlaczego? Ponieważ nie masz wpływu na dane, które już zostały zebrane. Co więcej: podejmowanie decyzji biznesowych na podstawie sfałszowanego obrazu ruchu na stronie może być przyczyną daleko idących konsekwencji dla całej firmy. Najszybciej poznasz stan implementacji kodu śledzącego Google Analytics przy pomocy narzędzia GAChecker.com.

Śledzenie ruchu z innych domen

Teraz będzie coś ciekawego. Kod śledzenia Google Analytics nie jest tajny, przez co każdy może go poznać i użyć na dowolnej stronie. Wyobraź sobie witrynę postawioną przez konkurencję, której zadaniem będzie nabijać ruch tylko po to, by przełamać Twoje dane i odkryć tajemnice (choćby skuteczność kampanii reklamowej). Aby się przed tym uchronić polecam wykonać dwie rzeczy. Po pierwsze w raporcie Odbiorcy -> Technologie -> Sieć należy wybrać wymiar podstawowy „nazwa hosta”. Jeśli zobaczysz tu domeny inne niż Twoja (albo operatorów płatności), to znaczy, że masz cichego wielbiciela, którego celem może być przekłamanie danych w Twoim GA. Jak temu zapobiec? Wystarczy utworzyć filtr w konfiguracji widoku. Będzie on rejestrował ruchu jedynie w obrębie Twojej domeny.

Różnice w liczbie transakcji

To zagadnienie dotyka wyłącznie platformy e-commerce. Niemniej jednak trzeba podkreślić, że błędy w tym obszarze niosą za sobą dość poważne konsekwencje biznesowe: już od etapu planowania wydatków, aż po analizy kampanii czy wyników sprzedaży. 

Diagnostykę należy rozpocząć tu od porównania danych transakcyjnych z Google Analytics z systemem CRM. Rozbieżności są niemal pewne, ale nie powinny być znaczące. W normalnej sytuacji transakcji powinno być mniej. Jeśli odchylenie nie przekracza 15%, to jest całkiem spora szansa, że nie ma powodu do paniki. Dość powszechnie rejestracja transakcji na poziomie sklepu odbywa się przy powrocie z bramki płatniczej na tak zwanej „thank you page”, a zaznaczyć trzeba, że nie każdy klient to robi. 

Przy większych rozbieżnościach sprawę warto dokładnie przeanalizować. Może okazać się, że trzeba zacząć zliczać transakcje przed przejściem do bramki płatniczej. Co prawda w efekcie takiego działania część nieopłaconych zamówień będzie raportowana jako zrealizowana, ale fakt jest taki, że porzucenie transakcji na poziomie płatności zdarza się bardzo rzadko. Istotny jest tu też jeszcze jeden czynnik: prywatność. Część użytkowników korzysta z mechanizmów blokujących reklamy czy nawet skrypt Google Analytics. Dlatego też 15% rozbieżności poniżej rzeczywistej sprzedaży uważałbym za wynik bezpieczny i nie ingerował w analitykę.

Zgoła odmiennym problemem jest rejestrowanie większej liczby transakcji niż rzeczywista liczba zamówień. Znowu, najprostsze wytłumaczenie takiego stanu rzeczy to sytuacja, w której user wraca na „thank you page” i zostawia ją sobie na kartach przeglądarki. W ten sposób każde inicjowanie sesji na tej stronie będzie skutkowało wysłaniem informacji o transakcji do skryptu GA. Podobny efekt może dawać odświeżanie strony. Każdorazowe wczytanie multiplikuje wówczas transakcję na poziomie Google Analytics. Weryfikację tego zjawiska umożliwia porównanie raportów Konwersje -> E-commerce -> Przegląd i wartości „transakcje” w odniesieniu do: Konwersje -> E-comemrce -> Transakcje. Każda transakcja zostaje określona unikatowym numerem ID, zatem obie wartości powinny być równe.

Pojedyncze multiplikacje oznaczają wcześniej opisane przypadki, a wielokrotności znacznie poważniejsze problemy z konfiguracją i działaniem sklepu. Większe platformy proces zakupu mają zbudowany w taki sposób, że odświeżenie „thank you page” jest niemożliwe i najczęściej przekierowuje do historii zamówień. Tam klient może sprawdzić m.in. numer zamówienia czy inne związane z nim informacje.

Transakcje przypisywane do bramek płatniczych

Google Analytics domyślnie przypisuje transakcje (czy szerzej konwersje) do ostatniego znanego niebezpośredniego źródła ruchu. Tym samym odpowiedzialna za konwersję w typowej konfiguracji będzie strona operatora płatności i niejako referer, który ma miejsce tuż przed „thank you page”. A więc jeśli pozyskasz klienta z Google Ads i dokona on zakupu, to:

  • po pierwsze: Ads odnotuje koszyk, ale porzucony, bo klient opuścił Twoją domenę (co prawda, żeby dokonać płatności, ale system tego nie wie),
  • po drugie, klient zakończył transakcję, „wchodząc” na stronę z systemu płatności. Zatem oklaski i sława należą się bramce płatniczej, bo to ona dowiozła transakcję. 

Wszyscy wiemy, że to dalekie od prawdy. Rozsądnym posunięciem, aby temu zapobiec, jest dodanie operatora płatności i banków do listy wykluczeń witryn odsyłających. Zajęcie dość pracochłonne, ale skutkuje poprawnym przypisaniem odpowiedzialności za zakupy i ich wielkość. Jest to o tyle ważne, że różne kanały pozyskania może cechować różne ROI, czy ROAS i mając tu czyste dane łatwiej podejmować decyzje o rozwoju poszczególnych kanałów marketingowych.

Przypomnę też, że istnieje coś takiego jak „tricky part”. Starzy wyjadacze Google Analytics wiedzą, że o północy system kończy wszystkie sesje i zaczyna na nowo te, które trwają aktualnie. Do dodania takiego wykluczenia na własną domenę również zachęcam. Rzadko, bo rzadko, ale pomoże to odsiać własną stronę jako kanał pozyskania w sytuacji, kiedy dodanie produktu do koszyka odbyło się przed północą, a płatność już po.

Brak scalenia tych samych źródeł ruchu

Każdy, kto generuje ruch z Facebooka, przeklina pewnie dzień, w którym routing tej platformy rozrósł się tak bardzo, że analityka notuje wiele źródeł ruchu dla tego samego portalu. Wiem, że spora część z nas ma w analityce ruch z m.facebook albo z l.facebook oraz z Facebooka i jeszcze paru innych jego odmian oraz subdomen. Da się to jednak wyeliminować przez zastosowanie odpowiedniego filtra. Powinien on zastępować różne nazwy domen Facebooka jedną, która będzie spójna dla wszystkich. Działa to na podobnej zasadzie jak „znajdź” i „zamień” znane z Worda i Excela. Tak samo warto postąpić z serwisem YouTube, Instagram, Messenger, Pinterest i innymi większymi platformami internetowymi.

Brak wykluczenia parametrów zapytania

Parametry zapytania są zmorą analityków na każdym kroku. To adresy, które zaczynają się od pytajnika (np. w WordPress ?s=seo oznacza wyszukiwanie na frazę SEO w obrębie strony). O ile warto te rzeczy mierzyć i analizować, o tyle na większości widoków są to dane zupełnie zbędne. 

Inny przykład „śmieciucha” to identyfikatory nadawane przez Facebooka w momencie kliknięcia linku, który został opublikowany w serwisie. Noszą one złowrogą nazwę FBCLID. Dane te możesz łatwo wykluczyć, wchodząc do: Administracja -> Widok > Ustawienia widoku. Ważne jest, by do listy pomijanych parametrów dodać tylko te, które są zbędne np.: fbclid, sortowanie wyników po cenie, nazwie itd. W przypadku każdego biznesu trzeba zdecydować indywidualnie, które z nich są w analizach niepotrzebne. A to, które notujesz, możesz sprawdzić, przechodząc do: Zachowanie -> Zawartość Witryny -> Wszystkie Strony i w polu wyszukiwania wpisując po prostu „?”. Znajdziesz tam setki, jeśli nie tysiące, linków z parametrami, które nic nie wnoszą do analiz.

Niepoprawna struktura widoków raportowania

To zagadnienie dla nieco bardziej zaawansowanych użytkowników Google Analytics. Bardzo duże szkody w tym obszarze może wyrządzić niedoświadczony user. Jak już wspominałem, filtry nie działają wstecz. Trzeba więc mieć też na uwadze, że raz pozyskane informacje nie podlegają modyfikacji. Źle skonstruowany raport powoduje, że danych nie da się odzyskać. W niekompletnej formie będą gromadzić się nadal aż do momentu zmiany ustawień widoku.

Bardzo dobrą praktyką jest tworzenie dodatkowych widoków od samego początku. Zalecam, aby były to co najmniej trzy widoki:

  • roboczy, na którym opierane są analizy,
  • testowy, na którym weryfikowane jest działanie filtrów i dokonywane są modyfikacje przed wdrożeniem na widoku głównym,
  • czysty, który zawiera dane niefiltrowane. To plan B w sytuacji, kiedy wszelkie inne metody bezpieczeństwa i testów zawiodą. Na tym widoku zawsze będzie dostępny komplet danych.

Podsumowanie

Możesz mieć wiele danych do analizy… Prawda jest jednak taka, że nie ich ilość, ale jakość decyduje o wynikach i przekłada się na trafność podejmowanych decyzje. Warto dołożyć wszelkich starań już na samym początku konfiguracji Google Analytics. Po to, aby zbieranie informacji było jak najmniej zaburzone i w efekcie dostarczało maksimum wiarygodnego materiału. Opłaca się zadbać, by kolejne kroki biznesowe opierały się na faktach, a nie sfałszowanych danych. Czas potrzebny na weryfikację i konfigurację Google Analytics zaprocentuje już pierwszych miesiącach analiz.

Wielu osobom wydaje się, że dane, które pozyskują przez Google Analytics to prawdziwa żyła złota. I na nich opierają ważne decyzje biznesowe. Tymczasem okazuje się, że raporty generowane przez to narzędzie mogą być polem minowym. Dlatego w tym artykule porozmawiamy sobie o najczęstszych błędach w konfiguracji i wdrażaniu Google Analytics. Fakt, mogą przytrafić się każdemu. Ale jeśli zapoznasz się z poniższymi radami – Tobie nie muszą.

Takie są fakty…

Doświadczenie pokazało mi, że każda nowo powstała strona już na starcie ma przynajmniej kilka błędów związanych z konfiguracją Google Analytics. Obserwuję to zwłaszcza na www firm, które obecność w sieci traktują jak zło konieczne. I o ile z niektórymi defektami można żyć, o tyle spora ich cześć sprawia, że działy marketingu opierają swoje analizy i decyzje o nieprawdziwe dane. A one finalnie mogą prowadzić do błędnych wniosków. I już ta informacja powinna skłonić każdego marketingowca do zweryfikowania, jak wdrożono Google Analytics na firmowej stronie. Bo może się okazać, że strategię działań trzeba będzie zmienić o 180 stopni…

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

Parametry UTM dodawane do adresów URL służą do identyfikacji i oceny skuteczności kampanii reklamowych. Link otagowany „uteemem” dostarcza informacji choćby o tym, gdzie został on opublikowany, albo jaką treść promował. Typowy UTM składa się z minimum dwóch parametrów, ale do dyspozycji jest ich więcej:

  • campaign ID – odpowiada za określenie kampanii reklamowej, pomaga przy bardziej złożonych działaniach promocyjnych. Może mieć postać alfanumeryczną i przypisywać ruch do konkretnej kampanii reklamowej. Składnia: utm_id=
  • campaign source* – pierwszy z dwóch obowiązkowych parametrów. Jego przeznaczenie polega na przypisaniu źródła pozyskania. Najczęściej spotkać można go w źródle google/facebook/direct. Wskazuje miejsce, z którego pochodzi ruch. Składnia: utm_source=
  • campaign medium* – drugi obowiązkowy parametr. Pomaga zidentyfikować medium rozumiane najczęściej jako rodzaj działania np.: email, organic, cpc, social, display czy referral. Umożliwia określenie typu kampanii/kreacji, która wygenerowała ruch. Składnia: utm_medium=
  • campaign name – obecność w UTM tego parametru dowodzi, że po drugiej stronie mamy do czynienia z kimś, kto już całkiem nieźle zna się na marketingu i na Analytics. Campaign Name zwykle służy do przekazywania informacji o nazwie kampanii np. „black week” czy „lato2020”. Spora część działań reklamowych i promocji prowadzona jest wielokanałowo i na wiele sposobów. Zatem UTM przydaje się, aby zebrać dane o wynikach np. newslettera, kampanii pcc czy aktywności w socialach i ich szybkiego zgrupowania. Składnia: utm_campaign
  • campaign term – wykorzystywany tak na dobrą sprawę tylko w płatnych wyszukiwaniach. Przekazuje informacje o słowie kluczowym, które doprowadziło użytkownika do strony. Składnia: utm_term=
  • campaign content – praktykowany w testach A/B, ale zdarza się też obserwować go przy głębokiej analizie kampanii. To taki duży worek, do którego marketerzy wrzucają masę informacji o kanale, treści reklamy, jej formacie… Można tu upchnąć dowolny zakres informacji. Składnia: utm_content

Dane użyte do utworzenia UTM można sprawdzić w Google Analytics w sekcji Pozyskanie -> cały Ruch -> Źródło/Medium. Z kolei budowa samych parametrów może odbywać się na różne sposoby. Najprościej zacząć od dedykowanego temu narzędziu: Google Campaign URL Builder.

Co fajnego jest w UTM?

Dzięki nim masz możliwość zbadać efektywność każdego linka, publikacji, reklamy, kodu QR – wszystkiego, co można kliknąć i co finalnie prowadzi do wizyty na stronie www. Drugim dobrym argumentem jest to, że Google samo próbuje te dane dla Ciebie zebrać, ale niestety niekoniecznie sobie z tym radzi. W efekcie do Direct zwykle trafia wszystko to, co było uznane za kliknięcie linku. I nieważne czy odbyło się ono w mailu z ofertą wysłanym do już pozyskanego klienta, czy był to klik linku np. w ofercie w PDF, a w skrajnych przypadkach nawet ruch przekierowany z bloga przy niepoprawnej konfiguracji wersji http/https i www.

Jak widzisz, bardzo łatwo strzelić sobie samobója i nabijać niczym nieuzasadnione statystyki.

Na uwagę zasługuje też fakt, że śledzenie kampanii Google Ads odbywa się w sposób automatyczny. Oczywiście, jeśli wcześniej dokonało się połączenia obu kont (Ads i Analytics) oraz wybrało opcję automatycznego tagowania linków w kampaniach. Ułatwia to trochę życie, ale z drugiej strony może być niespójne z przyjętą w większych organizacjach strukturą oznaczania kampanii.

No i jeszcze jedna bardzo ważna obserwacja. Za dodanie UTM do linków wewnętrznych przewidziana jest kara zbliżona dotkliwością do oblania smołą i obsypania puchem. To najprostszy sposób do pozbawienia się danych o ruchu i przekłamywania nt ilości sesji oraz źródeł pozyskania. UTM bowiem nadpisuje się i jeśli Twój slider z nieuzasadnionych powodów oznaczyłeś jako UTM, to ruch pochodzący z Google Ads po kliknięciu w slajd zamieni się w ruch pozyskany ze slidera. Prawda, że bzdura totalna?

Moja rada? Nie rób sobie krzywdy i zapomnij o UTM w linkowaniu wewnętrznym. Jeśli już musisz, wymyśl sobie zdarzenia albo własne zmienne i to za ich pomocą przekazuj informacje takie jak np. ta, który slajd kliknął użytkownik. No ale jak już wspomniałem: tylko jeśli musisz. Bo prawda jest taka, że można to zrobić znacznie efektywniej. Podyskutujemy o tym w innym wpisie.

Śledzenie własnych sesji

Warto zacząć od tego, że Google Analytics nie wie, że Twoi pracownicy są Twoimi pracownikami. Dlatego w panelu rejestrowane jest każde ich wejście na stronę. Potrafię sobie wyobrazić sytuację, w której masz jakiś system sprzedaży bazujący na domenie sklepu (w zasadzie każdy panel administracyjny od Woocommerce po Prestashop tak ma). Zatrudniasz kilka osób i każda z nich przez 8 godzin dziennie (będąc zalogowanym w adminie) napędza średni czas sesji, liczbę podstron czy ogólnie efektywność kanału direct. No nie ma to sensu.

Czy można temu zaradzić?

Owszem, a nawet się powinno. Sposobów jest kilka. Najprościej możesz tego dokonać, jeśli Twoja firma posługuje się stałym adresem IP. Wtedy po prostu wystarczy wykluczyć przy pomocy filtra to konkretne IP i dane zbierane przez GA stają się nagle bliższe prawdy.

Jeśli IP jest dynamiczne, trzeba trochę bardziej się namęczyć. Można np. oprzeć filtr o ten fragment adresu URL, który wskazuje na bycie zalogowanym w panelu administracyjnym (na przykład wp-admin w WordPress). W ostateczności można też spreparować link z parametrami UTM, który posłuży do logowania i filtr wykluczający ruch z analizy zbudować na tych właśnie parametrach. 

WAŻNE! Większość popularnych CMS-ów i wtyczek do integracji kodu Google Analytics ma opcje, które pozwalają na wykluczenie zalogowanych użytkowników i administratorów ze zbierania danych.

Brak oznaczenia zdarzeń

Ten temat wiąże się z celami, które mają być zrealizowane przez witrynę i tego, co chcemy na niej mierzyć. Co do zasady zdarzenia można podzielić na dwa rodzaje:

  • zdarzenia z interakcją, czyli takie, które służą wprost śledzeniu interakcji użytkownika. Jest to np. wysłanie formularza, pobranie pliku czy kliknięcie określonego przycisku.
  • zdarzenia bez interakcji, czyli takie, które dzieją się niezależnie od działalności użytkownika. Zalicza się tu np. załadowanie strony, wywołanie okna pop-up czy automatyczne odtworzenie filmu. 

Co ważne: określenie zdarzeń ma istotny wpływ na współczynnik odrzuceń. Zdarzenia bez interakcji mogą bardzo mocno zaburzać tę metrykę (obniżając ją do zera). Prosty przykład mamy w sytuacji, kiedy użytkownik otwiera stronę, pokazuje mu się pop-up i stronę zamyka. W klasycznej metodzie liczenia Bounce Rate odrzucenie nie miało tu miejsca, ponieważ Analytics odnotował dwa zdarzenia (załadowanie witryny i wywołanie okna pop-up). W praktyce jednak BR miało miejsce. Aby temu zaradzić, należy przy określaniu zdarzeń wybrać wartość „działanie niezwiązane z interakcją” jako prawda. W ten sposób mierzymy to, co chcemy, bez fałszowania danych.

Niepoprawna instalacja kodu śledzącego

Jest to notoryczny błąd. Najczęściej można spotkać się z podwójnym wysłaniem kodu, wysłaniem kodu tylko w części podstron witryny albo w ogóle z brakiem instalacji. Każde z tych uchybień ma ogromne konsekwencje w kontekście gromadzonych danych: od ich podwojenia, przez losową multiplikację, aż po brak danych o wizytach. A więc musisz jak najszybciej upewnić się, że Twój kod jest zainstalowany poprawnie. Dlaczego? Ponieważ nie masz wpływu na dane, które już zostały zebrane. Co więcej: podejmowanie decyzji biznesowych na podstawie sfałszowanego obrazu ruchu na stronie może być przyczyną daleko idących konsekwencji dla całej firmy. Najszybciej poznasz stan implementacji kodu śledzącego Google Analytics przy pomocy narzędzia GAChecker.com.

Śledzenie ruchu z innych domen

Teraz będzie coś ciekawego. Kod śledzenia Google Analytics nie jest tajny, przez co każdy może go poznać i użyć na dowolnej stronie. Wyobraź sobie witrynę postawioną przez konkurencję, której zadaniem będzie nabijać ruch tylko po to, by przełamać Twoje dane i odkryć tajemnice (choćby skuteczność kampanii reklamowej). Aby się przed tym uchronić polecam wykonać dwie rzeczy. Po pierwsze w raporcie Odbiorcy -> Technologie -> Sieć należy wybrać wymiar podstawowy „nazwa hosta”. Jeśli zobaczysz tu domeny inne niż Twoja (albo operatorów płatności), to znaczy, że masz cichego wielbiciela, którego celem może być przekłamanie danych w Twoim GA. Jak temu zapobiec? Wystarczy utworzyć filtr w konfiguracji widoku. Będzie on rejestrował ruchu jedynie w obrębie Twojej domeny.

Różnice w liczbie transakcji

To zagadnienie dotyka wyłącznie platformy e-commerce. Niemniej jednak trzeba podkreślić, że błędy w tym obszarze niosą za sobą dość poważne konsekwencje biznesowe: już od etapu planowania wydatków, aż po analizy kampanii czy wyników sprzedaży. 

Diagnostykę należy rozpocząć tu od porównania danych transakcyjnych z Google Analytics z systemem CRM. Rozbieżności są niemal pewne, ale nie powinny być znaczące. W normalnej sytuacji transakcji powinno być mniej. Jeśli odchylenie nie przekracza 15%, to jest całkiem spora szansa, że nie ma powodu do paniki. Dość powszechnie rejestracja transakcji na poziomie sklepu odbywa się przy powrocie z bramki płatniczej na tak zwanej „thank you page”, a zaznaczyć trzeba, że nie każdy klient to robi. 

Przy większych rozbieżnościach sprawę warto dokładnie przeanalizować. Może okazać się, że trzeba zacząć zliczać transakcje przed przejściem do bramki płatniczej. Co prawda w efekcie takiego działania część nieopłaconych zamówień będzie raportowana jako zrealizowana, ale fakt jest taki, że porzucenie transakcji na poziomie płatności zdarza się bardzo rzadko. Istotny jest tu też jeszcze jeden czynnik: prywatność. Część użytkowników korzysta z mechanizmów blokujących reklamy czy nawet skrypt Google Analytics. Dlatego też 15% rozbieżności poniżej rzeczywistej sprzedaży uważałbym za wynik bezpieczny i nie ingerował w analitykę.

Zgoła odmiennym problemem jest rejestrowanie większej liczby transakcji niż rzeczywista liczba zamówień. Znowu, najprostsze wytłumaczenie takiego stanu rzeczy to sytuacja, w której user wraca na „thank you page” i zostawia ją sobie na kartach przeglądarki. W ten sposób każde inicjowanie sesji na tej stronie będzie skutkowało wysłaniem informacji o transakcji do skryptu GA. Podobny efekt może dawać odświeżanie strony. Każdorazowe wczytanie multiplikuje wówczas transakcję na poziomie Google Analytics. Weryfikację tego zjawiska umożliwia porównanie raportów Konwersje -> E-commerce -> Przegląd i wartości „transakcje” w odniesieniu do: Konwersje -> E-comemrce -> Transakcje. Każda transakcja zostaje określona unikatowym numerem ID, zatem obie wartości powinny być równe.

Pojedyncze multiplikacje oznaczają wcześniej opisane przypadki, a wielokrotności znacznie poważniejsze problemy z konfiguracją i działaniem sklepu. Większe platformy proces zakupu mają zbudowany w taki sposób, że odświeżenie „thank you page” jest niemożliwe i najczęściej przekierowuje do historii zamówień. Tam klient może sprawdzić m.in. numer zamówienia czy inne związane z nim informacje.

Transakcje przypisywane do bramek płatniczych

Google Analytics domyślnie przypisuje transakcje (czy szerzej konwersje) do ostatniego znanego niebezpośredniego źródła ruchu. Tym samym odpowiedzialna za konwersję w typowej konfiguracji będzie strona operatora płatności i niejako referer, który ma miejsce tuż przed „thank you page”. A więc jeśli pozyskasz klienta z Google Ads i dokona on zakupu, to:

  • po pierwsze: Ads odnotuje koszyk, ale porzucony, bo klient opuścił Twoją domenę (co prawda, żeby dokonać płatności, ale system tego nie wie),
  • po drugie, klient zakończył transakcję, „wchodząc” na stronę z systemu płatności. Zatem oklaski i sława należą się bramce płatniczej, bo to ona dowiozła transakcję. 

Wszyscy wiemy, że to dalekie od prawdy. Rozsądnym posunięciem, aby temu zapobiec, jest dodanie operatora płatności i banków do listy wykluczeń witryn odsyłających. Zajęcie dość pracochłonne, ale skutkuje poprawnym przypisaniem odpowiedzialności za zakupy i ich wielkość. Jest to o tyle ważne, że różne kanały pozyskania może cechować różne ROI, czy ROAS i mając tu czyste dane łatwiej podejmować decyzje o rozwoju poszczególnych kanałów marketingowych.

Przypomnę też, że istnieje coś takiego jak „tricky part”. Starzy wyjadacze Google Analytics wiedzą, że o północy system kończy wszystkie sesje i zaczyna na nowo te, które trwają aktualnie. Do dodania takiego wykluczenia na własną domenę również zachęcam. Rzadko, bo rzadko, ale pomoże to odsiać własną stronę jako kanał pozyskania w sytuacji, kiedy dodanie produktu do koszyka odbyło się przed północą, a płatność już po.

Brak scalenia tych samych źródeł ruchu

Każdy, kto generuje ruch z Facebooka, przeklina pewnie dzień, w którym routing tej platformy rozrósł się tak bardzo, że analityka notuje wiele źródeł ruchu dla tego samego portalu. Wiem, że spora część z nas ma w analityce ruch z m.facebook albo z l.facebook oraz z Facebooka i jeszcze paru innych jego odmian oraz subdomen. Da się to jednak wyeliminować przez zastosowanie odpowiedniego filtra. Powinien on zastępować różne nazwy domen Facebooka jedną, która będzie spójna dla wszystkich. Działa to na podobnej zasadzie jak „znajdź” i „zamień” znane z Worda i Excela. Tak samo warto postąpić z serwisem YouTube, Instagram, Messenger, Pinterest i innymi większymi platformami internetowymi.

Brak wykluczenia parametrów zapytania

Parametry zapytania są zmorą analityków na każdym kroku. To adresy, które zaczynają się od pytajnika (np. w WordPress ?s=seo oznacza wyszukiwanie na frazę SEO w obrębie strony). O ile warto te rzeczy mierzyć i analizować, o tyle na większości widoków są to dane zupełnie zbędne. 

Inny przykład „śmieciucha” to identyfikatory nadawane przez Facebooka w momencie kliknięcia linku, który został opublikowany w serwisie. Noszą one złowrogą nazwę FBCLID. Dane te możesz łatwo wykluczyć, wchodząc do: Administracja -> Widok > Ustawienia widoku. Ważne jest, by do listy pomijanych parametrów dodać tylko te, które są zbędne np.: fbclid, sortowanie wyników po cenie, nazwie itd. W przypadku każdego biznesu trzeba zdecydować indywidualnie, które z nich są w analizach niepotrzebne. A to, które notujesz, możesz sprawdzić, przechodząc do: Zachowanie -> Zawartość Witryny -> Wszystkie Strony i w polu wyszukiwania wpisując po prostu „?”. Znajdziesz tam setki, jeśli nie tysiące, linków z parametrami, które nic nie wnoszą do analiz.

Niepoprawna struktura widoków raportowania

To zagadnienie dla nieco bardziej zaawansowanych użytkowników Google Analytics. Bardzo duże szkody w tym obszarze może wyrządzić niedoświadczony user. Jak już wspominałem, filtry nie działają wstecz. Trzeba więc mieć też na uwadze, że raz pozyskane informacje nie podlegają modyfikacji. Źle skonstruowany raport powoduje, że danych nie da się odzyskać. W niekompletnej formie będą gromadzić się nadal aż do momentu zmiany ustawień widoku.

Bardzo dobrą praktyką jest tworzenie dodatkowych widoków od samego początku. Zalecam, aby były to co najmniej trzy widoki:

  • roboczy, na którym opierane są analizy,
  • testowy, na którym weryfikowane jest działanie filtrów i dokonywane są modyfikacje przed wdrożeniem na widoku głównym,
  • czysty, który zawiera dane niefiltrowane. To plan B w sytuacji, kiedy wszelkie inne metody bezpieczeństwa i testów zawiodą. Na tym widoku zawsze będzie dostępny komplet danych.

Podsumowanie

Możesz mieć wiele danych do analizy… Prawda jest jednak taka, że nie ich ilość, ale jakość decyduje o wynikach i przekłada się na trafność podejmowanych decyzje. Warto dołożyć wszelkich starań już na samym początku konfiguracji Google Analytics. Po to, aby zbieranie informacji było jak najmniej zaburzone i w efekcie dostarczało maksimum wiarygodnego materiału. Opłaca się zadbać, by kolejne kroki biznesowe opierały się na faktach, a nie sfałszowanych danych. Czas potrzebny na weryfikację i konfigurację Google Analytics zaprocentuje już pierwszych miesiącach analiz.