Wyrażenia regularne są językiem, dzięki któremu za pomocą odpowiednich operatorów możemy dopasować dowolny ciąg znaków spełniający konkretne założenia. W Google Analytics dają wielką elastyczność, dzięki której można je wykorzystać m.in. w filtrach widoku danych, celach, segmentach, odbiorcach, grupach treści, a nawet grupowaniu kanałów. Z kolei w przypadku Google Analytics 4 znajomość wyrażeń regularnych najczęściej przydaje się w takich obszarach, jak: narzędzie Eksploracja, tworzenie segmentów wykluczenia witryn odsyłających.

Muszę przyznać, że ostatnio coraz bardziej przekonuję do wyrażeń regularny (ang. regular expressions, regex), do tego stopnia, że stosuję je zawsze, kiedy jest to tylko możliwe. Ciebie również będę chciał do nich przekonać i mam nadzieję, że dzięki temu artykułowi oraz zawartym w nim przykładom – zobaczysz, że naprawdę nie taki wilk straszny, jak go malują, a popularne regexy na stale zagoszczą w Twoim “arsenale”.

O konkretnych przykładach zastosowania wyrażeń regularnych opowiem Ci w kolejnych paragrafach. Jednak pozwól, że najpierw przybliżę Ci tematykę związaną z podstawowym znaczeniem znaków wykorzystywanych w regexach.

Co znajdziesz w tym artykule?
Znaki używane w wyrażeniach regularnych. Jakie wyróżniamy?
Jak testować wyrażenia regularne?
Testowanie wyrażeń regularnych w Google Analytics – omówienie regexów
Gdzie w Google Analytics możesz stosować wyrażenia regularne?
Google Analytics 4 a wyrażenia regularne
Regex w Google Analytics 4 (GA4) – nowe ograniczenia i najlepsze praktyki
Wyrażenia regularne w Google Analytics – podsumowanie

Znaki używane w wyrażeniach regularnych. Jakie wyróżniamy?

W wyrażeniach regularnych najczęściej (przynajmniej w mojej codziennej pracy analityka internetowego) wykorzystuję następujące znaki. Poniżej, wraz z definicjami, znajdziesz również proste przykłady ich zastosowania. W następnym paragrafie artykułu będzie natomiast więcej informacji o ich bardziej “życiowym” wykorzystaniu:

• ^ (daszek) – rozpoczyna się od – ten znak dopasowuje wszystkie wyrażenia, które zaczynają się od danego wzoru. Np. ‚^sto’ dopasuje takie słowa, jak: sto, stonoga, stokrotka, stomatolog. Jednak nie dopasuje już takich, jak: miasto, ciasto itd.
• $ (dolar) – kończy się na – odwrotnie, znak ten dopasowuje wszystkie wyrażenia, które kończą się na daną frazę. Wracając do powyższego przykładu dla ‚sto$’ dopasowane zostanie: sto, miasto i ciasto, ale nie: stonoga, stomatolog czy stokrotka.

Na pewno udało Ci się dostrzec, że stosując kombinację ^ oraz $ otrzymasz coś w stylu dopasowania ścisłego (np. dla wyrażenia ‚^miarka$’ dopasuje nam tylko i wyłącznie słowo miarka).

• | (rurka, ang. pipe) – lub – w logice ładnie nazywa się to alternatywą. Dzięki temu znakowi dopasowanie będzie dotyczyło wartości, które stoją po obu stronach. Np. dla ‚^miarka$|^siarka$’ – dopasowane zostanie wyłącznie jedno z dwóch słów: miarka lub siarka.
• . (kropka) – zastępuje jeden dowolny znak w wyrażeniu (większa liczba kropek oznacza większa dowolną liczbę znaków) – dzięki wyrażeniu postaci ‚^..aza$’ dopasujesz słowo takie jak: zmaza czy skaza (dwie kropki zastępują w tym przypadku dwie litery „zm” lub „sk”). Jeżeli wyrażenie zostanie napisane z dodatkową kropką na początku tj. ‚^…aza$’ – to możesz dopasować np.: zaraza, ale wcześniejsze słowa (zmaza i skaza) nie zostaną już dopasowane. Kropki można mnożyć w nieskończoność, ale do tego typu operacji zdecydowanie lepsza jest gwiazdka (o czym przeczytasz już za moment).
• * (gwiazdka) – zastępuje nieskończoną liczbę znaków, po których następuje – najczęściej wykorzystuję ją w połączeniu z kropką. Dzięki takiemu połączeniu można osiągnąć dowolny ciąg znaków np. ‚^m(.*)a$’ dopasuje słowa: mantra, manna, mazda, Marianna itp., czyli każdą frazę, która zaczyna się na „m” i kończy na „a”.
• + (plus) – oznacza powtórzenie przynajmniej raz poprzedniego znaku, czyli dla wyrażenia ‚^arka+’ zostaną dopasowane: arka, arkaa, arkaa itd.
• ? (znak zapytania) – oznacza brak wystąpienia lub powtórzenie jeden raz poprzedzającego znaku – dla wyrażenia ‚arka?’ dopasowane zostaną zatem jedynie: arka lub ark.
• [] (nawiasy kwadratowe) – oznaczają dopasowanie dowolnego pojedynczego znaku w ich ramach – dzięki wyrażeniu regularnemu ‚[ck]on[vw]ersion’ dopasowane zostaną następujące frazy: conversion, konversion, conwersion oraz konwersion. Nawiasy kwadratowe w połączeniu z daszkiem w środku dopasują dowolny znak, który NIE znajduje się w sprawdzanej frazie. Np. dla wyrażenia ‚[^abc]’ dopasuje każdy znak, poza trzema pierwszymi literami z alfabetu.
• – (myślnik) – oznacza zakres wyrażeń – najczęściej wykorzystuję go w połączeniu z nawiasem kwadratowym. Np. wyrażenie regularne ‚ar[b-c|k-m]a’ dopasuje następujące frazy: arba, arca, arka, arla, arma. Możemy również wykorzystać cyfry tj. ‚aria[1-9]’, dzięki czemu dopasuje nam: aria1, aria2, aria3 itd.
• (ukośnik tylny) – przywraca standardowe znaczenie znaków wykorzystywanych w wyrażeniach regularnych – jak już z pewnością udało Ci się zauważyć – wyrażenia regularne wykorzystują znaki, które są często używane w kodzie źródłowym strony internetowej. Najlepszym przykładem jest kropka. W wyrażeniach regularnych oznacza dowolny znak, natomiast normalnie jest separatorem np. w adresie internetowym. Jeżeli wpiszemy wyrażenie ‚^www.wp.pl$’, to dopasowane zostaną m.in. następujące frazy: www1wpepl, wwwwwppl itp. W celu dopasowania konkretnego adresu internetowego należy wpisać następujące wyrażenie regularne: ‚^www.wp.pl$’.

Więcej przykładów tego, w jaki sposób możesz wykorzystać poniższe znaki znajdziesz pod tym adresem. Dowiedz się m.in. jak sprawdzają się one w filtrach, segmentach niestandardowych, a nawet celach.

Jak testować wyrażenia regularne?

Mimo że wyrażenia regularne nie zaliczają się do bardzo skomplikowanych obszarów, to podobnie, jak w przypadku każdego innego języka programowania – przed jego implementacją warto przeprowadzić testy sprawdzające.
Osobiście, do testowania moich wyrażeń regularnych, najchętniej wykorzystuję następujące rozwiązania: filtry w raportach treści w Google Analytics Universal (jak to zrobić przeczytasz w tym miejscu), karty eksploracji w Google Analytics 4, a także dedykowane serwisy takie, jak: regex101.com bądź regexr.com.

Testowanie wyrażeń regularnych w Google Analytics – omówienie regexów

Pierwszy sposób ma szczególne znaczenie w Google Analytics Universal przy konfiguracji celów z wykorzystaniem wyrażeń regularnych. Jak zapewne pamiętasz – w Google Analytics możesz skonfigurować 4 typy celów:

• docelowy adres URL,
• czas spędzony w witrynie,
• strony/odwiedziny,
• zdarzenie.

Przy czym warto zwrócić uwagę, że wyrażenia regularne w Google Analytics Universal w praktyce najczęściej znajdują zastosowanie w pierwszym rodzaju celu, czyli celach opartych na adresach URL.

Zastosowanie wyrażeń regularnych w Google Analytics.

Jeżeli zdecydujesz się na dopasowanie wyrażenia URL, to musisz zastanowić się, jakie wyrażenie regularne dopasuje URL, który będzie dla oznaczał konwersję użytkownika. Wszystkie adresy URL, które odsłonili użytkownicy, dostępne są w raportach sekcji: Zachowanie / Zawartość witryny / Wszystkie strony.
Tam również (tuż nad tabelą dostępny jest filtr, który pomoże Ci zdecydować, czy wyrażenie regularne wykorzystane w konfiguracji celu rzeczywiście dopasowuje adres URL, na którym Ci zależy. Jeżeli tak – śmiało możesz wykorzystać to wyrażenie regularne w konfiguracji celu.

Wyrażenie regularne wykorzystane w konfiguracji celu.

Drugim rozwiązaniem, które osobiście stosuję przede wszystkim do testowania wyrażeń regularnych na potrzeby filtrów oraz segmentów, stanowi serwis regex101.com.
Działanie serwisu jest bardzo intuicyjne. Wystarczy, że w polu “REGULAR EXPRESSION” wpiszesz swoje wyrażenie regularne, a w polu “TEST STRING” – frazy, które chcesz poddać weryfikacji. Proste

Źródłó: Własne – regex101.com

Gdzie w Google Analytics możesz stosować wyrażenia regularne?

W praktyce, jak już wspominałem, istnieje co najmniej kilka zasadniczych elementów, w których można wykorzystać wyrażenia regularne.
Jednak zdecydowanie najczęściej wykorzystuje się je w filtrach oraz konfiguracji celów.

Wykorzystanie wyrażeń regularnych w filtrach w interfejsie raportowania

Z filtrami w Google Analytics mamy do czynienia w co najmniej dwóch miejscach – filtrach w ramach widoków danych oraz filtrach w widoku raportów. Te drugie (filtry w ramach raportów), są znacznie częściej wykorzystywane – zwłaszcza, jeżeli chcemy przyjrzeć się wybranym słowom kluczowym.

Aby lepiej Ci to zobrazować – pozwól, że posłużę się przykładem. W poniższej operacji moim celem było wyszukanie wszystkich słów kluczowych zaczynających się od “żel” lub “krem”. Dodatkowo, słowa kluczowe dla “żel” mogły pojawić się również bez polskich znaków.
Oczywiście mogłem wypisać wszystkie możliwe odmiany tych słów. Ale powiedzmy sobie szczerze – czy jest sens, aby tracić czas i energię, jeśli wszystko można zastąpić jednym i zdecydowanie krótszym wyrażeniem?
W tej sytuacji wystarczyło bowiem zastosować taki krótki regex:

Zastosowanie regexu.

A oto efekty, jakie wygenerowało wyrażenie:

Efekt zastosowanego wyrażenia.

Wykorzystanie wyrażeń regularnych w filtrach (w widoku danych)

Inny przykład rozwiązania stosowanego w ramach widoku danych stanowi filtr włączający ruch z danej sekcji serwisu. W tym wypadku jest to opcja włączająca ruch z jedynie dla “Studiów II stopnia”.
W związku z tym, że URL na tej stronie skonstruowane są w ten sposób, że każdy należący do tej sekcji zaczyna się od ‚/studia-ii-stopnia’ lub ‚/studia_ii_stopnia’, to wyrażeniem regularnym będzie tutaj:

Sam filtr z kolei filtr wówczas przyjmie następującą postać:

Wzorzec filtra.

Kolejnym przykładem filtru, w ramach którego możesz wykorzystać możliwości wyrażeń regularnych, stanowi ten wykluczający ruch z podanego zakresu adresów IP.

Kolejny wzorzec filtra.

Przykład? Dla zakresu adresów “178.42.219.143-200” – odpowiednie wyrażenie regularne będzie miało postać:

Wykorzystanie wyrażeń regularnych w celach

Przy konfiguracji celów w Google Analytics musisz pamiętać o tym, że wybierając dany rodzaj dopasowania adresu URL, determinujesz go również dla konfiguracji ścieżki do celu.
Każda aktywność użytkownika może zostać przeliczona na konkretne wartości pieniężne. Kilka przydatnych porad, jak podchodzić do kwestii ich obliczania, znajdziesz pod tym adresem. Z kolei mój przykład takiego celu prezentuję poniżej.

Wykorzystanie wyrażeń regularnych w celach.

Aby przekonać się, czy dane wyrażenie regularne zadziała prawidłowo, możesz zweryfikować je w raporcie Zachowanie / Zawartość witryny / Wszystkie strony. W tym celu warto odnieść się do sekcji testowania wyrażeń regularnych.

Wykorzystanie wyrażeń regularnych w segmentach

Musisz wiedzieć, że regexy znajdują swoje zastosowanie również w obszarze związanym z określaniem segmentów użytkowników. Na ich podstawie możesz definiować, chociażby ich pochodzenie (na poniższym przykładzie pokazałem Ci, jak to zrobić w odniesieniu do płatnych źródeł ruchu z social mediów).

Wykorzystanie wyrażeń regularnych w segmentach.

Grupowanie treści za pomocą wyrażeń regularnych

Do kolejnych zastosowań zaliczamy grupowanie, które znajduje szczególne zastosowanie – zwłaszcza, gdy Twoja strona internetowa posiada strukturę adresów URL, która pozwala na pogrupowanie adresów w określone kategorie.
Poniżej prezentuję Ci przykład takiego grupowania treści, w którym jako grupę – Blog / Twarz chcę przypisać wszystkie artykuły zawierające w adresie /blog/twarz.

Grupowanie treści za pomocą wyrażeń regularnych.

Grupowanie kanałów przy pomocy wyrażeń regularnych

Do niestandardowego grupowania kanałów również można wykorzystać wyrażenia regularne. Na poniższej grafice znajdziesz praktyczny przykład. A jeśli chcesz dowiedzieć się nieco więcej o opcji grupowania kanałów – zapoznaj się z tą lekturą od Google.

Grupowanie kanałów przy pomocy wyrażeń regularnych.

Google Analytics 4 a wyrażenia regularne

Do tej pory opowiedziałem Ci wiele o zastosowaniu regexów w odniesieniu do Google Analytics w wersji Universal. Mając na względzie, że czas tej usługi powoli dobiega końca i już niedługo zastąpi ją Google Analytics 4 – muszę napisać również “co nieco” o wyrażeniach regularnych właśnie w kontekście GA4. Aby nie przedłużać, pozwól, że od razu przejdę do konkretów.

Wykorzystanie regexów w narzędziu eksploracja

Tzw. Eksploracje to narzędzie Google Analytics 4, w którym znajdziesz cały zestaw zaawansowanych metod, dzięki którym będziesz w stanie otrzymać wiele dokładnych informacji na temat aktywności klientów. Znajdziesz tam m.in. ścieżki, kohorty, pokrywanie się segmentów i wiele, wiele więcej.

Jednak w mojej ocenie, najczęstszym wykorzystaniem wyrażeń regularnych w narzędziu eksploracja w GA4, będą filtry (grafika poniżej).

Wykorzystanie regexów w narzędziu eksploracja – filtry.

Na screenie możesz dostrzec wszystkie zdarzenia dla danej usługi. Ale co zrobić, jeśli chcesz zobaczyć tylko te związane z działaniami Ecommerce? Do tego posłuży Ci filtr z wykorzystaniem wyrażeń regularnych:

view_item|add_to_cart|view_cart|begin_checkout|purchase

Wykorzystanie regexów w narzędziu eksploracja – filtry związane tylko z działaniami ecommerce.

Poniżej efekt, jaki udało się uzyskać właśnie dzięki zastosowaniu naszego filtra z wyrażeniem regularnym:

Efekt po zastosowaniu filtra z wyrażeniem regularnym.

Wykorzystanie regexów w segmentach

Podobnie jak w Google Analytics Universal – wyrażenia regularne w Google Analytics 4 sprawdzają się wyśmienicie również w przypadku tworzenia mniej lub bardziej zaawansowanych segmentów.

Wykluczenia witryn odsyłających za pomocą wyrażeń regularnych

W tym miejscu możemy mówić o pewnej nowince. Otóż, w przypadku konfiguracji tego elementu istnieje możliwość zastosowania wyrażeń regularnych do definicji wykluczeń witryn odsyłających. W klasycznym Universal Analyticsie nie było to możliwe.

Co więcej – można skonfigurować maksymalnie 50 warunków, a co za tym idzie – wykorzystanie wyrażeń regularnych w tym miejscu często jest wręcz koniecznością.

Zastosowanie wyrażeń regularnych do definicji wykluczeń witryn odsyłających.

Przykład zastosowania? Załóżmy, że chciałbym wykluczyć bramkę płatności PayU, które może występować pod 3 różnymi adresami URL: secure.payu.pl, payu.pl oraz payu.com.

Zamiast wpisywać każdą domenę do osobnego warunku, wystarczy zastosować takie wyrażenie regularne:

Przykładowe zastosowanie wyrażeń regularnych do definicji wykluczeń witryn odsyłających.

Regex w Google Analytics 4 (GA4) – nowe ograniczenia i najlepsze praktyki

Wdrożenie GA4 zmienia zasady gry dla wyrażeń regularnych – m.in. domyślny tryb „matches regex” wymaga pełnego dopasowania łańcucha, a nie tylko zawierania wzorca. Warto więc przeanalizować: jakie wzorce działają poprawnie, jakie ograniczenia niesie za sobą składnia RE2 (np. brak lookahead / lookbehind), oraz jak uniknąć typowych błędów.

Limity RE2 w GA4 – co oznaczają dla analityka i jak je obejść

Wyrażenia regularne w Google Analytics – podsumowanie

Mam nadzieję, że zapoznanie się z tym wpisem przekonało Cię, że stosowanie wyrażeń regularnych jest po prostu opłacalne – w końcu pozwala oszczędzić naprawdę masę czasu i energii!
Jak widzisz, wyrażenia regularne zapewniają elastyczność i dają naprawdę niesamowite możliwości. Na pewno udało Ci się również zauważyć, że nawet przy ich podstawowej znajomości, można znacznie szybciej i łatwiej konstruować zaawansowane filtry.
Jedyne, o czym musisz pamiętać, to fakt, iż w filtrach można stosować wyrażenia regularne o maksymalnej długości 255 znaków. Choć od tej “bolączki” wolne są już segmenty zaawansowane.

Jeśli wyrażenia regularne zainteresowały Cię to mam nadzieję, że temat segmentacji jak i filtrów również przypadnie Ci do gustu i uzupełni zdobytą dzisiaj wiedzę!

The post Wyrażenia regularne – czym są i jak wykorzystać regex w Google Analytics? first appeared on Conversion.

Czy “wyciągnięcie” jakichkolwiek danych ze strony www, sklepu internetowego lub też aplikacji mobilnej zawsze musi oznaczać przymus kontaktowania się z działami IT i… czasami długie oczekiwania na ich reakcje? Powiedzmy sobie szczerze, jeśli wszystkie działania związane z implementacją i modyfikacją kodów wykorzystywanych w analityce internetowej spoczywałyby na barkach programistów, to wielu analitykom prędzej urosłyby siwe brody (i przeszliby na emerytury), niż doczekaliby się na planowanego wdrożenia.

Na szczęście firma Google już dawno zdała sobie sprawę z tego, że spece od IT zawsze mają coś ważniejszego na swoich głowach. Dlatego zaproponowała rozwiązanie, które pozwala nie tylko wdrażać, ale również sprawnie zmieniać kluczowe z punktu analityki elementy – i to każdemu, kto ma dostęp do Google Tag Managera.

Czym jest DataLayer? Jakie ma zastosowanie? Kto powinien z niego skorzystać? Aż wreszcie – jak podejść do jego konfiguracji i implementacji? Odpowiedzi na wszystkie te (plus kilka dodatkowych) pytań, postarałem się zawrzeć w tym artykule. Zapraszam do lektury :)!

