Ten artykuł jest naprawdę długi (ale jednocześnie warty przeczytania). Dlatego pozwól, że tym razem pominę wstęp i od razu przejdę do konkretów (a jest ich całkiem sporo!)

Poznaj definicję zdarzeń w Google Analytics. Dowiedz się, co i w jaki sposób warto śledzić, a także poznaj kluczowe zagadnienia związane z ich konfiguracją.

P.S. Na końcu czeka na Ciebie kilka konkretnych PRO TIPÓW, które znacznie ułatwią Ci event tracking w Twojej organizacji.

Co znajdziesz w tym artykule?
Czym są i do czego służą zdarzenia w Google Analytics?
Jakie zdarzenia warto śledzić za pomocą narzędzia od Google?
Jak prezentowała się struktura zdarzeń w UA, a jak obecnie wygląda w przypadku GA4? Opis zmian i różnic.
Zaawansowane podejścia do śledzenia zdarzeń GA4: najlepsze praktyki i trend server-side w 2025/2026
Na co warto zwrócić uwagę podczas definiowania zdarzeń w GA4?
Do wyboru, do koloru. Jakie rodzaje zdarzeń znajdziesz w Google Analytics 4?
Co zrobić, jeśli nie udało Ci się znaleźć odpowiedniego zdarzenia?
Event tracking a GA4. W jaki sposób z niego korzystać?
Jak zaimplementować zdarzenia w Google Analytics 4?
Jak jeszcze możesz przeprowadzić proces implementacji zdarzeń w GA4?
Gdzie w GA4 znaleźć już skonfigurowane zdarzenia?
Testy wykonane i co dalej?
Event tracking w Google Analytics 4 – podsumowanie i zakończenie

Czym są i do czego służą zdarzenia w Google Analytics?

Zanim dasz się porwać technologicznemu wirowi, dotyczącemu zdarzeń w Google Analytics, zacznijmy od nieco luźniejszego wstępu. Co sprawia, że uznajemy dany dzień za udany? Myślę, że gdybyśmy zebrali wszystkie potencjalne odpowiedzi, to z pewnością łączyłby je jeden wspólny mianownik, czyli: “coś się działo” czyt. wystąpiło jedno lub pojawiło się więcej zdarzeń, które nas “pochłonęły” lub sprawiły, że po prostu dobrze się bawiliśmy.

I wiesz co? Nie inaczej jest w przypadku Google Analytics. Abyśmy mogli dobrze się “bawić” podczas analizowania ruchu na naszej stronie internetowej – potrzebujemy do tego zdarzeń. No, chyba że lubisz, gdy w Twoich raportach widnieją same zera. Wówczas wystarczy, że utworzysz usługę GA i tak już ją zostawisz. Kończąc to odrobinę swobodniejsze wprowadzenie – pozwól, że przejdę do konkretów.

O ile, w przypadku Universal Analytics mieliśmy do wyboru, czy chcemy urozmaicać nasze raporty, poprzez śledzenie zdarzeń (jeden z kilku rodzajów hitów), o tyle w przypadku GA4 można powiedzieć, że zostaliśmy postawieni pod analityczną ścianą. Wszystko przez fakt, że każda interakcja podjęta przez użytkownika w Google Analytics automatycznie otrzymuje miano “zdarzenia”.

Właśnie dlatego na pytanie “po co śledzić zdarzenia w Google Analytics?” możemy odpowiedzieć pół żartem, pół serio: “tak”. Tak, ponieważ to właśnie dzięki dobrze zdefiniowanym oraz prawidłowo skonfigurowanym zdarzeniom zyskasz szczegółowe informacje na temat tego, jakie interakcje są podejmowane na Twojej stronie – w jakiej ilości oraz z jaką częstotliwością.

Jakie zdarzenia warto śledzić za pomocą narzędzia od Google?

To naturalne, że z poziomu artykułu nie jestem w stanie zaproponować Ci gotowej listy zdarzeń, która będzie idealnie dopasowana do charakteru Twojego serwisu, specyfiki biznesu, aż wreszcie – Twoich potrzeb. W związku z tym poniżej znajdziesz kilka przykładowych interakcji, które z pewnością warto rozpatrzyć jako potencjalne zdarzenie:

• śledzenie transakcji e-commerce (opcja dla sklepów internetowych, choć z powodzeniem możesz ją wykorzystać także w bardziej niestandardowy sposób – np. na stronie blogowej)
• śledzenie kroków ścieżki zakupowej (m.in. wyświetlenie produktu, dodanie produktu do koszyka, czy rozpoczęcie realizacji zamówienia)
• wysłanie formularza
• zapis do newslettera
• kliknięcie lub wyświetlenie jakiegoś elementu
• zalogowanie lub zarejestrowanie się
• błędy 404 na stronie
• “wskoczenie” użytkownika do grupy odbiorców (ciekawa opcja w interfejsie GA4)

Jak prezentowała się struktura zdarzeń w UA, a jak obecnie wygląda w przypadku GA4? Opis zmian i różnic.

Jeżeli korzystasz z obu tych narzędzi jednocześnie (stosując tzw. dual-tagging) – z całą pewnością udało Ci się dostrzec pewne różnice w strukturze występujących tam zdarzeń.

W Universal Analytics masz do wykorzystania 3 podstawowe wymiary rozróżniające, a także metrykę, która określa wartość zdarzenia. Oczywiście, możesz również definiować wymiary oraz metryki niestandardowe, jednak w tym miejscu mam na myśli strukturę, która występuje domyślnie.

Jeżeli chodzi o wspomniane wymiary – w ich zakres wchodzą: kategoria, akcja oraz etykieta. Dodatkowo możesz określić tzw. “nie-interakcyjność” danego zdarzenia, której ustawienie na “0” sprawi, że w przypadku wywołania takiego zdarzenia sesja użytkownika nie będzie uznana jako odrzucenie.

A jak to wszystko wygląda w Google Analytics 4? W tym miejscu narzędzie pozostawia Ci sporo swobody. W nowej wersji Analyticsa nie ma standardowych wymiarów zdarzeń (czyli “kategorii”, “akcji” i “etykiety”). W zamian masz do wykorzystania aż do 25 parametrów – i to na poziomie przesyłanego zdarzenia. Niektóre z nich są przesyłane w sposób automatyczny (np. page_location, czy page_referrer), co sprawia, że nie musisz ich dodatkowo definiować.

Aczkolwiek, jeżeli zależy Ci na wzbogaceniu poszczególnych zdarzeń, a rekomendowane parametry przez Google nie spełniają w pełni Twoich oczekiwań – pamiętaj, że zawsze możesz zdefiniować własne parametry (maksymalna ilość znaków nazwy to 40). Informacje o pozostałych limitach odnoszących się do omawianych zdarzeń znajdziesz bezpośrednio na stronie Google – w tym miejscu.

Zaawansowane podejścia do śledzenia zdarzeń GA4: najlepsze praktyki i trend server-side w 2025/2026

Poza klasycznym śledzeniem zdarzeń w GA4, w 2025–2026 coraz większe znaczenie zyskują praktyki, które poprawiają jakość danych i odporność pomiaru na ograniczenia prywatności – np. server-side tracking oraz odpowiednie filtrowanie ruchu wewnętrznego. Specjaliści zalecają konfigurację odpowiednich okresów retencji danych, wykluczanie ruchu testowego oraz stosowanie dedykowanych zmiennych i modeli machine learning, by unikać „szumu” i uzyskiwać bardziej wiarygodne wskaźniki zaangażowania i konwersji.

Server-side tracking i Integracja z Google Tag Manager – jak zwiększyć dokładność eventów GA4

Na co warto zwrócić uwagę podczas definiowania zdarzeń w GA4?

Podczas mojej pracy bardzo często spotykam się z problemem, w którym zauważam, że spora część osób nie chce odchodzić od struktury opisywania zdarzeń i dalej używa parametrów takich jak np.: event_category, czy event_label. Takie podejście wynika głównie z przyzwyczajenia do Universal Analytics.

Oczywiście, w GA4 można przepisać te zdarzenia z UA dosłownie “jeden do jednego” (poza nie-interakcyjnością – ta funkcjonalność zniknęła wraz ze zmianą podejścia do zaangażowania użytkowników w Google Analytics 4).

Aczkolwiek, zamiast kurczowo trzymać się starych rozwiązań – uważam, że warto wykorzystać proces migracji do przemyślenia obecnej struktury zdarzeń i dostosowania jej do nowych standardów. To trochę tak, jakbyśmy po zakupie nowego samochodu przekładali silnik z poprzedniego, ponieważ “stary silnik dobrze się sprawdzał”.

Do wyboru, do koloru. Jakie rodzaje zdarzeń znajdziesz w Google Analytics 4?

Słysząc, że więcej zdarzeń oznacza także więcej danych do analizy – z pewnością możesz stwierdzić, że w takim razie chcesz śledzić… WSZYSTKO! Pomijając już fakt, że takie podejście nie jest najlepszym rozwiązaniem – na początku warto sprawdzić, jakie możliwości daje Google na “dzień dobry”.

Pierwszą kategorią zdarzeń, które warto wyróżnić, są zdarzenia automatyczne. Wraz z zaimplementowaniem Google Analytics (np. poprzez gtag, GTM-a, czy SDK Google Analytics pod Firebase) niektóre eventy same będą się “odkładać”. Przykładem takiego zdarzenia jest, chociażby session_start, który samoistnie jest wywoływany (“doklejany”) przed pierwszą interakcją na stronie w ramach danej sesji.

W obrębie automatycznych możemy wyodrębnić całkiem sporą grupę zdarzeń, które wchodzącą w zakres tzw. Enhanced Measurement (pełną listę znajdziesz tutaj). Ich plusem jest to, że możemy je w łatwy sposób wyłączyć z poziomu ustawień streama (Administracja w interfejsie). A tak już całkiem poważnie – to oczywiście nie jest to ich jedyna zaleta.

Mianowicie, ten wbudowany moduł pozwala śledzić kilka ciekawych interakcji, takich jak page_view, scroll (po przewinięciu 90% strony), czy click (w linki wychodzące). Jest to z pewnością bardzo ciekawe rozwiązanie dla biznesów wchodzących w świat analityki internetowej, ale również kilka z tych opcji z pewnością można wykorzystywać przy bardziej zaawansowanych wdrożeniach.

Przy tym wszystkim należy pamiętać o weryfikacji poszczególnych zdarzeń np. przy pomocy DebugView. Szczególnie nie warto ufać automatycznym zdarzeniom, które dotyczą formularzy lub video. Kto konfigurował śledzenie formularzy z poziomu GTM-a przy użyciu domyślnego listenera – ten doskonale wie, o co chodzi.

Co zrobić, jeśli nie udało Ci się znaleźć odpowiedniego zdarzenia?

Jeżeli zdarzenie, które Cię interesuje, nie znajduje się na liście wszystkich automatycznych zdarzeń lub też wybrane zdarzenie nie spełnia Twoich oczekiwań (np. pod kątem przekazywanych parametrów) – musisz wziąć pod uwagę drugą kategorię zdarzeń. Są nimi wszelkie eventy, które wymagają implementacji.

Google przygotował specjalną listę rekomendowanych zdarzeń, które zostały dopasowane do konkretnych branż (np. szeroko pojętej sprzedaży online), aby w ten sposób ułatwić swoim użytkownikom pracę. Pełna lista rekomendowanych zdarzeń jest dostępna pod tym adresem.

Event tracking a GA4. W jaki sposób z niego korzystać?

Jeśli klikniesz w konkretne zdarzenie – Twoim oczom ukaże się szczegółowa specyfikacja, w której znajdziesz strukturę potencjalnego zdarzenia oraz zalecane lub wymagane parametry.

Ze wspomnianej listy warto korzystać np. w momencie, gdy chcesz rozszerzać śledzenie. Nic nie stoi na przeszkodzie, aby zdefiniować całkowicie nową nazwę zdarzenia. Z własnego doświadczenia jednak wiem, że zdecydowanie lepiej podejść do tego “z głową”. Tak, aby szerokie możliwości i spora dowolność nie okazały się Twoim największym wrogiem.

P.S. Pamiętaj o limicie 500 unikalnych nazw zdarzeń dla aplikacji. Początkowo ten limit dotyczył również stron webowych, ale na szczęście został zniesiony.

Jak zaimplementować zdarzenia w Google Analytics 4?

Jeśli po dotarciu do tej części artykułu w Twojej głowie zrodził się pomysł: “Chcę zostać bohaterem w Google Analytics i zaimplementować go własnoręcznie” – poniżej czeka na Ciebie gotowa instrukcja.

Jednym z najwygodniejszych i najszybszych sposobów jest… powierzenie tego zadania specjalistom od Conversion. Wówczas wystarczy, że skontaktujesz się z nami, przekażesz niezbędne informacje, a my zajmiemy się całą resztą. Nieskromnie dodam, że akurat to rozwiązanie jest unikalne i z pewnością nie znajdziesz go w specyfikacji. Właśnie dlatego postanowiłem od niego zacząć!

A teraz żarty na bok… (chociaż moje zaproszenie do współpracy z Conversion jest jak najbardziej na serio!). W końcu jesteśmy pierwszą w Polsce firmą – specjalizującą się w analityce internetowej oraz optymalizacji konwersji. Więc jeśli korzystać z usług, to z najlepszych!

Jak jeszcze możesz przeprowadzić proces implementacji zdarzeń w GA4?

Musisz wiedzieć, że możliwości implementowania takich zdarzeń jest co najmniej kilka. Najważniejsze z nich zawarłem w poniższych punktach.

#1 Google Tag Manager

Ulubionym (dla każdego analityka internetowego) jest wdrażanie zdarzeń przy użyciu GTM-a. W jego interfejsie znajdziesz gotowy template pod tag zdarzenia, w którym możesz m.in. wpisać wybraną nazwę zdarzenia, ustawić parametry oraz podpiąć regułę wywołującą dane zdarzenie. W tym wszystkim nie zapomnij, aby odnieść się do tagu konfiguracyjnego.

Oczywiście, każde zdarzenie rządzi się swoimi prawami i wymaga odpowiedniego podejścia. Jednak temat konfigurowania zdarzeń to materiał na dedykowany wpis, a nawet cały tutorial. Dlatego w tym miejscu jedynie o nim wspomniałem.

#2 Kod strony

Możesz również wykorzystać do tego celu tag Google (gtag.js), który umieścisz bezpośrednio w kodzie strony. W tym przypadku należy przygotować dedykowane kody zdarzeń (zgodnie ze specyfikacją), a następnie dodać je od razu na stronie.

W większości przypadków (jeśli nie korzystasz z popularnych CMSów typu WordPress), proces ten będzie wymagał wsparcia specjalistów od IT. No, chyba że znasz się na rzeczy i masz odpowiednie dostępy do strony.

Jeżeli nie, a Twoi deweloperzy są dość mocno obłożeni – takie rozwiązanie może okazać się dość problematyczne. Zwłaszcza jeśli weźmiesz pod uwagę ewentualne zmiany i konieczność aktualizowania kodu w przyszłości, chociażby po to, aby wzbogacać śledzenie).

#3 Measurement Protocol

To z kolei nieco alternatywne rozwiązanie, które nie wymaga implementacji GA4 w środowisku, z którego pochodzą dane. Polega na przesyłaniu tzw. requestów HTTP o ustalonej strukturze (oto przykład jak zbudować potencjalny request).

Tego rodzaju podejście stosuje się zazwyczaj w specyficznych scenariuszach, do których możemy zaliczyć: przesyłanie konwersji ze sklepu offline oraz interakcje server-to-server. Stanowi również “jakieś” wyjście w przypadku ograniczeń technicznych przy osadzaniu kodów śledzących.

Oprócz wspomnianych powyżej rozwiązań, w przypadku aplikacji warto korzystać z Analytics SDK dla Firebase.

Gdzie w GA4 znaleźć już skonfigurowane zdarzenia?

Nie samą konfiguracją człowiek żyje. Gdy już uda Ci się przebrnąć przez cały proces konfiguracji – wreszcie przyjdzie wyczekiwany moment, w którym zobaczysz owoce swojej ciężkiej pracy. W tym miejscu małe wtrącenie:

• Jeżeli korzystasz z GTM-a – zanim opublikujesz śledzenie zdarzeń rozważ włączenie opcji Preview Mode oraz zweryfikuj, jak te zdarzenia spływają do GA4 przy użyciu DebugView (znajdziesz to w sekcji Administracja).
• Jeżeli korzystasz z innego rozwiązania wdrożeniowego – również możesz wyodrębnić swój ruch np. poprzez włączenie wtyczki Google Analytics Debugger podczas chodzenia po stronie. Po jej włączeniu zobaczysz swoje interakcje we wspomnianym już DebugView.

Oczywiście, do dyspozycji masz również znane i lubiane – raporty w czasie rzeczywistym. Jednak na potrzeby testowania, DebugView jest zdecydowanie lepszym miejscem.

Testy wykonane i co dalej?

Gdy stwierdzisz, że Twoje śledzenia działa zgodnie z planem, to z pewnością zechcesz zobaczyć inne raporty związane ze zdarzeniami. Domyślny raport znajdziesz w sekcji Raporty -> Zaangażowanie -> Zdarzenia.

Do dyspozycji masz również Eksploracje, w których możesz przygotować raporty “szyte na miarę” – odwzorować standardowy raport lub stworzyć zupełnie nowy.

Event tracking w Google Analytics 4 – podsumowanie i zakończenie

Jeżeli udało Ci się dotrwać do końca tego artykułu – nie mam innego wyjścia, jak tylko Ci pogratulować oraz… wręczyć nagrodę! Na zakończenie mojego długiego i merytorycznego (mam nadzieję!) wywodu o event trackingu w GA4 przygotowałem kilka prawdziwych PRO TIPÓW, które znacznie ułatwią Ci korzystanie ze zdarzeń w GA4. Zapoznaj się z nimi i korzystaj do woli!

• Nie zapominaj o dodaniu parametru “currency”, jeśli definiujesz parametr “value”

Jeżeli tego nie zrobisz, to przychody (np. w raportach “Generowanie przychodu”) będą wyzerowane. Łatwo się na to naciąć, jeśli wykorzystujesz warstwy danych pod standard Universal Analytics

• Zdarzenia w GA4 są batchowane oraz mogą spływać nawet do 72 godzin od wystąpienia zdarzenia

Takie opóźnienie może wystąpić na przykład w przypadku przerwania połączenia z Internetem. Batchowanie oznacza, że zdarzenia są grupowane i wysyłane paczkami do GA4. Jednak mamy kilka wyjątków np. nie dotyczy konwersji, które są wysyłane natychmiast po wystąpieniu.

• Konfigurujesz zdarzenie, które będzie wywoływane z ograniczoną częstotliwością lub Twoja strona opiera się na małej ilości ruchu? Istnieje spore ryzyko, że nie zobaczysz takich zdarzeń w raportach zawierających metryki z liczbą użytkowników.

Wynika to z progowania (“thresholding”), które pojawia się w przypadku włączonej identyfikacji użytkowników opartej o Google Signals. Domyślnie ustawiona “Tożsamość na potrzeby raportowania” to “Mieszana”, w której skład wchodzi również identyfikacja na podstawie Google Signals.

Jeżeli jest to w Twoim przypadku problematyczne, a dodatkowo nie dostrzegasz wartości dodanej w takim trybie identyfikacji – możesz rozważyć przełączenie się na (dobrze Ci znaną z Universal Analytics), identyfikację opartą na urządzeniu (client_id).

Aby to zrobić, należy wejść do sekcji Administracja -> Tożsamość na potrzeby raportowania i wybrać opcję Zależne od urządzenia. Zmiana jest retroaktywna i w każdej chwili możesz powrócić do wcześniejszych ustawień – bez trwałego oddziaływania na dane.

• Problem z kardynalnością (mocą zbioru) jest dość powszechny w GA4

Zwłaszcza jeżeli przesyłasz wymiary cechujące się dużą unikalnością wartości. Według Google za takie wymiary należy uznać parametry, które przekazują powyżej 500 niepowtarzalnych wartości na dzień.

Pewnie zastanawiasz się, w jaki sposób możesz zidentyfikować ten problem? Jeżeli w raporcie na poziomie wymiaru zauważysz (other) to wiedz, że “coś się dzieje”. Nie będę wchodzić w dalsze szczegóły, ponieważ jest to dość rozbudowany temat. Jednak zachęcam, aby o tym pamiętać i zanim coś zdefiniujesz jako parametr – zastanów się, czy nam jest potrzebny lub czy nie warto pogrupować jego wartości.

• Przesyłasz dodatkowe parametry i chcesz mieć do nich swobodny dostęp z poziomu raportów, eksploracji, czy w Looker Studio? Zdefiniuj je jako wymiar niestandardowy.

Co ciekawe, warto to zrobić również w przypadku parametrów przesyłanych w ramach zdarzeń Enhanced Measurement (np. search_term). Bez tego działania nie otrzymasz do niego dostępu z poziomu Looker Studio (domyślny connector) oraz np. w podsumowaniu raportu standardowego (w sekcji “Eksploracje” ta grupa parametrów jest dostępna bez dodatkowych modyfikacji).

Mam nadzieję, że udało mi się przekonać Cię do przetestowania tego rozwiązania! Jeśli wiedzę zawartą w tym artykule uważasz za wartościową to koniecznie sprawdź wpis na naszym blogu mówiący o tym dlaczego warto wdrożyć Google Tag Managera!

The post Event tracking bez tajemnic. Jak śledzić zdarzenia w Google Analytics? first appeared on Conversion.

Branża: Sklep elektroniczny
Klient: Botland (Bralin, Polska)
Strona: www.botland.com.pl

Punkt wyjścia

Botland to sklep internetowy specjalizujący się w sprzedaży elektroniki i komponentów. Dla zespołu kluczowe było wiarygodne mierzenie sprzedaży w Google Analytics 4 oraz poprawna atrybucja transakcji do sesji i źródeł ruchu, tak aby decyzje marketingowe mogły opierać się na rzetelnych danych.

W trakcie współpracy okazało się, że obecny sposób rejestrowania transakcji znacząco obniża jakość danych analitycznych, szczególnie w kontekście atrybucji.

Wyzwania

Analiza wykazała, że transakcje były rejestrowane w sposób mieszany:

• część zdarzeń była wywoływana na stronie podziękowania („thank you page”),
• część transakcji była dodatkowo dosyłana z backendu za pomocą Measurement Protocol.

Taka implementacja powodowała, że znaczna część zdarzeń sprzedażowych nie była poprawnie łączona z kontekstem sesji użytkownika. W praktyce około 50% transakcji traciło informację o źródle wizyty.

W danych GA4 przekładało się to na wysoki udział transakcji oznaczonych jako „(not set)”, który sięgał 21% wszystkich konwersji. Przy takiej skali problemu jakość atrybucji była niewystarczająca do wiarygodnej oceny skuteczności kanałów i kampanii, co utrudniało podejmowanie decyzji budżetowych oraz optymalizację działań marketingowych.

Nasze podejście