Co to jest Data Layer?
Przykłady zastosowania warstwy danych
Jakie informacje mogą znajdować się w Data Layerze?
Jak wygląda warstwa danych?
Data Layer a Google Tag Manager – co mają ze sobą wspólnego?
Dlaczego warto postawić na wdrożenie poprzez GTM?
Jak wdrożyć Data Layer za pomocą GTMa?
Wykorzystanie warstw danych w e-commerce
Dlaczego warto? Korzyści wynikające z wdrożenia i użytkowania warstwy danych.
Data Layer – podsumowanie

Co to jest Data Layer?

Z czysto technicznego punktu widzenia, Data Layer (czyli warstwa danych) to po prostu obiekt JSON (nazywany też tablicą). Wykorzystuje się go do przesyłania informacji np. z Twojej strony internetowej – bezpośrednio do kontenera menedżera tagów.

W praktyce DataLayer (DL) pozwala na uporządkowanie danych tak, aby menedżer mógł w łatwy i szybki sposób docierać do niezbędnych parametrów, które są umiejscowione bezpośrednio w kodzie źródłowym. Oczywiście, takie warstwy danych mogą być skonfigurowane zarówno dla serwisów internetowych (stron czy sklepów), jak i aplikacji. 

Przykłady zastosowania warstwy danych

Warstwa danych (data layer) można wykorzystać w wielu scenariuszach: np. przy śledzeniu dodania produktu do koszyka – pushujesz event: addToCart z informacjami o produkcie, jego cenie i ilości. Innym przykładem jest rejestracja użytkownika: warstwa danych może przesłać event: userSignUp wraz z planem abonamentu czy źródłem kampanii. W e-commerce klasycznym zastosowaniem jest przekazanie danych transakcji (ID zamówienia, wartość, lista produktów) do GTM i dalej do Google Analytics lub narzędzi remarketingowych. Takie zastosowania zapewniają spójność danych, łatwe mapowanie i odseparowanie logiki marketingowej od warstwy prezentacji strony.

Jakie informacje mogą znajdować się w Data Layerze?

Muszę powiedzieć, że zastosowanie warstw danych ogranicza głównie Twoja wyobraźnia, potrzeby biznesowe oraz specyfika samego serwisu czy aplikacji.

Data Layer może odnosić się do wielu zmiennych, w tym: atrybutów, nazw, zdarzeń i wielu innych. Ponadto, sprawdza się również przy okazji i tworzenia reguł, jak i samych tagów. Pomimo tego, że można ich używać praktycznie na dowolnych stronach czy aplikacjach – zdecydowanie największe “pole do opisu” znajdują się oczywiście w obszarze e-commerce.

W tej materii Data Layer może obsługiwać takie informacje, jak:

• Dane na temat produktów, w tym ich nazwy, kategorie oraz ceny.
• Dane na temat transakcji, w tym wartość koszyka zakupowego, sposób oraz daty płatności.
• Dane o klientach lub użytkownikach, w tym: czy są to nowe, czy też powracające osoby.

Data Layer może też dotyczyć prowadzonych kampanii reklamowych, w tym informować o źródłach wizyt użytkowników odwiedzających sklep internetowy.

Naturalnie może być wykorzystywany w wielu innych miejscach. W przypadku bloga, dane, które mogą być przekazywane “dalej”, to chociażby: nazwa wpisu, data publikacji, kategoria, imię i nazwisko autora. 

Jak wygląda warstwa danych?

Jak już wspomniałem kilka akapitów wcześniej – DataLayer odwołuje się bezpośrednio do kodu strony, do czego wykorzystuje obiekt JSON. Obiekt ten zawiera opis elementów strony internetowej lub aplikacji. Może prezentować się np. w następujący sposób: 

’ProductName’ – oznacza nazwę produktu na danej podstronie

‘Brand’ – oznacza markę danego produktu

‘Category’ – oznacza kategorię, w której znajduje się dany produkt

’Price’ – oznacza cenę danego produktu

W tym miejscu muszę jasno zaznaczyć, że zarówno kwestia nazewnictwa poszczególnych elementów, jak i parametrów, do których mają się odwoływać – jest całkowicie dowolna. To oznacza, że nie istnieje jedna “z góry” określona struktura, której trzeba się “trzymać”. Oczywiście mamy tutaj wyjątki.

W praktyce możesz więc nazywać je tak, jak tylko zechcesz. Zalecam jednak pewną ostrożność. Weź pod uwagę, aby zadbać o maksymalną intuicyjność oraz czytelność elementów w Twoim Data Layerze. Tak, aby inne osoby, które będą z nimi pracowały, nie miały żadnych problemów z określeniem “co autor miał na myśli” .

Dobrą praktykę w tej materii stanowi stosowanie jasnych i powszechnie stosowanych określeń (zarówno w języku polskim, jak i angielskim) np.:

• “price” lub “cena” – dla ceny produktów.
• “category” lub “kategoria” – dla ich kategorii.
• “source” lub “źródło” – dla źródła pochodzenia klientów.

I tak dalej, i tak dalej.

Jednocześnie staraj się wystrzegać oznaczeń, które nie są jednoznaczne lub kompletnie “nic nie mówią”. Przykłady, które warto omijać, to między innymi: przypadkowe ciągi liter lub cyfr, nazwy własne, długie i skomplikowane zwroty.

Data Layer a Google Tag Manager – co mają ze sobą wspólnego?

Istnieją co najmniej dwa najpopularniejsze sposoby implementacji warstw danych. Pierwsza z nich to tzw. ręczna – wymaga posiadania wiedzy i umiejętności programistycznych, a dodatkowo potrafi zabrać bardzo dużo czasu. Polega bowiem na pracy bezpośrednio w kodzie strony lub aplikacji. W tej zazwyczaj niezbędna jest pomoc osób, które posiadają dostęp do kodu źródłowego Twojego serwisu.

Na szczęście istnieje też druga, zdecydowanie prostsza, szybka i taka, którą zajmiesz się osobiście – bez konieczności angażowania specjalistów z działu IT. I właśnie opcji nr 2 poświęcę ten i kolejny akapit.

Data Layer możesz bowiem z powodzeniem zaimplementować za pośrednictwem Google Tag Managera. Jeżeli nie wiesz, co to takiego – gorąco zachęcam Cię do zapoznania się z tym artykułem o GTM, którego autorem jest jeden z ekspertów Conversion – Paweł Ogonowski. W skrócie: wystarczy, że opracujesz odpowiednie makra, które przechwycą wybrane informacje, a Google Tag Manager będzie już wiedział, czego dotyczy dana podstrona.

Dlaczego warto postawić na wdrożenie poprzez GTM?

Jedną z głównych zalet są oczywiście: prosta obsługa, łatwy dostęp oraz czytelność. Warto także wiedzieć, że wdrożenie Data Layera oznacza też znacznie mniej problemów przy okazji migracji serwisu. Jeśli Twoja organizacja postanowi odświeżyć lub też całkowicie zmodyfikować stronę lub sklep – wcale nie musisz martwić się, że wszystkie dane zostaną stracone, a całą pracę należy zacząć od nowa. Jedyne, o czym wówczas należy pamiętać, to zmigrowanie stworzonej wcześniej warstwy danych.

Jak wdrożyć Data Layer za pomocą GTMa?

Dobra wiadomość jest taka, że nie będziesz do tego potrzebować bardzo zaawansowanej wiedzy programistycznej. A tak szczerze, to nawet ta mniej zaawansowana też nie będzie niezbędna ;). Jedyne aspekty, o które musisz zadać, to odrobina wolnego czasu i upewnienie się, że na Twojej stronie jest już wdrożony Google Tag Manager. Gdy to będzie już za Tobą – postępuj zgodnie z poniższą instrukcją.

Krok 1: przygotuj plan warstwy danych

Oczywiście, najlepiej zrobić to przy okazji instalacji samego GTMa. Na wstępie dopilnuj, o to, aby Twoja warstwa danych spełniała te 3 warunki: była przemyślana, przyszłościowa i skalowalna.

Zastanów się, jakie zmienne będą Ci potrzebne oraz na jakiego typu stronach chcesz je umieścić. Pamiętaj, że zarówno strony kategorii, produktów, jak i artykułów blogowych prezentują inne informacje. Dlatego każda z nich powinna wysyłać też inne dane do GTM. 

W tym miejscu kieruj się zasadą “lepiej więcej niż mniej”. Pomyśl, jakie dane nie są Ci obecnie potrzebne, ale mogą przydać się w przyszłości i je także uwzględnij w swoich warstwach.

Krok 2: zaimplementuj

Przejdź do Google Tag Managera, dodaj nowy Tag i zajmij się jego konfiguracją. Jeśli nie masz jeszcze utworzonego GTMa lub stawiasz w nim swoje pierwsze kroki – rzuć okiem na ten poradnik. Następnie utwórz niestandardowy kod HTML i umieść w nim Twój skrypt (przykład poniżej).

<script>

DataLayer.push ({

‘price’: ‘19,99’

‘category’: ‘obuwie’

‘product’: ‘trampki’

‘size’: ‘45’

});
</script>

Podczas konfigurowania pamiętaj, aby zachować spójność. Nazwa Twojej zmiennej warstwy danych powinna mieć taką samą nazwę również bezpośrednio w kodzie. Szczegółową instrukcję na temat konfiguracji zmiennej znajdziesz w tej instrukcji od Google.

Jeżeli zależy Ci, aby były wywoływane tylko na konkretne typy podstron – pamiętaj o dodaniu takiego warunku w Twoim kodzie. W przypadku artykułów blogowych mogą to być adresy zawierające w sobie /blog/, w przypadku kategorii – wskazujące konkretną grupę produktów (np. /buty-sportowe/), a przy samych produktach – posiadające, chociażby element /product/.

Krok 3: rozwijaj i optymalizuj

Jednorazowe wdrożenie Data Layera wcale nie oznacza, że Twoja przygoda z warstwami danych ma dobiec końca. Przeciwnie! Musisz mieć na względzie, że raz wdrożona warstwa danych powinna być stale rozwijana i dostosowywana – zarówno do zmieniającego się otoczenia konkurencyjnego, branży, jak i potrzeb Twojej firmy. Aby ułatwić sobie to zadanie – koniecznie zadbaj o stworzenie oraz aktualizowanie dokumentacji.

Wykorzystanie warstw danych w e-commerce

Doskonały przykład wykorzystania potencjału Data Layera stanowią transakcje w sklepach internetowych. Wówczas może on stanowić łatwy sposób na przesyłanie wszystkich niezbędnych informacji, które dotyczą takich aspektów, jak: nazwa produktu i kategorii, kod SKU, cena produktu, zamówiona ilość, rodzaj płatności, sposób i koszt dostawy, a dodatkowo także: numer samej transakcji, źródło pochodzenia klienta, wysokość podatku.

W takim obszarze doskonale sprawdza się korzystanie z zaawansowanych skryptów, które pozwalają na przesyłanie danych do Enhanced Ecommerce. W takim przypadku Data Layer może agregować kilkanaście, a nawet kilkadziesiąt różnych zmiennych.

Niezwykle istotnym aspektem jest również elastyczność takiego podejścia. W e-commerce bardzo często mamy do czynienia z dziesiątkami, setkami, a nawet tysiącami produktów. Wiele z nich odznacza się różnymi parametrami (np. cenami), DL pozwala nam na wywoływanie reguł w zależności od tego czy produkt spełnia daną cechę, czy nie. Jest to użyteczne w kampaniach marketingowych.

Dlaczego warto? Korzyści wynikające z wdrożenia i użytkowania warstwy danych.

Data Layer to bez wątpienia ogromny krok w stronę lepszej, wygodniejszej i bardziej efektywnej analityki internetowej, która pozwala lepiej rozumieć zachowania klientów i osiągać lepsze wyniki biznesowe. Dzięki odpowiednio zaplanowanym oraz wdrożonym warstwom danych:

• Zapewnisz sobie solidne źródło cennych danych o klientach i użytkownikach – i to na “wyciągnięcie ręki”.
• Unikniesz informacyjnego chaosu i zapewnisz sobie ciągłość danych – przy odświeżeniu lub całkowitej zmianie Twojej strony.
• Usprawnisz procesy gromadzenia, przetwarzania i wykorzystywania informacji – praktycznie wszystko będzie znajdowało się w jednym miejscu.
• Zyskasz możliwość pełnej customizacji zbieranych danych – to Ty decydujesz, jakie informacje mają trafiać do Twojego GTM.
• Unikniesz konieczności scrapowania danych ze strony – dzięki temu oszczędzisz czas i energię.
• Uniezależnisz się od programistów i działu IT – zdecydowaną większość zmian wprowadzisz we własnym zakresie, bez czekania godzin, dni, a nawet tygodni na reakcję specjalistów od IT .

Data Layer – podsumowanie

Korzystanie z Data Layer, choć tylko pozornie skomplikowane i problematyczne, to tak naprawdę najprostsza i najszybsza droga do tego, aby wprowadzić korzystanie z Google Tag Managera na zdecydowanie wyższy poziom, a co za tym idzie – ułatwić i przyspieszyć Twoją codzienną pracę związaną z analizą danych.

Potrzebujesz wsparcia przy dodaniu i konfiguracji Data Layera w obrębie Twojej strony internetowej?

Nie czekaj i już dziś skorzystaj z niezobowiązujących konsultacji z ekspertami Conversion. Pomożemy Ci zdefiniować Twoje potrzebny związane z gromadzeniem i przesyłaniem odpowiednich danych, a następnie z chęcią zajmiemy się również wdrożeniem niezbędnych zmian, dzięki którym wykorzystasz możliwości, jakie dają Ci odpowiednio skonfigurowane warstwy danych.

The post Data Layer (warstwa danych) – czym jest, do czego służy, jak wykorzystać? first appeared on Conversion.

Jeżeli do tej pory zdarzyło Ci się żyć w przeświadczeniu, że pojawienie się nowej wersji Google Analytics (4) to tylko kolejny, mały i prawdopodobnie nic nieznaczący update tego narzędzia – możesz się “lekko” zdziwić. Otóż, musisz zdawać sobie sprawę, że przesiadka na tę platformę nie ograniczy się jedynie do wizualnej oraz kosmetycznej zmiany interfejsu czy też dołożenia kilku dodatkowych funkcji, które ucieszyłyby tylko zapalonych analitycznych freak’ów.
Wraz z nadejściem ery GA4 zmienił się tak naprawdę cały fundament, na którym opierało się dotychczasowe podejście do agregowania i przetwarzania danych, czy chociażby to, w jaki sposób odbywa się identyfikacja samych użytkowników. I co najlepsze – te zmiany nie są jedynymi. Warto bowiem zauważyć również fakt, iż dane do tej pory zebrane przez UA nie są (i nie będą!) przenoszone do nowszej wersji Analyticsa.

Co jeszcze się zmieni i jak warto się przygotować do tej rewolucji, zanim Google całkowicie odetnie Cię od możliwości korzystania ze starego narzędzia? Poniżej znajdziesz listę aż 7 rzeczy, o których należy pamiętać jeszcze przed podjęciem pierwszych kroków związanych z migracją do GA4.

Co znajdziesz w tym artykule?
#1 Kompletnie odmieniony sposób zbierania danych
#2 Zmiana dataLayerów oraz sposobu implementacji przez GTM
#3 Zmiany w wymiarach i danych niestandardowych
#4 Zmiana z “ręcznego” na automatyczne śledzenie zdarzeń
#5 Zmiana sposobu śledzenia celów X
#6 Zmiana podejścia do kwestii privacy
#7 Zmiana widoków
O czym pamiętać, przed przejściem na Google Analytics 4? Podsumowanie.

#1 Kompletnie odmieniony sposób zbierania danych

U podstaw braku kompatybilności danych pomiędzy obiema wersjami Analyticsa leży fakt, że te narzędzia stosują zupełnie odmienne podejścia do agregowania danych.

W przypadku Universal Analytics całość opierała się na tzw. sesjach, co sprawdzało się w przypadku śledzenia użytkowników webowych. Problem pojawiał się natomiast wówczas, gdy próbowaliśmy porównać dane pochodzące z aplikacji (które to bazowały przede wszystkim na pomiarach zdarzenia) – z danymi webowymi. Biorąc pod uwagę coraz częściej występujące zjawisko cross-device (czyli wykorzystywanie wielu różnych urządzeń na drodze do zakupu), poprzedni GA nie pozwalał więc na całościowe śledzenie drogi, jaką pokonywał dany użytkownik.

W nowej wersji postanowiono oprzeć pomiary nie o sesje, a właśnie o zdarzenia, co było już wcześniej znane, chociażby w Google Analytics dla Firebase. Takie rozwiązanie umożliwia analizę danych pochodzących zarówno z aplikacji, jak i webów, a co za tym idzie – może okazać się kluczowe do wytyczenia wąskich gardeł w biznesie oraz do skutecznego tworzenia kampanii remarketingowych.

Jednak sprawne integrowanie informacji z różnych urządzeń to niejedyna zmiana, jaką przygotował gigant z USA

Otóż, w UA zdarzenia otrzymywały takie oznaczenia, jak: kategoria, działanie, etykieta i wartość. Natomiast przy okazji wdrożenia GA4 postanowiono od tego odejść, a na ich miejsce wybrano tzw. parametry, które mogą być inne dla każdego zdarzenia.

Dla przykładu: Google Analytivs 4 będzie traktował odsłony jako zdarzenie page_view z odpowiednimi parametrami np. page_title, page_location.

Zmianie uległo także podejście do samych sesji, dla których w UA czas był liczony jako różnica pomiędzy pierwszym oraz ostatnim działaniem w sesji. Natomiast w GA4 czas trwania sesji będzie się opierał na zdarzeniach. Za początek sesji uznając zdarzenie session_start, zaś za koniec sesji – moment wystąpienia ostatniego zdarzenia w sesji. Muszę zaznaczyć, że ten czynnik może powodować bardzo znaczne różnice pomiędzy danymi pochodzącymi z UA, a tymi widocznymi bezpośrednio w GA4.

Dużą różnicą w kwestii podejścia do sesji jest to, że gdy użytkownik powrócił na stronę z innego źródła kampanii, sesja w UA wygasała, a następnie rozpoczynała się od nowa. W GA4 taka sytuacja jest z kolei rejestrowana jako jedna sesja, co ponownie może powodować spore rozbieżności pomiędzy tymi narzędziami. Należy również pamiętać, że sesja w GA4 nie wygasa automatycznie po północy, jak to miało miejsce w UA, choć może być liczona 2 razy dla każdego dnia jako osobne sesje.

A czy są jakieś podobieństwa? Jasne! Jednym z nich jest, chociażby czas wygasania sesji – po 30 min od momentu wysłania zdarzenia / działania.

#2 Zmiana dataLayerów oraz sposobu implementacji przez GTM

Przy okazji projektowania GA4, firma Google postanowiła również odświeżyć dotychczasową wersję warstwy danych, która istotnie odróżnia się od tej, którą znaliśmy do tej pory z UA. Zmianie w tej materii uległa zarówno struktura obiektu dataLayer, nazewnictwo poszczególnych parametrów, jak i domyślnie wysyłane parametry dla zdarzeń e-commerce.

Aby ułatwić “przesiadkę” na nowszą wersję, Google udostępniło szczegółowe wytyczne ułatwiające dostosowanie warstw danych dla swojego biznesu.

Jeżeli w tym momencie zasoby firmy nie pozwalają na wdrożenie dataLayerów, które będą w 100 procentach zgodne z nowymi wymaganiami – pamiętaj, że zawsze możesz wykorzystać szablon stworzony przez Simo Ahavę – “EEC Products -> GA4 items”. Jest on dostępny w Google Tag Managerze. Z jego pomocą łatwo uda Ci się zmapować tablicę produktów stworzoną pod UA do wersji GA4, a następnie rozpocząć śledzenie – bez konieczności modyfikacji dataLayer pod GA4.

#3 Zmiany w wymiarach i danych niestandardowych

Dotychczas w Universal Analytics, aby stworzyć wymiar niestandardowy, należało wybrać poziom zakresu danych: użytkownik, sesja, hit, produkt. W przypadku “czwórki” nie będzie już takiej konieczności, albowiem wybór poziomu zakresu będzie się odbywał pomiędzy takimi obszarami, jak: właściwości użytkownika, niestandardowe wymiary i metryki oraz parametry zakupów.

Niestandardowe wymiary i metryki w Google Analytics 4 dodaje się w obrębie zdarzenia – jako parametr. Przy czym trzeba wziąć pod uwagę, że wymiary będące opisem użytkownika należy dodać w obrębie zdarzenia jako właściwość użytkownika (np. zawód).

A co z parametrami niestandardowymi na poziomie itemów, które będą służyły do lepszego opisu produktów w zdarzeniach e-commerce? Na nie przyjdzie nam jeszcze chwilę poczekać, ponieważ obecnie znajdują się w fazie testów.

Kolejną (i to bardzo pozytywną zmianą) jest zwiększenie limitu wymiarów oraz metryk, z dotychczasowych 20 do aż 50 – i to dla każdego z nich. Natomiast limity właściwości użytkowników dla jednego zdarzenia wynoszą 25 na pojedynczą usługę.

#4 Zmiana z “ręcznego” na automatyczne śledzenie zdarzeń

Ważna modyfikacja objęła kwestie związane ze zdarzeniami, które w Google Analytics 4 nie wymagają ręcznego wdrażania. Oczywiście wspomniana automatyzacja nie dotyczy wszystkich, a do zdarzeń, które są nią objęte, możemy zaliczyć następujące:

• wyświetlanie strony*,
• wyszukiwanie w witrynie,
• przewinięcie w dół strony,
• kliknięcia wychodzące,
• interakcja z filmem,
• pobrania pliku,
• interakcje z formularzem.

* Razem z tym zdarzeniem możesz śledzić modyfikacje na stronie na podstawie zmiany historii przeglądania.

Jest jednak jeden mały “haczyk”. Aby zdarzenia mogły być zbierane w sposób automatyczny – musisz pamiętać o uruchomieniu opcji pomiaru zaawansowanego, który znajdziesz w Strumieniu danych. Warto zauważyć, że automatyczne pomiary nie zawsze muszą działać w 100% poprawnie. Źródłami problemów mogą być na przykład niestandardowo zaimplementowane formularze, wyszukiwarki w witrynie albo potrzeba śledzenia głębokość przewijania strony co określony procent. W takich sytuacjach należy zaimplementować śledzenie przez GTM lub gtag.

Warto zastanowić się również, które pomiary mają prawdziwą wartość dla Twojego biznesu, a które są jedynie “zapychaczami”, które tylko ładnie prezentują się w tabelkach. Jest to szczególnie istotne z perspektywy jakości pozyskiwanych informacji. W końcu trzeba pamiętać, że zbieranie wszystkiego “jak popadnie” może generować dużą ilość eventów, a co za tym idzie wpływać na próbkowanie oraz powodować konieczność eksportu danych do BigQuery*.

* W przypadku korzystania z darmowej wersji GA4 mamy do czynienia z limitami eksportu danych z GA4 do Big Query, które wynosi 1 milion zdarzeń na dzień.

#5 Zmiana sposobu śledzenia celów X

Zarówno w UA, jak i GA4 ze śledzeniem celów można sobie poradzić bez konieczności stosowania GTM. To ukłon w stronę marketerów, którzy nie do końca są zaznajomieni z tym narzędziem.

W przypadku śledzenia celów w UA wystarczyło użyć Typu celu “Miejsce docelowe”, czyli adresu URL strony uznawanej jako cel (mogła to być np. strona zakupu). Jeśli chodzi o GA4, można sobie z tym poradzić przy użyciu nowego zdarzenia, w którym: event_name jest równy page_view i page_location równy adresowi URL, który chcemy śledzić.

#6 Zmiana podejścia do kwestii privacy

Nie przesadzę, jeśli stwierdzę, że Google Analytics 4 diametralnie zmienia sposób podejścia do identyfikacji użytkownika. W przypadku Universal Analytics opierała się ona o pliki cookies, co jak łatwo się domyślić – było rozwiązaniem bardzo dalekim od ideału.

W najnowszej wersji Analyticsa postanowiono oprzeć identyfikacje użytkownika na podstawie kilku elementów:

• User ID – ta metoda jest możliwa do zastosowania, gdy użytkownik jest zalogowany do strony bądź aplikacji.
• Google Signals – metoda ta wykorzystuje fakt zalogowania do profilu Google na różnych urządzeniach, co pozwala lepiej “wychwycić” użytkownika – zwłaszcza, gdy regularnie zmienia urządzenia, na których korzysta z sieci.
• Pliki cookie – metoda wykorzystuje dane z ciasteczek zapisanych na urządzeniu lub w przeglądarce.
• Modelowanie behawioralne – metoda jest stosowana, gdy użytkownicy nie wyrażą zgody na ciasteczka. Wówczas Google Analytics stosuje tzw. behavioral modeling, za sprawą którego może uzupełnić powstałą lukę w danych. Narzędzie bazuje wówczas na informacjach na temat zachowań podobnych użytkowników, którzy zaakceptowali zgodę.

Warto zaznaczyć, że Google Analytics wspiera consent mode. To oznacza, że może działać zarówno w przypadku, gdy użytkownik wyrazi zgodę na ciasteczka, jak i bez niej – poprzez wykorzystanie mieszanych danych do zbierania informacji o użytkowniku. To pomaga uzupełniać luki w profilowaniu, urealnia dane, a także przyczynia się to do lepszego zrozumienia dróg użytkowników i celniejszego stosowania remarketingu (np. przy przechodzeniu między aplikacją a desktopem).

Jeśli chcesz dowiedzieć się więcej o kwestiach privacy w GA, to koniecznie zapoznaj się z artykułem mówiącym o tym jak w Google Analytics uzyskać maksymalną zgodność z RODO.

#7 Zmiana widoków

Dotychczas w UA zalecane było stworzenie 3 widoków: dane surowe, filtrowane dane oraz widok testowy. Na widoku testowym weryfikowało się filtry widoku, co działało jako bufor bezpieczeństwa – chroniącym przed ewentualną utratą danych po nałożeniu filtra.

W GA4 istnieje z kolei tylko jeden widok raportowania, w którym stosuje się filtry danych. Rozwiązanie nie posiada widoku testowego, przez co należy obchodzić się z nim bardzo ostrożnie. Bowiem wszystkie zmiany w obrębie filtrów mogą dostarczyć nam błędnych danych za okres z błędnie nałożonymi filtrami.

W Google Analytics 4 możemy wyróżnić 3 typy filtrów danych:

• Ruch wewnętrzny, który odfiltrowuje adresy IP. Gdy taki filtr zostanie stworzony – parametr traffic_type jest automatycznie dodawany do zdarzeń.
• Ruch deweloperski, który odfiltrowuje ruch deweloperów z aplikacji (pod warunkiem że pracują na urządzeniach deweloperskich). Identyfikuje się go za pomocą parametrów debug_mode lub debug_event.
• Filtry z subproperties – Google Analytics 360 udostępnia możliwość stworzenia podzbioru danych (nazywanych subproperties). Podczas tworzenia tej usługi odfiltrowuje się zdarzenia na podstawie ich parametrów takich, jak np. Kraj.

O czym pamiętać, przed przejściem na Google Analytics 4? Podsumowanie.

Jak widzisz, migracja z UA na GA4 wymaga odpowiedniego przygotowania, a także bacznego zwrócenia uwagi na aspekty, które odróżniają oba te narzędzia. Do kluczowych zmian, którym po prostu trzeba się przyjrzeć, zaliczamy modyfikacje dotyczące:

1. sposobu zbierania danych
2. dataLayerów oraz sposobu implementacji przez GTM
3. zmian w wymiarach i danych niestandardowych
4. automatycznego śledzenia zdarzeń
5. sposobu śledzenia celów X
6. podejścia do kwestii privacy
7. widoków

Jeśli chcesz przeprowadzić wdrożenie GA4 sprawnie, koniecznie zapoznaj się z naszym artykułem, w którym pokazujemy jak wdrożyć Google Analytics 4 krok po kroku.

Potrzebujesz wsparcia ekspertów, którzy ocenią poprawność Twojego wdrożenia Google Analytics 4? A może szukasz specjalistów, którzy zajmą się tym procesem za Ciebie?

Choć przejście na nową wersję Analyticsa może wydawać się trudne i skomplikowane – musisz pamiętać o tym, że to narzędzie zostało stworzone po to, aby jeszcze lepiej odpowiadać na potrzeby nowoczesnego biznesu. Mówiąc wprost – po prostu to Ci się opłaca.

Z drugiej strony – Google nie pozostawia nam zbyt dużego wyboru. Firma już dawno ogłosiła, że w lipcu 2023 roku Universal Analytics przestanie działać (czytaj: zbierać nowe dane), a przedsiębiorstwa, które do tego czasu nie zdążą przeprowadzić procesu migracji – zostaną “odcięte” od źródła danych.

A jeśli zaciekawił Cię temat migracja na Google Analytics 4, a 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ć i używać Google Analytics 4!

The post 7 rzeczy, o których musisz pamiętać zanim, przejdziesz na Google Analytics 4 first appeared on Conversion.

Pomimo faktu, że termin finalnego pożegnania się z Google Analytics 360, a co za tym idzie – ostatecznego przejścia na Google Analytics 4 został przesunięty o kolejne 9 miesięcy (w przypadku płatnej wersji tym razem jest to 1 lipca 2024 r. – bezpłatna wersja GA nie uległa zmianom), plany giganta z USA pozostają w tej materii niezmienne. Otóż, prędzej (a tym przypadku – raczej nieco później ), każdy biznes działający w sieci będzie musiał zmierzyć się z wyzwaniem transformacji swojego narzędzia do analityki. Jak do tego podejść, aby taka operacja była stosunkowo “bezbolesna” i pozwoliła na sprawne przełączenie się pomiędzy dwoma odmiennymi rozwiązaniami?

Sprawdź skondensowany poradnik, w którym znajdziesz opis migracji krok po kroku, a dodatkowo – otrzymasz mnóstwo wskazówek, które pozwolą Ci na jeszcze lepszego przygotowanie się do całego procesu zmiany.

Co znajdziesz w tym artykule?
Jak przygotować swój biznes do migracji na GA4?
Migracja na Google Analytics – krok po kroku. Jak ją przeprowadzić?
O czym warto pamiętać podczas transformacji z GA3 na GA4?
Czym jest i jak działa plan tagowania?
A co ze spójnością danych pochodzących z różnych stron lub aplikacji?
Jak skutecznie przejść na nową wersję Google Analytics?

Jak przygotować swój biznes do migracji na GA4?

Jednak zanim przejdę do szczegółowego omówienia konkretnych kroków niezbędnych podczas migracji – pora na małe wtrącenie, a zarazem wskazówkę.

Migruj “z głową” – na początek wprowadzając podwójne tagowanie danych

Moja rada: nie rzucaj się od razu na głęboką wodę. Zamiast całkowitej rezygnacji z poprzedniej (choć nadal aktualnej) wersji Analyticsa, wybierz opcję podwójnego tagowania, czyli jednoczesnego korzystania zarówno z Universal, jak i Google Analytics 4. Taki zabieg zapewni Ci większą kontrolę nad danymi, a co najważniejsze – da możliwość kontroli stanu GA3 i sprawdzania najważniejszych rzeczy (takich, jak: struktura i ustawienia widoków, filtry i konfiguracja celów).

Przejście na nową wersję Analytics będzie również doskonałą okazją do tego, aby bacznie przyjrzeć się obecnemu śledzeniu w Universal Analytics. Z mojego doświadczenia wynika, że większość firm nie przykłada wystarczającej uwagi do jakości danych. Niektórzy robią to okazjonalnie – od audytu do audytu. Z kolei inni kompletnie “odpuszczają” sobie takie działania. Natomiast z mojej perspektywy – powinien to być proces ciągły.

Dopiero gdy uznasz, że migracja przebiegła tak, jak trzeba, a wszystkie dane „zbierają” się zgodnie z założeniami – możesz zrezygnować z podwójnego tagowania.

Migracja na Google Analytics – krok po kroku. Jak ją przeprowadzić?

Aby przekazać Ci jak najwięcej praktycznej wiedzy – poniżej prezentuję, jak wyglądają modelowe wdrożenia GA4, które przeprowadzamy dla klientów Conversion.

Krok pierwszy: organizacja warsztatów

Na początku spotykamy się ze wszystkimi właścicielami firm lub osobami decyzyjnymi, które interesują się danymi online. W tym etapie przeprowadzamy proces mapowania ich potrzeb m.in. pod kątem zachowania samych użytkowników strony, sklepu, aplikacji itp.

Krok drugi: określenie potrzeb biznesowych

Następnie pomagamy klientom wskazać ich konkretne preferencje dotyczące biznesu. Ustalamy między innymi, które działania użytkowników powinny być śledzone, a także bierzemy pod uwagę dotychczasową konfigurację zastosowaną w Universal Analytics.

Krok trzeci: przygotowanie planu tagowania

Wykonanie dwóch poprzednich kroków, czyli odkrycia potrzeb, a następnie wyprowadzenia elementów działania, prowadzi nas do finalnego etapu, czyli opracowania ostatecznego planu tagowania dla konfiguracji GA4 – wraz z listą elementów, które należy naprawić także w GA3.

Nieco więcej o samym planie tagowania opowiem Ci w kolejnych akapitach.

A jeśli chcesz przeprowadzić wdrożenie GA4 samodzielnie, koniecznie zapoznaj się z naszym artykułem, w którym pokazujemy jak wdrożyć Google Analytics 4 krok po kroku.

O czym warto pamiętać podczas transformacji z GA3 na GA4?

Checklista, którą warto się posiłkować podczas tego typu działań:

• Zacznij od małych kroków i nie rób wszystkiego na raz.
• Skup się na śledzeniu kluczowych danych (interakcji), w tym: odsłon, logowań, rejestracji i oczywiście zakupów.
• Działaj powoli, ale konsekwentnie. Ogromne plany tagowania są zwykle wdrażane w ciągu kilku miesięcy. Na początku wdrażaj te, które są dla Ciebie najważniejsze.

Czym jest i jak działa plan tagowania?

Na początku może wydawać się to odrobinę trudne. Jednak sam plan tagowania to swego rodzaju mapa tego, jak będzie wyglądać Twoja implementacja analityki cyfrowej. Osobiście do narysowania takiej mapy używam arkuszy kalkulacyjnych Google.

Załóżmy, że wszystko, co udało Ci się śledzić w Universal Analytics, chcesz teraz skonfigurować bezpośrednio w Google Analytics 4. Jak do tego podejść? Przede wszystkim pamiętaj, że w GA4 model danych jest nieco inny niż w Universal Analytics. W Universal Analytics mamy tzw. hity – dwa najpopularniejsze z nich to odsłony oraz zdarzenia. Musisz je przełożyć na model danych Google Analytics 4.

Każda interakcja będzie śledzona za pomocą zdarzenia, w którym określisz jego nazwę oraz dodatkowe parametry. Do zdarzenia możesz dodać maksymalnie 25 parametrów niestandardowych – określając własne parametry.

Do tego zabiegu możesz zastosować dwa różne podejścia:

• Opcja numer 1: nazwać parametry w GA4 – używając do tego tych, które są domyślne w GA3 (w ten sposób parametry w GA4 zostaną nazwane odpowiednio: kategoria zdarzenia, akcja, etykieta itp.).
• Opcja numer 2: stworzyć spersonalizowane nazwy dla parametrów (pamiętaj, aby jak najdokładniej opisywały, o co chodzi w danym parametrze).

Przykład? W GA3 mamy etykietę wydarzenia, która pokazuje rozmiar odzieży dodanej do koszyka. Załóżmy zatem, że: kategoria zdarzenia = koszyk produktu, akcja zdarzenia = dodaj do koszyka, natomiast etykieta zdarzenia pokazuje dokładny rozmiar (na przykład XL). Na tej podstawie, zamiast nazywać parametry w GA4 etykietą_zdarzenia, nazwalibyśmy to rozmiarem, a dokładna interakcja miałaby następujące parametry:

nazwa_zdarzenia=add_do_koszyka, rozmiar=XL

Oczywiście drugie podejście może zająć trochę więcej czasu, ale im więcej pracy włożysz w przygotowanie i szczegółową konfigurację na początku, tym płynniejsze będzie samo przejście.

A co ze spójnością danych pochodzących z różnych stron lub aplikacji?