Aby poprawić jakość danych, zdecydowaliśmy się na zmianę momentu rejestrowania zdarzenia „purchase”. Zamiast wysyłania go na stronie „thank you page”, zdarzenie zaczęło być rejestrowane w momencie przejścia użytkownika do bramki płatniczej.

Takie podejście pozwoliło:

• zwiększyć liczbę transakcji rejestrowanych bezpośrednio przez GA4,
• poprawnie przypisać transakcje do sesji oraz źródła ruchu,
• znacząco ograniczyć skalę problemu transakcji bez przypisanego źródła („not set”).

Efekty

Wdrożone zmiany przyniosły wyraźną poprawę jakości danych:

• udział transakcji wysyłanych z przeglądarki wzrósł z 68% do 98%,
• liczba transakcji rejestrowanych z warstwy frontendu wzrosła o 30%,
• odsetek transakcji oznaczonych jako „(not set)” spadł z 21% do 10%, czyli o 11 punktów procentowych,
• poprawiła się wiarygodność atrybucji i oceny skuteczności kanałów oraz kampanii.

Co istotne, poprawa jakości danych nie odbyła się kosztem kompletności pomiaru. Całkowite pokrycie transakcji w GA4 utrzymało się na poziomie 75%, a rozkład pokrycia według metod płatności pozostał bez zmian. Oznacza to lepsze dane bez kompromisów w zakresie zasięgu rejestrowanych transakcji.

Opinia na temat współpracy Botland.com.pl z Conversion

Dzięki wprowadzonym zmianom Botland zyskał stabilne i spójne dane sprzedażowe w GA4. Poprawiona atrybucja pozwala obecnie na znacznie bardziej wiarygodną ocenę skuteczności kanałów marketingowych oraz podejmowanie decyzji budżetowych w oparciu o „czyste” dane.

Podsumowanie

Współpraca z Botland pokazuje, jak duży wpływ na jakość danych analitycznych ma sposób implementacji zdarzeń sprzedażowych. Zmiana momentu rejestrowania transakcji pozwoliła znacząco poprawić atrybucję i wiarygodność raportów, przy jednoczesnym zachowaniu tego samego poziomu pokrycia transakcji w GA4.

The post Botland.com.pl – 30% więcej transakcji z frontendu i spadek „(not set)” z 21% do 10% first appeared on Conversion.

Wyobraź sobie świat, w którym możesz samodzielnie modyfikować kody śledzące na Twojej stronie www. Jesteś w stanie w łatwy sposób przekazywać do Google Analytics dodatkowe informacje, kody remarketingowe od różnych usługodawców, przeprowadzać testy A/B, czy zmieniać warunki, które powodują wywołanie kodu śledzącego konwersje Google Ads. I uwaga… to wszystko za sprawą GTM i praktycznie bez żadnego udziału specjalistów z działu IT!

Tak, zdecydowanie Google Tag Manager to jedno z tych typów narzędzi, bez którego większość z nas nie wyobraża już sobie codziennych działań analitycznych. Posiadanie GTM-a zdecydowanie usprawnia działania związane ze zbieraniem danych, a także pozwala na lepsze zarządzanie kodami śledzącymi.

Dowiedz się, co to jest Google Tag Manager, jak działa i w jaki sposób możesz wykorzystać możliwość GTM także w swojej firmie. Zapraszam!

Co znajdziesz w tym artykule?
Czym jest Google Tag Manager?
Jak zainstalować Google Tag Managera?
Do czego służy Google Tag Manager? Po co Ci GTM?
Jak przedstawia się struktura Google Tag Managera?
Zaawansowane funkcje Google Tag Manager
GTMowa wisienka na torcie, czyli: zarządzanie użytkownikami, wersjami oraz debugowanie
Tryb zgody – Consent Mode w Google Tag Manager
Google Tag Manager – podsumowanie

Czym jest Google Tag Manager?

Google Tag Manager (w skrócie GTM) to system służący do zarządzania wszystkimi skryptami (tagami), które znajdują się na danej stronie www. Można więc powiedzieć, że stanowi “coś” w rodzaju CMSa (Content Management System), który został stworzony specjalnie do dodawania oraz modyfikowania obecnych na stronie internetowej skryptów. Wspomniane skrypty mogą przyjmować najróżniejsze formy – od skryptów śledzących narzędzi analitycznych (jak Google Analytics), poprzez skrypty wykorzystywane do śledzenia konwersji z systemów reklamowych (jak np. Google Ads), aż po niemal dowolne skrypty wykorzystujące JavaScript (np. ankiety).

Jak zainstalować Google Tag Managera?

Aby zainstalować GTM na naszej stronie, jedyne co musisz zrobić, to umieścić kawałek kodu JavaScript. Kod ten nazywa się kontenerem (ang. container) i wygląda w następujący sposób:

• część pierwsza, umieszczona w części <head> witryny:

• oraz dodatkowo druga jego część, po tagu otwierającym <body>:

Dzięki niemu Google Tag Manager będzie w stanie uruchamiać zdefiniowane w panelu narzędzia skrypty:

Tak wygląda podgląd kodów w Google Tag Managerze wraz z regułami, które decydują o tym, kiedy który z nich zostanie uruchomiony.

Do czego służy Google Tag Manager? Po co Ci GTM?

Zastanawiając się nad zastosowaniem GTM, z pewnością pierwszą rzeczą, która przychodzi Ci na myśl, jest analityka (w tym zbieranie, przetwarzanie oraz interpretowanie danych na temat użytkowników Twojej strony). Zgadza się? Jasne, to jedno z kluczowych zastosowań Google Tag Managera, jednak musisz wiedzieć, że z pewnością nie jest ono jedyne. Kolejnymi obszarami, w których sprawdza się poczciwy GTM, są:

1. Szybsza strona internetowa

Kolejne tagi na stronach internetowych spowalniają je coraz bardziej. Z testów przeprowadzonych przez jednego z naszych “branżowych kolegów” wynika, że różnice mogą wynosić nawet kilka sekund. A jak pokazuje infografika od KISSmetrics – szybkość ładowania strony ma zdecydowanie kluczowy wpływ na generowany przez nią przychód. Dlatego, jeżeli Twoja strona ma być skuteczna – wdrożenie na niej GTMa jest po prostu koniecznością.

W jaki sposób GTM pomaga Ci radzić sobie z szybkością ładowania witryny? Można powiedzieć, że robi to aż na 2 różne sposoby:

• Po pierwsze, Google Tag Manager ładuje tagi asynchronicznie. Szybciej ładujące się tagi nie muszą “czekać” na te wolniejsze, co w rezultacie przyspiesza działanie całego serwisu.
• Po drugie, GTM daje nam możliwość sprawowania łatwej kontroli nad tagami. Zazwyczaj jest tak, że w trakcie wdrożeń bardzo mocno kontrolujemy IT pod względem ich poprawności. Niestety, w momencie usuwania tagów, zazwyczaj tej skrupulatności zaczyna już nam brakować. W efekcie powoduje to, że na wielu stronach pozostają “osierocone” tagi, które mogą spowalniać działanie witryny.

2. Gwarancja otagowania każdej strony

Wielokrotnie pojawiającym się problemem jest również ten związany z ciągłym udoskonalaniem stron www. Bardzo często zdarza się bowiem, że pieczołowicie przygotowane tagi znikają z niektórych podstron – i to w “niewyjaśnionych okolicznościach”. Dział IT mógł zapomnieć “przekleić” wybranej linijki JavaScriptu do nowego szablonu lub pozbyć się tagowania na nowym landing page’u – cóż, nawet najlepszym się zdarza.
Z podobnym problemem spotykamy się, gdy chcemy, aby wybrany kod pojawiał się tylko na wybranych podstronach (np. ankieta na stronie podziękowania) lub gdy pomimo sprawdzenia, że kod został wprowadzony na 95% stron, na których miał być umieszczony, to nadal pozostało te nieszczęsne 5%, które pominięto. Z GTM nie ma tych problemów, ponieważ jedyne, o co należy zadbać, to aby specjaliści IT poprawnie wdrożyli kod kontenera na wszystkich podstronach. Taki zabieg sprawi, że wszystkie tagi wywołają się dokładnie tam, gdzie został umieszczony skrypt kontenera, a to z kolei nawet kilkunastokrotnie ograniczyć miejsca, które trzeba zweryfikować.
Wygodne, co nie?

3. Ominięcie działu IT przy wdrożeniach kodów (hurra!)

Na koniec ta najbardziej oczywista korzyść. Wdrożenie Google Tag Managera pozwala ominąć dział IT przy wdrażaniu zdecydowanej większości nowych kodów. Oczywiście, pewnych prac po stronie informatyków nie da się wyeliminować całkowicie. W końcu “ktoś” musi umieścić na stronie, chociażby kod samego kontenera. Ponadto, część informacji będzie musiała być wysyłana z tzw. backendu (np. w przypadku zdarzeń e-commerce czy informacji o stanie zalogowania użytkownika). Jednak bezdyskusyjnie, posiadanie GTM-a sprawi, że świat (przynajmniej ten analityczny!) z miejsca stanie się piękniejszy.

To by było na tyle, jeśli chodzi o wstęp. Pora przejść do omówienia samego narzędzia.

Jak przedstawia się struktura Google Tag Managera?

Konstrukcja popularnego GTM przewiduje kilka obszarów. Najważniejsze z nich omówiłem w kolejnych akapitach.

Konto i kontenery w GTM

Gdy rejestrujesz się w Google Tag Managerze – z miejsca otrzymujesz swoje konto. Jego struktura przypomina Google Analytics, dzięki czemu po zalogowaniu się do GTM, prawie od razu możesz przejść do innych kont, do których masz dostęp. W obrębie każdego konta może istnieć jeden lub więcej typów kontenerów, w tym:

• kontener dla witryn internetowych,
• kontener dla aplikacji iOS,
• kontener dla aplikacji Android,
• kontener dla stron typu AMP (jest to standard kodowania stron internetowych, który pozwala na lepsze dopasowanie ich wydajności do urządzeń mobilnych),
• kontener typu server side.

Typy kontenerów w Google Tag Manager.

Można więc powiedzieć, że kontener to coś w rodzaju “worka”, w którym możesz trzymać różnorodne kody śledzące. Każdy kontener ma osobny kod, który musisz umieścić na swojej stronie (przykład prezentowałem na samym początku tego artykułu).

Jeden kontener możesz wykorzystywać na jednej lub wielu witrynach jednocześnie. Osobiście zalecałbym korzystanie z dobrych praktyk z Google Analytics i kierowanie się zasadą pt.: osobne konto dla każdej domeny głównej (a w przypadku roll-upu także osobnego konta zbiorczego).

W tym wpisie zajmę się pierwszym wspomnianym typem, z którym zapewne większość z użytkowników ma najczęściej do czynienia.

Data Layer (warstwa danych w GTM)

Data Layer to jeden z kluczowych aspektów zarządzania tagami z wykorzystaniem takich narzędzi jak GTM. Google Tag Managera daje możliwość sczytania wybranej wartość z Twojej strony internetowej (np. element DOM lub zmiennej JS). To jest naprawdę super opcja.
Istnieje tylko jeden problem. Co się stanie, jeśli strona www zostanie przebudowana, a jej kod źródłowy ulegnie zmianie? Wtedy niektóre z wykorzystywanych przez DOM elementów (lub zmienne JS) mogą po prostu “wyparować”. Jedynym wyjściem będzie wówczas przeprowadzenie aktualizacji kodu. Niestety, zazwyczaj nikt z IT nie poinformuje Cię, że takowa zmiana w ogóle miała miejsce.

Jak sobie z tym poradzić?

Właśnie na takie okazje stworzono tzw. warstwę danych, która umożliwia przekazanie do GTM wszystkich niezbędnych informacji. Takimi informacjami mogą być nazwy kupionych produktów, typ oglądanej strony, wersja oglądanej strony, wartość konwersji, ID ostatniej transakcji itd.

Jak to wygląda w praktyce? Otóż, dzięki oddzieleniu warstwy danych od struktury strony, będziesz mieć pewność, że zmiany w HTMLu nie wpłyną nam na wcześniej zdefiniowaną Data Layer.

Oznacza to – ni mniej, ni więcej, że oprócz przekonania działu IT o wdrożeniu kodu kontenera, trzeba będzie ich jeszcze “zmusić” do wprowadzenia warstwy danych w obrębie całej witryny. Dodaje to pracy Tobie (bo w końcu “ktoś” to musi zaplanować) oraz specjalistom IT. Jednak daję słowo, że ten wysiłek bardzo się opłaci.

Jak wygląda warstwa danych w Google Tag Manager?

W praktyce, warstwa danych to tak naprawdę jeden, bardzo to prosty fragment JavaScript. O, dokładnie taki:

Gdzie za ‘nazwa’ należy wstawić nazwę danej zmiennej, z kolei za ‘wartość’ – oczywiście… jej wartość :), którą przyjmuje na danej stronie www.

Potrzebujesz przykładu? Proszę bardzo! Jeżeli prowadzisz sklep internetowy i chcesz przekazać do GTM kategorię produktu, na której znajduje się użytkownik (a dodatkowo również nazwę oraz ID produktu), warstwa danych mogłaby wyglądać w następujący sposób:

Przekazane do GTM zmienne możesz wówczas dowolnie wykorzystać – albo w samych tagach (np. nadając zmienną niestandardową o wartości nazwy kategorii produktu, w tym przypadku – wody), albo w warunkach (np. uruchom ankietę, jeżeli id produktu będzie równe 123123). Oczywiście tych danych nie trzeba wprowadzać ręcznie na każdej podstronie. Wystarczy wykorzystać do tego przez informatyków skrypt.

Osobiście polecam, żeby w warstwie danych przekazać więcej informacji (nawet, jeżeli części z nich nie będzie wykorzystana). Samą warstwę należy umieścić powyżej kodu kontenera Google Tag Managera — w tzw.lub też na samym początku.

Dzięki warstwie danych można przekazywać nie tylko statyczne dane, ale także dynamiczne. Przykładowo, jeżeli użytkownik zaznaczy w formularzu swoją płeć lub ulubiony kolor, ta informacja będzie mogła trafić do Google Tag Managera. Wykorzystuje się do tego komendy push. Taką komendę podpinamy pod wybrane pole, np.:

Warto nadmienić, że nowo nadane wartości zmiennych nadpisują poprzednie wartości. Jeżeli domyślną wartością dla zmiennej ‚plec’ było ‚brak’ to po wywołaniu powyższej linijki, zmienna ta przyjmie wartość ‚kobieta’.

Zmienne w Google Tag Managerze

Pojęcie zmiennej w GTM jest bardzo łatwe do wytłumaczenia. Zmienne przechowują wartości poszczególnych elementów. Jeżeli w warstwie danych przekażesz płeć wybraną w formularzu, to w GTM trzeba stworzyć zmienną, w której ta wartość będzie przechowywana (jeżeli chcesz z nią cokolwiek zrobić).

W Google Tag Managerze mamy do czynienia ze zmiennymi wbudowanymi oraz zmiennymi zdefiniowanymi przez użytkownika.

Zmienne wbudowane to m.in. zmienne typu adres URL (np. Page Path, który mówi nam o lokalizacji użytkownika), czy zmienne typu warstwa danych (np. Click Element, który dostarcza informacji o klikanym przez użytkownika elemencie).

Pełną listę zmiennych wbudowanych dla kontenerów internetowych znajdziesz w tym miejscu: https://support.google.com/tagmanager/answer/7182738?hl=pl&ref_topic=7182737

Widok okna w Google Tag Manager, gdzie możemy uaktywnić zmienne wbudowane. Po ich włączeniu będziemy widzieć ich wartości podczas debugowania kontenera.

Pozwól, że zatrzymam się jeszcze na chwilę na naszym przykładzie z płcią. Załóżmy, że przekazaliśmy jej wartość za pomocą warstwy danych i teraz chcemy ją wykorzystać w GTM (tak, aby np. przekazać jako zmienną niestandardową do Google Analytics).

Aby to zrobić, musimy przekształcić ją w tzw. zmienną:

W taki sposób musimy przekształcić każdy element przekazany w warstwie danych w zmienną, aby używać go w GTM.

Tagi wykorzystywane przez Google Tag Managera

Może być tak, że zechcesz, aby Google Tag Manager wykonał jakiś skrypt w momencie, gdy użytkownik kliknie w konkretny link na Twojej stronie internetowej. Aby GTM się o tym dowiedział, musisz skorzystać z pomocy tagów.

Wyobraź sobie, że chcesz, aby Google Tag Manager wysłał wirtualną odsłonę w momencie, gdy użytkownik kliknie powiększenie zdjęcia, które w Twoim serwisie nie wywołuje nowej odsłony. Aby przekazać odpowiednią informację do GTM, musisz skorzystać z eventu.
Na koniec: pamiętaj, aby nie mylić zdarzeń z Google Tag Managera ze zdarzeniami z Google Analytics. Główną różnicą pomiędzy tymi narzędziami jest to, że tzw. zdarzenia GTM-owe mogą wysyłać informacje nie tylko do Google Analytics, ale także do innych systemów.

Jakie są rodzaje tagów, które spotkasz w GTM?

Do podstawowych typów tagów możemy zaliczyć:

• tagi Google Analytics: zarówno do wersji Universal Analytics, jak i Google Analytics 4,
• tagi związane w produktami Google (Google Ads, Floodlight czy Google Optimize),
• tagi zintegrowane z platformami do zarządzania zgodami użytkowników,
• tagi “approved” by Google, które są związane z dodatkowym śledzeniem (z firm takich, jak: Hotjar, Microsoft Advertising czy Linkedin),
• tagi customowe – gdzie najczęściej można mówić o tzw. tagach typu Custom HTML.

Tagi używane w GTM mogą posiadać również dodatkowe ustawienia. W tej materii możemy zatem wymienić:

• • Tag firing priority – pozwól, że do wyjaśnienia jego działania, posłużę się cytatem z Google. Mianowicie:

Określa kolejność, w jakiej będą uruchamiane tagi. Jego wartość może być ujemną lub dodatnią liczbą całkowitą, a tagi z wyższym priorytetem będą uruchamiane w pierwszej kolejności. (Tag o priorytecie równym np. 3 będzie uruchamiany przed tagami o priorytetach 1 i 2). Jeśli nie ustawisz żadnej wartości, priorytet ma domyślną wartość 0. Tagi będą wciąż uruchamiane asynchronicznie. – zmiana priorytetu tagu nie zapobiegnie uruchamianiu innych tagów, nawet jeśli któryś o wyższym priorytecie w ogóle się nie uruchomi.

• • Tag sequencing – w tym przypadku za wyjaśnienie niech również posłuży informacja od Google:

Sekwencjonowanie tagów pozwala wskazywać tagi do uruchomienia bezpośrednio przed uruchomieniem danego tagu „głównego” lub po nim.”

Przykład? Tagi dostawców takich jak TikTok często wymagają odpowiedniego ustawienia wywoływania, aby mogły działać poprawnie (np. tag odsłony powinien wywoływać się przed tagiem view_content).

• Additional Tag Metadata – opcja używana dość rzadko, która pozwala dodawać metadane do każdego pojedynczego tagu w kontenerze.
• Consent settings – to z kolei ustawienie, które pozwala modyfikować wywoływanie tagu na podstawie udzielonej przez użytkownika zgody. Jeżeli interesuje Cię ta tematyka – koniecznie zapoznaj się z artykułem na temat Consent Mode.

Triggers (tzw. reguły GTM)

Reguły to już ostatnie pojęcie, które jest Ci potrzebne do zrozumienia działania Google Tag Managera.

To właśnie dzięki ustalanym regułom, GTM wie, kiedy wczytać odpowiedni skrypt. Najprostszą i najczęściej wykorzystywaną regułą (oprócz tej, aby w ogóle “odpalić” kod na każdej stronie www), będzie uruchomienie kodu konwersji na stronie podziękowania. Taka reguła mogłaby wyglądać w następujący sposób:

Przykładowa reguła w Google Tag Managerze, którą będziemy mogli wykorzystać, aby np. uruchomić skrypt konwersji na stronie podziękowania.

Na podstronie z podziękowaniem z powodzeniem można także użyć reguły “zdarzenie niestandardowe”, ale o tym opowiem Ci za chwilę.

Typy reguł możemy podzielić w następujący sposób:

1. Wyświetlenie strony – w ramach których mamy do czynienia z kilkoma podtypami:
   • inicjacja zgody, która pomaga w uwzględnianiu ustawień związanych ze zgodami – jeszcze przed uruchomieniem samych reguł.
   • zdarzenie inicjujące, które uruchomienie następuje na samym początku (zaraz za inicjacją zgody).
   • wyświetlenie strony, do którego uruchomienia dochodzi od razu po tym, jak przeglądarka rozpocznie ładowanie witryny.
   • element DOM dostępny, który zostaje uruchomiony, gdy przeglądarka sfinalizuje proces tworzenia strony w języku HTML, a co za tym idzie – pozwoli analizować element DOM.
   • wczytanie okna, które wyzwala się, gdy strona całkowicie się załaduje (mowa tu zarówno o samym kodzie, jak i wszystkich zasobach – obrazach, skryptach itp.).
2. Kliknięcie – dotyczy kliknięć w linki lub elementy strony. Podczas konfigurowania tych reguł zazwyczaj korzysta się z dodatkowych warunków – takich, jak wyzwalanie reguły kliknięcia w określony tekst lub w element strony.
3. Zaangażowanie (np. głębokość przewijania czy widoczność elementu).
4. Błąd Skryptu JavaScript – jednym z przykładów może być kod serwisu (np. społecznościowego), w którym prowadzisz działania reklamowe i wysyłasz tam dane o wyświetleniach produktów czy dodaniach do koszyka.Kiedy kod np. nie może wywołać się poprawnie lub sczytać ze strony internetowej odpowiednich informacji, można wówczas uruchomić np. tag Google Analytics i tym samym wysłać tę informację do swojej usługi. Jest to cenna informacja z punktu widzenia prowadzenia działań reklamowych.
5. Grupa wyzwalaczy – jak można wyczytać na stronach Google:
   “Grupa reguł oceni, czy są spełnione warunki dwóch lub większej liczby reguł jako całości. Grupa reguł uruchomi się dopiero wtedy, gdy wszystkie wybrane reguły uruchomią się co najmniej raz”Przykład zastosowania? Uruchomienie tagu tylko wtedy, gdy użytkownik na danej podstronie kliknie 2 przyciski.
6. Minutnik – reguła, którą z powodzeniem można zastosować na podstronach, które zawierają dużo treści/tekstu i oprócz kliknięcia w link (np. produktu na wpisie blogowym), jako zaangażowanie chcesz też mierzyć czas spędzony na stronie. Dodatkowo, za jego pomocą, możesz też zmodyfikować współczynnik odrzuceń.
7. Zdarzenie niestandardowe – reguła uruchamia się w momencie wywołania w kodzie funkcji dataLayer.push(), z którą dodatkowo mogą być wysłane dodatkowe zmienne. Z przykładem zdarzeń niestandardowych zderzysz się najczęściej przy konfiguracji Enhanced Ecommerce (dodanie do koszyka czy zakup). Innym przykładem może być śledzenie wypełnienia formularza na stronie. Wówczas możesz śledzić jego wypełnienie, ale dostać także dodatkowe informacje, które nie są widoczne na stronie (każdy użytkownik, niezależnie od wypełnionego formularza, ląduje na tym samym TYP). W tym przypadku możesz poprosić programistę o wprowadzenie dodatkowego kodu:

   dataLayer.push({’event’:’form_submit’,’typ’:[typ formularza],’opcja_dodatkowa’:[tak/nie]});