Musisz pamiętać, że Google Analytics 4 został stworzony między innymi właśnie po to, aby jak najbardziej uprościć dane na temat zachowania użytkowników sieci. Narzędzie wykonuje swoją pracę pod względem metryk i domyślnych wymiarów.

Mając to na względzie, warto pamiętać, aby wszystkie dodawane przez nas zdarzenia i parametry posiadały odpowiednie nazwy dla wszystkich śledzonych przez nas produktów: stron internetowych, aplikacji mobilnych, aplikacji smart tv, aplikacji punktów sprzedaży itp.

Podsumowując: gdy to samo działanie można wykonać w zarówno aplikacji, jak i na stronie – upewnij się, że posiada ono takie same parametry oraz wartości! Jeśli tego nie zrobisz – z całą pewnością nie będziesz w stanie w pełni korzystać z tego narzędzia.

Jak skutecznie przejść na nową wersję Google Analytics?

Na koniec artykułu, który powstał na podstawie tego podcastu – pozwól, że udzielę kilku rad, które z pewnością ułatwią Ci rozstanie się z GA3, a co za tym idzie – umożliwią płynne i być może bezproblemowe zaprzyjaźnienie się z Google Analytics 4 . Na początek rozpocznij mapowanie swoich potrzeb. Przejrzyj obecną konfigurację Twojego Universal Analytics i zastosuj elastyczne podejście do implementacji.

W ludzkiej naturze jest preferowanie znanego systemu od tego nowego. Dlatego cały proces będzie wymagał on Ciebie trochę dyscypliny. Jednak pamiętaj, że Universal Analytics i tak zostanie w końcu wycofany. A takie jak najwcześniejsze “zmuszanie się” do celowego wybierania interfejsu GA4 częściej niż GA3 pod względem analizy danych – przyniesie Ci spore korzyści, gdy już nadejdzie czas ostatecznego pożegnania ze starym narzędziem.

Osobiście znam co najmniej kilka osób, które całkowicie usunęły śledzenie Universal Analytics, aby po prostu nie pozostawić sobie żadnego wyboru. Nie uważam tego za mądre podejście, ale każdy ma na to swój własny sposób. Jeśli uważasz, że mogłoby się to sprawdzić w Twoim przypadku – droga wolna !

Bez względu na to, jak zdecydujesz się zacząć, zachowaj spokój i dbaj o swoje dane Google Analytics. Jeśli masz dodatkowe pytania – skontaktuj się ze mną na LinkedIn. Bardzo chętnie Ci pomogę. A jeżeli…

Chcesz, aby ktoś inny odpowiedział za cały proces przejścia z Universal Analytics na Google Analytics 4 – powierz to w ręce ekspertów z Conversion.

Z przyjemnością zajmiemy się gruntownym przygotowaniem, jak i kompleksowym wykonaniem wszystkich prac, dzięki którym zyskasz dostęp do w pełni skonfigurowanego źródła wartościowych danych. Kliknij w to miejsce, aby już teraz skontaktować się z naszymi przedstawicielami i porozmawiać o możliwościach współpracy.

A jeśli Twoim celem jest poszerzanie horyzontów z zakresu analityki internetowej i nie tylko – nie zapomnij o regularnych odwiedzinach naszego analitycznego bloga. Jestem przekonany, że zainteresuje Cię wpis o tym dlaczego warto wdrożyć i używać Google Analytics 4!

The post Transformacja biznesu z udziałem Google Analytics 4. Jak się do niej przygotować i jak ją przeprowadzić? first appeared on Conversion.

Pełne wdrożenie Google Analytics, a co za tym idzie – ostateczne “pożegnanie” z jego dotychczasowym odpowiednikiem (Universal Analytics) zbliża się wielkimi krokami. Dokładnie 1 lipca 2023 roku wszystkie usługi tzw. Google Analytics 3 przestaną już działać. A mówiąc wprost – jeśli do tego czasu nie zdążysz “przesiąść się” na nowszą wersję GA – stracisz możliwość gromadzenia, jak i analizowania danych, które są zbierane w obrębie Twojej stronie internetowej.

W dalszej części artykułu podpowiem Ci, jak do tego nie doprowadzić. Czytaj: jak zaplanować oraz wykonać migrację na nowe Google Analytics 4. Zapraszam!

Co znajdziesz w tym artykule?
Jak przygotować się do implementacji GA4?
Migracja z Universal Analytics na Google Analytics 4 – instrukcja krok po kroku
Pamiętaj o aktualizacji lub wdrożeniu nowego kodu śledzącego
Przejście z 3 na 4 wersję Google Analytics – podsumowanie
Po co ta cała zmiana i migracja na GA4? Czy to w ogóle potrzebne?
Potrzebujesz wsparcia w migracji danych do Google Analytics 4?

Jak przygotować się do implementacji GA4?

W trakcie, gdy piszę ten artykuł, do pożegnania GA3 pozostał blisko rok. Jednak z doświadczenia wiem, że nie warto czekać do ostatniego momentu i zająć się tym najszybciej, jak tylko się da. Zanim przystąpisz do właściwej migracji – upewnij się, że znasz odpowiedzi na kilka bardzo istotnych pytań:

• Po 1 – czy wiesz, jakie są Twoje cele? A mówiąc dokładniej – jakie KPI ma realizować Twój serwis internetowy?
• Po 2 – w jaki sposób korzystasz z możliwości Analytics do tej pory? Jakie wskaźniki, dane i inne parametry były brane przez Ciebie pod uwagę?
• Po 3 – jak podchodzisz do strukturyzowania gromadzonych danych? Dzielisz je ze względu na język strony, segment użytkownika itp., a może wszystko wrzucasz do “jednego worka”?
• Po 4 – który moment do mierzenia uważasz za kluczowych? Dodawanie produktów do koszyka, pozostawianie danych kontaktowych, konkretne zachowania użytkowników, a może po prostu – sprzedaż?

Gotowe? W takim razie pora przejść do konkretów!

Migracja z Universal Analytics na Google Analytics 4 – instrukcja krok po kroku

Zobacz, jak zadbać o sprawne przejście oraz podstawową konfigurację usługi Google Analytics 4. Zaznaczam, że poniższy poradnik dotyczy przede wszystkim użytkowników, którzy do tej pory korzystali z możliwości oferowanych przez Universal Analytics.

Krok 1: Uruchom Google Analytics 4

W tym celu wejdź na stronę Google Analytics, przejdź do zakładki Administracja, wybierz stronę, którą chcesz zmigrować, a następnie kliknij odnośnik o nazwie Asystent konfiguracji usługi Google Analytics 4, który znajdziesz tuż pod wybraną usługą. W tym miejscu na Twoim ekranie ukaże się sekcja, w której zyskasz możliwość utworzenia nowej usługi. Kliknij przycisk Zacznij, a gdy na Twoim monitorze pojawi się nowe okno – kliknij Utwórz usługę.
Po tej akcji status asystenta konfiguracji usługi GA4 zmieni się na “Połączono”, a Ty otrzymasz możliwość dalszej konfiguracji nowego narzędzia.

Źródło: Google Analytics

Krok 2: Skonfiguruj Google Analytics 4

W tym celu kliknij Przejdź do usługi GA4, a platforma przeniesie Cię do asystenta konfiguracji. Znajdziesz tu takie obszary, jak: gromadzenie danych, połączenia z innymi źródłami, odbiorcy, konwersje, a nawet opcję zarządzania użytkownikami.
W tym miejscu zyskasz także możliwość połączenia GA4 między innymi z: Google Ads, BigQuery, a także zaimportowania istniejących połączeń Google Ads ze “starego” Universal Analytics. Ponadto ta sekcja będzie również doskonałą okazją do wykonania konfiguracji konwersji, zdefiniowania odbiorców, pomiarów e-commerce, jak i celów.
Te ostatnie, podobnie, jak w przypadku Google Ads – możesz również zaimportować z GA3.

Źródło: Google Analytics

Krok 3: Skonfiguruj zaawansowane funkcjonalności

Ten etap nie jest konieczny, ale jeżeli zajmujesz się zbieraniem, analizą i wykorzystywaniem danych “na serio” – lepiej go nie pomijać.
Na ostatniej prostej możesz skonfigurować, chociażby User-ID, sposób eksportowania danych z GA4 do BigQuery, eksport danych z innych narzędzi (stron i aplikacji), prosto do Analyticsa (za pomocą tzw. measurement protocol), jak również zaimportować do narzędzia wiele innych informacji.

Źródło: Google Analytics

Pamiętaj o aktualizacji lub wdrożeniu nowego kodu śledzącego

Jeżeli wykonasz wszystkie wyżej wymienione czynności – pozostanie Ci już ostatnia rzecz, którą jest wdrożenie kodu śledzącego. Aby to zrobić, wejdź do panelu Google Analytics i z usług i aplikacji wybierz tę, która została stworzona podczas konfiguracji GA4. Na głównym ekranie zobaczysz komunikat “Twoja witryna nie przesłała jeszcze danych.“, z tuż pod nim przycisk Uzyskaj instrukcje tagowania. Wystarczy, że go klikniesz, aby przejść do sekcji, którą z pewnością udało Ci się poznać podczas wdrażania Universal Analytics.
Następnie wybierz sposób tagowania: za pomocą kodu, który umieścisz w sekcjina swojej stronie www lub też przy użyciu menedżera tagów Google.Gdy to zrobisz – “przejście” oraz podstawowa konfiguracja Google Analytics 4 dobiegną końca, a Ty będziesz korzystać z dostępu do danych w zupełnie nowej jakości. Serio!

Źródło: Google Analytics

Przejście z 3 na 4 wersję Google Analytics – podsumowanie

To by było na tyle, jeśli chodzi o kroki, które musisz podjąć, aby “przejść” z GA3 na GA4, a także przeprowadzić podstawową konfigurację tego nowego narzędzia.
Jeżeli czujesz, że jesteś zdecydowanie bardziej zaawansowanym użytkownikiem i już na samym początku chcesz “wycisnąć” z tej platformy jeszcze więcej, to zapraszam Cię do wpisu Mariusza Michalczuka na LinkedIn. Znajdziesz tam kompletny i bardzo rozbudowany poradnik wdrożenia Analytics 4 – i to przygotowany przez samego Google’a!

Po co ta cała zmiana i migracja na GA4? Czy to w ogóle potrzebne?

Jeśli wdrożenie już za Tobą, ale cały czas towarzyszy Ci pytanie pt. “po co zmiana na czwórkę, skoro trójka radziła sobie całkiem nieźle?!” – już odpowiadam.
Jak pewnie wiesz – świat ciągle się zmienia. Pojawiają się nowe regulacje związane z ochroną prywatności w sieci, rozwijają się coraz nowsze technologie, a co najważniejsze – istotnym zmianom ulegają przyzwyczajenia oraz zachowania samych użytkowników.
To wszystko znajduje swoje odzwierciedlenie również w tym, w jaki sposób powinniśmy podchodzić do analityki internetowej. Podejście, jakie sprawdzało się jeszcze kilka czy kilkanaście lat temu, ma się nijak do tego, jak wygląda rzeczywistość.
Technologia również musi nadążać za wszystkimi zmianami, a zadaniem Google Analytics 4 jest właśnie to, aby ich zbieranie, agregowanie oraz analizowanie było nie tylko łatwiejsze, ale przede wszystkim – przynosiło wymierne korzyści.

Potrzebujesz wsparcia w migracji danych do Google Analytics 4?

Jeśli daleko Ci do profesjonalnego analityka internetowego, ale mimo tego chcesz cieszyć się dostępem do wartościowych danych – nie czekaj!
Skontaktuj się z nami, a specjaliści Conversion z przyjemnością pomogą Ci na każdym etapie – oferując zarówno usługi wdrożenia i migracji Google Analytics, jak i fachowe dostęp do fachowych szkoleń z tego zakresu.

Jeśli zainteresował Cię temat migracji na GA 4 to mam nadzieję, że wpis mówiący, o tym co musisz wiedzieć zanim, przejdziesz na Google Analytics 4 również przypadnie Ci do gustu i uzupełni zdobytą dzisiaj wiedzę!

The post Migracja Google Analytics 4: jak zaimplementować GA4 w 3 prostych krokach? first appeared on Conversion.

Jeżeli jesteś na tym blogu, to z pewnością zdajesz sobie sprawę z tego, czym jest i jak działa darmowa odsłona Google Analytics – zarówno w starszej wersji 3 (tzw. Universal Analytics), jak i w jej nowszej odmianie – wersji 4 (która w niedługim czasie ma całkowicie zastąpić swojego poprzednika). Dlatego pozwól, że daruję Ci szczegółowe omawianie specyfiki popularnej “trójki” i zamiast skupiać się na zasadach jej działania – od razu zacznę od przybliżenia Ci, czym jest i jak działa tzw. płatna odmiana popularnego narzędzia, czyli New Google Analytics 360.

Z dalszej części artykułu dowiesz się, co to jest New GA 360, czym różni się jego wersja darmowa od płatnej, jak ją wdrożyć, a także – ile za to wszystko przyjdzie Ci zapłacić. Zapraszam serdecznie!

Co znajdziesz w tym artykule?
Google Analytics 4 w wersji 360. Co to takiego?
Jakie są kluczowe różnice pomiędzy Google Analytics 4 a wariantem 360?
New Google Analytics 360 – ile to kosztuje i od czego zależy finalna cena?
Czy wersja 360 jest dla Ciebie?
Jak przygotować się do zakupu oraz wdrożenia New Google Analytics 360?
A co, jeśli już posiadasz 360, ale w poprzedniej wersji – Universal Analytics?
New Google Analytics 360 – podsumowanie

Google Analytics 4 w wersji 360. Co to takiego?

New Google Analytics 360 to zaawansowane narzędzie analityczne zaprojektowane, aby oferować jeszcze więcej wartości dodanych dla użytkowników narzędzia niż standardowa wersja Google Analytics 4. New Google Analytics 360 pozwoli Tobie elastycznie zarządzać strukturą konta, poziomami dostępu, czy korzystać z niestandardowego raportowania w celu dokładniejszego interpretowania i wykorzystywania danych w obrębie Twoich witryn. Struktura New GA 360 pozwala wykorzystać BigQuery na szerszą skalą, dzięki większym limitom dot. eksportu danych, czy liczby “list odbiorców” do stworzenia (co jest szczególnie ważne przy tworzenie i kierowaniu komunikatów marketingowych przy remarketingu).

Narzędzie premium adresuje również obszar prywatności (które jest jednym z głównym wyzwań w 2022 – resztę wyzwań w 2022 znajdziesz tutaj) gwarantujący najwyższy poziom bezpieczeństwa ujęty w SLA.

Jakie są kluczowe różnice pomiędzy Google Analytics 4 a wariantem 360?

Stosując motoryzacyjną metaforę: jeśli zwykłe GA możemy porównać do cywilnego samochodu osobowego – GA 360 to jego stuningowana – większa, szybsza, mocniejsza i zdecydowanie bardziej funkcjonalna wersja. Mówiąc więc wprost – tego rodzaju rozwiązanie pozwala wynieść analitykę internetową na zupełnie nowy i dużo wyższy poziom.

Od swojego tradycyjnego odpowiednika różni się, chociażby:

• Dostępem do danych historycznych – wersja 360 umożliwia bowiem wgląd nawet do 4 lat wstecz.
• Możliwością przeprowadzania analizy danych w czasie rzeczywistym.
• Pełną elastycznością związaną z zarządzaniem strukturą konta (w tym także dostępami).
• Brakiem limitów dla eksport danych do BigQuery.
• SLA, czyli Service Level Agreement, który gwarantuje bezawaryjność i pewność tego narzędzia.
• Opcją korzystania z kilkudziesięciu wymiarów niestandardowych oraz raportów, które ułatwiają personalizację oraz prowadzenie innych działań marketingowych.

New Google Analytics 360 to także platforma pozwalająca na integrację wszystkich kluczowych narzędzi od Google – taką opcję daje również GA 4 – w tym: Display & Video 360, Search Ads 360, Optimize 360, Tag Manager 360, a także Data Studio.

Usługi Google Analytics 4 oraz New Google Analytics 360

New Google Analytics 360 – ile to kosztuje i od czego zależy finalna cena?

Na ostateczny koszt wdrożenia oraz użytkowania wersji 360 wpływa kilka czynników.
Pierwszym i najistotniejszym jest liczba generowanych zdarzeń miesięcznie. Na nią z kolei wpływa liczba kont, które wchodzą w skład grupy i mają zostać objęte licencją oraz poziom zaawansowania konfiguracji GA4 na poszczególnych kontach. Kolejny czynnik dotyczy regionu, w jakim znajduje się spółka nabywająca daną licencję.
Podczas tej inwestycji należy wziąć pod uwagę również konieczność wydatków, jakie należy ponieść na działania BigQuery. Szczegóły oraz cennik znajdziesz bezpośrednio na stronie Google właśnie pod tym adresem.

Jak widzisz – ostateczny wpływ na koszty związane z użytkowaniem GA 360 są zależne od kilku czynników. Jeżeli chcesz poznać dokładną cenę dla Twojej firmy to skontaktuj się z nami!

Czy wersja 360 jest dla Ciebie?

Nie ma co ukrywać – tego rodzaju rozwiązanie nie jest przewidziane dla każdego. Jeżeli prowadzisz mały e-biznes, który generuje minimalnych ruch na stronach www. Do tego nie zwracasz szczególnej uwagi na dane ani nie przeprowadzasz ich pogłębionej analizy – prawdopodobnie GA 360 nie będzie dla Ciebie dobrym rozwiązaniem.
Jeśli jednak Twoją ambicją jest intensywny rozwój firmy, zdajesz sobie sprawę, że dostęp, a następnie właściwa analiza danych może poprawić Twoje wyniki, a dodatkowo chcesz się ciągle rozwijać – Analytics 360 jest właśnie dla Ciebie!

Jak przygotować się do zakupu oraz wdrożenia New Google Analytics 360?

Proces ten wygląda inaczej, w zależności od tego, na jaki etapie obecnie się znajdujesz. W przypadku, gdy jesteś całkowicie nowym klientem i będzie to Twój pierwszy kontakt z Google Analytics w wersji 360 – postępuj zgodnie z poniższą instrukcją.

• Zaplanuj migrację na Google Analytics 4 – uwzględniając przy tym zarówno wyższe limity, jak i dodatkowe funkcjonalności, które zapewni Ci wersji 360.
• Dokładnie zmapuj wszystkie strumienie danych, które będą generować zdarzenia po pełnej migracji na GA4.
• Sprawdź obecną liczbę generowanych “hitów” – pochodzących ze wszystkich strumieni danych, a następnie przelicz je na zdarzenia (używając do tego współczynnika z zakresu 1 – 2).

Przykład: jeśli generujesz 14 milionów hitów ze strumieni danych (webowych) oraz estymujesz, że aplikacja może generować dodatkowo około 6 milionów hitów – łącznie będzie ich 20 000 000. Przyjmijmy, że współczynnik przeliczeniowy (hity UA -> zdarzenia GA 4) wynosi 1,3. Po przeliczeniu otrzymujemy 26 milionów zdarzeń miesięcznie, które może być wygenerowane przez Twoją konfigurację po pełnej migracji na Google Analytics 4.

• Poproś o wycenę firmę, która jest licencjonowanym partnerem w zakresie zakupu oraz wdrożenia New Google Analytics 360. Możesz to zrobić bezpośrednio tutaj – i skorzystać z fachowej obsługi ekspertów Conversion.

A co, jeśli już posiadasz 360, ale w poprzedniej wersji – Universal Analytics?

W tym miejscu muszę zaznaczyć, że obecnie mamy do czynienia z tzw. okresem przejściowym. Mianowicie, tylko do końca 2022 roku istnieje możliwość przedłużenia 360 zarówno dla “starszego” Universal Analyticsa, jak i jego nowszej wersji, czyli GA 4. W 2023 u wszystkich klientów wymagane będzie posiadanie wyłącznie kontraktu na GA 360.

Zatem, jeśli posiadasz starsze GA i chcesz “przesiąść się” na jego nowszą wersję – oto prosta instrukcja:

• Zaplanuj migrację dotychczasowego narzędzia na Google Analytics 4 – uwzględniając wyższe limity oraz dodatkowe funkcjonalności, które oferuje Ci wersja 360.
• Szczegółowo zmapuj wszystkie strumienie danych, które będą generować zdarzenia po pełnej migracji na GA 4.
• Włącz i przetestuj GA 360 w wersji beta. To bardzo ważne, aby uniknąć ewentualnych błędów oraz potencjalnej utraty cennych danych.
• Użyj wbudowanej funkcji Bill Preview służącej do estymowania miesięcznej liczby zdarzeń w oparciu o dane dostępne w obecnej konfiguracji GA 360.
• Skontaktuj się z firmą i poproś o wycenę – wybierz markę, która jest licencjowanym partnerem w zakresie zakupu oraz wdrożenia New Google Analytics 360.

New Google Analytics 360 – podsumowanie

Google Analytics 4 w wersji 360 to zaawansowane narzędzie adresowane przede wszystkim do firm oraz osób, które chcą “wyciągać” ze swoich danych zdecydowanie więcej niż dotychczas. Jeżeli opierasz swoją działalność głównie na aktywności online i chcesz zbierać, agregować oraz przetwarzać informacje w sposób, który pozwoli Ci zmaksymalizować wyniki finansowe – koniecznie rozważ zamianę klasycznego Google Analytics na jego płatną i zdecydowanie bardziej rozwiniętą wersję 360.

W Conversion, jako specjaliści od analityki internetowej, chętnie pomożemy Ci w całym procesie. Sprawdzimy jak w Twoim przypadku wyglądać będzie wdrożenie GA 360, umożliwimy sprawny zakup, a następnie odpowiemy za przygotowanie oraz finalne wdrożenie.
Jeśli chcesz rozpocząć swoją przygodę z GA 360 lub masz dodatkowe pytania – skontaktuj się z nami. Chętnie przekażemy Ci wszelkie niezbędne informacje. Zapraszam – w imieniu swoim, jak i całego zespołu!

Jeśli ten post Cię zainteresował, a w temacie GA 4 chcesz być na bieżąco – koniecznie obserwuj profil Mariusza Michalczuka na LinkedInie, na którym znajdziesz mnóstwo treści o tej tematyce!

The post Google Analytics 4 vs. New Google Analytics 360. Czy warto “przesiąść się” na płatną wersję GA4? first appeared on Conversion.

Na pewno część z Was spotkała się w swojej pracy z Google Analytics z informacją o próbkowaniu danych.

Przy korzystanie z bardziej zaawansowanych analiz (np. z wykorzystaniem wymiarów dodatkowych lub segmentów zaawansowanych) na pasku funkcjonalnym może nam pojawić się informacja o próbkowaniu.

Co to tak naprawdę dla nas oznacza? Czy powinniśmy się tym przejmować, czy jednak stawiać wnioski z pewną dozą ostrożności? Czy podejmując decyzje na podstawie takich danych możemy być pewni ich trafności?

W tym artykule od podstaw wytłumaczę czym jest i jak działa próbkowanie w Google Analytics? Pokaże na podstawie Google Analytics Premium, jakie przekłamanie niosą raporty próbkowania danych.

Istota próbkowania

Próbkowanie w statystyce oznacza proces, w którym z populacji (np. mieszkańców kraju) losujemy jakąś reprezentację (grupę ludzi) i na jej podstawie podajemy cechy całej populacji. Dobrym przykładem są tutaj badania sondażowe partii politycznych. W sondażach bierze udział pewna część społeczeństwa (próba), która deklaruje poparcie dla danej opcji politycznej. Na tej podstawie następnie jest obliczane poparcie całego społeczeństwa.

Jest to jedyny sposób, aby w ramach ograniczonego budżetu badania opisać całą populację–trudno jest w końcu pytać każdego Polaka z czynnym prawem wyborczy, na którą partię jest skłonny w danym momencie zagłosować. Następuje tu swoista wymiana pomiędzy wartością poznawczą badania, a kosztem przeprowadzenia takiego sondażu. Trudno w końcu co miesiąc organizować mini wybory parlamentarne–badania sondażowe bazują na próbie ok 1-2 tysięcy Polaków.

Próbkowanie (losowanie) polega na tym, że dla na podstawie losowo dobranej próby opisuje się całą populację. Prawa statystyki pozwalają zakładać, że wiedza o populacji uzyskana na podstawie próby jest prawdziwa.

Dzięki mechanizmom losowania (losowego doboru) próby uznaje się, że metryki opisujące próbę odzwierciedlają stan całej populacji. Stąd wyniki sondażowe niemal w całkowitym stopniu pokrywają się z późniejszymi wyborami parlamentarnymi. Ich dokładność zależy tak naprawdę od doboru próby, czyli tego czy agencje badawcze prawidłowo wybiorą ludzi do badania.

Próbkowanie w Google Analytics polega na tym samym, z tym że tutaj zachodzi wymiana pomiędzy dokładnością obliczania metryk, które widzimy w raportach, a czasem ładowania raportów w interfejsie narzędzia. W przypadku dużych serwisów mamy do czynienia z ogromną ilością danych opisujących zachowanie użytkowników. Wszystkie te dane składowane są na odległych serwerach Google. Jeżeli chcemy wykonać analizę bazującą na większym zakresie danych, to Google Analytics musi wówczas odpytać bazy danych znajdujące się na tych serwerach. W związku z ogromną ich ilością nie może wziąć wszystkich pod uwagę, ale uruchamia mechanizm próbkowania, którym w tym większym stopniu działa, im większy ruch (więcej danych) generuje serwis.

Próbkowanie w Google Analytics

Część z Was może zadać pytanie: „Ok, mam bardzo duży ruch, ale kiedy włączam wszystkie „podstawowe” raporty, to nie widzę, aby dane były próbkowane. Dopiero w momencie włączenia segmentu zaawansowanego lub dodania wymiaru dodatkowego mechanizm próbkowania daje o sobie znać.”

Dokładnie tak jest. Dane, które widzimy w predefiniowanych raportach są obrazem wszystkich danych leżących na serwerze. Poniżej pewnego progu (o tym w dalszej części artykułu) nie są one próbkowane. Można zobrazować to w ten sposób:

Raporty standardowo, pomimo dużego ruchu nie mają włączonego próbkowania danych, ponieważ bazują na predefiniowanych tabelach w bazie danych Google Analytics. Aktualizowane są one (1) raz dziennie. My w raportach Google Analytics możemy oglądać je w czasie rzeczywistym (2).

Na poziomie usługi przechowywane są surowe, cząstkowe dane dotyczące ruchu użytkowników. W każdym widoku danych tworzony jest zestaw predefiniowanych raportów, które korzystając z codziennie odświeżanych tabel, które zawierają zagregowane dane. Dzięki temu (do pewnego progu) takie raporty nie są próbkowane.

Dopiero w momencie, w którym chcemy nałożyć segment zaawansowany lub po prostu utworzyć raport niestandardowy, to interfejs musi sięgnąć do surowych danych zgromadzonych „głębiej” na serwerze i od początku je przeprocesować (omijając krok 2). Jeżeli tych danych jest tam bardzo dużo, to na poczet szybszego ładowania się docelowego raportu dane te są selekcjonowane tzn. próbkowane. To co widzimy w raporcie końcowym jest efektem obliczeń na podstawie wylosowanej próby.

Nie wszystkie raporty predefiniowane mają takie same progi, powyżej których są próbkowane. Wyjątek stanowią raporty ścieżek wielokanałowych oraz raporty przepływu. Tutaj próbkowanie następuje znacznie szybciej.

Z dużą ilością danych związane jest również zjawisko pojawiania się „(other)” w raportach. Na ten temat jednak Paweł pisał oddzielny artykuł. Przeczytacie w nim, jaki jest powód powstawania tej wartości wymiaru w raportach oraz jak sobie z nim radzić.

Oprócz tego, że raporty mogą bazować na próbkowanych danych, to takie próbkowanie możemy samodzielnie zdefiniować z poziomu kodu śledzącego. W przypadku ustawienia poziomu próbkowania np. na poziomie 50%, co drugi użytkownik brany jest pod uwagę tzn. śledzone jest jego zachowanie. Więcej na ten temat można przeczytać na stronie pomocy Google Analytics.

Co to znaczy „duży ruch”?

Metryki pokazywane w raportach Google Analytics będą poddane próbkowanie w jednym z dwóch przypadków. Każdy z nich oczywiście zależy od wolumenu ruchu, jaki generuje nasz serwis.

Próbkowanie włączy się w przypadku, którym nasz „niestandardowy” raport będzie wymagał dostępu do większej niż 1 milion unikalnych kombinacji wymiarów. Powiedzmy, że chcemy wygenerować raport, który będzie pokazywał wejścia oraz współczynnik odrzuceń dla kombinacji wymiarów: strony, przeglądarka oraz rozdzielczości ekranu. Kombinacja tych trzech wymiarów daje nam tabelę, która ma ponad 1 milion wierszy. W takim wypadku Google Analytics wyświetli nam 1 milion / liczbę dni, dla których chcemy pokazać analizę.

Jeżeli nasze „niestandardowe” zapytanie dotyczy więcej niż 500k sesji (może to łatwo nastąpić dla dłuższych okresów czasu), to wówczas dane do kalkulacji będą wzięte dla maksymalnie 500k sesji. W rzeczywistości, w momencie kiedy próbkowanie sią włącza, to mamy informację, dla jakiej liczby sesji zostały obliczone poszczególne metryki. Standardowo próbka określona jest na ok 250k sesji, ale na korzyść większej dokładności obliczeń metryk możemy wybrać wolniejszy czas ładowania się raportów.

Jeżeli wolimy dysponować bardziej dokładnymi danymi i nie śpieszy nam się tzn. godzimy się na dłuższy czas ładowania raportów, to mamy możliwość wyboru poziomu próbkowania.

Precyzja próbkowania

Z założenia próba powinna odzwierciedlać całą populację, więc metryki obliczone na jej podstawie powinny być analogiczne dla całej populacji. Na pewno mniejszych przekłamań możemy spodziewać się na poziomie metryk względnych (współczynniki, średnie). Gorzej jest w przypadku metryk nominalnych, ponieważ ich wartości obliczane są po prostu jako wynik z próby pomnożony przez współczynnik próbkowania (jeżeli na podstawie próby wyjdzie, że dany wymiar miał np. 200 sesji, to przy 20% próbkowaniu dla całej populacji wartość tego wymiaru zostanie określona jako 5 x 200 = 1000 sesji).

Jak jest w rzeczywistości? Do sprawdzenia tego wykorzystaliśmy Google Analytics Premium. W wybranym raporcie „zadaliśmy pytanie” dotyczące wybranego segmentu ruchu. Otrzymaliśmy następujące wyniki:

Przy ok. 30% próbkowaniu otrzymaliśmy powyższe wyniki. Jak za chwilę zobaczymy próba dobrana do wyświetlenia metryk w interfejsie podała w bardzo dużą dokładnością prawdziwe dane.

Po „zamówieniu” raportu niepróbkowanego okazało się, że metryki obliczone na podstawie wszystkich danych kształtują się następująco:

Jak się okazuje wyniki pokazywane przez interfejs na podstawie ok. 30% próby nie odbiegają bardzo od rzeczywistości.

W związku z tym możemy uznać, że mechanizm próbkowania zadziałał prawidłowo. Jednak aby potwierdzić tą prawidłowość musielibyśmy powtórzyć powyższą analizę dla różnych wymiarów i metryk. Z pewnością wymiary, które normalnie są mniej reprezentowane w całej populacji mogą być niedoszacowane (trudniej jest je wylosować i na tej podstawie rzetelnie oszacować ich statystyki).

Czym dla nas skutkują ewentualne rozbieżności?

Po pierwsze, jeżeli danych Google Analytics używamy do celów kontrolingowych, to próbkowanie możemy wpłynąć na rzetelność wyników. Jeżeli raportujemy dane do systematycznych podsumowań, to w związku z próbkowaniem nasza praca może być niewłaściwie oceniona.

Również w przypadku analiz–złe dane, to w dalszej kolejności błędne wnioski i nietrafne rekomendacji, a więc błędne decyzje biznesowe. Wyzwanie w takim wypadku może okazać się poważne. Zwłaszcza, kiedy rekomendujemy działania, które wynikają z niepoprawnych danych.

Jak możemy się przed tym bronić?

Co zrobić, aby nasze analizy, a więc wnioski i rekomendacji zawsze bazowały na poprawnych (niepróbkowanych) danych?

Po pierwsze możemy przejść na Google Analytics Premium. Jeżeli generujemy na tyle duży ruch, który jest dla nas wyzwaniem przy jego analizie, to najprawdopodobniej zarabia on na nas na tyle, że powinniśmy być w stanie zainwestować w narzędzie klasy premium. Pamiętajmy, że nie jest to inwestycja bezzwrotna–analizy danych z pewnością pozwoli na poprawę naszej efektywności, a tym samym na zwiększenie przychodów/zysków z biznesu. Jestem przekonany, że inwestycja w Google Analytics Premium ma duży zwrot–warunkiem oczywiście są zasoby, które te dane są w stanie przekuć na trafne decyzje biznesowe.

Co więcej, w samym Google Analytics Premium otrzymujemy dostęp do BigQuery–systemu zarządzania bazą surowych danych Google Analytics, który umożliwia nam dostęp do bardzo granularnych danych–nawet na poziomie pojedynczych hitów. Na tej podstawie możemy tworzyć bardzo zaawansowane modele matemtyczne, które posłużą nam do prognozy przyszłej efektywności na podstawie scenariuszów zachowania naszego makrootoczenia.

Jeżeli jednak nie możemy sobie pzowlić na zakup licencji Google Analytics Premium, to również są sposoby, aby w jego bezpłatnej wersji walczyć z próbkowaniem. Poniżej podaję kilka możliwości:

• W związku z tym, że próbkowanie zachodzi na poziomie usługi, to możemy tak zaplanować strukturę naszego konta Google Analytics, aby poszczególne jego sekcje śledzone były oddzielnymi usługami. Zmniejszy to ilość danych napływającą do naszego konta, a tym samym prawdopodobieństwo próbkowania. Taka struktura może wyglądać w sposób następujący:

Odpowiednia struktra konta pozwala zniwelować próbkowanie. Wystarczy, że każdą sekcję serwisu będziemy śledzili w ramach pojedycznych usług (próbkowanie zachodzi na poziomie usługi). Dodatkowo możemy utworzyć roll-up account, w którym tak czy inaczej będziemy śledzili cały serwis.

• W związku z tym, że próbkowanie dotyczy zazwyczaj dłuższych okresów czasu (większej ilości danych), to zawsze możemy skorzystać z API Google Analytics i samodzielnie tworzyć większe zbiory danych. Polega to na tym, że odpytujemy API pod dniach, a następnie dni łączymy w tygodnie, miesiące, lata obliczając samodzielnie metryki dla większych agregatów. Pomocne tutaj mogą okazać się zewnętrzne narzędzia jak Shufflepoint czy Analytics Canvas, które tę pracę dużej mierze za nas zautomatyzują.
• Zawsze w końcu możemy narzucić próbkowanie na poziomie kodu. Wydaje się, że taki sposób próbkowania jest zdecydowanie lepszy niż w przypadku próbkowania na poziomie raportów–niestety nie sprawdzaliśmy nigdy tego empirycznie, ale myślę, że może to być ciekawe studium przypadku.

Podsumowanie

Jak okazało się na podstawie przeprowadzonego eksperymentu, próbkowanie danych w Google Analytics nie przynosi duży rozbieżności pomiędzy wylosowaną próbką a stanem faktycznym. Jednak dane zostały wygenerowane na podstawie jednego segmentu.

Warto mimo wszystko swoje decyzje biznesowe podejmować na większości danych, którymi dysponujemy. Dlatego walka z próbkowaniem jest bardzo ważna. Najłatwiejsze rozwiązanie to inwestycja w narzędzie klasy premium. Jednak są również sposoby walki z próbkowaniem w bezpłatnej wersji Google Analytics. Czy macie inne, niż podane powyżej sposoby? Podzielcie się w komentarzach!

The post Próbkowanie danych w Google Analytics first appeared on Conversion.

U jednego z naszych Klientów system obsługujący wysyłkę newsletterów nie posiadał systemu raportowania danych takich jak Open Rate (OR) czy Click Through Rate (CTR). Naszym celem współpracy z IT klienta było stworzenie rozwiązania umożliwiającego raportowanie tych danych oraz przekazanie ich do konta Google Analytics.

Rozwiązanie

Wypracowana koncepcja zakładała wykorzystanie Measurement Protocol (tutaj link do dokumentacji Google) w celu przekazania do Google Analytics informacji o liczbie wysłanych maili, liczbie ich otwarć oraz kliknięć w link z maila. Measurement Protocool umożliwia przesłanie danych bezpośrednio do Google Analytics i przekazania odpowiednich parametrów (tutaj link do listy parametrów).

W ramach konta została stworzona dodatkowa usługa: UA-XXXXXX-2, przeznaczona do odbioru danych mailingów. W ramach usługi włączono przekazywanie Universal ID (UID), a długość sesji została maksymalnie zwiększona, czyli 4 godzin.

Konfiguracja UserID na poziomie usługi do odbioru danych z mailingów. Aby śledzić mailingi za pomocą Measurement Protocool konieczne jest identyfikacja użytkownika na każdym z etapów, dlatego przekazujemy UserID

Konfiguracja czasu sesji na poziomie usługi do odbioru danych z mailingów. Aby śledzić mailingi za pomocą Measurement Protocool konieczne jest zachowanie ciągłości sesji, dlatego ustawiamy długość sesji do maksymalnej możliwej wielkości, czyli 4 godzin.