8. Zmiana w historii – jest to reguła używana na stronach typu SPA w celu śledzenia wirtualnych odsłon.

Takie reguły odpowiadają za uruchomienie tagu, jeśli identyfikator fragmentu adresu URL (oznaczony za pomocą kratki) zostanie zmodyfikowany lub też, jeśli w samej witrynie zostanie wykorzystany interfejs API HTML5 (typu pushstate). Omawiana reguła sprawdza się podczas uruchamiania tagów, które mają śledzić wirtualne odsłony strony w aplikacji Ajax.

Foldery w GTM

Według informacji od Google, w miarę rozrastania się kontenerów, śledzenie wszystkich konfiguracji tagów, reguł, jak i samych zmiennych, staje się coraz trudniejsze. Aby usprawnić pracę z tymi elementami, warto uporządkować je w logiczne grupy, do czego można wykorzystać właśnie foldery Menedżera tagów.

Zatem, grupowanie przy użyciu folderów może odbywać się na różne sposoby. Można klasyfikować tagi zależnie od zespołów, które się nimi zajmują, czy też dzielić kontener na podstawie części witryny, które dane tagi obsługują.

Templates w aplikacji Google Tag Manager

GTM pozwala również na korzystanie z gotowych szablonów tagów, które nie wymagają “ręcznego” kopiowania oraz przepisywania kodów HTML i JavaScript. W tym celu udostępnia tzw. galerię szablonów, która stanowi swego rodzaju repozytorium – aktualizowane także przez samych użytkowników GTM.

Zaawansowane funkcje Google Tag Manager

GTM oferuje funkcje wykraczające poza prostą obsługę tagów – np. możliwość uruchamiania kodu po stronie serwera (server-side tagging), co zmniejsza obciążenie strony i pomaga w ochronie prywatności. Można też wykorzystywać warstwę danych (dataLayer) do przekazywania zmiennych kontekstowych, stosować reguły warunkowe (np. niestandardowe filtry), a także korzystać z gotowych szablonów i rozszerzeń (community templates), które pozwalają szybko integrować mniej standardowe zdarzenia.

Integracja z Google Analytics

Dzięki GTM możesz łatwo podpiąć Google Analytics (zwłaszcza GA4) bez edytowania kodu strony – wystarczy utworzyć tag konfiguracyjny z identyfikatorem pomiaru oraz tagi zdarzeń (np. kliknięcia, przewijanie).

Przez GTM można też centralnie zarządzać parametrami (np. wartości transakcji, identyfikator produktu) i przekazywać je jako zmienne do GA. Dzięki temu dane są bardziej spójne i łatwiej rozszerzalne, bo zmiany robi się w GTM, a nie bezpośrednio w kodzie witryny.

GTMowa wisienka na torcie, czyli: zarządzanie użytkownikami, wersjami oraz debugowanie

Czytając ten artykuł, z pewnością naszły Cię wątpliwości związane z tym, czy aby na pewno w GTM każdy będzie mógł zmieniać, dodawać, usuwać, a następnie uruchamiać na stronie. Rozwiewam Twoje obawy – na szczęście w GTM zostało to naprawdę dobrze rozwiązane.

Zarządzanie użytkownikami Google Tag Managera

Po pierwsze Google Tag Manager dostarcza Ci wiele bardzo fajnych sposobów na zarządzanie użytkownikami. Możesz zarządzać prawami na dwóch poziomach: konta oraz kontenera.

Na poziomie konta masz do dyspozycji 2 poziomy uprawnień:

1. View Only: użytkownik będzie widział konto, ale nie będzie widział żadnych kontenerów do momentu przyznania mu do nich praw.
2. View, Edit and Manage: na tym poziomie użytkownik będzie widział wszystkie kontenery w koncie i ich ustawienia. Nie będzie miał jednak możliwości ich edycji lub publikacji, chyba że nadamy mu odpowiednie prawa na poziomie kontenera.

Na poziomie kontenera masz z kolei aż 3 poziomy uprawnień:

1. View Only: z tymi uprawnieniami użytkownik ma podgląd wszystkich elementów kontenera (tagów, makr i reguł).
2. View and Edit: te uprawnienia dają użytkownikowi możliwość edycji wybranego kontenera i podglądu wprowadzanych zmian (tryb debugowania). Nie dają mu jednak opcji usuwania i publikacji zmian.
3. View, Edit, Delete & Publish: najwyższe uprawnienia, które dają użytkownikowi pełną swobodę. Może on przeglądać wszystkie elementy, edytować, usuwać, a nawet publikować je bezpośrednio w witrynie.

Każdemu użytkownikowi możemy przydzielić prawa na dwóch poziomach: konta i kontenera.

Zarządzanie wersjami kontenera w GTM

W celu łatwiejszego wdrażania zmian i powrotu do poprzednich, działających poprawnie wersji, GTM udostępnia opcję sprawnego zarządzania wersjami kontenera. Każda z wersji stanowi jakby zdjęcie obecnych ustawień kontenera, który edytujemy.

W zakładce Wersje jesteś w stanie prześledzić wszystkie wersje kontenera – zarówno te opublikowane, jak i nie.

Podpowiedź: Warto tworzyć klarowne i czytelne nazwy wersji oraz umieszczać dodatkowe informacje w opisie. Po dłuższym korzystaniu z kontenera, gdy pracuje nad nim coraz więcej osób (i przybywa także tagów), czytelna dokumentacja zmian jest niezwykle ważna. Warto o tym wiedzieć wcześniej, niż później.

Środowiska wykorzystywane w GTM

Środowiska to z kolei funkcja, która idealnie odnajduje się w organizacjach, które chcą zyskać podgląd do wszelkich zmian w ramach kontenerach, zanim zdecydują się na ich publikację w docelowym środowisku (tzw. produkcyjnym).
Z uwagi na powyższe, głównym obszarem ich zastosowania są tzw. środowiska projektowe (testowe).

Podgląd i debugowanie

W celu debugowania i zyskania dostępu do zmian, należy kliknąć przycisk w prawym górnym rogu narzędzia. Co ciekawe, możesz wybrać aż 2 sposoby na taki podgląd:

• podgląd na własnym komputerze,
• wysłanie linku do osoby, która ma zapoznać się ze zmianami.

Szczególnie świetna jest druga z opcji. Możesz ją wykorzystać nie tylko do weryfikacji wprowadzonych zmian przez IT (lub kolegę z zespołu), ale również wykorzystać do sprawdzenia działania całego wdrożenia (np. na innej przeglądarce).

Tryb zgody – Consent Mode w Google Tag Manager

A co w przypadku kwestii prywatności? Czy GTM jest w stanie pomóc w lepszym zarządzaniu zgodami użytkownika? Odpowiedź brzmi: jak najbardziej.

W ustawieniach kontenera czeka na Ciebie dodatkowa opcja, której włączenie zapewnia wgląd w ustawienia uzyskiwania zgody w przypadku tagów w kontenerze.

Ustawienia kontenerów w GTM.

Po włączeniu tej funkcji, gdy przeniesiesz się na zakładkę Tagi i klikniesz ikonę Tarczy (znajduje się przy lupce), przeniesiesz się do przeglądu tagów:

Ustawienia tagów w GTM.

Dzięki odpowiednim ustawieniom tagów, zyskasz pewność, że Twoja witryna pozostaje w zgodzie z najnowszymi zasadami dotyczącymi prywatności w sieci, a tym samym – zmniejszysz utratę danych w momencie niewyrażenia przez użytkownika zgody.

Google Tag Manager – podsumowanie

Ufff. Ten wpis był naprawdę długi, jednak mam nadzieję, że udało Ci się dotrwać do końca i po przeczytaniu upewnisz się, że wdrożenie Google Tag Managera w Twoim serwisie to doskonały pomysł.

Osobiście gorąco polecam Google Tag Managera, ponieważ daje on naprawdę niesamowite możliwości, a korzyści, o których wspominałem na początku, poczujesz bez względu na to, czy w Twoim serwisie znajdują się obecnie 2, czy też 22 tagi. Dodatkowo teraz, w momencie coraz większego nacisku kładzionego na zbieranie danych zgodnie z intencją użytkownika, GTM pozwala także zmniejszyć utratę danych.
A Co Ty sądzisz o Google Tag Managerze? Często z niego korzystasz? Co sprawia Ci największą trudność w konfiguracji? Zapraszam do komentowania i dzielenia się spostrzeżeniami!

A tak na marginesie…
Jeśli uważasz, że wiedza zawarta w tym artykule jest wartościowa, a temat Google Tag Manager Cię zainteresował – koniecznie sprawdź te wpisy na blogu, które są związane z GTMem. Jestem pewny, że informacje zawarte w artykule o zmiennych niestandardowych oraz event tracking z pewnością Ci się spodobają!

The post Google Tag Manager – co to jest i do czego służy GTM? first appeared on Conversion.

Jest to obrazek skrajnie przerysowany, ale pozwala zrobić dobry wstęp do tematu, który chciałbym dzisiaj poruszyć. Mam na myśli problem jakości danych na których opieramy swoje decyzje. Wszystkie analizy, wszystkie raporty, wszystkie wnioski i wszystkie rekomendacje możemy wyrzucić do kosza jeżeli nie jesteśmy pewni danych na jakich je oparliśmy.

Dlaczego? Bazując na danych złej jakości (czyli takich, które słabo opisują rzeczywistość), przeprowadzamy bezwartościowe analizy z których wyciągamy kiepskie wnioski i tak dalej i tak dalej – problem z każdym kolejnym krokiem tylko się potęguje.

Jak więc zapewnić sobie dane, którym będziemy mogli zaufać? Kluczową rolę w całym procesie ciągłego utrzymania wysokiej jakości danych pełni poprawna instalacja i konfiguracja Twojego narzędzia analitycznego.

Pracując wielokrotnie nad wdrożeniami nowych instalacji, oraz modyfikując zastane konfiguracje narzędzi analitycznych, nasz zespół wypracował sobie coś w rodzaju listy kontrolnej, której wypełnienie daje dużą szansę na to, że będziemy zbierali dane najwyższej możliwej jakości. Przedstawię kilka najważniejszych zagadnień, których rozpatrzenie zagwarantuje to że do twojego Google Analytics będą spływały dane, które dobrze odwzorowują rzeczywistość.

Poniżej zebrałem, w formie krótkiej listy, elementy na które warto zwrócić uwagę aby zapewnić sobie dane dobrej jakości. W większości z tych punktów znajdą się informacje, które były już poruszane na naszym blogu, więc jeżeli chcecie dowiedzieć się na dany temat więcej to zachęcam do skorzystania z naszej wyszukiwarki.

#1 First things first

Sprawdź czy w swojej strukturze konta Google Analytics posiadasz przynajmniej trzy podstawowe widoki:

• Główny, czyli podstawowy widok, który służy Ci do przeprowadzania analiz.

• Bez filtrów, czyli widok, w którym gromadzisz niefiltrowane dane. To taka polisa ubezpieczeniowa na wypadek, gdyby stało się coś co w pozostałych widokach wpłynęłoby znacząco na jakość raportowanych danych.

• Testowy, czyli poligon, na którym można bez obaw bawić się filtrami, o których inni nie śnili nawet w najbardziej odważnych snach. Zanim wprowadzisz jakiś filtr do widoku „głównego”, przetestuj go najpierw na widoku „testowym”, bo danych utraconych w wyniku działania filtra nie da się już odzyskać.

Taka konfiguracja „minimum” zapewni Ci przejrzystość, oraz kontrolę nad tym co dzieje się w Twoim Analytics’ie. Jeżeli nie masz uzasadnionej potrzeby posiadania większej liczby widoków – zrezygnuj z nich.

#2 Podstawowe błędy

Google Analytics nie jest oprogramowaniem, które dostarczane jest w eleganckim pudełku wraz załączoną instrukcją instalacji i obsługi. Podyktowane jest to faktem, że praktycznie każda nowa instalacja jest unikalna i wyjątkowa. Tyle ile witryn w internecie, tyle różnych potrzeb na ich śledzenie. Proces instalacyjny musi być złożony, aby dać użytkownikowi pełną swobodę w sposobie konfiguracji swojego narzędzia.

Ze względu na to, że występuje tu czynnik ludzki istnieje też ryzyko popełnienia szeregu błędów już na etapie jego instalacji i konfiguracji. Można wyróżnić kilka typowych błędów, które łatwo popełnić, a które mogą negatywnie wpłynąć na jakość naszych danych. Do najczęstszych należą m. in.:

• Stosowanie parametrów UTM do tagowania wewnętrznych kampanii marketingowych w ramach serwisu. Jak już pisaliśmy na naszym blogu wielokrotnie: Wewnętrznych kampanii nie tagujemy parametrami UTM. Zmieniają one źródło i medium dla danego użytkownika, przez co tracimy cenną informację w jaki sposób go pozyskaliśmy.

• Zdarzenia na przeładowanie strony. Często próbujemy wysłać zdarzenie po kliknięciu w element, który jest hiperłączem do innej strony. Efekt może być taki, że owo zdarzenie nie zdąży się wysłać, przez co stracimy cenną informację. Warto stosować tzw. hitCallback – o czym też już pisaliśmy.

• Zdarzenia non-interaction, a właściwie brak wykorzystania opcji „non-interaction”. Kolejna pułapka na osoby korzystające ze zdarzeń. Czasem od razu po wejściu na daną stronę pojawia się pop-up, którego wyświetlenie jest rejestrowane w Google Analytics za pomocą zdarzenia. W takim scenariuszu współczynnik odrzuceń poleci na łeb, na szyję i będzie to efekt sztuczny, bo użytkownik nie wykonał przecież żadnej akcji, a Google Analytics „pomyśli”, że tak się właśnie stało.

#3 Bezpieczniki

W jednym z moich poprzednich wpisów poruszyłem już ten temat. Bezpieczniki – czyli automatyczne funkcjonalności, które mogą zwolnic nas z nieustannego „manualnego” monitorowania naszych danych. Jednym z takich bezpieczników są tzw. alerty. Alert działa jak czujka przeciwpożarowa, uruchamia się gdy wykryje anomalię w spływających do Analytics’a danych. Sami możemy ustalić na zmiany wartości jakich metryk ma reagować nasz alert i jak czuły powinien być. Polecam samodzielne skonfigurowanie grupy alertów, przynajmniej tych reagujących na zmiany w kluczowych dla nas metrykach.

Kolejnym z narzędzi, które wspomaga nas w monitorowaniu poprawności zbieranych danych są dashboardy, czyli modyfikowalne karty na których możemy umieszczać rozmaite informacje. W jednym widoku możemy widzieć demografię naszych użytkowników, liczbę odsłon z podziałem na grupy stron itd. Zarówno dashboardy jak i alerty mogą być wysyłane na naszą skrzynkę e-mailową, co dodatkowo ułatwia ich doglądanie.

#4 Śledzenie wszystkiego

Im więcej elementów na naszej stronie będziemy śledzili, tym uzyskamy pełniejszy obraz zachowania się użytkowników w jej obrębie. Dlatego warto zapoznać się z wirtualnymi odsłonami i zdarzeniami.

Współczesne strony internetowe mało mają już wspólnego z rozbudowanymi folderami zawierającymi dziesiątki, lub setki plików z rozszerzeniem *.html. Zamiast tego mamy strony, których zawartość zmienia się dynamicznie, osadzane są na nich całe aplikacje, a wzrok przykuwają efektowne elementy wizualne.

Aby zapewnić sobie pełne śledzenie naszej witryny i wycisnąć maksimum informacji o zachowaniu użytkowników w jej obrębie warto zainteresować się wykorzystaniem wirtualnych odsłon i zdarzeń. Zastosowań tych elementów jest naprawdę dużo, od raportowania wyświetleń toplayerów po czas w którym użytkownik zatrzymał odtwarzanie osadzonego filmu z Youtube.

#5 Rozszerzony e-commerce

Już od dłuższego czasu Google Analytics umożliwia wykorzystanie modułu rozszerzonego e-commerce. Do tej pory, stosunkowo niewiele firm zdecydowało się wykorzystać pełen potencjał tej funkcjonalności – a szkoda, bo możliwości jakie stwarza są ogromne. Dzięki skonfigurowaniu tzw. „enhanced e-commerce” możemy mierzyć liczbę wyświetleń poszczególnych produktów np. na stronach kategorii, wraz z nazwą listy na której produkt był prezentowany, oraz z numerem pozycji na której się znalazł. Dodatkowo w raportach pojawiają się informacje o kliknięciach w poszczególne produkty i wiele, wiele innych. Więc jeżeli chcesz mieć maksymalnie pełne dane o sposobie w jaki użytkownicy dokonują zakupów na Twojej stronie, to wdrożenie rozszerzonego e-commerce powinno stać się Twoim priorytetem.

To tylko kilka z dłuższej listy elementów, na które warto zwrócić uwagę jeżeli chcecie mieć dobrą instalację Google Analytics. Jeżeli macie jakieś przemyślenia, o które moglibyśmy rozbudować nasza listę to nie mogę się doczekać aby przeczytać o nich w komentarzach.

Jeśli potrzebujesz audytu konfiguracji narzędzi analitycznych (Google Analytics, AT Internet, Adobe Analytics czy Webtrends) lub chcesz rozwijać analitykę internetową wewnątrz organizacji skontaktuj się z Conversion by poznać nasze podejście. Więcej o analityce internetowej dowiesz się pobierając przygotowane przez nas bezpłatne poradniki, raporty oraz case studies.

The post 5 rzeczy, które musisz sprawdzić aby zbierać dobre dane w Twoim Google Analytics first appeared on Conversion.

Na stronie znajdowało się prawie 80 zdarzeń, zarówno zapisanych inline-owo w kodzie:

_gaq.push(['_trackEvent', 'Kategoria', 'Akcja', 'Etykieta', 'Wartość', true])

jak i wywoływanych np. po kliknięciu:

<a href="#" onClick="_gaq.push(['_trackEvent', 'Kategoria', 'Akcja', 'Etykieta', 'Wartość',true]);">Event</a>

Zdarzenia były wykorzystywane np. do przekazywania zmiennej niestandardowej z informacją na temat statusu logowania użytkownika. Przeniesienie wszystkich kodów z Klasycznego Analytics (ga.js) zajęłoby bardzo dużo czasu zespołowi IT, który w tym momencie nie miał dostępnych wystarczająco dużych zasobów. Wszelkie opóźnienia w procesie migracji spowodowałyby sytuację, w której zdarzenia nie byłyby raportowane do Google Analytics, czyli brakowałoby pełnych danych do analizy.

Aby nowo wdrożony Google Tag Manager mógł rejestrować zdarzenia powinny być one przekazane do warstwy danych (dataLayer), np. za pomocą dataLayer.push, czyli wyglądać w następujący sposób:

dataLayer.push({'event': 'GAEvent', 'EventCategory': 'Kategoria‘, 'EventAction': 'Akcja', 'EventLabel': 'Etykieta', 'EventValue': 'Wartość', 'EventInteraction': 'true, false lub jak nie ma to puste'});

Analogiczna sytuacja pojawiła się w przypadku wirtualnych odsłon oraz zmiennych niestandardowych, zapisanych za pomocą kodów klasycznego Analytics (ga.js):

1. 1. Wirtualne odsłony:

 _gaq.push(['_trackPageview', '/wirtualna_odsłona.html']);

1. 1. Zmienne niestandardowe:

_gaq.push(['_setCustomVar',1,'Zalogowany','Tak',2]);

które powinny być przekazane do warstwy danych (dataLayer), w postaci:

• Wirtualne odsłony:

dataLayer.push({'event': 'GAPageview', 'pageview': 'przekazywana odsłona np. /wirtualna_odsłona.html' });

• Zmienne niestandardowe:

dataLayer.push({'event': 'GAEventCustomVar', 'CustomVarIndex': , 'CustomVarName': '', 'CustomVarValue': '', 'CustomVarScope': });

Dodatkowo należało uwzględnić przypadek, w którym jednocześnie wywołuje się zdarzenie oraz wirtualna odsłona, czyli:

 _gaq.push(['_trackEvent','Kategoria','Akcja','Etykieta', 'Wartość'],['_trackPageview', '/wirtualna_odsłona.html']);

Aby uniknąć kosztownego i czasochłonnego przepisywania wszystkich zdarzeń, wirtualnych odsłon oraz zmiennych niestandardowych z kodów ga.js na kody Universal Analytics zdecydowaliśmy się znaleźć inne rozwiązanie, które w szybki sposób umożliwi migrację zdarzeń zakodowanych w ga.js do Universal Analytics.

Rozwiązanie – skrypt migrujący zdarzenia zakodowane w klasycznym Analytics (ga.js) do Universal Analytics (analytics.js)

Skutecznym rozwiązaniem okazało się stworzenie skryptu JS, który automatycznie przeniesie zdarzenia zakodowane w klasycznym Analytics do Universal Analytics. Skrypt po umieszczeniu na stronie przechwytuje zdarzenia, wirtualne odsłony oraz zmienne niestandardowe zapisane za pomocą kodów klasycznego Analytics (ga.js) a następnie przekazuje je do warstwy danych (dataLayer). Za pomocą odpowiednio skonfigurowanych tagów zdarzenia zostaną przekazane do Google Tag Managera.

Poniżej skrypt:

var _gaq =[];
var dataLayer = [];

_gaq.push = function (){
	for (var i = 0; i < arguments.length; ++i) {
		DataLayerProcessor.triggerEvent.apply(null, arguments[i])
	}
    return Array.prototype.push.apply(this,arguments);
}

var DataLayerProcessor = {
	triggerEvent: function() {
		switch (arguments[0]) {
			case "_trackEvent":
				DataLayerProcessor.sendTrackEvent.apply(null, arguments)
				break;
			case "_trackPageview":
				DataLayerProcessor.sendPageView.apply(null, arguments)
				break;
			case "_setCustomVar":
				DataLayerProcessor.sendCustomVar.apply(null, arguments)
				break;
		}		
	},

	sendTrackEvent: function() {
		dataLayer.push({
	         'event' : 'GAEvent',
	         'EventCategory' : arguments[1],
	         'EventAction' : arguments[2],
	         'EventLabel' : arguments[3],
	         'EventValue' : arguments[4],
	         'EventInteraction' : arguments[5]
	     })
	},
	sendPageView: function(){
		dataLayer.push({
	         'event' : 'GAPageview',
	         'pageview' : arguments[1]
	     })
	},
	sendCustomVar: function(){
		dataLayer.push({
	         'event' : 'GAEventCustomVar',
	         'CustomVarIndex' : arguments[1],
	         'CustomVarName' : arguments[2],
	         'CustomVarValue' : arguments[3],
	         'CustomVarScope' : arguments[4],
	     })
	}

}

Wdrożenie skryptu oraz konfiguracja tagów Google Tag Managera:

1. 1. Kod należy umieścić na każdej stronie przed kontenerem GTM np. w części Head. Warto umieścić kod jak najwyżej w strukturze strony, ponieważ jeśli jakieś zdarzenia wywołają się przed nim to nie zostaną one przekazane.
   2. Ze strony koniecznie należy usunąć stary kod śledzący (kod który wczytuje ga.js), żeby całość działała poprawnie.
   3. W Google Tag Manager należy skonfigurować 3 tagi, które będą odpowiedzialne za odbiór zdarzeń, wirtualnych odsłon oraz zmiennych niestandardowych:

1. 1. W tagu dla zdarzeń, należy wybrać rodzaj śledzenia: Zdarzenie, a parametry przekazać za pomocą makr:

a. Śledzenie:

b. Typ makra, należy ustawić jako zmienną warstwy danych, dla EventCategory, EventAction, EventLabel oraz EventValue:

c. Reguła, która umożliwi wywołanie tagu w odpowiednim momencie:

1. Ustawienie tagu dla wirtualnych odsłon oraz zmiennych niestandardowych: analogicznie konfigurujemy tagi dla wirtualnych odsłon oraz zmiennych niestandardowych.

Wcześniej czy później każda strona stanie przed koniecznością migracji z klasycznego kodu Google Analytics na Universal Analytics. W zależności o liczby śledzonych elementów za pomocą zdarzeń, wirtualnych odsłon czy zmiennych niestandardowych, migracja może być mniej lub bardziej czasochłonna.

Przedstawiony w powyższym artykule skrypt jest rozwiązaniem, które umożliwia szybkie przeniesienie zdarzeń, wirtualnych odsłon oraz zmiennych niestandardowych zakodowanych w klasycznym Analytics (ga.js) do Universal Analytics (analytics.js).

Zaprezentowane rozwiązanie nie powinno być rozwiązaniem docelowym, tylko tymczasowym. Zastosowanie skryptu umożliwiło nam zachowanie ciągłości i poprawności zbieranych danych w okresie od migracji aż do momentu kiedy zespół IT przeniesie całą instalację na Universal Analytics.

The post Migracja zdarzeń zakodowanych w klasycznym Analytics (ga.js) do Universal Analytics (analytics.js) first appeared on Conversion.

Przeprowadzając audyty Google Analytics u naszych Klientów, często zauważamy, że skupiają się oni głównie na rozbudowywaniu instalacji i wykorzystywaniu nowych funkcjonalności. Zdarza się, że dbanie o poprawność gromadzonych danych schodzi na drugi plan.

To duży błąd: pełne i rzetelne dane są podstawą dobrych analiz. Mówiąc bez ogródek: jeżeli masz robić analizy na postawie niepoprawnych danych, lepiej nie rób ich w ogóle.

Najczęściej popełniane błędy

W raporcie Conversion przeanalizowaliśmy kilkanaście błędów w instalacji narzędzi analitycznych. Pod lupę wzięliśmy tylko te błędy, które można sprawdzić, analizując kod źródłowy strony i żądania, które były przetwarzane na każdej stronie.

Z tego artykułu dowiecie się jak identyfikować, poprawiać i jak unikach najczęstszych błędów w instalacji Google Analytics.

Podwójne zapytanie do Google Analytics, które obniża współczynnik odrzuceń

Jeżeli zauważysz, że współczynnik odrzuceń na Twojej witrynie jest wyjątkowo niski, powinieneś nabrać podejrzeń.

Być może Twoja witryna faktycznie tak angażuje użytkowników, że masowo przechodzą oni na kolejne strony. Jednak gdy współczynnik odrzuceń w Twoim serwisie jest niższy niż 20% o wiele bardziej prawdopodobne jest, że dane zbierane są niepoprawnie.

Jeżeli użytkownik wejdzie do naszego serwisu i nie przejdzie na kolejną stronę w Google Analytics zlicza to jako odrzucenie. Jednak w przypadku, gdy na stronie podjęta zostanie jakaś akcja (która np. wywoła się zdarzenie) współczynnik odrzuceń nie jest zliczany.

W wielu serwisach przejście na poszczególne zakładki nie powoduje przeładowania się strony, i to jak użytkownicy poruszają się w tym obrębie śledzone jest za pomocą zdarzeń lub wirtualnych odsłon.

Jeżeli stroną wejścia jest karta produktu z zakładką, event o tym, że użytkownik jest w danej zakładce może zostać automatycznie wysłany do Google Analytics zaraz po wejściu na stronę. Wówczas współczynnik odrzuceń nie zlicza się, nawet jeżeli użytkownik spędził na stronie 5 sekund i natychmiast ją opuścił.

Taki błąd popełnia LeroyMerlin.pl. Gdy weszłam na serwis (stroną wejścia była karta produktu) od razu wywołał się event o nazwie Karta produktu – zakładki i etykiecie szczegóły. Mimo, że wyszłam ze strony po kilku sekundach, na koncie Google Analytics LeroyMerlin.pl moja wizyta nie została zliczona jaka odrzucenie.

W rezultacie analitycy i Zarząd zachwycają się niskim współczynnikiem odrzuceń na podstawie raportów, które mają niewiele wspólnego z rzeczywistością.

Rozwiązaniem jest stosowanie eventów non-interaction. Zdarzenia non-interaction nie wpływają na zliczanie współczynnika odrzuceń. Ustawienie zdarzeń non-interaction wymaga dodania jednego parametru w kodzie zdarzenia:

_gaq.push(['category', 'action', 'label', value, true]);

W przypadku śledzenia zdarzeń za pomocą Google Tag Managera sprawa jest jeszcze prostsza: ustawiając zdarzenie wybieramy Prawda dla opcji Niewymagające interakcji.

Aż 20% serwisów popełnia ten błąd i niepoprawnie zlicza współczynnik odrzuceń.

Zdarzenia na przeładowanie

To częsty błąd; wg raportu aż 18% serwisów niepoprawnie śledzi niektóre zdarzenia.

Z tym błędem mamy do czynienia, jeżeli ustawimy zdarzenie na element, który przenosi nas na kolejną stronę. Na przykład, jeżeli dzięki zdarzeniom chcemy dowiedzieć się w jaki sposób użytkownicy opuszczają naszą stronę i śledzimy linki wychodzące.

Jednak jeżeli za pomocą zdarzeń śledzimy akcje powodujące przejście do kolejnej strony, nie możemy być pewni poprawności zbieranych danych.

Wysyłanie zdarzenia tuż przed załadowaniem innej strony rodzi bardzo duże zagrożenie, że hit z informacjami do Google Analytics po prostu nie dotrze, ponieważ kolejna strona wczyta się szybciej, zanim przeglądarka odbierze potwierdzenie odebrania przez Google Analytics wysłanego żądania.

W takiej sytuacji możemy wykorzystać funkcję hitCallback. To rozwiązanie dla zaawansowanych użytkowników. Jak wykorzystać hitCallback przeczytacie w poście Mariusza.

W przypadku, gdy śledzimy przejścia na inne strony w obrębie naszego serwisu, sytuacja jest o tyle prostsza, że możemy ustawić zdarzenie na kolejnej stronie. Na przykład, gdy chcemy sprawdzić który link użytkownicy klikają najczęściej.

Ustawienie takich zdarzeń również nie należy do najłatwiejszych. W tym przypadku można także skorzystać z funkcji hitCallback. Nie jest to jednak idealne rozwiązanie (szczególnie gdy chcielibyśmy oprzeć o to całą nawigację). HitCallBack „czeka” bowiem aż Google Analytics prześle informacje, co może spowolnić ładowanie się strony.

Obie metody są dosyć skomplikowane. Dlatego w ostateczności możemy wykorzystywać błędny sposób ze świadomością, że dane są nierzetelne – jednak obarczone takim samym błędem. Na ich podstawie nie możemy wygenerować dokładnych raportów ilu użytkowników kliknęło w dany element. Ale możemy porównać skuteczność poszczególnych elementów (jaki procent użytkowników klika częściej w jeden albo drugi element).

Błędy w ustawieniach domen dla ciasteczek

Jeżeli posiadamy subdomeny w obrębie jednego serwisu ten błąd może skutkować utratą ciągłości śledzenia. Automatyczne ustawienia Google Analytics nie pozwalają narzędziu na rozpoznawanie subdomen. To oznacza, że dla każdej subdomeny będzie tworzony osobny pakiet ciasteczek.

Załóżmy, że posiadasz sklep internetowy ze sprzętem fotograficznym. Dodatkowo prowadzisz bloga, na którym udzielasz porad dotyczących wyboru sprzętu i robienia zdjęć. Twój sklep ma adres sklep.fotografia.pl, a blog: blog.fotografia.pl. Na pewno chciałbyś śledzić zachowanie użytkowników nie tylko w obrębie tych dwóch subdomen, ale także to jak przechodzą pomiędzy tymi stronami – np. jak dużo ruchu do sklepu sprowadzają kampanie na blogu.

Każda z dwóch subdomen nada użytkownikom nowy zestaw ciasteczek. I tak w przypadku, gdy użytkownik trafi do Twojego serwisu z bloga, na koncie sklepu będzie traktowany jak każdy inny użytkownik z serwisów zewnętrznych, takich jak wp.pl.

Aby uniknąć takiej sytuacji powinnyśmy zmienić ustawienia Google Analytics. Wykorzystujemy do tego metodę _setDomainName(), w której ustawiamy domenę, która jest właścicielem ciasteczek. W ten sposób w Google Analytics przepływ użytkownika pomiędzy domenami zobaczymy w jednym raporcie jako jednego i tego samego użytkownika.

Podobny problem może stworzyć posiadanie dwóch kodów śledzących w obrębie jednego serwisu. Wówczas ciasteczka tworzone przez jedno konto mogą nadpisywać drugie. Tutaj konieczne jest ustawienie _setDomainName:

var _gaq = _gaq || [];
_gaq.push(['_setAccount','UA-xxxxxxxx-a']);
_gaq.push(['_setDomainName','xyz.pl']);
_gaq.push(['_trackPageview'];
_gaq.push(['zbiorcze._setAccount','UA-yyyyyyy-1']);
_gaq.push(['zbiorcze._setDomainName','xyz.pl']);
_gaq.push(['zbiorcze._trackPageview'];

W najnowszej wersji kodu śledzącego, Universal Analytics, śledzenie subdomen jest ułatwione i wystarczy ustawić śledzenie automatyczne dla domen.

UTM w kampaniach wewnętrznych

Częstym błędem jest wykorzystywanie parametrów UTM w kampaniach wewnętrznych. To błąd, który wpływa negatywnie na rzetelność gromadzonych danych.

Parametry UTM (źródło, medium, nazwa kampanii, słowo kluczowe i zawartość) służą do oznaczania tylko kampanii zewnętrznych – dzięki nim dane zebrane w Google Analytics są łatwe do analizy i możemy skutecznie porównywać je w czasie.

Dlaczego nie powinniśmy oznaczać parametrami UTM kampanii wewnętrznych?

Załóżmy, że użytkownik trafił na stronę główną z newslettera. W momencie, kiedy kliknie w baner przenoszący go na kartę produktu parametry UTM nadpiszą właściwie źródło z którego użytkownik trafił do naszego serwisu. Nie mamy później możliwości śledzić go jako użytkownika z newslettera, a dodatkowo odwiedziny zostaną naliczone jako podwójne (wejście z newslettera i wejście z kampanii wewnętrznej)

BZWBK niepoprawnie śledzi kampanie wewnętrzne. Do serwisu trafiłam z kampanii CPC, następnie ze strony głównej przeszłam na stronę docelową Kredytu Gotówkowego. Do adresu URL dodany został parametr utm_source=bzwbk_slider. Tym samy na koncie Google Analytics nie odnotuje się moja ścieżka: CPC – Slider na stronie głównej.

Google Analytics domyślnie przypisuje konwersję do ostatniego źródła. W przypadku nadpisania źródła parametrami UTM nie uzyskujemy informacji z jakich płatnych kampanii zewnętrznych trafił do nas użytkownik. A tym samym nie wiemy tego co dla nas najważniejsze – jak efektywnie działają nasze płatne kampanie.

Wśród serwisów e-commerce 7,5% niepoprawnie śledzi swoje kampanie. Najgorzej wypada sekcja serwisów leadowych – 15% serwisów używa parametrów UTM do śledzenia kampanii wewnętrznych.

Jak poprawnie tagować kampanie wewnętrzne?

Jest kilka możliwości. Można wykorzystać parametry miejsce i nazwa kampanii lub modelu wyszukiwania w witrynie.

Serwis Frisco.pl odpowiednio śledzi kampanie wewnętrzne wykorzystując parametry miejsce (serwis-1-1) oraz nazwa kampanii.

Kolejnym rozwiązaniem jest wykorzystanie śledzenia zdarzeń (kliknięcie w kampanie odnotowujemy jako zdarzenie. Tutaj trzeba uważać na poprzedni błąd – zdarzenia na przeładowanie, i ustawić wywołanie eventu po przejściu użytkownika na kolejną stronę.

Monitorowanie kampanii wewnętrznych umożliwia także moduł ulepszony e-commerce.

Niepoprawne śledzenie transakcji

Aż 45% przebadanych serwisów e-commerce popełnia co najmniej jeden błąd w śledzeniu transakcji. To bardzo częsty problem.

W 20% serwisy rejestrują transakcje po jej opłaceniu na stronie podziękowania.

Zanim rozpoczniemy pracę z Klientem przeprowadzamy audyt i porównujemy dane dotyczące transakcji z danymi z CRM. Jeżeli rozbieżność to 10%-15% zakładamy, że dane zbierają się prawidłowo.

W przypadku większych rozbieżności zakładamy, że dane są niepoprawnie raportowane do Google Analytics. Aby to sprawdzić analizujemy i porównujemy dane w segmentach: jak wygląda pokrycie transakcji za przedpłatą a jak gdy użytkownik płaci za pobraniem.

Zwykle okazuje się, że często użytkownicy po przeniesieniu do zewnętrznego systemu płatności nie wracają na stronę podziękowania, na której umieszczony jest kod transakcji. Takie zakupy w ogóle nie są rejestrowane.

Rozwiązaniem jest umieszczenie kodu śledzącego przed przekierowaniem do zewnętrznego serwisu płatności. Należy pamiętać aby umieścić go na splash page: stronie przejściowej, która wyświetla się przez kilka sekund. To pozwoli zapewnić, że dane zostaną przesłane do Google Analytics. Co prawda zdarza się, że użytkownicy po przejściu ostatecznie nie dokonują zakupu, jednak dotyczy to niewielkiej liczby użytkowników.

Poprawnie transakcje śledzi sklep Merlin.pl – zanim użytkownik zostanie przekierowany na stronę płatności PayPal kod transakcji może się wywołać na splash page

Z kolei ci, którzy dokonali płatności, bardzo często nie wracają już do sklepu (znikomy procent użytkowników powraca na stronę podziękowania). Dane zebrane w ten sposób są nierzetelne.

Kolejną przyczyną rozbieżności w danych transakcyjnych między Google Analytics a CRM jest podwójne wywoływanie kodu transakcji na stronie podziękowania. Może to się zdarzyć w kilku przypadkach: gdy użytkownik powróci na stronę podziękowania, odświeży ją albo przejdzie z linku w e-mailu, który otrzyma po zakończeniu transakcji.

To czy kod transakcji wywołuje się poprawnie możemy szybko sprawdzić na naszym koncie Google Analytics.

W sekcji Konwersje – Transakcje sprawdzamy jaka jest liczba ID transakcji. W tym przypadku widzimy, że raport ma 1141 rzędów i takiej liczbie transakcji zostało nadane ID.

W sekcji Ogólem widzimy ile transakcji zliczył Google Analytics. 1146, czyli 5 transakcji zostało wywołanych podwójnie. Jako, że Google Analytics wykorzystuje te dane to wszystkich innych raportów i metryk (takich jak współczynnik konwersji), mamy nieprawdziwy obraz i zbieramy nierzetelne dane.

Rozwiązaniem jest zapewnienie, że kod wywołuje się tylko raz dla danej transakcji. Możemy to ustawić po stronie serwera lub stworzyć ciasteczko u użytkownika.
Rzetelne dane to podstawa dobrych analiz. Mam nadzieję, że sprawdzając krok po kroku swoją konfigurację Google Analytics zidentyfikujecie obszary, w których dane gromadzone są niepoprawnie, i uda Wam się je naprawić.

Nie traćcie czasu – pora na audyt Waszej instalacji Google Analytics.

Aby dowiedzieć się jeszcze więcej pobierzcie bezpłatnie swoją kopię Raportu Conversion Wykorzystanie narzędzi analityki internetowej w Polsce.

Jeśli potrzebujesz audytu konfiguracji narzędzi analitycznych (Google Analytics, AT Internet, Adobe Analytics czy Webtrends) lub chcesz rozwijać analitykę internetową wewnątrz organizacji skontaktuj się z Conversion by poznać nasze podejście. Więcej o analityce internetowej dowiesz się pobierając przygotowane przez nas bezpłatne poradniki, raporty oraz case studies.

The post Zadbaj o poprawne dane. 5 błędów w instalacji Google Analytics. first appeared on Conversion.

Narzędzie daje ogromne możliwości zaawansowanej konfiguracji. Tylko od nas zależy, czy nasze działania ograniczą się wyłącznie do generowania raportów o liczbie unikalnych użytkowników i oglądania sekcji „Na żywo”, czy użyjemy Google Analytics do przeprowadzania zaawansowanych analiz wykorzystując na przykład śledzenie zdarzeń czy segmentację.

Dowodem na to, że Universal Analytics może stać się, dedykowanym, szytym na miarę narzędziem dla każdej organizacji, są wprowadzone ostatnio wymiary i dane niestandardowe.

To duży krok w stronę integracji danych: możemy zasilić nasze konto Analytics zewnętrznymi źródłami danych. Od informacji o autorze postów, przez dane na temat pogody po liczbę wypitych kaw w biurze. Następnie wykorzystać te dane chociażby przy analizach segmentów użytkowników.

Jak wykorzystywać niestandardowe wymiary i dane do wyciągania jeszcze lepszych wniosków? Przygotowaliśmy dla Was krótki przewodnik.

Na początku krótka uwaga: jeżeli nie dokonaliście migracji na UA, nic z tego. To funkcjonalność dostępna tylko w Universal Analytics.

Co to są wymiary i dane?

Google Analytics definiuje wymiary jako „opisowy atrybut lub charakterystyka obiektu”, a dane jako „poszczególne elementy wymiaru, które można przedstawiać jako sumę lub stosunek”.

Mówiąc po ludzku, wymiar to po prostu segment użytkowników (użytkownicy charakteryzujący się jakąś jedną wspólną cechą) obecny w Google Analytics najczęściej jako wiersz w raporcie, podczas gdy dane stanowią ilościowy opis tego segmentu – w Google Analytics najczęściej przedstawiony w kolumnie. Wszystkie raporty w Google Analytics oparte są na połączeniu wymiarów i danych.

Mamy dostęp do 200 wymiarów i danych ustawionych domyślnie na naszym koncie Google Analytics. Ale nie musimy się do nich ograniczać.

Od niedawna mamy możliwość zasilenia naszego konta o nowe, przydatne konkretnie dla naszego biznesu dane. W tym przypadku można powiedzieć „sky is the limit”: jeżeli tylko wiemy, jak poprawnie skonfigurować niestandardowy wymiar bądź dane, możemy przesyłać właściwie wszystko, co przyjdzie nam do głowy.

Czym różnią się niestandardowe wymiary i dane od zmiennych niestandardowych?

Można powiedzieć, że to już było – podobne możliwości dawały zmienne niestandardowe. To prawda – te funkcjonalności są bardzo podobne, i jeżeli jesteście specami od ustawiania zmiennych niestandardowych – bez problemu poradzicie sobie z niestandardowymi wymiarami.

Jest jednak kilka znaczących różnic.

Po pierwsze, możemy wprowadzić do 20 niestandardowych wymiarów i 20 niestandardowych danych. W przypadku zmiennych niestandardowych to ograniczenie było dużo większe (tylko 5).

Po drugie, niestandardowe wymiary i dane definiuje się w interfejsie – tam określa się ich nazwę, poziom oraz slot. W kodzie definiowane są tylko wartości dla wymiary. Tymczasem w przypadku zmiennych niestandardowych całość musi być zdefiniowana po stronie kodu.

Oznacza to, że niestandardowe wymiary i dane można skonfigurować z poziomu konta – nie trzeba dokonywać zmian w samym kodzie.

Jak ustawić na swoim koncie Google Analytics niestandardowe wymiary i metryki?

Ustawienie niestandardowych wymiarów i metryk nie powinno być dużym wyzwaniem. Należy pamiętać, że ta opcja dostępna jest tylko jeżeli przeprowadziliśmy migrację na Universal Analytics.

Pokażę Wam na przykładzie naszego bloga, jak krok po kroku skonfigurować niestandardowe wymiary i dane – w naszym przypadku jako wymiar wybraliśmy autora tekstu.

W panelu administratora na poziomie usługi wybieramy niestandardowe definicje. Następnie przechodzimy do niestandardowych wymiarów.

Następnie wybieramy „Dodaj niestandardowy wymiar, nadajemy mu nazwę oraz ustawiamy zakres. Jeżeli odznaczymy opcję „Aktywna” wymiar dalej będzie się pojawiać w raportach niestandardowych, jednak dane nie będą zbierane.

W przypadku wybrania opcji autor zakresem będzie Hit. Mamy do wyboru jeszcze użytkownika oraz sesję – o tym czym różnią się poszczególne zakresy napiszę w dalszej części artykułu.

W momencie, gdy stworzymy już niestandardowy wymiar pojawiają nam się kody, które należy umieścić na stronie. Wymiarowi nadawany jest indeks – w tym przypadku jest to wymiar1. W momencie kiedy zdefiniujemy „dimensionValue”, Analytics widząc podaną wartość prześle zawarte w niej dane do naszego konta. Aby skonfigurować wartość wymiaru „autor” wykorzystaliśmy (kod, który zaciąga dane o autorze w nagłówku posta).

Dane lądują na koncie Google Analytics jako indeks plus wartość.

Należy pamiętać, że dane przesyłane są do konta Google Analytics tylko w połączeniu z innymi hitami (działaniami), takimi jak zdarzenie, wirtualna odsłona czy transakcja. Dlatego kod umieszczamy pod głównym kodem śledzącym Google Analytics.

Teraz możemy analizować to jak popularny są posty poszczególnych autorów i na przykład stworzyć ranking najbardziej poczytnych autorów. Albo sprawdzić, które posty danego autora mają najwyższy średni czas spędzony na stronie.

Zakres produktu, sesji, użytkownika, hitu

Jak wcześniej pisałam, jeżeli jako niestandardowy wymiar ustawiamy autora, robimy to w zakresie hitu. To chyba najtrudniejszy to zrozumienia element całej konfiguracji. Ci, którzy ustawiali już zmienne niestandardowe nie powinni mieć z tym problemu.

Możemy definiować wymiary w zakresie

• Hitu
• Sesji
• Użytkownika
• Produktu

Zakres hitu

Jako hit określamy jednostkową porcję danych przesyłanych do Google Analytics. Może to być zdarzenie, wirtualna odsłona czy transakcja. Jeżeli zakresem będzie hit – do danego hitu dołączana będzie porcja danych zawierających numer indeksu i wartość danego wymiaru.

W jednej sesji użytkownik może przesyłać wiele hitów: poruszając się po serwisie generuje różne zdarzenia czy wirtualne odsłony. W tym zakresie informacja o niestandardowym wymiarze zostanie przekazana przy każdym hicie, który zdefiniujemy. Czyli jeden użytkownik może „wysłać” kilka wymiarów i danych niestandardowych do Google Analytics.

W przypadku autora artykułu: za każdym razem kiedy użytkownik wyświetli tekst danego autora, do hitu „wirtualna odsłona” dołączona zostanie porcja informacji o autorze – i tak podczas jeden wizyty użytkownik może wysłać kilka (kilkanaście, jeżeli jest zagorzałym czytelnikiem) hitów z tą wartością.

Zakres sesji

Sesja to najprościej mówiąc, zestaw hitów zgrupowanych razem dla jednej wizyty jednego użytkownika. Sesja trwa 30 minut od pierwszego hitu.

W przypadku ustawienia zakresu Sesji kolejne hity z inną wartością nadpisują wcześniejsze działania. Jeżeli wymiar Autor ustawilibyśmy na poziomie sesji, otrzymywalibyśmy informacje tylko na temat autora ostatniego posta, który użytkownik przeczytał w czasie trwania sesji.

Poziom sesji możemy wykorzystać na przykład do przesyłania danych na temat logowania. Nie ma znaczenia w którym momencie użytkownik zalogował się do serwisu – ważne, że zrobił to w czasie trwania sesji. Jeżeli tylko wykonał taką akcję, do konta Google Analytics przesyłana jest informacja „Zalogowany”. Wówczas przy analizie segmentów możemy ustawić wartość „zalogowani” i analizować jak tacy użytkownicy zachowują się na stronie.

Podobnie w przypadku informacji o pogodzie: możemy ustawić niestandardowy wymiar w zakresie sesji (raczej mało prawdopodobne, że pogoda zmieni się diametralnie w ciągu 30 minut).

Zakres użytkownika

Google Analytics za pomocą ciasteczek jest w stanie zidentyfikować pojedynczego użytkownika. Kiedy wchodzi on do serwisu, przypisane jest mu ID i jest rozpoznawalny jako konkretna osoba (a raczej konkretny zestaw danych) przez 2 lata (tyle żyje ciasteczko). Zbierane dane są grupowane: w efekcie możemy segmentować nie tylko sesje, ale prawdziwych użytkowników.

To dobre rozwiązanie dla informacji, które nie zmieniają się często (albo w ogóle). W zakresie użytkownika możemy zdefiniować na przykład płeć (jeżeli mamy takie dane np. w CRM) czy to, jaki rodzaj konta w naszym serwisie posiada dany użytkownik (na przykład konto classic lub premium itd.)

Zakres produktu

Wartość danych bądź wymiarów niestandardowych jest przypisana konkretnie do produktu – ta opcja dostępna jest tylko w ulepszonym ecommerce.

Jak raportować niestandardowe wymiary i metryki?

W klasycznym Google Analytics zmienne niestandardowe znajdowały się w sekcji Odbiorcy / Niestandardowe / Zmienne niestandardowe. W tym miejscu nie znajdziemy już wymiarów i danych niestandardowych. Są one traktowane jako „zwykłe” wymiary dodatkowe.

Możemy wykorzystać je w najprostszy sposób: dokładnie tak jak zwykły wymiar w raporcie.

Niestandardowe wymiary ustawiamy jako wymiar dodatkowy raportu na przykład przy analizie raportów Cały Ruch.

Niestandardowe wymiary możemy wykorzystywać do tworzenia segmentów, raportów niestandardowych i filtrów. Trzeba pamiętać, że niestandardowe wymiary i dane ustawiane są na poziomie usługi – dlatego też filtry możemy ustawić na poziomie widoku – nie możemy tego zrobić dla całego konta.

Przykład raportu niestandardowego na podstawie danych o autorach naszego bloga. Mamy ustawione zdarzenia o etykiecie: Do końca i Do połowy (zdarzenia na scrollowanie, które pokazują jak użytkownicy czytają teksty). Generujemy raport niestandardowy (tabelę kartotekową), w którym wymiarem jest autor, a następnie ustawiamy etykietę zdarzenia Do końca lub Do połowy. Tym samym możemy prześledzić jak czytane są teksty poszczególnych autorów

Jak wykorzystywać niestandardowe wymiary i dane w swoich analizach?

Możliwości jest nieskończenie wiele: wszystko zależy od charakterystyki naszego biznesu i kompetencji zespołu analityków.

Poniżej kilka przykładów, które mogą Was zainspirować do wykorzystania tej funkcjonalności na swoich kontach:

Śledzenie pogody

W serwisach ecommerce warto np. przekazywać do Google Analytics informacje o pogodzie — na pewno każdy z właścicieli sklepów internetowych zaobserwował, że w dni z gorszą pogodą sprzedaż rośnie (nie wspominając już o skrajnie zależnych od warunków atmosferycznych branżach jak np. sprzedaż opon).

Aby skonfigurować dane dotyczące pogody musimy określić szerokość i długość geograficzną naszego IP i na tej podstawie zaciągnąć dane z zewnętrznego API (np. http://openweathermap.org/). Wymiar niestandardowy ustawiamy w zakresie sesji.

Więcej informacji jak ustawić informacje pogodowe za pomocą Google Tag Managera znajdziecie na blogu Simo Ahavy.

Śledzenie sposobu płatności

Tak, oczywiście można śledzić jaki sposób płatności (kartę Visa, Mastercard, za pobraniem itd.) wybierają użytkownicy za pomocą zdarzeń. Ustawienie niestandardowego wymiaru pozwoli jednak na lepszą analizę zachowania: możemy wykorzystać te informacje do analizy segmentów i obserwować korelację pomiędzy liczbą produktów w koszyku czy średnią wartością zamówienia.

Przekazywanie informacji o marży

To bardzo ciekawa opcja dla ecommerce, szczególnie przy analizie kampanii marketingowych. Jeżeli chodzi o ROI – a to przecież chodzi – to ile zarabiamy na danym produkcie ma znaczenie, a nie tylko jego cena. I tę wartość także powinniśmy brać pod uwagę.

Załóżmy, że w sklepie internetowym z elektroniką telewizor kosztuje 3000 PLN. Marża to 2%, więc na zakupie tego produktu zarabiamy 90 PLN . Z kolei sokowirówka kosztuje 250 PLN a marża wynosi 15% – czyli zarabiamy 45 PLN.

Oczywiście są to dane wrażliwe – jest jednak kilka sposobów na przekazanie je tak, aby nie były widocznie w kodzie, np. za pomocą serwowania tych danych z serwera poza wizytą użytkownika.

Informacje na temat interakcji użytkowników z aplikacją

Bardzo dobry przykład wykorzystania niestandardowych wymiarów w poszczególnych zakresach znajdziecie na stronie Pomocy Google.

Krok po kroku przedstawiona jest konfiguracja zmiennych niestandardowych na przykładzie aplikacji do gier. W zakresie hitu możemy obserwować jak często użytkownicy grają na poszczególnych poziomach gry, na poziomie sesji możemy zebrać dane o interakcjach użytkowników w czasie 3-dniowej wersji próbnej. W zakresie użytkownika możemy porównywać zachowanie tych, którzy posiadają darmową i płatną wersję. Pokazane jest także wykorzystanie zakresu produktu: jakie doładowania wykupują użytkownicy aplikacji.

Niestandardowe wymiary i dane otwierają ogromne możliwości analizy, a także łączenia danych offline z online. Jeżeli jeszcze zastanawiacie się nad migracją na Universal Analytics – ta funkcjonalność powinna Was do tego przekonać.

Czy macie już swoje pomysły na niestandardowe wymiary i dane? Jeżeli tak, podzielcie się nimi w komentarzach.

The post Wymiary i dane niestandardowe: doładuj swoje konto Analytics first appeared on Conversion.

Chciałbyś, żeby wyglądał co najmniej jak Apple.com, ale boisz się pakować w redesign, który jak wiesz, może skończyć się w najlepszym wypadku jednorazowym wydatkiem dużych środków i przekroczeniami harmonogramu projektu. W najgorszym – odpływem lojalnych użytkowników i znacznymi spadkami konwersji.

Co w takim razie zrobić? Rozpocząć długi, żmudny i kosztowny projekt redesignu i stracić powracających użytkowników, czy pozostać przy starym serwisie, który nie przyciągnie już nowych Klientów?

Wyjście nr 1: redesign

Wg badań serwisy internetowe przechodzą redesign średnio raz na dwa lata. W 2013 aż 1/3 marketerów nie była zadowolona z przebiegu redesignu, a 38% firm nie poprawiło wyników po zmianie swojej witryny. (*dane z HubSpot). Można założyć, że te dane i tak są zaniżone – w końcu niewielu marketerów chce się przyznawać do błędu.

Scenariusz jest zwykle podobny: wielkie zmiany to wielkie projekty, które często kończą się przekroczonymi terminami i budżetami. Redesign wymaga współpracy kilku działów i firm zewnętrznych, wiąże się z dużymi nakładami finansowymi i oczekiwaniami, którym naprawdę ciężko sprostać.

Opowiem Wam historię pewnego sklepu internetowego. Wszystko rozpoczęło się od stwierdzenia, że witryna nie jest już konkurencyjna i definitywnie wymaga zmiany. Co można na to poradzić?

Przepis na sukces: redesign

Cel: nowa, piękna witryna ze współczynnikiem konwersji wyższym o 20%, w 6 miesięcy, za 65 tysięcy

Trzeba było tylko przygotować specyfikację techniczną i makiety, omówić je, stworzyć grafiki, omówić je, poprawić grafiki, przeprowadzić testy z użytkownikami, zakodować wersję deweloperską, ponowić testy z użytkownikami, wdrożyć na produkcję i znowu przetestować.

Efekt: 10 miesięcy, 100 tysięcy i … 17% spadku współczynnika konwersji.

Czy można to nazwać sukcesem?

Redesign najbardziej odbija się w segmencie powracających użytkowników. Każda większa zmiana spotyka się z oporem – w końcu to nie jest już serwis, który znali i lubili. Poruszanie się po serwisie zajmuje im więcej czasu, dlatego też częściej rezygnują z zakupów. Łatwo to zrozumieć: to sytuacja analogiczna do zakupów w zwykłym hipermarkecie. W „swoim” jesteś w stanie kupić wszystko w 20 minut – wiesz, gdzie znaleźć konkretne produkty. Gdy przychodzisz do zupełnie nowego zakupy zamieniają się w trwające godzinami poszukiwania i kręcenie się w kółko w poszukiwaniu puszki pomidorów.

Wielkie redesigny zazwyczaj kończą się lawiną krytyki. Każda zmiana układu Facebooka skutkuje założeniem kilkunastu protestujących grup.

Często nawet zmiana logo wywołuje niezadowolenie – tak było w przypadku marki GAP, która pod naciskiem Klientów powróciła do starego logotypu.

Na pewno pamiętacie jeszcze „starego” Filmweba. Z tym redesignem długo użytkownicy nie mogli się oswoić: był szeroko komentowany i krytykowany. Na pewno była w pewnym stopniu reklama serwisu. Jednak jako, że opiera się on głównie na powracających użytkownikach przedsięwzięcie można zaliczyć do ryzykownych.

Wyjście nr 2: serwis bez zmian

Drugim wyjściem jest pozostawienie serwisu bez zmian, nie inwestując ogromnej ilości czasu i pieniędzy na projekt redesignu.

Jednak nie ma żadnych wątpliwości, że tempo zmian w internecie jest ogromne, i kto przez dłuższy czas stoi w miejscu po prostu wypada z rynku. Mato szczególne znaczenie w przypadku sklepów internetowych: użytkownicy są świadomi nowych możliwości i funkcjonalności. Jeżeli cokolwiek utrudnia im poruszanie się po sklepie – bez mrugnięcia okiem wybierają bardziej użyteczną stronę konkurencji.

Stare strony nie pozyskują nowych użytkowników. Możesz wydawać krocie na kampanie marketingowe i masowo sprowadzać ruch: jeżeli Twój serwis nie zyska aprobaty użytkowników w przeciągu kilku sekund, możesz zapomnieć o wysokim współczynniku konwersji.

Serwis Aukcjoner.pl zdecydowanie nie przyciąga nowych użytkowników i odbiega od nowoczesnych standardów designu. Strona na pierwszy rzut oka wygląda jak sprzed kilku lat, i zdecydowanie nie buduje wizerunku nowoczesnej marki internetowej.

Trzecia droga: optymalizacja współczynnika konwersji

Na szczęście nie jesteśmy skazani na wybór pomiędzy trwaniem przy starym serwisie a rozpoczęciem kosztownego i ryzykownego projektu redesignu.

Alternatywą dla redesignu jest ciągła optymalizacja współczynnika konwersji. Zamiast wielkich zmian: dużo mniejszych, które popychają serwis do przodu, nie wprowadzając jednocześnie rewolucji dla użytkowników.

Dla przypomnienia, sam proces optymalizacji konwersji opiera się o planowe działania w celu zwiększenia współczynnika konwersji. Aby był alternatywą dla redesignu powinniśmy zadbać o wdrożenie czterech powtarzalnych etapów:

1. 1. Zebranie danych i ich analiza

Powtarzamy to jak mantrę: u podstaw optymalizacji konwersji leżą dane gromadzone za pomocą narzędzi śledzących i narzędzi do badań jakościowych. Tylko na ich podstawie powinniśmy podejmować decyzję na temat tworzenia hipotez zmian w serwisie. Aby proces wdrażania zmian przyniósł wymierne efekty, niezbędne są analizy, które pozwolą na identyfikację rzeczywistych problemów i obszarów wymagających usprawnienia.

Śledzenie za pomocą zdarzeń sortowania, filtrowania, powiększania zdjęć (z powodzeniem robi to Play) może pomóc wyłonić najpopularniejsze ścieżki zachowania użytkowników. Jeszcze więcej danych na ten temat mogą dostarczyć sami użytkownicy, np. w badaniu użyteczności. Na podstawie takich danych możemy wygenerować rekomendacje. Zmiana wyglądu list kategorii sortowania, filtrowania i zdjęć może znacząco poprawić użyteczność, a także unowocześnić wygląd serwisu.

1. 1. Stworzenie rekomendacji i priorytetyzacja

W oparciu o dane tworzymy szereg hipotez. W przypadku serwisów, które wymagają odświeżenia, takich rekomendacji może być nawet kilkadziesiąt. Dlatego kluczowa jest ich odpowiednia prioretyzacja.

Należy pamiętać, że naszym celem jest wdrażania niewielkich zmian, które mogą przynieść duże efekty. Dlatego rekomendacje szeregujemy na podstawie potencjalnego wzrostu współczynnika konwersji (a tym samym – możliwych do uzyskania korzyści finansowych). Dodatkowo warto oczywiście uwzględnić czasochłonność wdrożenia i koszt proponowanych zmian (z powodu godzinowych wycen pracy czynniki te są ze sobą zazwyczaj silnie powiązane), aby lepiej dostosować je do dostępnych w danej chwili zasobów.

Bezapelacyjnie lepsze jest testowanie mniej pracochłonnych elementów posiadających mniejsze przełożenie na wzrost przychodów, niż nietestowanie w ogóle z powodu np. braku wystarczającej dostępności programistów.

Dobrą praktyką jest ocenianie w dwóch wymiarach: potencjalny wpływ na współczynnik konwersji w skali 1-5 (gdzie 5 oznacza zmianę najlepiej rokującą) oraz czasochłonność i koszt wdrożenia w skali 1-5 (gdzie 5 oznacza element bardzo prosty do wdrożenia).

1. 1. Testy A/B

O samych testach A/B pisaliśmy już wielokrotnie (więcej informacji znajdziecie w artykule Test online: A/B czy wielowymiarowe?).

Ważne aby testować dużo i często. Jeżeli uda się przeprowadzić 1 test miesięcznie, co nie jest trudnym (a możliwym do osiągnięcia) wynikiem to mamy 12 testów rocznie. Jeżeli uda się co drugi, to mamy 6 testów na których zanotowaliśmy wzrost współczynnika konwersji. Jeżeli średnio wzrost wyniesie 10%, to współczynnik konwersji podniesie się w ciągu roku o 77%.

Żeby wykluczyć możliwość uzyskania przypadkowego wyniku, należy zadbać o istotność statystyczną. Narzędziem, które pozwoli sprawdzić czy test osiągną odpowiedni poziom ufności jest np. prosty kalkulator Visual Website Optimizer.

1. 1. Analiza testów i wdrożenie zmian

Samo testowanie nic nie da – efekty procesu zobaczymy wtedy, gdy wdrożymy zwycięskie zmiany. Dlatego powinniśmy zrobić to jak najszybciej, mając na uwadze fakt, że każdy dzień z większym współczynnikiem konwersji to dla nasz większy zysk.

Przestroga: lepiej nie wdrażać poprawek z kilku wersji alternatywnych jednocześnie. Nauczeni doświadczeniem w przeprowadzaniu testów wiemy, że wdrożenie wszystkich zmian na raz może okazać się pułapką. O ile każda z nich osobno może przynosić duże wzrosty, w połączeniu nie zawsze muszą współgrać. Dlatego też lepiej wdrożyć jedną poprawkę, i na niej optymalizować kolejne. Wtedy mamy pewność, że wdrożone zmiany przyniosą założone efekty.

Ważne, żeby pamiętać o dokładnej analizie każdego testu. Wszystko powinno być dla nas lekcją – nawet w przypadku porażki powinniśmy wyciągnąć wnioski na przyszłość.

Najlepsze rozwiązanie

Do zalet procesu optymalizacji współczynnika konwersji można na pewno dorzucić stosunkowo niski koszt oraz dużo mniejszy nakład pracy – w porównaniu do redesignu. Jeden test to około 14 dni. Planowanie i wdrażanie zmian jest nieporównywalnie mniej czasochłonne niż przy wielkich projektach – cały proces może zamknąć się w ciągu miesiąca.

Dodatkowo w projekt angażuje się dużo mniej osób, co na pewno wpływa na efektywność projektu. W procesie redesignu udział w przedsięwzięciu bierze co najmniej pół firmy i 3 agencje zewnętrzne. Małe zmiany pozwalają ominąć szereg procedur, prezentacji, decyzji, spotkań Zarządu. Nie trzeba nikogo przekonywać do swojej wizji lepszej witryny: wyniki testy mówią czarno na białym, co działa a co nie.

Niech dowodem na sens wprowadzania małych zmian zamiast wielkiego projektu redesigu będzie serwis Amazon. Powyżej zdjęcie serwisu z 2001 roku i z 2014 roku. Nowa witryna wygląda dużo lepiej niż jego poprzednia wersja, nie jest to jednak wynikiem radykalnego redesignu, a ciągłych testów.

Mam nadzieję, że udało mi się Was przekonać, że pomiędzy redesignem a nic-nie-robieniem jest jeszcze trzecie, całkiem sensowne wyjście

Czas na małe, wielkie zmiany!

The post Zmiana serwisu bez redesignu? Postaw na proces optymalizacji współczynnika konwersji first appeared on Conversion.

I tak przeprowadzamy audyty narzędzi śledzących, implementujemy Google Tag Managera, wdrażamy zaawansowane funkcjonalności Google Analytics. Gdy wszystko jest gotowe, dane się zbierają, słupki rosną bądź maleją a eventy wywołują się jak szalone moglibyśmy spokojnie powiedzieć: projekt skończony.

Po wdrożeniu potrzebnych narzędzi okazuje się, że nie są one rozwiązaniem problemu – są jedynie wstępem do serii kolejnych projektów, których celem jest wdrożenie analityki internetowej w całej organizacji, tak aby zaczęła ona przynosić wymierne korzyści.

Załóżmy, że firma X posiada zestaw doskonale skonfigurowanych narzędzi. Prezes może dostać na biurko każdy raport, od statystyk klikania w poszczególne elementy strony po raport ścieżek wielokanałowych. Wie, że dane które otrzymał są pełne, prawdziwe i dają całkowity obraz tego jak funkcjonuje jego serwis. I chociaż to ważna wiedza, do momentu kiedy nie przełoży się na wzrost wyników finansowych firmy, nie ma dla niego absolutnie żadnego znaczenia.

Można zaryzykować stwierdzenie, że takich Prezesów jest w Polsce bardzo dużo. Z naszego doświadczenia wiemy, że wciąż wiele polskich firm ma tendencje do skupiania się na narzędziach: fiksowania się na rozbudowywaniu śledzenia i mierzeniu wszystkiego, co tylko da się zmierzyć.

Dobre narzędzia to dobry początek.

Ale to za mało. To mniej niż 1/3 pracy, którą trzeba włożyć, by zacząć czerpać prawdziwe korzyści z analityki internetowej.

Po pierwsze: narzędzia i dane

Oczywiście, wdrożenie i poprawna konfiguracja narzędzi to podstawa późniejszych analiz. Bez tego ani rusz. Jednak to nie działa tak, że im więcej narzędzi tym lepiej, im bardziej zaawansowane jeszcze lepiej, a jeszcze jak za nie słono zapłacimy – to już w ogóle sukces.

Kluczem są dane, bo to przecież o nie, a nie o narzędzia chodzi.

Aby zadbać o pierwszy filar analityki internetowej należy wziąć pod uwagę 3 ważne rzeczy: dobór narzędzia, integrację oraz prezentację danych.

Wybór narzędzi analitycznych

Nie ma co ukrywać, w Polsce wśród narzędzi śledzących berło dzierży Google Analytics (nie mówimy, że niezasłużenie). Dlatego też nie o doborze samego narzędzia będzie mowa, ale o tym jak dostosować je aby służyło celom biznesowym firmy, a nie przeglądaniu ilu użytkowników odwiedza naszą stronę w czasie rzeczywistym.

Wyznaczanie celów biznesowych i ustalanie Kluczowych Wskaźników Wydajności to podstawa rozpoczęcia pracy nad stworzeniem organizacji opartej na danych. Dlatego najpierw określmy cele, później dobierzmy do nich metryki, a później znajdźmy narzędzie, które potrzebne dane zbierze i zaprezentuje. Nigdy w innej kolejności.

Google Analytics daje potężne możliwości śledzenia. Jednak przeznaczanie czasu na konfiguracje funkcjonalności, które w żaden sposób nie przybliżają nas do realizacji celów biznesowych, jest po prostu marnowaniem potencjału, który można byłoby skierować na bardziej sensowne działania.

Podobnie jest z narzędziami klasy premium (AT Internet, Adobe SiteCatalyst czy Google Analytics Premium) oraz innymi, które służą do tworzenia map cieplnych, automatyzacji marketingu czy zarządzania tagami.

Jeżeli tworzymy heatmapę bo ładnie wygląda i słyszeliśmy, że można sobie podejrzeć czy użytkownicy oglądają nasze zdjęcia na stronie (jak widać na powyższym obrazku, nie oglądają za chętnie ) – marnujemy czas. Ma to sens tylko, gdy na tej podstawie podejmiemy jakieś działania – na przykład przesuniemy sekcję w inne miejsce na stronie.

Pytanie, które powinniśmy sobie zadać zanim zaczniemy instalacje i rozbudowywanie narzędzi, brzmi:

Czy narzędzie / funkcjonalność odpowiada wyznaczonym przeze mnie celom biznesowym? Czy metryki zawarte w tym narzędziu stanowią moje KPI? Czy narzędzie / funkcjonalność pozwoli rozwiązać mi konkretny problem?

Dobra odpowiedź: Wdrażamy Google Tag Manager ponieważ znacząco usprawni to pracę Działu Marketingu (uniezależni go od IT) i dzięki temu tenże Dział będzie mógł skupić się na optymalizacji naszej witryny poprzez wdrażanie nowych narzędzi, co przełoży się na wzrost współczynnika konwersji, co przełoży się na zysk.

Integracja danych

Analityka internetowa to nie tylko narzędzia śledzące. Analizowanie tego jak użytkownicy zachowują się na stronie czy jak działają kampanie marketingowe na pewno może prowadzić do dobrych wniosków (np. testów A/B poszczególnych elementów witryny), ale to wciąż mało.

Gdy mamy sklep internetowy zbieramy nie tylko dane o użytkownikach, ale także np. dane sprzedażowe z CRM. W momencie gdy połączymy te dwa zbiory danych – możemy w pełni wykorzystać potencjał analityki internetowej.

Możemy integrować Google Analytics z danymi kosztowymi z AdWords. To pozwala na analizę kampanii CPC i jeszcze lepsze lokowanie środków na kampanie marketingowe.

Kolejny potencjał to łączenie danych z on-line z off-line. Możemy obserwować i analizować jak działają nasze reklamy telewizyjne czy radiowe. Możemy sprawdzić jak pogoda wpływa na sprzedaż – i dostosowywać ofertę produktów i reklamy pod tym kątem dla naszych użytkowników.

Analityka to nie tylko śledzenie użytkowników na stronie, ale także umiejętność łączenia danych z różnych systemów – co przeniesie Wasze analizy na wyższy poziom.

Prezentacja danych

Kolumny i słupki surowych danych nie mówią zbyt wiele. Dopiero odpowiednia ich prezentacja pozwala na wyciągnięcie z nich rekomendacji, które później przerodzą się w działania.

Gdy mamy zdefiniowane KPI i dobrane narzędzia, które pozwolą nam je mierzyć (tak jak pisałam we wstępie – nigdy w innej kolejności). Jednak same metryki nie mają znaczenia, jeżeli nie będą zaprezentowane w odpowiedni sposób.

Dlatego niezbędne jest umiejętne prezentowanie najważniejszych metryk: na przykład za pomocą kokpitów managerskich. Są to narzędzia, które na jednym ekranie prezentują Kluczowe Wskaźniki Wydajności. Dzięki temu, że są automatyczne generowane oszczędzamy czas, który analityk może poświęcić na analizę.

Dzięki dobrej prezentacji danych udziałowcy procesu widzą jak w czasie zmieniają się metryki i na tej podstawie zgłaszają do analityka potrzebę szczegółowej analizy pod kątem danej zmiany. Dzięki temu analityk ma więcej czasu i może lepiej przyjrzeć się badanemu zjawisku, przez co wnioski płynące z takich analiz są z pewnością lepsze.

Kolejna rzecz to umiejętność tworzenia prezentacji, w których przedstawiamy dane i wnioski. Co z tego, że z analizy kohort analitycy dowiedzieli się, że dobrym posunięciem będzie zmiana strategii kampanii marketingowych i przydzielenie budżetu na remarketing produktowy, bo widzą potencjał w konkretnej grupie użytkowników. Jeżeli nie zostanie to przejrzyście i ciekawie zaprezentowane osobom decyzyjnym w organizacji – można sobie schować takie raporty do do szuflady.

O tym jak prezentować dane pisałam tutaj: 3 kroki do stworzenia dobrej prezentacji danych.

Analityka to nie tylko zbieranie i analiza danych, ale także ich prezentacja. Dane nabierają mocy, kiedy jesteśmy w stanie pokazać, dlaczego rekomendacje są warte wdrożenia i jak przełożą się na biznes.

Po drugie: ludzie

Avinash Kaushik pisze o zasadzie 10 / 90.

Jeżeli masz do wydania 10000 złotych na realizację celu biznesowego przeznacz 1000 złotych na narzędzia, a 9000 złotych na ludzi.

Nie można się z nim nie zgodzić.

Analityka internetowa to przede wszystkim kompetentni ludzie. Analitycy, którzy na podstawie danych wyciągają z nich wnioski i rekomendacje.

Nie ma co ukrywać – znalezienie ludzi, którzy są dobrymi analitykami (prawdziwymi data detective) jest nie lada wyzwaniem. W Polsce analityka internetowa to nowa, nieznana dziedzina. Dobrych specjalistów jest wciąż jak na lekarstwo. Dobrym pomysłem jest zatrudnienie osób, które mają analityczny umysł i bakcyla w tym kierunku – i rozwijać ich umiejętności.

Dlaczego kompetentny zespół jest tak ważny?

Nawet jeżeli masz Google Analytics Premium, który kosztuje majątek, a nie masz wiedzy, jak wykorzystać jego możliwości: otrzymasz tonę raportów i statystyk, a Twoja firma nie wygeneruje żadnych zysków.

Nawet jeżeli zainstalujesz Google Tag Managera, a Twój zespół nie będzie umiał wdrażać najprostszych kodów, nie odciążysz IT a Twoja firma nie wygeneruje żadnych zysków.

Nawet jeżeli zintegrujesz Google Analytics z hurtownią danych, a nikt nie będzie umiał z tego wyciągnąć sensownych wniosków, Twoja firma nie wygeneruje żadnych zysków.

Przykłady można mnożyć, i co najgorsze – to wcale nie są hipotetyczne sytuacje.

Dlatego z każdych 100 złotych, które przeznaczasz na analitykę, 90 zainwestuj w rozwijanie kompetencji swojego zespołu i inwestowanie w ludzi. Prosta matematyka: wydajesz rocznie na analitykę 50000 złotych. Ile z tych pieniędzy powinieneś zainwestować w swój zespół?

Po trzecie: procesy

Masz dane, narzędzia i ludzi. To już bardzo dużo.

Jeżeli nie zaprojektujesz i nie wdrożysz odpowiednich procesów, zmarnujesz cały zgromadzony potencjał.

Jakie procesy powinny funkcjonować w organizacji, która opiera się na analityce internetowej?

Na początek warto zadbać o 5 podstawowych procesów, które zapewnią efektywne wykorzystanie zasobów w postaci narzędzi i ludzi.

• Proces raportowania kluczowych metryk dla osób decyzyjnych w organizacji z wykorzystaniem kokpitów managerskich.
• Proces analizy danych ad hoc
• Proces optymalizacji współczynnika konwersji
• Proces optymalizacji kampanii marketingowych
• Proces optymalizacji media mix

W kolejnym artykule skupię się na tym, jak zaprojektować, wdrażać i przeprowadzać każdy z tych procesów.

Analityka internetowa nie kończy się na wdrożeniu narzędzi. Ona się wtedy dopiero zaczyna. Tylko wcielenie w życie 3 filarów analityki internetowej pozwoli w pełni uwolnić jej potencjał.

Praca nad budową kultury analitycznej w organizacji to ciągły i wymagający proces. Jednak nie ma żadnych wątpliwości, że gra jest warta świeczki.

The post Narzędzia to nie wszystko: 3 filary analityki internetowej first appeared on Conversion.

W praktyce jednak do tej pory śledzenie zdarzeń za pomocą tego narzędzia nie było takie proste. Zdarzenia na stronie mogły być śledzone na dwa sposoby:

1. Śledzenie za pomocą zaawansowanego kodu HTML – do jego wykorzystania konieczna jest znajomość programowania, ponieważ do śledzenia zdarzeń trzeba napisać krótki kod HTML, identyfikujący elementy obiektów, przekazujące je do makr, a następnie zawarte w tagu zdarzenia.
2. DataLayer push – dataLayer push działa na bardzo podobnej zasadzie do standardowego śledzenia zdarzeń w Google Analytics. Każde zdarzenie na stronie musi zostać otagowane w kodzie źródłowym strony. W momencie wystąpienia zdarzenia zostaje ono przesłane (wepchnięte) do warstwy danych i dzięki temu staje się dostępne dla Google Tag Managera. Ten typ tagowania powinien być stosowany wyłącznie w przypadku, kiedy nie jest możliwe rozróżnienie zdarzeń na podstawie parametrów obiektu, czyli informacji dotyczących tego elementu, które są zawarte w kodzie.

Od czasu wprowadzenia automatycznego śledzenia zdarzeń nie jest już koniecznie ani pisanie kodu, ani wdrażanie dataLayer pushy do kodu „na sztywno”. Śledzenie aktywności użytkownika na stronie odbywa się za pomocą odbiorników (ang. Listener).

Odbiornik „nasłuchuje” czy na stronie nie wystąpi zdefiniowana dla niego akcja. W momencie wystąpienia takiej akcji aktywowany zostaje zawarty w nim kod i przekazana informacja do warstwy danych. Od tego momentu jest ona dostępna dla Google Tag Manager i może być wykorzystana w tagach Google Analytics lub innych narzędzi zarządzanych przez Google Tag Managera.

Typy odbiorników

Początkowo wprowadzone zostały 4 typy odbiorników, obecnie jest ich już 6. Każdy z nich nasłuchuje występowania określonego typu zdarzeń na stronie:

• Odbiornik licznika (Timer listener)
• Odbiornik kliknięć (Click listener)
• Odbiornik kliknięć linków (Link click listener)
• Odbiornik kliknięć formularza (Form submit listener)
• Rejestrator błędów JavaScript (JavaScript error listener)
• Tag nasłuchiwania historii (History listener)

Odbiornik licznika

Odbiornik licznika to najprostszy z odbiorników. Działa on w taki sposób, że zdarzenie zostaje przekazane do warstwy danych po upływie zdefiniowanego przez nas czasu (np. 10 sekund). Jego najpopularniejsze wykorzystanie to śledzenie prawdziwego współczynnika odrzuceń, szczególnie przydatne przy analizie stron docelowych. Można go też wykorzystać do odpalenia ankiety jeśli użytkownik spędził na stronie określony czas lub oznaczania w Google Analytics segmentu zaangażowanych użytkowników.

Odbiornik kliknięć

Ten typ tagu nasłuchuje wszystkich kliknięć na stronie, niezależnie od tego jaki element został kliknięty – grafika, plik pdf, buton zamknięcia informacji wyświetlanej na toplayerze czy też link do innej strony. Do warstwy danych zostaje przekazana zmienna z parametrami klikniętego elementu.

Zastosowanie tego odbiornika daje wiele możliwości śledzenia – od oczywistych zastosowań, takich jak zliczanie pobrań oferty naszej firmy, po sprawdzanie czy użytkownicy wiedzą jak poruszać się po naszej stronie.

Odbiornik kliknięć linków

Ten typ odbiornika działa na takiej samej zasadzie jak odbiornik kliknięć ale jego zakres jest ograniczony do nasłuchiwania kliknięć w linki. Ten odbiornik przekaże do warstwy danych informację o kliknięciu w element, który zawiera się w tagu <a>, odpowiadającemu za odesłanie. Jest to szczególnie przydane w przypadku śledzenia przejść do zewnętrznych serwisów.

Możemy dzięki niemu sprawdzić jaki wielu użytkowników tracimy, bo opuszczają nasz serwis po kliknięciu w zamieszczony banner reklamowy. Możemy pójść nawet o krok: oznaczyć takich użytkowników zmienną niestandardową i przeanalizować jak zachowują się w serwisie (czy np. nie wychodzą serwisu przed zapoznaniem się z naszą ofertą).

Odbiornik przesyłanych formularzy

Ten odbiornik identyfikuje zdarzenia wysyłki formularza. Teoretycznie moglibyśmy wykorzystać tutaj odbiornik kliknięć (w przycisk wysyłki), jednak skorzystanie z odbiornika przesyłanych formularzy ma w tym przypadku znaczną przewagę.

Po pierwsze, zdarzenie zarejestruje tylko żądania, które faktycznie zostały wywołane, a także, jeśli ustawimy taką opcje te, które przeszły weryfikację i zostały poprawnie wysłane.

Po drugie, jeśli w kodzie danej strony znajduje się jeden tylko formularz, to nie będzie konieczne definiowanie dodatkowych reguł dotyczących parametrów elementu (np. w oparciu o ID lub class).

Rejestrator błędów JavaScript

Ten odbiornik wyłapuje żądania JavaScript które nie zostają wykonane i zwracają błąd. Do warstwy danych zostaje przekazane zdarzenie gtm.pageError opisane przez 3 parametry:

• gtm.errorMessage, w którym zawarty jest komunikat błędu
• gtm.errorUrl, w którym zawarty jest URL strony wsytąpienia błędu
• gtm.errorLineNumber, w którym zawarty jest numer linijki kodu dla którego wystąpił błąd

Pojawienie się tego odbiornika znacznie ułatwia pracę developerom. Błędy występujące po stronie serwera mogą być w prosty sposób logowane i dzięki temu poprawiane. Śledzenie błędów po stronie aplikacji (client-side errors) wymagało wdrażania dodatkowych, zaawansowanych skryptów na stronę. Teraz tę pracę może wykonać rejestrator błędów JavaScript

Tag nasłuchiwania historii

Ten nowy odbiornik to wyjątkowa pomoc dla posiadaczy stron z dynamiczną treścią, w Ajax lub HTML5. Na tego typu stronach pomimo zmiany treści nie zmienia się URL (lub zmienia się część URL po #), ponieważ nie następuje przeładowanie strony.

W związku z tym nie można w pełni śledzić jak zachowują się użytkownicy w serwisie. Tag nasłuchiwania historii wyłapuje zmiany, które nie są w standardowej konfiguracji przekazywane do Google Analytics np. fragmenty URL czy kliknięcia przycisku Wstecz.

Z parametrów przesyłanych do warstwy danych w ramach tego zdarzenia najciekawsze są zmienne:

• gtm.oldUrlFragment, w ramach której przekazywana jest informacja o zmienianym fragmencie URL
• gtm.newUrlFragment, w ramach której przekazywana jest informacja o tym jak zmienił się fragment URL

Na stronie w technologii AJAX do Google Analytics nie przekazuje się części URL po znaku „#”. Przy wykorzystaniu tagu nasłuchiwania historii każda zmiana URL po znaku „#” spowoduje przekazanie nowej wartości do warstwy danych w ramach parametru gtm.newUrlFragment. Następnie możemy tę wartość przekazać do Google Analytics jako wirtualną odsłonę, lub zdarzenie, i w pełni śledzić jak użytkownicy poruszają się po naszej stronie.

Dodanie tagu odbiornika

Samo dodanie tagu odbiornika kliknięć linków jest bardzo proste. W zakładce wersji roboczej kontenera klikamy przycisk dodawania nowych elementów i wybieramy z listy „Tag”. Następnie w ramach menu „Typ tagu” wybieramy „Odbiornik > Odbiornik kliknięć linków”. W prawej kolumnie definiujemy regułę kiedy ma się uruchamiać nasz tag.

W przypadku odbiorników najczęściej wykorzystujemy regułę odpalania tagu na wszystkich stronach w serwisie (standardowo dostępna opcja w Google Tag Managerze) – rozróżnienia które linki przekazujemy dalej dokonujemy dopiero na poziomie definiowania tagu Google Analytics.

Przy takiej konfiguracji pozostaje tylko nadać nazwę naszego tagu. Radzimy, aby nazywać je w taki sposób, żeby już po nazwie było jak najwięcej wiadomo na temat działania tagu.

Po takim skonfigurowaniu tagu możemy sprawdzić czy zdarzenie Google Tag Managera będzie wywoływało się na stronie. W tym celu przechodzimy do wersji debuggowania kontenera.

W ekranie wersji roboczej kontenera klikamy „Podgląd” a następnie „Debuguj”.

To uruchamia dodatkową konsolę przy przeglądaniu strony, na której jest zainstalowany kontener. W niej możemy zobaczyć, czy tag działa.

Tag który przed chwilą utworzyliśmy jest załadowany i nasłuchuje zdarzeń na stronie.

Dodanie tagu zdarzenia Google Analytics

Tag odbiornika kliknięć linków przekazuje informację o klikniętym elemencie i jego parametrach do warstwy danych, skąd są one dostępne dla Google Tag Managera. Żeby wykorzystać je w Google Analytics koniecznie jest zdefiniowanie kolejnego zdarzenia – będzie ono działało w oparciu o parametry przekazane do warstwy danych.

W naszym przypadku chcemy śledzić kliknięcia w „a href=”https://www.conversion.pl/blog/subskrypcja-rss-konfiguracja-i-analiza-celow-w-google-analytics/” Title=”Subskrypcja RSS konfiguracja celów w Google Analytics”>button RSS, który przekierowuje użytkowników z naszej strony do czytnika RSS. Żeby zdefiniować zdarzenie dla takiej akcji musimy sprawdzić jakie parametry są przekazywane do warstwy danych w naszym tagu odbiornika kliknięć po kliknięciu w taki link. Takiego sprawdzenia możemy dokonać na dwa sposoby: z poziomu konsoli JavaScript w przeglądarce lub korzystając z rozszerzenia przeglądarki np. DataSlayer.

W konsoli JavaScript po wpisaniu komendy „dataLayer” zwracane są wszystkie obiekty, które aktualnie się w niej znajdują. Po kliknięciu w link dane dla tego elementu zostają dodane do warstwy danych dzięki odbiornikowi kliknięć linków. W konsoli pojawia się nowy obiekt – w ten sposób poznajemy parametry klikanego obiektu.

Kiedy znamy już wartości parametrów dla obiektu, w który kliknięcia chcemy śledzić, możemy przejść do tworzenia tagu zdarzenia Google Analytics.

W naszym przypadku chcemy, żeby zdarzenie zostało przesłane do Google Analytics jeśli kliknięty link to ikonka feedu RSS. Dlatego najpierw musimy zdefiniować regułę uruchamiania tagu zdarzenia. Regułę definiujemy w oparciu o wartości parametrów obiektu z warstwy danych.

W naszym przypadku chcemy, żeby zdarzenie zostało przesłane do Google Analytics jeśli kliknięty link to ikonka feedu RSS. Dlatego najpierw musimy zdefiniować regułę uruchamiania tagu zdarzenia. Regułę definiujemy w oparciu o wartości parametrów obiektu z warstwy danych.

Zgodnie z naszą regułą, tag zostanie wysłany kiedy odbiornik kliknięć linków wyłapie kliknięcie w obiekt z element.id równym btnRss (czyli przycisk RSS)

Teraz pozostała nam ostatnia kwestia – skonfigurowanie zdarzenia. Tutaj nie ma już niespodzianek.

W podstawowej konfiguracji musimy jedynie podać kod śledzący Google Analytics naszego konta i zdefiniować kategorię, akcję i etykietę zdarzenia. Ponownie, zdarzenie nazywamy tak, aby na pierwszy rzut oka wiadomo było w jaki sposób ono działa.

Teraz już wszystko gotowe. Dla przypomnienia: ustawiliśmy tag odbiornika kliknięć linków, znaleźliśmy element identyfikujący obiekt, w którego kliknięcia chcemy przesyłać do Google Analytics, zdefiniowaliśmy regułę uruchamiania tagu (w oparciu o unikalne element.id naszego przycisku) i ustawiliśmy tag zdarzenia Google Analytics. Proste? Proste!

Łyżka dziegciu

Musimy pamiętać, że wykorzystanie automatycznego śledzenia zdarzeń nie jest możliwe, gdy wszystkie parametry elementów, które chcemy śledzić są puste. Powinna zostać określona przynajmniej jedna zmienna.

Zauważcie, że dla naszego buttona RSS parametry element.classes i element.target są puste. Może się zdarzyć, że żaden w tych parametrów nie będzie miał wartości i w takim przypadku nie będzie można zdefiniować zdarzenia w oparciu o automatyczne śledzenie.

Dodatkowo, wartości parametrów, które chcemy wykorzystać do identyfikacji powinny być unikalne. Jeśli taka sama wartość parametru element.id występuje dla wielu przycisków na stronie, to wszystkie kliknięcia zostaną wyłapane i błędnie przyporządkowane do danego zdarzenia Google Analytics.

Niemniej jednak, nawet z tymi ograniczeniami, wynikającymi ze struktury nazewnictwa elementów w kodzie, automatyczne śledzenie zdarzeń wreszcie urzeczywistnia wizję Google Tag Managera – wdrażanie śledzenia bez zmian w kodzie strony.

Automatyczne zdarzenia w Google Tag Manager dają nam praktycznie nieograniczone możliwości śledzenia zachowania użytkowników w serwisie bez ingerencji w kod źródłowy strony. Należy jednak pamiętać, że możliwość ich wykorzystania w dużej mierze zależy od tego, jaka jest napisany jest kod źródłowy strony – dopiero przy dobrze zaplanowanej strukturze i nazewnictwie elementów kodu możemy w pełni wykorzystać możliwości, jakie daje nam ta funkcjonalność.

Jeśli potrzebujesz audytu konfiguracji narzędzi analitycznych (Google Analytics, AT Internet, Adobe Analytics czy Webtrends) lub chcesz rozwijać analitykę internetową wewnątrz organizacji skontaktuj się z Conversion by poznać nasze podejście. Więcej o analityce internetowej dowiesz się pobierając przygotowane przez nas bezpłatne poradniki, raporty oraz case studies.

The post Automatyczne śledzenie zdarzeń w Google Tag Manager first appeared on Conversion.

Proces analizy, niezależnie czy celem serwisu jest sprzedaż czy generowanie leadów, jest dokładnie taki sam:

Pierwszym etapem jest zebranie danych. Musimy pamiętać, że dane muszą być prawdziwe (odpowiadać rzeczywistości) i użyteczne (odpowiadać kluczowym dla nas metrykom). Analiza danych opiera się w głównej mierze na odpowiedzi na pytania: co się stało i dlaczego tak się stało. Dzięki jasno sprecyzowanym informacjom stawiamy rekomendacje – definiujemy zmiany, które należy wprowadzić aby usprawnić analizowane obszary. Następnie podejmujemy działania, które, w dłuższej lub krótszej perspektywie, mają wpłynąć na poprawę wyników finansowych firmy.

Celem analiz może być przede wszystkim zwiększanie sprzedaży oraz maksymalizacji zysku z inwestycji online (ROI). Realizację tak sformułowanych celów mierzymy za pomocą Kluczowych Wskaźników Wydajności (KPI) – czyli po prostu odpowiednich metryk.

Na dobry początek: 3 obszary analiz

W tym poście przedstawię 3 obszary, które powinniście uwzględniać w swoich analizach. Wnioski pozwolą na poprawę stron docelowych a także pomogą podejmować decyzje o wydatkach na działania marketingowe.

Oczywiście to tylko wycinek możliwości, które daje analityka internetowa. Mam jednak nadzieję, że będzie to dobry wstęp do kolejnych artykułów

Konwersje makro i mikro

więcej konwersji = większa sprzedaż

Współczynnik konwersji to podstawowa metryka, która pokazuje efektywność naszej strony internetowej: ilu użytkowników, którzy na nią trafili dokonało pożądanej przez nas akcji. W przypadku serwisów generujących leady konwersją będzie na przykład pozostawienie danych do kontaktu, pobranie pliku lub wykonanie telefonu.

Załóżmy, że w Twoim serwisie z 500 wysłanych leadów w danym miesiącu 50 przeradza się w transakcje (np. rozpoczęcie projektów). Jeżeli średni przychód na jednym kliencie wynosi 2 000 zł to wartość jednego leadu wynosi 200 zł.

średnia wartość potencjalnego klienta = (pozyskani klienci x średni przychód ze sprzedaży) / liczba potencjalnych klientów

Jeżeli z 500 zapytań 50 przeradza się w klientów (konwersja leadów 10%), którzy przynoszą zysk rzędu 2 000 to zwiększenie liczby leadów do 1000 za pomocą optymalizacji współczynnika konwersji podwoi nasz zysk. Oczywiście jeżeli odbywa się to przy takiej samej jakości ruchu i takim samym współczynniku konwersji leadów (10%).

Aby zmierzyć współczynnik konwersji witryny generującej leady za pomocą Google Analytics możemy ustawić cele. Najlepszym rozwiązaniem jest skonfigurowanie celu na URL strony podziękowania: oznacza to, że gdy użytkownik znajdzie się na tej stronie, zliczać się będzie konwersja. Co ważne: konwersja w przypadku celu nalicza się tylko raz (nawet jeżeli użytkownik w danej sesji pobierze plik bądź wypełni formularz kilkukrotnie).

W przypadku Avivy konwersją będzie zamówienie bezpłatnej rozmowy (strona podziękowania po wypełnieniu formularza). Będzie nią także kontakt telefoniczny. Jak sprawdzić, ilu użytkowników kontaktowało się z infolinią? Dobrą metodą jest przypisanie jednego numeru telefonu tylko dla danego landing page (wówczas wiemy, że użytkownik trafił do nas z tej strony). Aby jeszcze lepiej analizować całościowo współczynnik konwersji warto spróbować ustawić cel na zdarzenie np. przy wyświetlaniu numeru telefonu po kliknięciu „Pokaż numer”. Możemy wtedy zliczać pokazanie numeru jako konwersję.

Jak zwiększyć współczynnik konwersji strony docelowej? Powinniśmy pracować nad samym wyglądem i formą strony, ale także nad jej użytecznością – z pomocą przyjdą tutaj najlepsze praktyki projektowania stron docelowych oraz testy A/B, które potwierdzą bądź obalą nasze hipotezy.

W przypadku stron generujących leady kluczowym elementem jest formularz. To właśnie jego wypełnienie definiujemy jako konwersje, dlatego musi być maksymalnie przyjazny dla użytkownika.

Nikt w nie lubi wypełniać formularzy. W wielu przypadkach sprawdza się zasada: im krócej, tym lepiej. Czasami może wystarczyć tylko adres e-mail. Warto tu jednak przeanalizować koszt. Im mniej informacji o użytkowniku, tym mniej wartościowe leady. Dlatego zanim podejmiemy decyzję o skróceniu formularza, warto zastanowić się czy nam się to opłaci (jeżeli np. na stronie banku zrezygnujemy z obowiązkowego pola PESEL, uzyskanie tej informacji później może wiązać się z dodatkowym kosztem).

Jednak tak jak w przypadku każdego elementu witryny, i przy formularzach nie ma złotej zasady, która sprawdza się w każdej firmie.

Na etapie projektowania formularza powinniśmy skorzystać z heurystyk. Gdy umieścimy je już na stronie należy śledzić interakcje użytkowników z formularzem i testować poszczególne jego elementy za pomocą testów A/B.

Być może okaże się, że zamiast dłuższego formularza lepiej przygotować dwa kroki: najpierw prezentujemy krótki formularz z prośbą o adres e-mail i imię, a w następnym kroku o numer telefonu. Jest szansa, że użytkownik, który już i tak zaangażował się w wypełnianie formularza, dokończy rozpoczętą akcję (mimo, że w jednym kroku taka ilość pól zniechęciłaby go do podjęcia akcji). Może warto to przetestować?

Jak śledzić w jaki sposób użytkownicy wchodzą z interakcje z formularzem – i kontrolować jak radzą sobie z wypełnianiem poszczególnych pól?

Wykorzystuje się do tego zaawansowane śledzenie zdarzeń. Dodajemy kody śledzące zdarzenia do skryptu formularza. Zdarzeniem może być rozpoczęcie wypełniania formularza bądź poszczególne błędy w walidacji.

W raporcie Zachowanie / Zdarzenia otrzymamy zestawienie pól formularza dla których najczęściej popełniane są błędy. Dzięki temu mamy informację o tym które pole najczęściej powstrzymywało użytkownika w wysyłce formularza. Można również skorzystać z innych narzędzi: na przykład Clicktale posiada funkcję śledzenia formularzy.

Śledzenie zdarzeń pozwoli także na sprawdzenie jak często użytkownicy popełniają ten sam błąd (porównując zdarzenia do unikalnych zdarzeń) lub to, jak często przechodzą całą „ścieżkę wypełnienia formularza” (współczynnik „wysłań” formularza: ile użytkowników rozpoczyna do całkowitej liczby przesłania formularza). Możemy nawet sprawdzić jak bardzo użytkownicy są zdeterminowani (jak często próbują poprawiać formularz).

Dzięki takim danym możemy identyfikować problemy i naprawiać je – zwiększając tym samym współczynnik konwersji witryny.

Konwersje mikro

Nie zawsze użytkownicy od razu podzielą się z Tobą swoimi danymi: dlatego równie ważne jest zdefiniowanie i mierzenie konwersji mikro, czyli „mniejszych” akcji, które bezpośrednio nie kończą się zakupem, ale pośrednio mogą do niego prowadzić. Co może być konwersją mikro?

W przypadku Wonga.com jako konwersje mikro możemy zdefiniować przesuwanie suwaków: to świadczy o zaangażowaniu użytkowników w to jakie treści im prezentujemy (zainteresowali się ofertą i sprawdzają możliwości otrzymania pożyczki).

Jak mierzyć konwersje mikro? Jeżeli chcemy zmierzyć ile osób obejrzało film na nasze stronie – ustawiamy zdarzenie, które wywołuje się po naciśnięciu „play”. Możemy zrobić jeszcze więcej: ustawiając wartość zdarzenia „play” jako 0, a wartość zdarzenia „koniec filmu” jako 1 uzyskamy współczynnik i tym samym sprawdzimy, ilu użytkowników ogląda prezentowany film do końca.

Gdy chcemy sprawdzić ilu użytkowników przeczytało informacje prezentowane na stronie do końca – możemy wykorzystać skrypt śledzący przewijanie strony. Zdarzeniem może być także rozwinięcie danej kategorii czy naciśnięcie dowolnego przycisku (np. wyświetlenie kontaktu).

Konwersje mikro to źródło informacji o tym, czy użytkownicy angażują się w prezentowane treści i jak to zaangażowanie przekłada się na generowanie leadów sprzedażowych.

Jak w praktyce wykorzystać śledzenie mikrokonwersji? Możemy sprawdzać za pomocą testów A/B jakie treści bądź filmy (powiedzmy instrukcja vs wideoreferencje) lepiej wpływają na współczynnik konwersji naszej witryny.

Śledzenie zdarzeń rozszerza możliwości analiz: gdy chcemy zoptymalizować naszą stronę warto sprawdzić, jak zachowuje się segment użytkowników, którzy konwertują przy pierwszej wizycie. Jeżeli okaże się, że oglądają film do końca możemy założyć, że istnieje korelacja pomiędzy tą akcją a konwersją. Warto wówczas zadbać o to, aby więcej użytkowników trafiających na stronę obejrzało materiał: może zachęcić ich lepszym nagłówkiem albo skrócić czas trwania filmu?

Dopasowanie

lepszy ruch = więcej konwersji = większy zwrot z inwestycji w pozyskiwanie ruchu

Współczynnik odrzuceń definiujemy jako procent użytkowników, którzy weszli na nasz serwis (niezależnie na którą podstronę), i od razu go opuścili – nie przechodząc na kolejne strony. Za Avinashem Kaushikiem: user came, puked and left

To bardzo ważna metryka: dzięki niej jesteśmy w stanie stwierdzić czy sprowadzamy tzw. „dobry ruch” na naszą stronę. Co z tego, że ściągniemy 10 000 unikalnych użytkowników, skoro, powiedzmy, 90% z nich nie jest zainteresowanych pozostawieniem swoich danych. Co oznacza, że 90% kosztów poniesionych na pozyskanie ruchu (kampanie marketingowe, AdWords itd.) zostało wyrzucone w błoto.

Wysoki współczynnik odrzuceń może świadczyć o braku dopasowania reklamy lub słów kluczowych do tego, co prezentujemy użytkownikowi. Ten przecież ma jakieś wyobrażenie o naszej stronie wchodząc na nią z kampanii bądź wyników wyszukiwania: jeżeli pojawia się obietnica darmowej wersji oprogramowania przez miesiąc, a po przejściu na stronę pierwszym co widzi użytkownik jest tylko cennik – prawdopodobnie porzuci witrynę w mniej niż 5 sekund.

Reklama PZU oferuje opcję kalkulatora, który policzy moją składkę OC i AC oraz gwarantuje „najtańsze OC”

Jednak po przejściu na stronę docelową nie widzę nie tylko nagłówka (nie wiem gdzie dokładnie jestem) ale także obiecanego kalkulatora. Dlaczego więc miałabym rozpocząć wypełnianie formularza?

Wysoki współczynnik odrzuceń powinien skłonić nas do głębszej analizy treści i dopasowania naszych serwisów do oczekiwań użytkowników.

O ile w przypadku serwisów to, że użytkownik nie przeszedł do następnej strony może być traktowane jako „odrzucenie”, przy landing page nie do końca się sprawdza.

To, że użytkownik trafił na naszą stronę docelową i przeczytał wszystkie informacje i nie wypełnił formularza niekoniecznie oznacza, że jest ona niedopasowana. Może po prostu użytkownik znajduje się w początkowej fazie procesu zakupowego.

Google Analytics nalicza nam w takim przypadku odwiedziny równe 0 min. Jeżeli użytkownik ogląda tylko jedną stronę do Google Analytics wysyła się informacja, że rozpoczął wizytę o 10:21:00. Niestety Analytics nie wie, kiedy ta wizyta się skończyła – nie doszło do kolejnej interakcji (np. przejścia na następną stronę). Informacja o wyjściu nie jest domyślnie przesyłana. Tym samym – współczynnik odrzuceń będzie bardzo wysoki: nawet jeżeli użytkownicy dokładnie zapoznali się z całą stroną docelową i uważnie przyjrzeli się Twojemu produktowi. Współczynnik odrzuceń w takim kształcie niewiele nam mówi o rzeczywistych odrzuceniach..

Możemy jednak dosłownie „dostosować” współczynnik odrzuceń do naszych potrzeb. Pomoże nam w tym zaawansowane śledzenie Google Analytics: poprzez małą modyfikację kodu możemy zmienić sposób w jaki liczony jest współczynnik odrzuceń. Niewielka zmiana w kodzie strony pozwoli nam zdefiniować odrzucenie jako wizytę w trakcie której użytkownik spędził na stronie docelowej mniej niż na przykład 10 sekund. W ten sposób będziemy mogli odróżnić użytkowników, którzy cytując wspominanego już Avinasha Kaushika “came, puke and left” od tych, którzy faktycznie zaangażowali się w nasz post.

Pomiar efektywności kanałów marketingowych

efektywne kanały marketingowe = większy zwrot z inwestycji

Jeżeli wydajemy pieniądze na działania marketingowe, bezmyślne byłoby niemierzenie efektywności poszczególnych źródeł ruchu. Powinniśmy przede wszystkim wiedzieć jaką wartość możemy przypisać poszczególnym źródłom i jaki jest zysk z każdej złotówki wydanej na dany kanał marketingowy.

Analizując strony, które generują leady warto przyjrzeć się procesowi zakupowemu użytkownika. Zostawienie swojego adresu e-mail przy pobieraniu poradnika przychodzi użytkownikowi zdecydowanie łatwiej niż wypełnienie formularza o konsultacje w sprawie kredytu hipotecznego. Co oznacza, że potrzebuje on mniej dni do „zakupu” oraz do jego pozyskania wykorzystywanych jest mniej kanałów marketingowych.

Dlatego w przypadku „prostych leadów” wystarczającą analizą efektywności źródeł ruchu będzie raport Kanały w sekcji pozyskiwania.

Google Analytics domyślnie przypisuje wartość konwersji ostatniemu źródłu (przed wejściem bezpośrednim). W przypadku stron gdzie liczba dni do zakupu jest niewielka a ścieżka użytkownika do konwersji obejmuje zwykle jeden kanał marketingowy, taki raport będzie wystarczający.

. Analiza ścieżek wielokanałowych pozwala dokładniej ocenić efektywność poszczególnych źródeł ruchu, wyróżniając te, które „wspomagają” i „zamykają konwersję”. I tak w przypadku kredytu hipotecznego użytkownik może najpierw zobaczyć reklamę display, później otrzymać maila z reklamą, a następnie – otrzymać reklamę remarketingową. Aby odpowiednio wycenić poszczególne źródła należy zwrócić uwagę na model atrybucji (możemy także stworzyć własny).

Dzięki określeniu wartości poszczególnych kanałów jesteśmy w stanie obliczyć zwrot z inwestycji – a w konsekwencji optymalizować nasze wydatki na działania marketingowe. Jeżeli okazuje się, że koszt wysyłki mailingu do wykupionej bazy przewyższa koszt pozyskanego leadu – może warto przeznaczyć ten budżet na bardziej efektywną kampanie PPC?

Przy analizie wydatków marketingowych powinno się wziąć pod uwagę jeszcze jedną, często pomijaną metrykę: wartość życiową klienta.

Customer Lifetime Value (LTV) to suma przepływów pieniężnych, których dokona raz pozyskany klient w czasie swojego życia.

Jeżeli wiemy, że raz zdobyty klient przez całe swoje życie kupi u nas 10 polis ubezpieczeniowych, to wartość każdego zebranego leada wzrasta. Znając wartość klienta będziemy mogli podejmować racjonalne decyzje na temat kampanii, dzięki którym pozyskujemy naszych klientów. Wiedząc, że raz zdobyty klient wygeneruje nam konkretny przepływ będziemy skłonni zapłacić za niego więcej.

Czy mogę wydać 50 zł na pozyskanie leada, gdy średnia wartość leada to 30 złotych? Poznanie średniej wartości klienta pozwoli nam na podjęcie takich decyzji – które, choć w krótkotrwałym rozliczeniu mogą wydać się nieracjonalne, w dłuższej perspektywie wpłyną pozytywnie na zysk firmy. Ma to szczególne znaczenie w organizacjach, gdzie raz pozyskany klient dokonuje wielu transakcji, na przykład w bankach, domach maklerskich, funduszach inwestycyjnych czy ubezpieczeniach.

Podsumowanie

Jest jedna sprawdzona, niezawodna technika zwiększenia liczby pozyskiwania leadów. Analityka internetowa.

Jeżeli proces analizy danych przebiega efektywnie i jest nastawiony na wyciąganie wniosków oraz stawianie rekomendacji – możemy podejmować akcje, które zwiększą nasz zysk. Wszystko na podstawie solidnych danych.

Co dalej? Dane, Analiza, Rekomendacje, Działanie. A później? Dane, Analiza, Rekomendacje, Działanie. I znowu? Tak. Tylko dzięki stałemu powtarzaniu tego procesu i wprowadzaniu ciągłych usprawnień możemy skutecznie rozwijać naszą firmę.

I pamiętajmy: analityka to nie jest sztuka dla sztuki. To działania, które mają przekładać się na zysk.

The post Co i jak analizować na stronach docelowych generujących leady? first appeared on Conversion.

Omawiana funkcja pojawiła się w publikacji naszego poradnika dotyczącego instalacji i konfiguracji kodu śledzącego Google Analytics jako jedna z możliwych modyfikacji kodu źródłowego.

Wykluczenie wybranych słów z ruchu organicznego

Niespełna rok temu pisaliśmy o konieczności uwzględnienia w analizach prawdziwego ruchu bezpośredniego. Dla przypomnienia jest to ruch, który oprócz standardowego directa uwzględnia odwiedziny z wykorzystaniem brandowych słów kluczowych – w końcu słowa jednoznacznie kojarzące się z nasza marką nie wnoszą zbyt dużo przy analizie ruchu z wyszukiwarek. W związku z tym, te słowa należałoby wrzucić do worka zwanego ruchem bezpośrednim.

W artykule na temat prawdziwych wejść bezpośrednich jako jeden ze sposób na rozwiązanie tego zjawiska podałem funkcję _addIgnoredOrganic, która z założenia – użytkowników, którzy trafiają do nas po słowach brandowych (dla nas takim słowem jest np. 'conversion’) traktuje jako ruch bezpośredni.

Pisząc nasz poradnik na temat instalacji i konfiguracji kodu śledzącego Google Analytics również zamieściliśmy podaną funkcję jako przykład możliwej modyfikacji kodu śledzącego. Została ona uwzględniona, ponieważ jakiś czas temu sukcesywnie stosowaliśmy ją u jednego z naszych Klientów. Po publikacji poradnika zostaliśmy zapytani czy wspomniana funkcja działa. Powiem szczerze, że nie byłem w stanie z przekonaniem odpowiedzieć na to pytanie, ponieważ ostatni raz używaliśmy jej ponad rok temu. Stąd postanowiliśmy to sprawdzić na własnej skórze…

_addIgnoredOrganic na witrynie Conversion.pl

W połowie września zmodyfikowaliśmy kod śledzący naszej strony firmowej www.conversion.pl tak, aby zgodnie ze specyfikacją _addIgnoredOrganic nie uwzględniał w słowach kluczowych frazy 'conversion’.

Modyfikacja została wprowadzona w połowie września i niestety, po zajrzeniu w raport słów kluczowy w październiku nie było widać jej działania (dla pewności porównałem pełne miesiące – z i bez implementacji _addIgnoredOrganic.

I co się okazuje… odwiedzin ze słowem kluczowym „conversion” w październiku było jeszcze więcej niż w sierpniu. Co jest przyczyną? Pierwsze miejsce, w którym w takich sytuacjach szukam pomocy są grupy dyskusyjne Google Analytics. Tam okazało się, że nie tylko ja mam problem z funkcją _addIgniredOrganic.

Jednak znalazłem w jednym z wątków taką oto informację:

the addIgnoredOrganic doesn’t „untag” previous visitors who already have that keyword, it only prevents visits from being tagged with that keyword in the future. What you should start to see is a sharp change in the „% New Visits” for that keyword, and over six months the visits will taper off (keywords are tagged to a visitor for up to 6 months, or until they arrive via a different source)

Co oznacza, że funkcja _addIgnoredOrganic nie likwiduje słowa kluczowego, ale nie zapisuje jego użycia dla nowych użytkowników. W związku z tym, po jej zastosowaniu (w długim okresie) powinniśmy zaobserwować spadek nowych odwiedzin na dane słowo do 0. W przypadku naszej witryny i wprowadzonej modyfikacji kodu śledzącego jednak tak nie jest… a przynajmniej nie widać zasadniczej zmiany w % nowych odwiedzin.

W październiku można było zobaczyć nawet trend odwrotny tj. wzrost udziału nowych odwiedzin w ruchu. Dodam, że ruch ogólnie w październiku nie uległ znaczącej zmianie w porównaniu do poprzednich miesięcy, dlatego postanowiłem to dalej sprawdzić…

Weryfikacja _addIgnoredOrganic

W związku z niejednoznacznością wyników postanowiliśmy sprawdzić działanie funkcji _addIgnoredOrganic na swój sposób – wykorzystując w tym celu zmiennną niestandardową na poziomie użytkownika. Dzięki niej możemy śledzić każdego żytkownika po jego numerze identyfikacyjnym, który wyciągany jest z ciasteczka __utma dzięki następującemu kodowi.

Jeżeli chcecie zastosować powyższy skrypt u siebie, to oprócz powyższego kodu musicie pamiętać o funkcji, która będzie wyciągała odpowiednie informacje z ciasteczek. Więcej na ten temat w artykule pod tytułem Read Google Analytics Cookie Script.

Po wykasowaniu ciasteczek i odwiedzeniu naszej strony, możemy z ciasteczka __utmv odczytać, jaki numer został nam przypisany. Po tym numerze następnie w raporcie zmiennych niestandardowych będziemy mogli dokładnie zobaczyć nasze zachowanie na stronie. Zapamiętajmy ten numer, ponieważ za chwilę będziemy sprawdzali źródło jego odesłania:)

Jeżeli zajrzymy do raportu zmiennych niestandardowych, to okazuje się, że pomimo zastosowania funkcji _addIgnoredOrganic w kodzie śledzącym moje odwiedziny po brandowym słowie kluczowym zostały raportowane przez Google Analytics jako ruch organiczny – mimo że wykasowałem wcześniej ciasteczka i zostałem potraktowany jako nowy użytkownik.

Jeszcze jeden widok raportu, tym razem z drugim wymiarem określającym słowo kluczowe, po którym wszedłem na naszą stronę.

Jak widzimy, pomimo zastosowania wykluczenia słowa kluczowego 'conversion’ za pomocą funkcji _addIgnoredOrganic Google Analytics ciągle raportuje źródło organiczne z tym słowem kluczowym, co oznacza, że funkcja ta nie działa.

Podsumowanie

Na kanwie powyższych rozważań jestem przekonany, że obecnie funkcja _addIgnoredOrganic nie działa! Nie jestem w stanie powiedzieć, jak to wyglądało historycznie, ponieważ długi czas jej nie wykorzystywaliśmy.

Pisząc ten artykuł i czytając wypowiedzi użytkowników doczytałem, że podobna sytuacja jest z funkcją _addIgnoredRef, ale tego osobiście już nie sprawdziłem. Szkoda tylko, że jeżeli taka sytuacja ma miejsce, to ciągle funkcje te znajdują się w pomocy technicznej Google Analytics.

Czy możecie sprawdzić to u siebie przeprowadzając analogiczną analizę? Będę bardzo wdzięczny za Wasze spostrzeżenia i uwagi na ten temat:)

The post Czy funkcja _addIgnoredOrganic działa? first appeared on Conversion.

Użytkownicy Facebooka mają dwa sposoby, aby podzielić się ze znajomymi treściami na naszych stronach www:

• poprzez umieszczenie linku na swojej tablicy / tablicy fanpagea (tzw. udostępnienie naturalne)
• lub poprzez kliknięcie „Lubię to!” na podstronie naszego serwisu (btw. kliknij „Lubię to!” na górze tego postu;))

Przyglądnijmy się więc dwóm metodom, które pozwalają na śledzenie statystyk na temat współdzielenia przez użytkowników treści z naszych stron internetowych:

1. statystyki Facebooka – oprócz śledzenia statystyk dla strony na Facebooku (fanpagea), możliwe jest też śledzenie statystyk na temat współdzielenia (tak kliknięć na „Lubię to!” jak i udostępnień naturalnych) naszego serwisu w ramach Facebooka – sprawdzimy co można z nich wyciągnąć.
2. statystyki Google Analytics – istnieje sposób na przekazanie informacji o liczbie kliknięć w przycisk „Lubię to!” w ramach naszego serwisu do Google Analytics – pokażemy jak to zrobić (i dlaczego może to być momentami lepsze rozwiązanie niż statystyki Facebooka).

Ale nim zaczniemy…

Odpowiedzmy sobie na jedno, bardzo ważne pytanie:

Po co nam te informacje?

Odpowiedź jest prosta. Na ich podstawie będziemy wiedzieli jakiego typu treści podobają się naszym użytkownikom.

Przykładowo, jeżeli prowadzimy portal informacyjny, dzięki tym danym, będziemy wiedzieli na jakiego typu newsach w przyszłości możemy się skupić, aby zainteresować naszych użytkowników. Poznamy, które treści dodatkowe (jakiego typu albumy, filmy etc) cieszą się największym wzięciem wśród naszych czytelników. Dzięki temu będziemy umieli pokierować ich kreacją w przyszłości.

O ile lepszą metryką dla tego typu stron jest liczba kliknięć „Lubię to!” na stronę niż metryki zaangażowania jak czas na stronie. Kierując się takim KPI nie tylko zwiększymy ruch do swojego serwisu z serwisów społecznościowych, ale jak się również okazuje poprawimy swoje rankingi w SERPach (ang. search engine results page – wyniki organiczne)

Przechodząc do konkretów – jak zbierać i gdzie szukać tych danych

Tak jak wspomniałem na wstępie, dane na temat współdzielenia naszą stroną możemy uzyskać z dwóch miejsc – pierwszym z nich jest Facebook, drugim – odpowiednio skonfigurowany Google Analytics.

Statystyki Facebooka na temat stron www

Facebook umożliwia śledzenie statystyk na temat współdzielenia (tak kliknięć na „Lubię to!” jak i udostępnień naturalnych) naszego serwisu w ramach Facebooka.

Aby mieć do nich dostęp, musimy postępować według następujących kroków:

1. Wejść na stronę Facebook Insights (bedąc oczywiście zalogowanym do swojego konta)
2. Kliknąć na przycisk „Insights for your Website”

Kliknij na zdjęcie, aby je powiększyć

3. Wyświetli nam się okno dialogowe, w którym musimy uzupełnić domenę strony internetowej (w naszym przypadku www.conversion.pl) oraz otrzymamy kod html, który musimy umieścić w sekcji meta naszego serwisu (w naszym przypadku <meta property=”fb:admins” content=”564278374″ />) – po jego dodaniu klikamy „Get Insights”
4. Od tego momentu klikając „Wybierz statystyki” na stronie Facebook Insights będziemy mieli dostęp również do statystyk stron internetowych

Kliknij na zdjęcie, aby je powiększyć

Kliknij na zdjęcie, aby je powiększyć

Statystyki na Facebooku możemy przeglądać na dwóch poziomach:

• wszystkie strony – holistyczny pogląd na wszystkie podstrony naszego serwisu
• wybierz stronę – przeglądanie statystyk dla konkretnej podstrony

Informacje, które zapewnia nam Facebook Insights dla stron www można podzielić na 3 kategorie:

• współdzielenia – czyli liczby kliknięć na przycisk „Lubię to!” w ramach naszego serwisu oraz udostępnień naturalnych (o które chodzi nam najbardziej, ponieważ nigdzie indziej tych informacji nie ma)
• rozkładzie wyświetleń – czyli jak dużo użytkowników widzi na Facebooku udostępnioną z naszego serwisu informację (przydatne do liczenia i optymalizacji CTR z Facebooka)
• wejścia na stronę wynikające ze współdzieleń – osobiście wg mnie najmniej przydatna rzecz – wolę polegać na statystykach z Google Analytics w tym zakresie – jeżeli poprawnie oznaczymy linki prowadzące do naszego serwisu z kampanii prowadzony na Facebooku to nie będzie z tym problemu

Skupimy się na pierwszej z tych kategorii, czyli współdzieleniach, ponieważ to one są w mojej opinii najbardziej interesujące. W menu po lewej stronie możemy wejść do szczegółowych statystyk na temat kliknięć w „Lubię to!” oraz naturalnych udostępnień.

Z bardziej dokładnych statystyk możemy się dowiedzieć nie tylko ile mieliśmy kliknięć w przycisk „Lubię to!”, ale również uzyskać informacje o liczbie przeklików z tego typu udostępnień i rozkład demograficzny. Szczerze powiem, że wszystkie te informacje są mało przydatne do optymalizacji efektywności naszych stron. Najciekawsza informacją, którą chcielibyśmy uzyskać jest to, które z naszych treści są najbardziej lubiane (żeby pisać takich treści więcej!).

Taką informację Facebook zapewnia. Niestety, są to informacje jedynie z bieżącego dnia lub godzin Jeżeli nie jesteśmy dużym serwisem informacyjnym, który na bieżąco publikuje wiadomości, tylko publikujecie treść raz na tydzień, te statystyki niespecjalnie nam pomogą (i będą zazwyczaj wyglądały tak jak niżej, czyli będą puste ):

Kliknij na zdjęcie, aby je powiększyć

Na szczęście te statystyki możemy uzupełnić za pomocą Google Analytics (ale o tym za chwilę) lub za pomocą własnej aplikacji, która pobierała by tego typu informacje poprzez API Facebooka.

Podobnie jak statystyki dla „Lubię to!” prezentują się statystyki dla udostępnień naturalnych. Zakres dostępnych informacji jest bardzo podobny. Niestety, ponownie nie ma tych najbardziej interesujących nas informacji czyli, które dokładnie strony są najczęściej udostępniane w sposób naturalny przez naszych użytkowników. Co gorsza, o ile w przypadku kliknięć w „Lubię to!” możemy ten niedobór kluczowych informacji uzupełnić za pomocą Google Analytics, w przypadku udostępnień naturalnych już takiego manewru zrobić nie możemy. Facebook jest jedynym posiadaczem tego typu informacji i jak widać nie chce nam ich udostępnić dla dłuższego niż jednodniowy okres (chyba, że obejdziemy to poprzez eksport i zapis tych danych z API Facebooka).

Kliknij na zdjęcie, aby je powiększyć

Statystyki Google Analytics na temat kliknięć w „Lubię to!” na stronie

UPDATE 1.07.2011: W dniu wczorajszym Google udostępniło aktualizację Google Analytics upraszczając śledzenie wszystkich akcji związanych z sieciami społecznościowymi (m.in. „Lubię to!”) – kliknij tutaj aby przejść do specyfikacji.

Łatwym sposobem na ominięcie problemu, którym jest brak pokazywania najbardziej lubianych przez użytkowników stron w dłuższym okresie niż jeden dzień jest wykorzystanie w tym celu Google Analytics. Jak dobrze wiemy, Google Analytics zapewnia informacje z jednodniowym opóźnieniem – dlatego w tym przypadku statystyki zapewniane przez Facebooka są idealnym uzupełnieniem (zapewniając dane na bieżąco).

Najprostszym rozwiązaniem umożliwiającym śledzenie kliknięć na przycisk „Lubię to!” byłoby dodanie śledzenia zdarzeń przekazywanego w momencie kliknięcia przez użytkownika przycisku za pomocą onclick. Takie rozwiązanie jest nieoptymalne, ponieważ kliknięcie na „Lubię to!” nie jest tożsame z polubieniem danej strony. Kliknąć mógł użytkownik, który nie ma konta na Facebooku lub który właśnie „znielubił” naszą stronę.

Jeżeli chcemy, aby kod śledzenia zdarzeń Google Analytics był wywoływany tylko wtedy, gdy kliknięcie „Lubię to!” powiodło się, użyjmy następującego kodu (oczywiście zakładam, że mamy na stronie zainstalowany przycisk „Lubię to!”):

Oczywiście jeśli chcielibyśmy zliczać cele w starej wersji Google Analytics musielibyśmy wykorzystać do zliczania kliknięć w „Lubię to!” wirtualne odsłony (pamiętajmy, że w nowym interfejsie Google Analytics do konfiguracji celu można użyć również śledzenia zdarzeń). Od tej pory statystyki się zliczają – są one dostępne w zakładce śledzenia zdarzeń w Google Analytics:

UPDATE: Zapomniałem wspomnieć, że przycisk „Lubię to!” musi być zainstalowany jako xfbml, a nie iframe.

Kliknij na zdjęcie, aby je powiększyć

Podsumowanie

Wyniki badania opublikowanego przez SEOmoz potwierdzają, że przed Facebookiem nie ma ucieczki. Linki publikowane tam przez użytkowników już dziś mają wpływ na wyniki organiczne w SEO. Obok świetnej metryki mierzącej zaangażowanie użytkowników, jest to kolejny argument za tym, że warto śledzić udostępnianie przez użytkowników treści, które tworzymy w ramach naszego serwisu. Wiedząc, które treści są przez naszych użytkowników najbardziej lubiane na pewno uda nam się poprawić treści w ramach naszej witryny tak, aby podobały się coraz większej liczbie naszych użytkowników.

Czy sądzicie na temat zliczania liczby kliknięć w „Lubię to!” i wykorzystywania jej jako metryki oceniającej zaangażowanie odwiedzających naszą witrynę użytkowników?

Jeśli potrzebujesz audytu konfiguracji narzędzi analitycznych (Google Analytics, AT Internet, Adobe Analytics czy Webtrends) lub chcesz rozwijać analitykę internetową wewnątrz organizacji skontaktuj się z Conversion by poznać nasze podejście. Więcej o analityce internetowej dowiesz się pobierając przygotowane przez nas bezpłatne poradniki, raporty oraz case studies.

The post Śledzenie kliknięć w „Lubię to!” i naturalnych udostępnień na Facebooku i w Google Analytics first appeared on Conversion.

Dzisiaj chcielibyśmy powiedzieć coś więcej o zaawansowanych metodach śledzenia – jak poprzednio będzie to raczej uporządkowanie wiedzy zgromadzonej na naszym blogu, ponieważ większość tematów poruszaliśmy już w naszych postach.

Zaawansowane śledzenie

Pierwszą rzeczą – w ogóle, jaką powinniśmy zrobić jest „przeklikanie naszego serwisu od początku do końca”, rejestracja we wszystkich formularzach, kliknięcie na wszystkie możliwe odnośniki – jednym słowem przejrzenie strony na wylot. Podejrzewam jednak, że będąc właścicielem serwisu sami dobrze wiemy, co w nim siedzi… Działania te mają na celu zidentyfikowanie specjalnych implementacji, które pozwolą nam na zaawansowane śledzenie naszych użytkowników.

Śledzenie zdarzeń (ang. event tracking)

Dla hiperłącz, które nie wywołują załadowania nowej strony (ściągnięcie pliku, wysłanie formularza kontaktowego, kliknięcie w link maila itp.) należy skonfigurować śledzenie zdarzeń. Jeżeli jednak będziemy chcieli skonfigurować cel w Google Analytics, który będzie raportował wykonanie takiej akcji, to wówczas powinniśmy wykorzystać do tego wirtualne odsłony. Poruszaliśmy te tematy w artykułach zatytułowanych: Śledzenie zdarzeń w Google Analytics (ang. event tracking) oraz Wirtualne odsłony – uzupełnienie śledzenia zdarzeń. Dodatkowo musimy pamiętać o zachowaniu odpowiedniej struktury raportowania śledzenia zdarzeń.

Jeżeli w naszym serwisie znajduje się bardzo dużo linków zewnętrznych lub maili, czyli hierpłączy, które nie wywołują załadowania strony z naszym kodem śledzącym, to możemy ułatwić sobie życie – nie ma konieczności tagowania wszystkich linków oddzielnie. Wystarczy na swoim serwerze umieścić dwa pliki, a na wszystkich stronach w ramach serwisu, w sekcji head umieścić następujący kod:

Poszczególne pliki mają natomiast następującą zawartość.

mailto.js

outband.js

Zmienne niestandardowe (ang. custom variables)

Zmienne niestandardowe służą do „oznaczania” wybranych użytkowników. Ta funkcjonalność pomoże nam na pewno w segmentacji naszego ruchu Możemy np. chcieć zobaczyć, jak zachowują się użytkownicy zarejestrowani vs. niezarejestrowani lub osoby, które obejrzały wybraną stronę wobec internautów, którzy do niej nie dotarli – bez implementacji zmiennych niestandardowych niestety nie będzie to możliwe. O zastosowaniu tej funkcjonalności pisaliśmy w artykule pt. Zrozumieć zmienne niestandardowe w Google Analytics, w którym znajdziecie szczegóły na ten temat.

Śledzenie wypełniania formularzy

Formularze są częstą przyczyną wąskich gardeł na ścieżce konwersji. Dlatego bardzo istotna jest śledzenie ich wypełnienia. O optymalizacji konwersji formularzy pisaliśmy już jakiś czas temu w artykule pt. Jak analizować formularze, by poprawić ich skuteczność. Metodę pomiaru formularzy w Google Analytics opracował Bluerank – nasza firma partnerska. Możecie przeczytać o niej na oficjalnym blogu Google Analytics.

Śledzenie stron błędu 404

Tej tematyce poświęciliśmy dosyć niedawno artykuł pt. Strona błędu 404 w Google Analytics. Znajdziemy w nim sposób, dzięki któremu możemy bardzo łatwo zautomatyzować proces śledzenia ślepych linków w naszym serwisie np. poprzez implementację odpowiednich alertów niestandardowych.

Instalacja E-Commerce

Instalacja modułu e-commerce to już trochę dłuższa historia. Do tej pory nie pisaliśmy nic na ten temat, jednak znalazł on miejsce w naszym planie wydawniczym na najbliższy kwartał. Omówienie instalacji śledzenie transakcji e-commerce wymaga poświęcenia jej w całości całego artykułu, więc na razie niech zadowoli nas jedynie jej krótki przedsmak w postaci filmiku z kanałau Google Analytics na YouTube.com.

The post Jak poprawnie skonfigurować Google Analytics cz. 2 first appeared on Conversion.

Duża i stała baza subskrybentów RSS jest celem każdego blogera. W końcu nasza działalności nie sprowadza się do tego, aby publikować w sieci kolejne bezwartościowe słowa, lecz wnosić do niej interesujący element. Najlepszym tego wymiarem jest liczba użytkowników, którzy odwiedzają nasz serwis, aby tą treść konsumować, a jeszcze większym wyróżnieniem dla blogera są użytkownicy, którzy deklarują regularną konsumpcję naszego serwisu poprzez subskrypcję źródła RSS.

Jak już wiecie, Google Analytics daje niezliczone możliwości mierzenia metryk związanych z ruchem w ramach naszego serwisu – również subskrypcji RSS. Dzisiaj chciałbym krótko opisać, jak my podchodzimy do tego zagadnienia na naszym blogu.

Cel – subskrypcja RSS

Z reguły, każdy blog oferuje subskrypcję artykułów. Jednym z najbardziej popularnych narzędzi, używanym również na naszym blogu jest Feedburner. Po zarejestrowaniu i podstawowej konfiguracji możemy dzielić się linkiem, dzięki któremu użytkownicy w łatwy sposób mogą subskrybować nasze posty przechodząc do strony subskrypcji.

Kliknij na zdjęcie, aby je powiększyć

Następnie link do takiej strony umieszczamy na naszym blogu tak, aby użytkownik mógł je w łatwy sposób znaleźć i się zapisać. Na Conversion blog możecie znaleźć go w dwóch miejscach: na pasku bocznym oraz pod każdym artykułem.

Konifguracja celu

Kolejnym krokiem powinno być skonfigurowanie celów, którymi będzie kliknięcie w te linki. W Google Analytics możemy zmierzyć jedynie kliknięcie, a nie samą subskrypcję, ponieważ użytkownik dokonuje „ostatecznej” subskrypcji ze strony Conversion blog w Feedburnerze. W związku z tym, że nie jesteśmy w stanie śledzić stron trzecich musimy przyjąć, że użytkownik za każdym razem zapiszę się do RSS po przejściu na Conversion blog zróżnicowaliśmy dwa odnośniki subskrypcji RSS, konfigurując dwa oddzielne cele.

Kliknij na zdjęcie, aby je powiększyć

Na pewno pamiętacie, że linki, które nie wywołują załadowania nowej strony nie są rejestrowane przez Google Analytics. W związku z tym, w celu ich śledzenia musimy wykorzystać śledzenie zdarzeń. Jednak, aby móc konfigurować cele dla takich zdarzeń, powinniśmy wykorzystać szczególną odmianę śledzenia zdarzeń tj. wirtualne odsłony. Dla linków pod artykułami na Conversion blog wyglądają one następująco (jak widzisz jest w nich skonfigurowane zarówno śledzenie zdarzeń, jak i wirtualna odsłona):

Kliknij na zdjęcie, aby je powiększyć

Link na pasku boczny ma zaimplementowaną wirtualną odsłonę postaci /blog/RSS/sidebar. Dlatego jeżeli byśmy chcieli śledzić subskrypcję RSS jako jeden cel – bez rozróżnienia, w którym miejscu na blogu miała ona miejsce, to są dwa rozwiązania:

• skonfigurować wirtualne odsłony dla kliknięcia w każdy link subskrypcji jako /blog/RSS i skonfigurować cel w Google Analytics jako Dopasowanie ścisłe adresu wirtualnej odsłony,
• zostawić wirtualne odsłony tak, jak są obecnej konfiguracji i skonfigurować cel w Google Analytics jako Dopasowanie części głównej adresu /blog/RSS.

Następnie, dzięki wirtualnym odsłonom możemy skonfigurować odpowiedni cel w Google Analytics. Na Conversion blog celom subskrypcji RSS z paska bocznego oraz ze stopki artykułu nadaliśmy różne wartości. Stwierdziliśmy, że jeżeli użytkownik po przeczytaniu postu subskrybuje nasze źródło RSS, to ma to dla nas większe znaczenie niż jeżeli robi to za pomocą linku na pasku bocznym. Oznacza to dla nas, że artykuł był dla niego na tyle ciekawy, aby bez zastanowienia skorzystać z naszego wezwania do działania:)

Kliknij na zdjęcie, aby je powiększyć

Analogicznie skonfigurowaliśmy cel zapisania się do RSS w sekcji bocznej Conversion blog, nadając mu jedynie mniejszą wartość realizacji.

Analiza celów

Tutaj, jak w całej analityce internetowej ciężko mówić o jakiś best practices. Nie będę również przedstawiał całego procesu, jak odbywa to się u nas. Nakreślę jedynie trzy raporty, które moim zdaniem warto zwrócić uwagę.

Po pierwsze powinniśmy zobaczyć, jak użytkownicy realizują postawione przed nimi cele. Pomoże nam w tym sekcja Cele. Mimo że w przypadku tak skonfigurowanych celów nie dowiemy się z niej zbyt dużo, to na pewno powinniśmy zajrzeć do Odwrotnych ścieżek do celu, aby zobaczyć, jaką drogę pokonali użytkownicy przed wypełnieniem akcji, którą przed nimi postawiliśmy.

Innym sposobem, aby przekonać się, w którym miejscu użytkownicy najczęściej zapisują się do naszego kanału RSS jest raport Śledzenia zdarzeń w sekcji Treść. Jest to możliwe dzięki temu, że w linkach subskrypcji RSS skonfigurowaliśmy śledzenie zdarzeń w sposób następujący:

_gaq.push([’_trackEvent’, 'outbound-follow’, 'RSS’, location.pathname]);

W związku z tym, że jako etykietę zastosowaliśmy location.pathname, to w sekcji Śledzenie zdarzeń / Etykiety drążąc w dół oudband-follow / RSS dowiemy się, na których stronach użytkownicy najczęściej zapisali się naszego kanału RSS.

Pisząc ten post doszedłem do wniosku, że lepszym rozwiązaniem byłoby dla nas zastosowanie etykiety, która rozróżni kliknięcia w linki pod artykułem i na pasku bocznym, a następnie dodatkowa segmentacja wg Strony.

Moim zdaniem jednak dużo bardziej ciekawe będą raporty z innych sekcji, które po prostu zawierają zakładkę z poszczególnymi konfiguracjami celów. Weźmy na przykład Źródła odwiedzin. Na pewno chcielibyśmy wiedzieć, skąd pochodzą nasi „najlepsi” użytkownicy. Wchodząc do tej sekcji i klikając w zakładkę Konfiguracja celu 1 możemy zobaczyć jak mają się nasze cele subskrypcji wobec źródeł ruchu, po których trafili nasi użytkownicy. My w pierwszym zestawie, oprócz celów związanych z subskrypcją RSS mieliśmy jeszcze cele związane z naszą obecnością w social media. W tym miejscu możemy sortować i patrzeć, które źródła ruchu maja największy udział w realizacji poszczególnych celów. Dodatkowo możemy włączyć jeszcze jeden wymiar do analizy np. typ użytkownika. Dzięki temu dowiemy się, jacy użytkownicy w podziale na poszczególne źródła odwiedzin konwertują wobec tak postawionych przed nimi celów.

Kliknij na zdjęcie, aby je powiększyć

Posiadając wiedzę dotyczącą tego, skąd pochodzą użytkownicy, którzy subskrybują nasz RSS oraz po których artykułach są bardziej skłonni to robić, wiemy jak dalej kreować nasze działania. Jeżeli naszym celem jest zbudowanie dużej bazy czytelników, to będziemy inwestowali w źródła, które przyciągają najlepszych pod tym względem użytkowników oraz pisali artykuły na wzór tych, które najlepiej zachęcają ich do kliknięcia w zawołanie do działania. Z drugiej strony dla źródeł ruchu, które słabiej konwertują pod tym względem możemy przemyśleć sposób komunikacji dla danej grupy użytkowników i tak dalej i tak dalej….

Analiza użytkowników

Kolejnym krokiem analizy RSS powinna być analiza samych użytkowników – jednak o tym będziemy pisali w oddzielnym artykule. Z pewnością nie obejdzie się tutaj bez statystyk Feedburnera oraz segmentów zaawansowanych, ale o tym niedługo…

Jak Wy podchodzicie do analizy subskrypcji RSS, czy też analizy samych użytkowników pochodzących z tego źródła?

The post Subskrypcja RSS – konfiguracja i analiza celów w Google Analytics first appeared on Conversion.