Do Google Analytics za pomocą wirtualnych odsłon powinny raportować się 3 typy danych:

1. wysyłki maili – /wysylki
2. otwarcia maili – /otwarcia
3. kliknięcia w link z maila – /klikniecia/{{email_section}} gdzie email_section to sekcja maila w którą kliknął użytkownik przekazana w linku za pomocą zmiennej

Dane będą raportowane na poziomie:

1. wysyłki maili – serwer pocztowy, za pomocą Measurement Protocol
2. otwarcia maili – program pocztowy, za pomocą Measurement Protocol
3. kliknięcia w link z maila – na stronie po przejściu z maila za pomocą kodu Universal Analytics

Na podstawie danych przekazanych do Google Analytics skonfigurowaliśmy cele (ze ścieżką), za pomocą których można raportować:

1. 1. Open Rate (OR) = otwarcia maili / wysyłki maili

Konfiguracja Celu Open Rate na poziomie widoku do odbioru danych z mailingów. Open Rate (OR) = otwarcia maili / wysyłki maili, dlatego ustawiamy miejsce docelowe na /otwarcia z pierwszym krokiem na /wysylki

1. 1. Click Through Rate (CTR) = kliknięcia w link z maili / wysyłki maili

Konfiguracja Celu Click Through Rate na poziomie widoku do odbioru danych z mailingów. Click Through Rate (CTR) = kliknięcia w link z maili / wysyłki maili, dlatego ustawiamy miejsce docelowe na /klikniecia z pierwszym krokiem na /wysylki

Aby całość raportowała się poprawnie, sesja nie może być przerwana, ID usera (UID) musi być takie samo, a źródło odwiedzin nie może się zmieniać. Aby źródło odwiedzin pozostało niezmienione, konieczne było otagownie linków tak aby przekazywały się parametry utm: źródło, medium oraz kampanie.

Wdrożenie Measurement Protocool

W ramach Measurement Protoocol przekazujemy, oprócz wirtualnej odsłony UID oraz parametry utm danej kampanii, oznaczone zgodnie ze schematem tagowania, oraz identyczne na każdym z etapów (wysyłka, otwarcie, kliknięcie).

1. Uid – jest to unikalne id użytkownika z bazy mailingowej, przekazane jako ciąg cyfr i liter. Nie może to być adres email np. abc123efg
2. Utm_campaign – nazwa kampanii np. kampania1
3. Utm_medium – medium kampanii np. e-mail
4. Utm_source – źródło kampanii np. mailing-baza123
5. Email_section – jest to parametr określający w którą część z maila użytkownik kliknął. Przykładowo, może to być naglowek.

Przykładowy request wysłany na serwerze pocztowym:
https://www.google-analytics.com/collect?v=1&tid=UA-XXXXXXXX-2&t=pageview&cn=kampania1&cs=mailing-baza123&cm=e-mail&t=pageview&dp=/wysylki&uid=abc123efg&cid=35009a79-1a05-49d7-b876-2b884d0f825b

W zależności od konfiguracji serwera (i wielkości bazy mailingowej), można rozważyć wysyłkę requestów w paczkach, tak, aby zbyt duża liczba requestów w tym samym czasie nie została zablokowana.

Aby móc wykorzystać Measurement Protocool w ramach wiadomości e-mail potrzebujemy maila w formacie HTML. Jest to konieczne, ponieważ musimy spowodować, aby request Measurement Protocool został wywołany, co możemy zrobić symulując pobranie obrazka z zewnętrznego serwera. Fragment kodu html maila powinien wyglądać w ten sposób:

Przykładowy kod w treści maila:

 img src=”https://www.google-analytics.com/collect?v=1&tid=UA-XXXXXXXX-2&t=pageview&cn=kampania1&cs=mailing-baza123&cm=e-mail&t=pageview&dp=/otwarcie&uid=abc123efg&cid=35009a79-1a05-49d7-b876-2b884d0f825b/>

Fragment pierwszy:
https://www.google-analytics.com/collect?v=1
Odpowiada za wysłanie danych na serwer GA oraz wersję protokołu, która obecnie równa się “1”. Ten fragment się nie zmienia.

Fragmenty pozostałe:

1. tid=UA-XXXXXXXX-2 – numer ID naszego profilu Google Analytics
2. t=pageview – typ zdarzenia (hit type)
3. cn=kampania1 – nazwa kampanii (campaiqn name)
4. cs=mailing-baza123 – źródło kampanii (campaiqn source)
5. cm=e-mail – medium kampanii (capaign medium)
6. dp=/otwarcia– ścieżka dokumentu (document path)
7. uid= – user ID
8. cid=35009a79-1a05-49d7-b876-2b884d0f825b – tzw. Client ID czyli unikalny identyfikator użytkownika. Wartość tej zmiennej powinna być wygenerowana dla każdego użytkownika osobno, zgodnie z dokumentacją o UUID (wersja 4) < link do http://www.ietf.org/rfc/rfc4122.txt. >

Informacji przesyłanych za pomocą Measurement Protocool nie można sprawdzić w konsoli przeglądarki. Jednak niedawno Google stworzył narzędzie, dzięki któremu możemy zwalidować, czy napisany przez nas request jest poprawny. Wystarczy w pierwszej części linka wpisać /debug/collect zamiast /collect i po wejściu w ten link zostaniemy przekierowani do strony z walidacją requesta.

Przykładowy request do walidacji:
https://www.google-analytics.com/debug/collect?v=1&tid=UA-12345678-2&t=pageview&cn=kampania1&cs=mailing-baza123&cm=e-mail&t=pageview&dp=/wysylki&uid=abc123efg&cid=35009a79-1a05-49d7-b876-2b884d0f825b

Strona z walidacją poprawności requestu dla Measurement Protocool, gdzie możemy sprawdzić czy skonfigurowany przez nas request jest poprawny.

Wdrożenie kodów Universal Analytics

Ostatni etap, czyli kliknięcia w link z maila raportują się na stronie, za pomocą kodu Universal Analytics. Poniższy skrypt powinien się wywoływać na każdej stronie po przejściu z mailingu, czyli wtedy gdy parametr email_section istnieje. Po wejściu na stronę powinna wywołać się wirtualna odsłona:

/klikniecia/
gdzie jako zmienna zostanie przekazana nazwa sekcji w którą kliknął użytkownik, np.
/klikniecia/naglowek

Kod:

  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');
 
  ga('create', 'UA-XXXXXXXX-2', {'name': 'mailing'}, 'auto' );
  ga('mailing.set', '&uid',  {{USER_ID}}); 
  ga('mailing.send', 'pageview', '/klikniecia/');

Tworząc drugi tracker na stronie należy pamiętać o tym, aby nadać mu nazwę (w tym przypadku jest to mailing), oraz wysłać wirtualną odsłonę właśnie do tego trackera.

Całość będzie dobrze działała, w sytuacji gdy użytkownicy szybko otwierają maile po ich wysyłce (co było kwestią u naszego klienta), bo wtedy sesja nie zostanie przerwana. W innych przypadkach (czasu dłuższego niż 4 godziny od wysyłki do otwarcia) sesje zostaną przerwane, ale możemy za pomocą API wyeksportować liczbę unikalnych użytkowników na każdej ze stron w podziale na kampanie i mieć 100% pewność, że dzielenie sesji nie ma wpływu na wyniki tego co oglądamy.

Podsumowanie

Dzięki zastosowaniu Measurement Protocool możemy wysłać requesty (jak np. pageview, event czy transakcja) bezpośrednio do Google Analytics, przekazując odpowiednie parametry.

W tym poście pokazałem jak można wykorzystać to rozwiązanie do śledzenia skuteczności mailingów w ramach Google Analytics. Ponieważ requesty Measurement Protocool nie są widoczne w konsoli przeglądarki, możemy zastosować to rozwiązanie to przekazywania informacji, których nie chcemy ujawniać użytkownikom, przykładowo jeśli w ramach śledzenia ecommerce chcemy przekazać marże dla każdego produktu wchodzącego w skład danej transakcji. Dzięki zastosowaniu Measurement Protocool konkurencja nie będzie mogła podejrzeć poufnych informacji przesyłanych przez nas do Google Analytics

The post Śledzenie mailingów w Google Analytics za pomocą Measurement Protocol first appeared on Conversion.

Na początek kilka słów wstępu dla osób, które nie poruszają się na co dzień w techniczno-informatycznym żargonie. Czym w ogóle jest API? API to skrót od angielskiego Application Programming Interface. W języku polskim zwykło tłumaczyć się te słowa jako: „programistyczny interfejs aplikacji”, ale najczęściej mówi się po prostu „API”.

Jest to zestaw reguł, których muszą przestrzegać dwie komunikujące się aplikacje, by mogły się porozumiewać i wymieniać informacje. Aby ta komunikacja przebiegała sprawnie i bez zakłóceń wszystkie „rozmawiające” ze sobą programy muszą używać nie tylko wspólnego „języka”. Muszą też przestrzegać pewnych wymogów technicznych, przykładowo – nie nadawać informacji, gdy druga strona „konwersacji” nie skończyła jeszcze nadawać swoich (jakie to bliskie nam wszystkim).

Szczęśliwie dla nas, Google Analytics nie jest jedynie kapsułą, do której dostęp mamy tylko przez małe okienko naszej przeglądarki internetowej. Dzięki API mamy możliwość dobrania się do jego wnętrza i wyciągnięcia stamtąd wielu danych i informacji, w konfiguracjach, które nie są dostępne w standardowym interfejsie graficznym użytkownika. Wymaga to jednak stworzenia programu komputerowego, który będzie „rozmawiał” z API Google Analytics i pozyskiwał dla nas informacje, których żądamy.

Celem tego posta nie jest wchodzenie w informatyczne szczegóły pisania programów wykorzystujących API GA, lecz przedstawienie kilku pomysłów na nie. O technikaliach można dużo poczytać na stronach developers.google.com.

#1 Super Dashboardy

Oglądacie czasami filmy sensacyjne lub science-fiction? Od czasu do czasu przewija się w nich motyw wielkich centrów dowodzenia (coś takiego jak ma NASA – patrz fotografia niżej)

API Google Analytics pozwala na pobieranie i późniejsze przetwarzanie wielu informacji. Nic nie stoi zatem na przeszkodzie, aby przy odrobinie wysiłku, przekształcić swoje biurko w mini-centrum kontroli i analiz zachowań użytkowników. (źródło: www.space.com)

Prawda, że 12 widżetów w niestandardowych panelach informacyjnych Google Analytics wygląda przy tym trochę blado? Przecież na co dzień analizujemy wielowymiarowe dane z całych ekosystemów witryn internetowych, więc dlaczego nie postawić w biurze wielkiego video-wall’a, na którym będziemy mieli wszystkie informacje podane jak na tacy? Możemy uzyskać dzięki temu możliwość błyskawicznego reagowania na wszelakie anomalie w zbieranych danych.

API Google Analytics umożliwia pobieranie danych historycznych oraz „na żywo”. Wystarczy nam więc program, który te dane będzie pobierał i aktualizował w sposób automatyczny (np. z sekundowym interwałem czasowym), a następnie za pomocą bibliotek graficznych, prezentował na ekranie w sposób, który jest dla nas najwygodniejszy. Dzięki zastosowaniu API, nie jesteśmy związani ograniczeniami, które występują w klasycznym interfejsie Google Analytics, więc możliwości dostosowania prezentacji danych jest tyle ile podsuwa nam nasza kreatywność.

Jeżeli nie chcecie zgłębiać tajników programowania to równie dobrze możecie wykorzystać API Google Analytics, aby tworzyć kokpity menedżerskie z wykorzystaniem Excel’a, Google Docs, lub w dedykowanej aplikacji, która korzysta z gotowej biblioteki JavaScript (rysunek poniżej).

Istnieje możliwość skorzystania z narzędzi, które ułatwiają budowanie dashboard’ów z wykorzystaniem Google Analytics API. Pozwalają ona na dostosowanie sposobu prezentacji danych do naszych oczekiwań (źródło: ga-dev-tools.appspot.com)

#2 Efektywne zarządzanie konfiguracją

Czasami spotykam się z problemami, które trzeba rozwiązać np. poprzez wprowadzenie zmian w konfiguracji widoku w Google Analytics. Myślę tutaj o nałożeniu na widok dodatkowego filtra, zmianę w konfiguracji celu i inne tego typu zadania.

Niewielkim nakładem sił można zmienić ustawienia w dwóch, czy czterech widokach. Co w przypadku, gdy tych widoków będzie 100 i we wszystkich trzeba poprawić kilka celów? Żeby było bardziej dramatycznie, dołóżmy do tego wymóg, że trzeba zmienić tylko jedną literę w drugim kroku ścieżek celów, które w nazwie mają przedrostek „[conversion]”. Wizja wielu godzin spędzonych nad tym zadaniem nie wydaje się zbyt pociągająca.

Z pomocą znów przychodzi nam API Google Analytics. Możliwe jest napisanie sprytnego oprogramowania, które najpierw pobierze wszystkie cele w interesujących nas widokach i odfiltruje te, które mają charakterystyczny przedrostek. Następnym krokiem będzie wyszukanie w ścieżce każdego z celów tej konkretnej litery i zastąpienie jej tą właściwą. Następnie program powinien dla każdego rozpatrywanego celu wysyłać żądanie do Google Analytics, które zmieni tylko konkretny krok w ścieżce rozpatrywanych celów.

Jak widać, wykorzystanie API jest świetnym rozwiązaniem, które może zdecydowanie skrócić czas wykonywania pewnych zadań. Szczególnie dla osób zarządzających bardzo dużymi konfiguracjami Analytics’a.

Podobnie do przedstawionego wyżej przykładu, może wyglądać zarządzanie użytkownikami narzędzia analitycznego w dużych organizacjach (wiem, że takie zadanie potrafi pochłonąć mnóstwo czasu. Szczególnie, gdy mówimy o firmach, posiadających wiele witryn).

Naszą przykładową aplikację można rozbudowywać o kolejne elementy, np. o wprowadzanie zmian do konfiguracji zgodnie z ustawionym harmonogramem. Znowu, możliwości jest naprawdę dużo.

#3 Integracja baz danych

Wiele firm prowadzi analizy, które oparte są na danych pochodzących z Google Analytics. Jeszcze więcej firm chciałoby prowadzić analizy, które będą oparte na danych, które zbiera narzędzie Google Analytics, ale także na tych danych, które przechowuje ich wewnętrzny system informatyczny. Oczywiście, można wygenerować niestandardowy raport, pobrać go, a następnie za pomocą jakiegoś zewnętrznego narzędzia połączyć z konkretną tabelą z bazy danych. Gdy jednak okazuje się, że ten ciąg czynności trzeba powtarzać codziennie staje się to co najmniej uciążliwe. Komputer może nas przecież wyręczyć w wykonaniu tego zadania, dodatkowo zrobi to szybciej i dokładniej.

Dobrym przykładem jest integracja danych, które zawiera firmowy CRM z danymi Google Analytics. W wewnętrznym systemie firmy przechowuje się dane o transakcjach zawierające informacje, które niekoniecznie dostępne są w Google Analytics (marża, historia klienta itp.). Za to w Google Analytics znajdują się informacje, których próżno szukać w CRM’ach.

Aby prowadzić skuteczne analizy, warto połączyć te dwa światy i poddać analizie dopiero końcowy efekt operacji połączenia danych z dwóch źródeł. Zarówno transakcje w CRM’ie, jak i te rejestrowane przez Google Analytics posiadają unikalny kod transakcji. Jest to naturalny kandydat na klucz do połączenia tych dwóch zestawów danych. Nasz hipotetyczny program za pomocą API może pobierać konkretne dane, a następnie przeprowadzić operację ich integracji. Szybkie i wygodne.

Podsumowując, API Google Analytics jest świetnym i darmowym narzędziem w rękach programistów, szczególnie, że wspiera najpopularniejsze języki programowania (Java, PHP, Python). Dzięki jego wykorzystaniu, mamy możliwość zautomatyzowania pewnych czynności, które wymagają dużej ilości czasu. Możemy wykonywać naszą pracę lepiej i dokładniej.

API jest też zdecydowanie szybsze niż standardowy interfejs graficzny Google Analytics, choć posiada swoje ograniczenia, jak na przykład maksymalną liczbę 10 żądań na sekundę (czytelniku, spróbuj wygenerować 10 raportów w ciągu sekundy nie wykorzystując API).

Jeżeli macie jakieś super pomysły na wykorzystanie API Analytics’a to zapraszam do podzielania się nimi w komentarzach.

The post 3 sposoby do wykorzystania API w Google Analytics do lepszych i szybszych analiz first appeared on Conversion.

Mówi się, że w życiu nie ma nic za darmo – aby osiągać swoje cele, należy najpierw poświęcić pewne zasoby (czasowe lub finansowe). Inwestując wspomniane środki w różne działania, zwykle chcemy wiedzieć, czy przynoszą one pożądany efekt, aby w przyszłości móc lokować je jeszcze lepiej.

Jeżeli chodzi o prowadzenie działalności marketingowej w internecie zwykle nie ograniczamy się do jednego medium. Problem w tym, że różne narzędzia i systemy różnie raportują dane o skuteczności działań i nie lada wyczynem jest porównanie ich w łatwy sposób.

Spójrzmy w raporty Google Analytics pewnego sklepu internetowego, który pozyskuje ruch z różnych, płatnych źródeł (zrzut ekranu poniżej).

Patrząc w raporty, w których dane o kosztach nie zostały zaimportowane do interfejsu Google Analytics, można wysnuć błędne wnioski dotyczące np. opłacalności inwestycji w pewne źródła ruchu. Na podstawie powyższego raportu moglibyśmy podjąć decyzję o zwiększeniu inwestycji w źródło znajdujące się najwyżej w tabeli. Przedstawiony raport nie uwzględnia bowiem kosztów pozyskania ruchu ze źródeł. Jeżeli koszty dla „ceneo.pl” okażą się wysokie to ROI z innych źródeł może okazać się korzystniejsze.

Wyraźnie widać, że źródło „ceneo.pl” jest lepsze od „nokaut.pl” pod względem współczynnika konwersji. Nie jesteśmy jednak w stanie powiedzieć, czy to do końca prawda, do momentu, w którym nie poznamy informacji o kosztach pozyskania tego ruchu.

Google Analytics od jakiegoś czasu pozwala na import danych o kosztach, pochodzących z zewnętrznych (nie-Google’owych) źródeł, do swojego interfejsu. W tym wpisie postaram się pokazać w jaki sposób można tego dokonać i zacząć czerpać korzyści z analizy ROI z różnych kanałów bezpośrednio w Google Analytics.

A więc, jak zabrać się do importowania danych o kosztach?

Po pierwsze: otaguj swoje linki

Jeżeli jeszcze nie otagowałeś URL’i podpiętych do Twoich reklam, zrób to teraz! Zagwarantuje to, że do Google Analytics zostaną przekazane parametry śledzenia kampanii powiązane z konkretną sesją i że będzie możliwość połączenia ich z danymi o kosztach z zewnętrznego źródła.

Po drugie: Skonfiguruj zbiór danych

W Google Analytics w zakładce „Administracja“, wybierz konto i usługę do której chcesz importować dane. W sekcji „Usługa“ odnajdziesz przycisk „Import Danych“. Po kliknięciu go, zobaczysz duży, czerwony prostokąt z napisem „+Nowy zbiór danych“ – kliknij go. Następnie zostaniesz poproszony o wybranie typu zbioru danych – wybierz „Dane o kosztach“ (Thank you captain obvious!).

Pierwszym wyzwaniem przy imporcie kosztów do Google Analytics jest odszukanie sekcji „Import danych“. Powyższy zrzut ekranu, może okazać się pomocny. W zakładce „Administracja” (1) wybierz konto (2) i usługę (3), a następnie kliknij w przycisk „Import danych” (4). W nowo otwartym oknie kliknij czerwony przycisk: „+Nowy zbiór danych” , a następnie wybierz jego typ („Dane o kosztach”).

Wprowadź nazwę dla nowego zbioru. Polecam wybrać nazwę serwisu z którego będą pochodziły dane np. „facebook“. Następnie wskaż widoki w których dane będą dostępne.

Teraz czas na skonfigurowanie schematu zbioru danych. Chyba każde źródło danych o kosztach kampanii pozwala na pobieranie surowych danych do postaci pliku. Import informacji do Google Analytics, również opiera się na pliku zawierającym te dane, które docelowo mają zostać załadowane do interfejsu. Aby poprawnie skonfigurować swój schemat, popatrz w plik z danymi o kosztach pobrany z zewnętrznego źródła. Zastanów się, które z wartości znajdujących się w nim, odpowiadają wymiarom i metrykom Google Analytics.

Na pewno musisz odnaleźć odpowiedniki Analytics’owych wymiarów „Źródło“ i „Medium“ – ich obecność jest obowiązkowa podczas importu kosztów i stanowią tzw. klucze. Dodatkowo, musisz odszukać przynajmniej jeden z parametrów, który odpowiada metrykom: „Kliknięcia“, „Koszt“, lub „Wyświetlenia“ z Google Analytics. Jednak im więcej metryk odnajdziesz w swoim pliku i uda Ci się je zmapować na metryki Analytics’a tym będziesz miał więcej możliwości analizowania swoich danych. Na koniec, jeżeli twoje źródło je zapewnia, możesz wskazać dodatkowe metryki, lub wymiary, które chciałbyś zaimportować. Gdy już będziesz wiedział, które wielkości chcesz załadować do Google Analytics, wybierz odpowiednie pozycje z rozwijalnych list.

Teraz, gdy schemat został zdefiniowany, możesz pobrać szablon, który ułatwi Ci stworzenie pliku, który, po uzupełnieniu o dane, będzie można zaimportować do Google Analytics. Aby to zrobić, kliknij na przycisk „Pobierz schemat“.

Zrzut ekranu z przykładową konfiguracją zbioru danych. Po kliknięciu przycisku „pobierz schemat“, wygenerowany zostanie plik *.csv, który należy uzupełnić danymi. W nagłówkach kolumn znajdą się nazwy widoczne po prawej stronie: ga:medium, ga:source itd., oraz nagłówek ga:date (jeżeli go nie ma, to dodaj pierwszą kolumnę i wprowadź go ręcznie).

Po trzecie: Przygotuj swoje dane

Aby proces przebiegł pomyślnie plik, który będziemy importowali do Google Analytics musi mieć określoną postać, aby mógł zostać poprawnie przetworzony. Pierwszy wiersz w pliku zarezerwowany jest na nagłówki kolumn, które zawierają nazwy metryk i wymiarów w formie rozpoznawalnej przez Google Analytics. Otwórz dowolne narzędzie do edycji arkuszy kalkulacyjnych (MS Excel jest w sam raz). Jeżeli pobrałeś schemat pliku w poprzednim kroku to po otwarciu go w pierwszym wierszu będą znajdowały się już odpowiednie wartości. Następnie dodaj dane z zewnętrznego źródła w odpowiednich kolumnach i zapisz plik w formacie *.csv.

Pamiętaj, że jeżeli którychś danych będzie brakowało, to Google Analytics zastąpi je wartością 0. Gotowy plik powinien wyglądać podobnie do przedstawionego niżej:

Aby załadować plik do interfejsu Google Analytics, musi mieć on określoną postać i zawierać dane pobrane z zewnętrznego źródła. Dla przedstawionego przykładu dostępne były tylko dane o dziennych kosztach. Zwróć uwagę, że plik zawiera w pierwszym wierszu nagłówki w formacie rozpoznawalnym przez Analytics’a, data jest zapisana w formacie RRRRMMDD (np. 20141231), a liczby zawierają kropkę zamiast przecinka.

Formalne wymagania dotyczące formatu pliku *.csv, można znaleźć pod adresem: https://developers.google.com/analytics/devguides/platform/cost-data-import#csv_format

Jeżeli Twój plik spełnia wszystkie warunki to jesteś gotowy do załadowania swoich danych do Google Analytics. W zakładce „Administracja“, w sekcji „Import danych“, w tabeli obok pozycji, którą wcześniej stworzyłeś, kliknij w „Zarządzaj przesyłaniem“ i załaduj przygotowany wcześniej plik.

Tak wygląda ekran w którym, po skonfigurowaniu zbioru danych, mamy możliwość przesyłania przygotowanych plików z danymi o kosztach. Po kliknięciu w „Zarządzaj przesyłaniem“, należy wskazać lokalizację pliku *.csv.

Gotowe! Jeżeli wszystko poszło dobrze, to dane, które zaimportowałeś pojawią się za chwilę w Twoich raportach (Pozyskiwanie > Kampanie > Analiza kosztów). Wracając do przywołanego na wstępie przykładu. W kolumnie „Koszt” pojawiły nam się konkretne wartości, co pozwala na obliczenie innych metryk. W tym przypadku zwrotu z nakładów na reklamę. Gdybyśmy zaimportowali więcej informacji (np. o liczbie kliknięć), z widocznej na poniższym zrzucie ekranu tabeli zniknęło by wiele zer.

Po zaimportowaniu danych do Google Analytics, pojawiają się one w raportach. Dodatkowo kalkulowane są metryki oparte na tych wartościach. Im więcej różnych metryk załadujemy do interfejsu, tym więcej możliwości analizy uzyskamy. Na powyższym przykładzie widać, że wspomniany na początku wpisu sklep internetowy, powinien rozważyć możliwość zwiększenia nakładów na reklamę w serwisie ceneo.pl, ponieważ współczynnik ROI jest dla niego dużo wyższy niż dla konkurencyjnego nokaut.pl.

Co dalej?

Okej, to był pierwszy, manualny sposób importowania kosztów do Google Analytics. Co gdy przedstawiona wyżej metoda nie jest dla nas dostatecznie wygodna? W takim przypadku istnieją jeszcze co najmniej dwa rozwiązania.

Pierwszym sposobem jest skorzystanie z interfejsów współpracujących z API Google’a, oferowanych przez różne serwisy np. Shufflepoint. Usługa „Shufflepoint In2GA“ pozwala automatycznie pobierać dane z wielu źródeł i automatycznie, konwertując je do wymaganej przez Google formy, ładować do interfejsu Analytics’a. W tym przypadku jesteśmy zwolnieni z ręcznego formatowania pliku, który będzie importowany. Wszystkie operacje od pobierania danych z zewnętrznych źródeł, przez formowanie pliku, po załadowanie go do narzędzia Google są wykonywane po stronie serwerów Shufflepoint.

Źródło: shufflepoint.com

Drugi sposób to samodzielne wykorzystanie API Google Analytics i stworzenie własnej aplikacji, lub oprogramowania, które cyklicznie może pobierać dane, konwertować je do odpowiedniej formy i importować do Google Analytics. Wymaga to jednak zlecenia tego zadania do działu IT Twojej organizacji, zewnętrznej firmie, lub wykorzystania własnych umiejętności programistycznych. Ale o tym opowiemy Wam, w szczegółach, innym razem.

Rozpoczęcie regularnego importowania kosztów do Google Analytics otwiera nam drogę do podejmowania lepszych decyzji odnośnie inwestowania środków w różne kanały marketingowe. Mam nadzieję, że pokazałem, że droga do wyższych współczynników ROI jest krótsza, niż wielu do tej pory uważało.

The post Import kosztów do Google Analytics first appeared on Conversion.

Przedstawiamy Wam (subiektywne) zestawienie najważniejszych funkcjonalności, które pojawiły się w tym roku w Google Analytics.

Przeczytajcie, co się zmieniło i jak wykorzystać nowe funkcjonalności w swoich analizach:

Remarketing Google Analytics w Universal Analytics oraz wyjście Universal Analytics z wersji beta.

Nasze zestawienie zaczynamy od prawdopodobnie największego wydarzenia tego roku: na początku kwietnia Universal Analytics wyszło z beta. Oznacza to, że nowa wersja kodu śledzącego jest już w 100% kompatybilna, obsługuje wszystkie funkcjonalności (w tym funkcjonalności dostarczane przez skrypt dc.js) i raporty klasycznego Analytics.

Czego do tej pory najbardziej brakowało? Na pewno list remarketingowych, które tworzone w klasycznym Analytics pozwalały grupować użytkowników, którzy dokonali konkretnej akcji (np. dodali produkt do koszyka) lub odwiedzili daną stronę. Pozwalało to serwować im odpowiednie kreacje reklamowe za pomocą Google Display Network. Tej funkcji do kwietnia nie obsługiwał Universal Analytics. Na szczęście to się zmieniło.

Kolejną funkcjonalnością, na którą musieliśmy poczekać w Universal Analytics, są raporty zainteresowań i dane demograficzne oraz pełna kompatybilność z Google Tag Manager. Obie te funkcje pojawiły się wraz z wyjściem z bety. Dodatkowo wprowadzono procesowanie danych w oparciu o poszczególne strefy czasowe: dotychczas dane procesowane były w czasie pacyficznym (PST). Universal Analytics zapewnia więc najświeższe dane niezależnie od strefy czasowej.

Należy także wspomnieć, że oprócz przeniesienia wszystkich funkcjonalności klasycznego Analytics do Universal Analytics, pojawiły się nowe, długo wyczekiwane funkcje, takie jak śledzenie użytkowników pomiędzy różnymi urządzeniami (poprzez nadawanie unikalnego User-ID). W momencie, kiedy użytkownik loguje się do serwisu, uaktywnia się klucz z bazy CRM (np. numer klienta czy adres email), z którym sparowany jest UUID. W efekcie w interfejsie Google Analytics możemy analizować zachowanie online użytkownika korzystającego z kilku urządzeń czy przeglądarek, a nawet offline, jeżeli na karcie klienta umieścimy taki sam User-ID.

Migracja na Universal Analytics jest nieunikniona – kolejne funkcjonalności dostępne są tylko w nowszej wersji kodu śledzącego. Wystarczy wymienić nowe metryki i dane niestandardowe czy ulepszony e-commerce, o którym za chwilę.

Ulepszone śledzenie e-commerce (enhanced e-commerce)

To była prawdziwa rewolucja: Google Analytics w maju udostępnił zupełnie nowy moduł śledzenia e-commerce. Ta funkcjonalność dostępna jest tylko w Universal Analytics i zapewne dla wielu była bodźcem do migracji na nowy kod śledzący Analytics.

Skąd to całe zamieszanie? Ulepszone śledzenie e-commerce to duży zastrzyk dodatkowych danych, do których wcześniej nie mieliśmy dostępu. Po pierwsze, możemy zbierać dane dotyczące zaangażowania użytkowników, m.in.: jak użytkownicy jak użytkowników zachowują się w koszyku (np. ile produktów dodają bądź usuwają), jak wygląda dokładnie ich ścieżka od zainicjowania po transakcję (bądź porzucenie koszyka). To daje możliwość tworzenia zaawansowanych segmentów i jeszcze lepszych analiz użytkowników.

Spośród wielu możliwości, które daje enhanced e-commerce można wymienić np. wyliczanie współczynnika konwersji dla konkretnych produktów czy ułatwione śledzenie kampanii wewnętrznych. Nowością i bardzo przydatną funkcjonalnością jest możliwość segmentacji w obrębie ścieżki zakupowej – do tej pory mogliśmy śledzić ścieżkę za pomocą celów, jednak jej analiza w obrębie poszczególnych segmentów wymagała tworzenia filtrów lub poziomej ścieżki konwersji.

Raporty porównawcze (benchmarking)

W Google Analytics możesz już sprawdzić, jak działa Twój serwis w porównaniu do konkurencji. Możesz wyświetlać raporty porównując je z danymi innych serwisów z Twojej branży. Są to dane zagregowane – nie ma możliwości zidentyfikowania konkretnej firmy.

Co można porównywać? W tym momencie możemy zestawić raporty dotyczące kanałów, lokalizacji oraz urządzeń, z których korzystają użytkownicy. Do wykorzystania mamy 6 metryk: sesje, % nowych sesji, nowych użytkowników, strony/sesje, średni czas trwania sesji oraz współczynnik odrzuceń. Możemy zobaczyć jak nasza organizacja wypada na tle konkurencji – na przykład o ile więcej (bądź mniej) procent ruchu zdobywamy z płatnych wyników wyszukiwania niż konkurencja.

Nowe raporty znajdziecie w sekcji Odbiorcy | Test porównawczy. Aby udostępnić tę funkcje musimy zgodzić się na udostępnienie danych anonimowo usłudze Google (tę opcję znajdziecie w ustawieniach konta Google Analytics).

Benchmarking możemy wykorzystać np. do analizy w czasie, tj. do porównywania jak w poszczególnych okresach roku działa nasz serwis względem konkurencji. Może uda się znaleźć kanały, które w danym czasie są bardziej efektywne, niż te które stosowaliśmy do tej pory?

Należy pamiętać o pewnych ograniczeniach tej funkcjonalności: nie wiemy do końca jak wygląda branża, którą dobrało nam Google (nie mamy wpływu na to, czy jest to strona o podobnym profilu czy wolumenie ruchu). Kolejnym dużym ograniczeniem jest brak informacji o tym, ile inni wydają na poszczególne aktywności marketingowe. Tym samym możemy sprawdzić, że nasi konkurenci pozyskują dużo więcej ruchu z AdWords – nie możemy jednak ocenić efektywności tych działań nie mając danych na temat budżetu.

Możliwość filtrowania botów

Możliwość wykluczania ruchu robotów ze statystyk Google Analytics pojawiła się w lipcu 2014 roku. Na pierwszy rzut oka nie jest to może spektakularna funkcjonalność, jednak w przypadku dbania o poprawne i rzetelne dane, filtrowanie robotów i tzw. spiderów ma bardzo duże znaczenie.

Roboty i spidery to automatyczne programy, które chodzą po stronach internetowych. Mogą to być roboty wyszukiwarek internetowych, programy, które skanują Twoją stronę w poszukiwaniu najnowszych treści lub konkretnych informacji np. o danej marce. Robotami są programy, które Twoje zlecenie sprawdzają sprawność serwera czy też czas ładowania się strony. Duża część botów krążących po stronach internetowych to tzw. spamboty, które wyszukują adresy e-mailowe i dodają je do list mailingowych.

Niektóre roboty nie powodują wywoływania kodu Google Analytics – wtedy ich wizyta odnotowywana jest tylko w logach serwerowych. Inne, tzw. smartboty podczas wejścia „zachowują” się tak jak użytkownik: do narzędzia przesyłany jest hit i Google Analytics zlicza to jako zwykłą wizytę. Może to zaburzać analizę danych – jak bardzo przekonacie się przeglądając raport Incapsula, który wskazuje, że nawet 60% ruchu na stronach internetowych generowane jest właśnie przez roboty.

Ustawienie tej funkcjonalności jest naprawdę proste: w panelu Administracja wybieramy „Ustawienia widoku” zaznaczamy opcję” Wykluczenie wszystkich działań znanych robotów”.

Google Analytics identyfikuje i odfiltrowuje roboty na podstawie listy tworzonej przez IAB/IAC (IAB/IAC International Spiders & Bots List). Dostęp do pełnej listy kosztuje całkiem sporo (od 4000 USD nawet do 14000 USD), jednak nie musimy jej znać aby korzystać z tej funkcjonalności.

Jeżeli jeszcze nie wykorzystaliście możliwości wykluczania działań robotów – powinniście to zrobić jak najszybciej. Warto, na początek, przez kilka tygodni sprawdzać jej działanie na testowym widoku – jeżeli wszystko będzie działać poprawnie, można zaaplikować funkcjonalność w obrębie całego konta.

Diagnostyka

Zapewne nie umknęło Waszej uwadze, że w prawym górnym rogu na Waszym koncie Google Analytics pojawiły się alarmy i komunikaty. To nowa opcja Google Analytics – Diagnostyka.

Google Analytics raportuje błędy takie jak brak kodu śledzącego, kolidujące filtry czy błędy w poszczególnych raportach czy w konfiguracji celów. Dodatkowo pojawiają się sugestie np. dotyczące ustawienia nowych celów.

Z raportu Conversion wynika, że duża część polskich witryn internetowych ma problem z jakością gromadzonych danych: w wyniku błędów są one niepełne i nierzetelne. Oczywiście diagnostyka Google Analytics to zdecydowanie za mało, aby zapewnić poprawność danych – niemniej jednak warto skorzystać z tej pomocy.

Google Analytics Demos & Tools

W tym roku Google Analytics udostępniło nową platformę – Google Analytics Demos & Tools. Znajdziemy na niej sporo materiałów, które ułatwią wdrażanie nowych funkcjonalności i korzystanie z samego narzędzia – głównie w formie filmów instruktażowych, prostych aplikacji demo i opisów. W demo enhanced e-commerce możemy zobaczyć, jak działa ta funkcjonalność w obrębie serwisu oraz otrzymujemy przykładowe kody do wdrożenia na stronę.

Kolejna sekcja to Google Analytics Embed API. To biblioteka Javascript, która pozwala na tworzenia i osadzanie w interfejsie Google Analytics dashboardów na zewnętrznych stronach. Daje to możliwości wizualizacji danych i przedstawiania ich „poza” narzędziem Google Analytics.

Jedyne, czego potrzebujesz aby stworzyć dedykowany dashboard to praca Twoich deweloperów. Daje to naprawdę ogromne możliwości i pozwala na tworzenie dobrej dokumentacji. Możesz zintegrować wykresy z Google Analytics aby wyglądały tak samo, bądź narysować własne wykorzystując narzędzia do wizualizacji takie jak d3.js czy chart.js.

W sekcji demo znajdziesz przykłady i pomysły prezentacji danych, między innymi w formie wykresów interaktywnych bądź zestawiania danych z dwóch i więcej widoków (co nie jest możliwe z wykorzystaniem interfejsu Google Analytics). Wykorzystanie Embed API pozwala także na wykorzystanie niestandardowych komponentów w dashboardach. Jeżeli chcecie dowiedzieć się więcej sięgnijcie do Google Develepors Centre.

Sekcja narzędzia zawiera znane części z Was narzędzie Google Analytics Query Explorer, które pozwala na wyciąganie danych z Google Analytics z poziomu tego narzędzia. Query Explorer pozwala między innymi na wyciągnięcie danych z większej liczby wymiarów (w obrębie interfejsu Google Analytics możemy to zrobić tylko dla maksymalnie dwóch wymiarów). Query Explorer pozwala wyeksportować dane dotyczące wszystkich parametrów kampanii – tj. medium, źródło, kampania, słowa kluczowe i treść.

Mamy także dostęp do kilku innych narzędzi: Account Explorer, Dimensions & Metrics Explorer oraz Google Analytics Spreadsheet Add-on, który ułatwia eksport, przekazywanie i wizualizację danych z Google Analytics do arkuszy kalkulacyjnych Google Docs.

Aby korzystać z Google Analytics Demos & Tools musimy zalogować się do swojego konta Analytics – wówczas poszczególne demo zasilane są danymi z naszego własnego konta.

A co zmieniło się w Google Analytics Premium? Oto 3, naszym zdaniem, najważniejsze funkcjonalności, które pojawiły się w płatnym Analytics w 2014 roku:

Raportowanie zbiorcze w Google Analytics Premium

Raportowanie zbiorcze, czyli tzw. roll-up, to konto, które łączy w sobie kilka różnych stron internetowych (tzn. różnych domen, np. sklep.buty.pl, blog.buty.pl itd.). Każda z domen jest śledzona osobnym kontem Google Analytics, jednak aby mieć pełny obraz zachowania użytkownika we wszystkich serwisach tworzone jest właśnie konto zbiorcze.

Stworzenie takiego konta jest możliwe w obrębie Google Analytics (informacje jak to zrobić znajdziecie w poście Mariusza), jednak nowością Premium jest to, że nie ma potrzeby implementacji kilku kodów śledzących na jednej stronie. Samo stworzenie usługi roll-up jest bardzo proste i nie wymaga zmian w kodzie źródłowym strony.

Roll-up reporting to niewątpliwie wyjście naprzeciw dużym organizacjom, które posiadają wiele domen w różnych krajach. Posiadanie pełnego obrazu obecności on-line danej firmy jest niezbędne do podejmowania najważniejszych decyzji biznesowych.

Jakie możliwości daje opcja zbiorczego raportowania? Możemy w obrębie jednego interfejsu sprawdzić jak działają poszczególne jednostki (np. różne serwisy bądź lokalizacje) porównując je do siebie. To także lepsze spojrzenie na ścieżkę użytkownika pomiędzy naszymi serwisami (łącząc te dane np. z danymi dotyczącymi urządzeń, z których korzystają użytkownicy).

Integracja Google Analytics Premium z DoubleClick

To kolejna ważna informacja dla użytkowników Google Analytics Premium – w 2014 nastąpiła pełna integracja DoubleClick Campaign Manager z Google Analytics Premium.

DoubleClick to ad-server Google, który korzysta z danych pochodzących z ciasteczek. Dzięki temu możliwe jest odtworzenie historii przeglądania stron użytkownika, a co za tym idzie – wyodrębnienie jego preferencji. DoubleClick cookies wykorzystuje te dane do targetowania kampanii reklamowych. Na pewno nie raz widzieliście, że gdy tylko przejrzycie ofertę butów w Zalando.pl, „buty” będą chodzić za Wami cały dzień – na przykład w wyszukiwarce Google. Tak działa DoubleClick.

Integracja tych narzędzi to między innymi dostęp z poziomu Google Analytics do danych dotyczących wyświetleń i kliknięć w kreacje reklamowe, a także monitorowania jak poszczególne kreacje wpływają na konwersję. Możemy ocenić efektywność kreacji i kampanii z uwzględnieniem wszystkich dostępnych metryk Google Analytics (takich jak współczynnik odrzuceń czy czas spędzony na stronie) i jeszcze dokładniej analizować ROI z kampanii marketingowych i poszczególnych kanałów.

Możliwość eksportowania niepróbkowanych raportów poprzez API

Do tej pory Google Analytics Premium umożliwiało pobieranie niesamplowanych raportów wyłącznie do pliku csv. W tym roku dodano funkcjonalność dostępu do niepróbkowanych raportów poprzez API. To rozszerza możliwości analizy danych i odpowiada na specyficzne potrzeby konkretnych biznesów – np. poprzez możliwość integracji API z oprogramowaniami Business Intelligence i zasilenie go niepróbkowanymi danymi z Google Analytics Premium.

Raporty niepróbkowane tworzone za pomocą API procesowane są w trybie offline. Kompletny raport jest dostępny z poziomu API, ale także mogą być zapisane na Google Drive albo na Google Cloud.

Na koniec dobra informacja dla wszystkich, którzy potwierdzić swoją znajomość narzędzia Google Analytics i zdać egzamin Google Analytics Individual Qualification: zdawanie GAIQ jest już darmowe. Co więcej można zdawać egzamin po polsku. To jest 10 zmiana, którą wprowadził Google Analytics w 2014 roku.

Patrząc na tempo rozwoju Google Analytics w 2014 roku nie możemy już się doczekać co przyniesie kolejny rok

Jeżeli jeszcze nie mieliście okazji zapoznać ze wszystkimi nowościami – czas najwyższy!

The post 10 nowości, które pojawiły się w Google Analytics w 2014 roku 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.

Na pewno wielu z Was już słyszało o tej nowości. Google obiecuje, że ten kod jest w stanie spełnić wiele oczekiwań, którym klasyczna wersja kodu nie była w stanie sprostać, np. możliwość analizowania przepływu internautów między różnymi przeglądarkami i urządzeniami. Rewolucja w świecie analityki? Na pewno. Tylko jak ta magia działa? Jakie są jej fundamenty? Jakie są ograniczenia niesamowitych, jak się wydaje, możliwości tego narzędzia? Jeżeli szukaliście ostatnio odpowiedzi na te i inne pytania o Universal Analytics, liczę, że po lekturze tego posta temat nie będzie dla nikogo tajemnicą.

Jak było, a jak jest

…czyli o kluczowej różnicy między klasycznym kodem Google Analytics a Universal Analytics

Aby móc dobrze zrozumieć to, jak działa Universal Analytics, na początek krótkie przypomnienie tego jak działa klasyczna wersja kodu – ga.js (czy jego wariacja, dc.js). Kod Google Analytics opierał się do tej pory na ciasteczkach zapisywanych w przeglądarce użytkownika, to w nich zapisywane były informacje m.in. o źródle, medium odwiedzin, ich godzinie czy dacie. Za pomocą najróżniejszych wtyczek zawsze można było sprawdzić zapisane w przeglądarce ciasteczka Analyticsa – „utm”.

Do informacji zapisanych w ciasteczkach Google Analytics – utm, można zajrzeć np. dzięki dodatkowi na przeglądarkę Chrome (na screenie „Edit this cookie”).

Bazowanie na ciasteczkach wiązało się niestety z tym, że unikalny użytkownik oznaczał tyle, co unikalny zestaw ciasteczek. Ponieważ unikalny zestaw ciasteczek jest przypisany do danej przeglądarki i urządzenia, to gdy odwiedzam stronę X z tabletu, potem z lapotopa, to w oczach Google Analytics jestem dwoma unikalnymi użytkownikami. W świecie, gdy niemal każdy z nas ma co najmniej dwa urządzenia z dostępem do internetu, jest to dla analityków internetowych spore wyzwanie. Gdy struktura serwisu na to pozwalała, próbowaliśmy obejść ten problem zmiennymi niestandardowymi na użytkownika, przekazując w nich ID użytkownika. Ale nie była to metoda doskonała – gdybym chciała przejrzeć grupę użytkowników korzystających i z laptopa i z tabletu, nie było innej możliwości, jak zaszyć się w biurze na pół roku i filtrować dane pojedynczo, po każdym jednym ID.

Szaleństwo, przed którym może ocalić tylko Universal Analytics. Rewolucja związana z tym kodem polega na tym, że do jego działania (choć bez pełnej mocy) nie potrzebne są żadne ciasteczka! Universal Analytics tworzy tylko 1 ciasteczko z ID użytkownika, a pozostałe dane (m.in. źródło, medium, słowo kluczowe) przesyłane są od razu do serwerów Google. Jak to się dzieje?

Silnik Universal Analytics

…czyli measurment protocol i analytics.js

Measurment protocol to wykorzystywany przez Universal Analytics zbiór zmiennych, parametrów za pomocą których dane są przesyłane do serwerów Google Analytics. W klasycznym kodzie ga.js/dc.js dane przeglądarkowe i te z ciasteczek, jako parametry „utm” wysyłane były w paczce „_utm.gif”. W measurment protocol dane wysłane są w zupełnie innym formacie:

W Universal Analytics parametry „utm” przechodzą do historii. Nowy measurment protocol wykorzystuje zupełnie nowy zestaw parametrów do przesyłania danych na serwery Google.

Rozszyfrowując kilka parametrów:

• v – oznacza wersję mesasurment protocol, aktualnie będzie to 1;
• tid – parametr odnoszący się do numeru usługi Google Analytics, czyli numeru UA;
• cid – wartością tego parametru jest tzw. UUID czyli z angielskiego Universally Unique IDentyfier, jest to losowo przyznane danemu użytkownikowi ID;
• t – tutaj zdefiniowany będzie rodzaj hitu (na przykładowym screenie jest to „pageview”).

Wartość parametru „cid”, czyli UUID jest także przechowywana w jedynym „universalowym” ciasteczku „_ga”:

Universal Analytcs tworzy w przeglądarce użytkownika tylko jedno ciasteczko „_ga”, w którym zapisane jest unikalne ID.

Kolejna konsekwencja zastosowania measurment protocol to możliwość śledzenia przepływu użytkownika miedzy różnymi urządzeniami, przeglądarkami a nawet z uwzględnieniem jego/jej działań offline. Wyobraźmy sobie następujący scenariusz:

Jan Kowalski szukając aktówki na służbowym laptopie trafił na stronę sklepu Wittchen. Jeden z produktów bardzo mu się spodobał, sfinalizował transakcję rejestrując się do sklepu. Razem z aktówka została do niego przysłana karta klienta. Po tygodniu, gdy utknął w korku wracając z pracy przeglądał na tablecie prywatną skrzynkę mailową, gdzie rzucił mu się w oczy mailng Wittchena z całkiem atrakcyjnymi promocjami. Klika w link, loguje się do sklepu, żeby mieć dostęp do promocji i przegląda ofertę. Jak tylko spojrzał na torebki od razu przypomniało mu się, że żona jutro obchodzi urodziny. W panice gna do galerii handlowej, wbiega do salonu Wittchena i wybiera najdroższą z torebek (aby mieć pewność, że trafi w gust żony). Przy zapłacie chwali się kartą klienta, dzięki czemu dostanie kilka procent rabatu.

Klasyczna wersja Google Analytics zarejestrowałaby wizyty Jana Kowalskiego na stronie Wittchena jako dwóch unikalnych użytkowników (laptop, potem tablet), a wizyta w stacjonarnym sklepie w ogóle umknęłaby śledzeniu.

A jak zachowanie użytkownika Jana Kowalskiego śledziłby Universal Analytics? Podczas pierwszej wizyty zarówno w ciasteczku „_ga” jak i w parametrze cid zapisane by było UUID użytkownika. Przy kolejnej okazji (wizyta z tabletu) Jan Kowalski otrzyma nowy UUID, ale gdy tylko się zaloguje do sklepu zostanie on nadpisany przez ten z pierwszej wizyty w sklepie. Zadzieje się to dzięki temu, że po zalogowaniu stanie się aktywny klucz z bazy CRM (np. numer klienta, czy adres email), z którym sparowany jest UUID. Podobnie, dzięki połączeniu Google Analytics z CRMem, podczas korzystania z karty klienta w salonie stacjonarnym, aktywowany klucz zostanie sparowany z UUID Kowalskiego. W efekcie w interfejsie Google Analytics możemy analizować zachowanie online klienta korzystającego z kilku urządzeń oraz jego działania offline.

Nowy format przesyłania danych to nie jedyna narzędziowa zmiana w Universal Analytics. Aby dane o użytkowniku mogły być przesyłane w tym formacie, kod Google Analytics wywołujący wysyłkę danych także musiał się zmienić z dobrze znanego nam GATC, na:

Podstawowa postać kodu śledzącego Universal Analytics bazuje na nowej bibliotece – analytics.js

Tak, pojawiła się zupełnie nowa biblioteka, która obsługuj measurment protocol – analytics.js. Przestawienie się na nową strukturę może być z początku bolesne, ale warto. Analytics .js jest dużo prostszy (bez podkreślników, kwadratowych nawiasów etc.), bardziej intuicyjny i daje więcej możliwości. Dzięki analytics.js możemy np. tworzyć niestandardowe wymiary i metryki. Czyli gdy dopiszemy odpowiednią linijkę kodu, obok standardowych wymiarów w interfejsie Google Analytics będziemy mieli wymiary dostosowane do naszego biznesu np. jeżeli mielibyśmy serwis z materiałami prasowymi, taki wymiarem mógłby być tytuł artykułu. To samo można zdziałać z metrykami. Widzicie tę moc? A z Universal Analytics można zdziałać jeszcze więcej!

Więcej możliwości z Universal Analytics

Z klasycznym kodem Google Analytics wiele zmian i dodatkowej konfiguracji trzeba było organizować zmianami, rozszerzaniem kodu. Z Universal Analytics mamy więcej możliwości z poziomu interfejsu. W panelu administratora możemy:

• dodać do medium organic dodatkowe, nieobsługiwane przez narzędzie standardowo źródła = wyszukiwarki;
• ustawić funkcje „timeout”, czyli niestandardowego czasu wygaszania sesji czy przypisywania konwersji do danej kampanii;
• reklasyfikacja wejść z określonych słów kluczowych jako wizyty bezpośrednie.

Interfejs usługi Universal Analytics daje kilka użytecznych możliwości, które przy klasycznej wersji dostępne były tylko po rozszerzeniu kodu śledzącego. Teraz bez potrzeby angażowania IT można np. wydłużyć czas, po którym sesja będzie wygaszana.

Jeżeli do tego dodać wszystko to, o czym wspomniałam wcześniej, a więc możliwość śledzenia zachowania użytkowników między urządzeniami, przeglądarkami i światami online i offline, dodawanie niestandardowych wymiarów i metryk, od razu staje się jasne, dlaczego Universal Analytics jest określany jako kod nowej generacji. Jednak, jak każde narzędzie ma on także swoje ograniczenia, o których warto wiedzieć.

Ograniczenia Universal Analytics

Najważniejsze ograniczenia widoczne są w przykładzie o Janie Kowalskim i w jego przygodzie ze sklepem Wittchen. Aby moc śledzenia przy pomocy UUID dało się w pełni wykorzystać, użytkownik musi się do serwisu zalogować. Nie wiele jest aktualnie stron, które bezwzględnie tego wymagają, do tego cała pula osób niechętna rejestrowaniu się, wypadnie z zaawansowanego śledzenia i nadal będzie śledzona tak samo jak przy wykorzystaniu ga.js.

Kolejne wyzwanie – jeżeli chcemy łączyć dane z online i z offline czy śledzić użytkownika miedzy różnymi urządzeniami, potrzebujemy jakiegoś klucza, który powiąże dane CRM z danymi w Gogle Analytics. W przykładzie o Janie Kowalskim takim kluczem mógł być numer klienta parowany z UUID. Bez takiego klucza, tak zaawansowane łączenie danych nie będzie możliwe.

Aktualnie Universal Analytics nie posiada opcji sieci reklamowych, która daje możliwość gromadzenia danych demograficznych czy tworzenia list remarketingowych z poziomu Google Analytics. Ma to się zmienić – zgodnie z planem Google rozwoju narzędzia, dodanie opcji sieci reklamowych do Universal Analytics jest w planie. Dla zainteresowanych harmonogramem wszystkich planowanych zmian polecam stronę: https://developers.google.com/analytics/devguides/collection/upgrade/.

Pomimo ograniczeń Universal Analytics, ta wersja kodu jest przyszłością i wkrótce każdy, kto będzie chciał zbierać jak najlepsze dane będzie musiał albo założyć nową usługę z takim kodem albo przejść przez proces migracji.

Zakładanie usługi Universal Analytics

Po kliknięciu w zakładce administratora na „Utwórz nową usługę” zostawiamy standardowo wybraną wersję kodu Universal Analytics. Pozostałe pola uzupełniamy tak samo, jak by był to klasyczny kod Analytics.

Podczas zakładania nowej usługi można od razu zdecydować się na wersję Universal Analytics.

Migracja z ga.js/dc.js na analytics.js

Nie trzeba zakładać od razu nowej usługi, aby móc korzystać z możliwości Universal Analytics. Migracja jest ze starej wersji kodu na nową jest jak najbardziej możliwa. Jak to zrobić?

Krok 1

Ponieważ Universal Analytics jest bardzo nowym rozwiązaniem, jeszcze nie na wszystkich usługach znajdziecie zaznaczoną na screenie opcję. Jeżeli nie ma jej teraz, nie martwcie się, wkrótce powinna się pojawić.

Krok 2

Zanim klikniecie „Przenieś” warto dokładnie zapoznać się z informacjami na tej stronie, ponieważ dokonując migracji usługi, jej interfejs zmieni się nieodwracalnie na „universalową”.

Wystarczy kliknąć niebieski przycisk „Przenieś”, a po 24h-48h podmienić klasyczny kod Google Analytics na kod Universal Analytics. Jest to więc kwestią kilku kliknięć, aby taką migracje przeprowadzić. Należy jednak pamiętać, że zmiana interfejsu jest nieodwracalna – raz dokonując migracji na Universal Analytics w ramach danej usługi, nie można potem wrócić do jego poprzedniego wyglądu.

Podsumowanie

Universal Analytics mimo różnych ograniczeń jest przyszłością analityki internetowej. Kolejne fazy rozwoju narzędzia sprawią, że ograniczeń będzie coraz mniej, a śledzenie zachowania użytkowników coraz bliższe ich faktycznym działaniom. Jeżeli Wasz serwis wymaga rejestracji/logowania warto zacząć migracje na Universal jak tylko możliwa będzie opcja sieci reklamowych… i ani dnia później A czy Wy macie może już jakieś doświadczenia z Universal Analytics w praktyce? Koniecznie podzielcie się nimi w komentarzach.

The post Universal Analytics: kod, który zmieni oblicze analityki internetowej first appeared on Conversion.