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.

18 października 2011 Google ogłosiło, że jeśli wyszukiwanie w ich wyszukiwarce będzie się odbywać się przez protokół https to w raportach ruchu w Google Analytics nie zobaczymy słowa kluczowego jakie wpisał użytkownik.

Po co Googlowi Not Provided?

Google tłumaczy to prywatnością użytkowników. Jednak w tym samym czasie bez większego problemu podaje słowa kluczowe dla płatnych kampanii CPC.

Wprowadzenie Not Provided miało uderzyć przede wszystkim w SEO i skłonić marketerów aby większą uwagę poświęcili budowaniu contentu i relokowali swoje budżety na kampanie CPC, których skuteczność nadal można łatwo mierzyć.

Na początku nie było to dużym problemem, bo użytkownik był za https w Google tylko wtedy, gdy był zalogowany do konta Google, lub też się z niego wylogował i dalej w tej samej sesji wykonał wyszukiwanie.

Na początku 2012 roku procent słów kluczowych w raportach Google Analytics ukrytych za Not Provided wynosił około 15% i nie powodował drżenia rąk u specjalistów od SEO czy analityków internetowych.

Po roku od ogłoszenia zmiany Not Provided stało już za ponad 25% wizyt z Organica i problem stał się wyraźniejszy, choć jeszcze nie uniemożliwiał analizy danych. Liniowy wzrost trwał do połowy 2013 roku, od kiedy to wszystkie wyszukiwania są przeprowadzane przez protokół https. Jak rozwija się Not Provided możecie zaobserwować na Not Provided Count.

Ponieważ teraz wszystkie wyszukiwania obywają się już poprzez protokół https i nie ma już znaczenia to czy logujemy się do konta Google czy nie, to aktualnie 80% – 100% bezpłatnych słów kluczowych jest ukrytych za Not Provided. To skutecznie uniemożliwia pełną analizę tego, co wpisują użytkownicy w Google zanim trafią na naszą witrynę.

Czy zatem w SEO i w analizach jesteśmy skazani na zupełną ślepotę?

Nie jest tak źle.

Co nadal wiemy?

Google nie posprzątało danych do końca i dalej w Totalu informuje nas ile jest wizyt z Organica i jak ruch z tego źródła zachowuje się na stronie (jaki procent użytkowników z danego źródła dokonuje zakupu w naszym sklepie, ile czasu trwają wizyty, ile z wizyt kończy się porzuceniem itp., itd.)

Czego nie wiemy?

Nie wiemy, które słowo kluczowe dowozi ile ruchu i jak ten ruch potem zachowuje się na stronie.

Jak żyć?

Internet nie śpi i chociaż pełnej wiedzy sprzed rewolucji nie będziemy mieli, to cześć danych jesteśmy w stanie odzyskać. A części możemy się zwyczajnie domyślić Oto jak to zrobić:

Zacznijmy od tego jak odkryć to co dzieje się na naszej stronie:

Dedykowany profil w Google Analytics

Nadal wiemy, na jaki landing page przyszedł użytkownik. Można zatem przeciąć raport słów kluczowych przez stronę docelową lub stworzyć nowy profil w Google Analytics oraz filtr zaawansowany, który zrobi to za nas.

Po co nam strona docelowa? Znając landing page (np. sekcję sklepu z danym produktem w sklepie) możemy domyślić się, jakie słowo wpisał użytkownik w wyszukiwarkę Google. W raporcie Google Analytics powie nam jaki przychód generowało to słowo i jaki był jego współczynnik konwersji.

W nowym profilu, który zawiera tylko filtrowany ruch z Google Organic dokładamy taki oto filtr:

W tej konfiguracji w raporcie bezpłatnych słów kluczowych znajdziemy takie zestawienie:

W kolumnie słowo kluczowe znajdziemy oprócz hasła Not Provided również stronę docelową przez którą użytkownik trafił do naszego serwisu. Pozwoli do określić jakie słowo kluczowe wpisał użytkownik, przez które zawitał na naszą stronę i jaki jest współczynnik konwersji dla poszczególnych słów kluczowych.

Co widzimy na tym przykładzie?

Pierwsza pozycja to wejście na stronę główną serwisu. Możemy śmiało założyć, że jest to wizyta przez słowo, które ściśle wiąże się z marką (tzw. słowo brandowe). Następne pozycja to wejście na stronę kontaktu. Trzeci wiersz pokazuje wejście na stronę konkretnego produktu, więc tutaj zdiagnozowanie słowa kluczowego powinno być łatwe. Ostatnie słowo zaprowadziło użytkownika na stronę logowanie. Tu trzeba by się zastanowić, czy takie pozycjonowanie ma sens. Jest jednak spora szansa, że tutaj wejście nastąpiło na frazę brandową, do którego ktoś dopisał „logowanie”. Możemy zatem określić ile % wizyt (czy jak to teraz nazywa Google – sesji) związanych jest z siłą marki, a ile to efekt naszych prac SEO.

W podanym wyżej przykładzie widać, że słowa kluczowe nie konwertują. Warto jednak pokusić się jeszcze o analizę ścieżek wielokanałowych i tym sposobem dokładnie określić skłonność użytkownika do zakupu. Ponieważ teraz raport ścieżek jest bogatszy o LP dla Organica, z taką analizą nie powinno być większych problemów.

Google Webmaster Tools

Aby skorzystać z tej metody trzeba połączyć naszą witrynę z Google Webmaster Tools. Nie jest to skomplikowane: wystarczy skorzystać z tej instrukcji.

W narzędziu w sekcji „Ruch związany z wyszukiwaniem” można pobrać raport „Wyszukiwane hasła” i porównać go z raportem Google Analytics:

Łącząc ten raport z raportem z Google Analytics dotyczącym słów kluczowych możemy przywrócić część danych dotyczących ruchu schowanych przez Google. W moim przypadku bardzo dużo haseł zarejestrowanych przez Google Webmaster Tools nie miało ani jednej wizyty w raporcie generowanym przez Google Analytics.

W tym wypadku udało się oszacować ponad 17% całego Not Provided oraz odnaleźć bardzo ciekawe słowa kluczowe, poprzez które użytkownicy wchodzą na stronę (niestety nie mogę ich ujawnić – obliczcie to dla swoich witryn i wynikiem pochwalcie się komentarzu ).

Wiemy już jak odzyskać część danych. Teraz zobaczmy jak zaplanować nowe działania SEO. Znajdziemy słowa z potencjałem i określimy, na jaką konwersję z tych słów możemy liczyć.

Na początek poszukajmy słów, które mogą mieć duży potencjał w naszym biznesie.
Pomocne w tym będą Google Trends i Google AdWords

Google Trends

To narzędzie pokaże nam jak często użytkownicy wpisują zadaną frazę w wyszukiwarkę Google.

Co prawda nie zobaczymy ile tych wyszukań dokładnie jest, tylko ich znormalizowaną wartość. Wartości na wykresie oznaczają liczbę wyszukiwań konkretnego hasła w odniesieniu do łącznej liczby wyszukiwań w Google w tym samym czasie. Nie są to bezwzględne liczby wyszukiwań, bo dane są znormalizowane i przedstawione na skali od 0 do 100. Każdy punkt wykresu jest dzielony przez punkt najwyższy lub przez 100. Jeśli mamy za mało danych, wartość wynosi 0.).

Nie mniej jednak da nam to pojęcie, które słowa mają przyszłość, bo ich udział w rynku rośnie, a które mają coraz gorszy potencjał.

Zobaczyć możemy dane dla poszczególnych krajów, co przydatne może być przy planowaniu obecności na technologie, które za granicą są już znane i rozwinięte, a w Polsce dopiero są poznawane. Trendy Google pokazują też dla niektórych fraz prognozę, ale jest ona oparta tylko na danych historycznych i nie bierze pod uwagę uwarunkowań ekonomicznych.

W Polsce zainteresowanie hasłem Full HD jest na stałym poziomie, rośnie natomiast znaczenie technologii 4K. Z kolei hasło HD Ready czas największego boomu ma już za sobą.

Keyword Planner i Google Adwords

Planer Słów Kluczowych pokaże nam (podobnie jak Google Trends) jakim zainteresowaniem może się spotkać analizowane przez nas słowo kluczowe, ale pokaże nam już szacowane wartości wyświetleń. Jest to szalenie pomocne w prognozowaniu ruchu, których chcemy ściągnąć na stronę.

Narzędzie to podpowie nam również podobne słowa kluczowe i jakiego potencjału możemy się po nich spodziewać. Narzędzie ma wiele opcji i radzę przetestować wszystkie jego funkcjonalności.

Znając potencjalnie dobre trafficowo słowa warto je przetestować, i sprawdzić jak dobrze będą konwertować. Tu możemy znów wykorzystać Google AdWords i przeprowadzić testowe kampanie z szerokim dopasowaniem, a następnie korzystając z raportu dopasowanych zapytań sprawdzić, które z nich są najlepsze dla naszego biznesu i najlepiej konwertują.

Na koniec warto wspomnieć o jeszcze dwóch pomocnych źródła wiedzy, o których czasem zdajemy się zapominać:

Bing i inni

Na polskim rynku konkurencyjne wyszukiwarki nie ma zbyt dużego zasięgu (wg Gemius Ranking Bing i Yahoo mają w sumie około 3% ruchu wszystkich wyszukiwarek), ale warto zapoznać się z raportami słów kluczowych z tych wyszukiwarek. Jeśli jakieś słowo jest popularne w Bingu czy wy Yahoo jest spore prawdopodobieństwo, że jest też klikane w Google. Konkurencja Google nie ukrywa słów kluczowych za Not Provided, więc warto przyjrzeć się mniejszym graczom na rynku.

Wyszukiwarka wewnętrzna

Nie do przecenienia jest wyszukiwarka wewnętrzna na naszej witrynie. Najlepiej jest pozycjonować się na to czego szukają nasi użytkownicy.

W raporcie znajdziemy metryki opisujące jakość ruchu oraz konwersję czyli dane, których będziemy potrzebować do oszacowania zyskowności działań.

Reasumując, Google zabrało duży kawałek danych, ale nie zostawia nas z niczym. Posługując się dodatkowymi narzędziami możemy dalej efektywnie rozwijać strategię SEO, pokusić się o analizę słów kluczowych, czy za pomocą mechanizmów w AdWords symulować wielkość i konwersyjność ruchu, który możemy na naszą witrynę ściągnąć. Dużo wiedzy mogą nam też dostarczyć użytkownicy korzystający z konkurencyjnych wyszukiwarek a analiza haseł wpisywanych przez wyszukiwarkę wewnętrzną podpowie jaki kontent jest przez nich szczególnie poszukiwany.

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.

Autor: Adam Piątek

Zajmuje się analityką internetowa i optymalizacją konwersji od 4 lat. Ukończył Uniwersytet Szczeciński na kierunku Informatyka i Ekonometria. Swoją przygodą z biznesem internetowym rozpoczął od pracy dla największego w Polsce portalu rekrutacyjnego Pracuj.pl. Obecnie rozwija analitykę w na stronach Plusa i Cyfrowego Polsatu.

Czas wolny woli jednak spędzać na rowerze

The post Analiza SEO w dobie Not Provided first appeared on Conversion.

Z drugiej strony, czasem okazuje się jednak, że tych danych mamy w narzędziu za mało. Zapytacie pewnie jak to?

Google Analytics nie powie nam np. czy dane zamówienie jest pierwszym zamówieniem danego użytkownika i skąd przyszedł on przy pierwszym zamówieniu (ścieżki wielokanałowe zdradzają nam tylko część informacji). Nie powie nam także ile średnio odwiedzin naszego sklepu zajmuje mu podjęcie decyzji. Jeśli prowadzimy także sprzedaż offline to możemy pomarzyć o tym, aby Google Analytics powiedział nam, który użytkownik online odpowiada naszemu użytkownikowi offline

Zastanawialiście się kiedyś jak poradzić sobie ze zbudowaniem znacznie pełniejszego obrazu naszych klientów czy leadów pochodzących z kanału online? Prawdą jest, że im więcej danych mamy (i umiemy je wykorzystać), tym lepiej możemy dostosować nasze działania marketingowe, więc gra jest warta świeczki.

Czasem słyszałem pytania, czy istnieje możliwość importu danych z Google Analytics do zewnętrznych baz danych i łączenie tych danych ze sobą w celu dokładniejszej analizy.

Odpowiedź jest prosta: istnieje i to nie jedna.

API Google Analytics

Pewnie wielu z Was odrazu pomyślało: „hej, przecież możemy wyciągać dane z Google Analytics za pomocą API”.

Jasne, że możemy. Tylko jak je połączymy z danymi w innych systemach? Google Analytics nie przechowuje żadnych osobistych danych naszych użytkowników, czyli np. imienia i nazwiska, adresu zamieszkania czy adresu IP.

Oznacza to ni mniej ni więcej, że owszem możemy sobie wyeksportować liczbę odwiedzin w danym dniu, współczynnik odrzuceń (bounce rate) oraz źródło ich pochodzenia. Nie dowiemy się jednak, ilu z nich to klienci, którzy złożyli zamówienie dwa tygodnie temu. Google Analytics nam tych danych nie da, bo ich fizycznie nie posiada (a przynajmniej nam ich nie przedstawia ;))).

Kliknij na screen, aby powiększyć

Jak więc zaadresować ten problem?

Przekazywanie interesujących nas danych z Google Analytics do zewnętrznej bazy CRM

Jeżeli chcemy mieć możliwość analizy dodatkowych danych na temat naszych klientów czy leadów w naszych bazach CRM musimy te dodatkowe dane przekazać.

Wyobraźmy sobie sytuację sklepu internetowego, który chce widzieć jak zmieniały się źródła wejścia każdego z użytkowników wraz z kolejnymi zamówieniami. Czyli, że np. źródłem pierwszego zamówienia była kampania PPC, drugiego wejście bezpośrednie, a trzecie zamówienia danego klienta została zainicjowane mailingiem.

W normalnych warunkach, użytkownik przy składaniu zamówienia wypełniłby formularz (i pewnie się zarejestrował) zawierający takie dane:

• imię
• nazwisko
• adres dostawy
• email
• login

Co musielibyśmy zrobić, żeby widzieć w naszym CRMie jakie było źródło odwiedzin użytkownika? Musielibyśmy taką informację przekazać do CRMu wraz z pozostałymi danymi z formularza.

Jak więc to zrobić?

Nie będziemy przecież pytać użytkownika w formularzu składania zamówienia: „z jakiego źródła odesłania przychodzisz dobry człowieku?” (tutaj dowiesz się jakie są elementy, które warto w formularzach przetestować, a tutaj jak stworzyć dobry formularz). Szczególnie, że nie musimy o to pytać, ponieważ takie dane zawierają ciasteczka Google Analytics przechowywane w przeglądarce użytkownika. Musimy je jedynie przeczytać, a następnie wartość źródła odesłania przekazać w ukrytym polu formularza.

Nie wydaje się to łatwe? Nie wiesz jak czytać ciasteczka Google Analytics?

Tak naprawdę nie ma nic prostszego

Tak się składa, że niejaki Danny wyręczył nas w programowaniu i napisał skrypt, który czyta ciasteczka Google Analytics.

Wystarczy, że wczytamy skrypt na naszej stronie, a otrzymamy możliwość łatwego wykorzystania wszystkich elementów przechowywanych w ciasteczkach użytkownika. Przykładowo możemy m.in. poznać i przekazać w kodzie html:

• czas od ostatniej wizyty
• źródło odwiedzin
• słowo kluczowe odwiedzin
• numer kolejnych odwiedzin
• słowo kluczowe

a co za tym idzie także bezproblemowo te dane przesłać do naszej bazy CRM.

Przyznacie, że nie ma w tym nic trudnego, prawda?

Dążąc do perfekcji i osiągnięcia nirvany

Jest niestety jeden problem z wykorzystaniem tego podejścia. Tak jak pisałem, żeby analizować dane w CRMie, musimy je tam przekazać. Oznacza to, że już dziś musimy zadecydować, jakie dane będą nam potrzebne w przyszłości. Co jeśli ich nie przekażemy? Niestety nie będziemy mogli cofnąć czasu.

Na szczęście istnieje na to recepta.

Pamiętacie jak wspominałem o API Google Analytics? Daje nam ono dostęp do wszystkich danych historycznych zebranych w ramach naszego konta. Wspominałem, że standardowo nie da się tych danych wyeksportować dla pojedynczego użytkownika. Istnieje jednak na to pewien sposób.

Jak połączyć ze sobą dwa zestawy danych?

Zawsze jest tak, że jeżeli chcemy połączyć dwa zestawy danych, muszą one posiadać jeden wspólny element, który przyjmuje unikalne wartości. Przykładowo w bazie CRM takim kluczem jest numer klienta. Do jednego numeru może być przypisany tylko jeden klient i jego unikalne dane.

Z drugiej strony mamy dane z Google Analytics w których nie ma unikalnego numeru, który rozróżniałby każdego użytkownika i jego działania. Prawda jest jednak taka, że unikalny numer każdego użytkownika istnieje, tylko Google Analytics nam go nie udostępnia

To jest standardowe ciasteczko utma, które zostało utworzone przez Google Analytics na mojej przeglądarce w trakcie odwiedzin naszego bloga:

32856364.423507134.1316540148.1319460289.1321559324.8

Pogrubiony numer to ID użytkownika – losowy unikalny identyfikator (więcej informacji o ciasteczku utma znajdziecie tutaj). To ID nie zmienia się przy kolejnych odwiedzinach – zawsze pozostaje takie samo (dopóki ktoś nie skasuje ciasteczek ;)).

Teraz, jeżeli każdemu użytkownikowi przy odwiedzinach przekażemy do Google Analytics jako zmienną niestandardową ten numer ID (znowu za pomocą skryptu Danny’ego), to będziemy mogli analizować poczynania każdego pojedynczego użytkownika na naszej stronie:

Kliknij na screen, aby powiększyć

Mariusz korzystał z tego sposobu pisząc artykuł na temat _addIgnoredOrganic w Google Analytics.

Mamy więc taką sytuację:

1. W naszej bazie CRM, każdy klient / lead posiada unikalny wpis
2. W Google Analytics każdy pojedynczy użytkownik posiada unikalny numer ID

Aby połączyć te dane ze sobą, w obu bazach każdy użytkownik musi posiadać wspólny rekord. Oznacza to, że do bazy CRM musimy przekazać unikalne ID naszego użytkownika przechowywane przez Google Analytics (w zmiennych niestandardowych). Możemy ro zrobić opisywanym już sposobem, a więc w trakcie składania formularza przekazać wartość unikalnego ID jako ukryte pole do naszej bazy.

Stworzy nam się wtedy w bazie CRM taka tabela:

Z drugiej strony w Google Analytics będziemy mieli druga tabelę:

Kliknij na screen, aby powiększyć

Jak widzicie mamy część wspólną, czyli Unikalne ID użytkownika w jednej i drugiej bazie. Dzięki temu możemy je połączyć. Teraz, jeżeli będziemy potrzebowali jakichkolwiek informacji na temat któregoś z naszych użytkowników, wystarczy że stworzymy odpowiednie zapytanie przez API. Podając jako wyróżnik jego unikalne ID będziemy mieli dostęp do wszystkich zbieranych przez Google Analytics danych na jego temat.

Podsumowując

Google Analytics jest świetnym narzędziem do analizy danych ilościowych pochodzących z naszych serwisów. Niestety czasem jego możliwości się kończą i wtedy będziemy chcieli wykorzystać te dane w połączeniu z innymi, które mamy dostępne w hurtowniach danych lub bazach CRM. Dzięki takiemu podejściu będziecie mogli łączyć dane online i offline i przenieść swoją analizę i wnioski na prawdziwie wyższy poziom.

Co sądzicie o podejściu łączenia danych z Google Analytics z innymi systemami? Uważacie, że może to być przydatne?

The post Jak połączyć Google Analytics z systemami CRM? first appeared on Conversion.

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

Zaawansowane śledzenie

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

Śledzenie zdarzeń (ang. event tracking)

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

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

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

mailto.js

outband.js

Zmienne niestandardowe (ang. custom variables)

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

Śledzenie wypełniania formularzy

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

Śledzenie stron błędu 404

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

Instalacja E-Commerce

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

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

Pamiętam, że musiałem poświęcić sporo czasu w celu zrozumienia tej funkcjonalności. Nie było łatwo, ale było warto – naprawdę rozszerza ona pole widzenia ruchu na stronie internetowej. Ostatnio również miałem możliwość wykorzystać tą funkcjonalność i związku z tym, że musiałem wrócić do źródeł wiedzy na ten temat, postanowiłem napisać na ten temat artykuł – jak zawsze będę starał się kłaść nacisk na część praktyczną. Jednak tym razem bez wstępu teoretycznego się nie obejdzie. Moje rozważania w dużej mierze będą opierały sięna następujących treściach:

• Strona pomocy Google Analytics na temat zmiennych niestandardowych,
• Blog Google Analytics – moc zmiennych niestandardowych.
• Naszych doświadczeniach;)

Zmienne niestandardowe (ang. custom variables)

Najprościej mówiąc, zmienne niestandardowe dają Ci możliwość gromadzenia danych dotyczących różnych metryk i wymiarów (aby przypomnieć sobie co to jest zajrzyj do artykułu o raportach niestandardowych w Google Analytics), które nie są standardowo dostępne w panelu Google Analytics. Pozwalają one zdobyć dane na temat pewnych zachowań użytkowników Twojej strony, które nie są standardowo rozpoznawane przez system. Dla przykładu, Twoja firma oferuje darmową wersję kursu online na stronie. Możesz tak skonfigurować zmienną niestandardową, aby przekonać się jak poszczególni rodzaje użytkowników (zapisani vs. niezapisani na darmowy kurs) dalej zachowują się w ramach Twojej witryny. W szczególności możesz przekonać się m.in.:

• Jak dużo poszczególnych użytkowników powraca do Twojego serwisu?
• Jakie rodzaje wysyłki są najchętniej wybierane?

Jak działają zmienne niestandardowe?

Z technicznego punktu widzenia zmienne niestandardowe pozwalają oznaczyć użytkowników, którzy wykonali jakieś na działanie. Użytkownikowi, który np. kliknął button „Lubię to!” w Twoim serwisie zostaje nadana „etykieta”, która następnie może stać się wymiarem do segmentacji odwiedzających Twojego serwisu.

Zmienne niestandardowe mają zastosowanie na trzech poziomach strony: użytkownika, sesji, oraz pojedynczej strony. Najprościej podział ten można przedstawić za pomocą grafiki. Poniżej, krótka charakterystyka każdego z nich.

Źródło: http://analytics.blogspot.com/

1. 1. Poziom użytkownika

Etykieta jest nadana użytkownikowi, który spełnia założony warunek i jest określona dla niego do czasu wygaśnięcia lub usunięcia ciasteczek z jego przeglądarki np. klienci vs. niekliencki sklepu internetowego.

1. 1. Poziom sesji

Przypomnijmy, że sesja jest czasem spędzonym przez użytkownika od momentu jego wejścia do czasu wyjścia z witryny (lub wygaśnięcia odpowiedniego ciasteczka po 30 minutach – kwestia ustawienia w Google Analytics. W związku z tym również etykiety nadane użytkownikom są aktywne jedynie na ten czas. Po opuszczeniu serwisu przez odwiedzającego traci on status użytkownika, który otrzymał.

1. 1. Poziom strony

W czasie jednej sesji użytkownik może odwiedzić wiele stron. W zależności od akcji, którą wykonał może zostać przypisany do danej kategorii np. po kliknięciu linku lub zobaczeniu video.

Warto również wspomnieć, że zmienne niestandardowe zastąpiły zmienne typu SetVar. Jednak ich negatywną stroną jest fakt, że nie można ich stosować w filtrach.

Jak skonfigurować zmienne niestandardowe?

Przed przejściem do podania konkretnych przykładów, najpierw musisz dowiedzieć się, jak umożliwić sobie korzystanie z funkcjonalności, jaką są zmienne niestandardowe. Tutaj ponownie odwołam się do blogu Mariusza, na którym znajdziecie jak skonfigurować kod, aby mieć możliwość korzystania ze zmiennych niestandardowych. Oczywiście, nieocenionym źródłem pomocy w tym względzie może okazać się również centrum pomocy Google Analytics. Gdyby tego było za mało, w przykładach poniżej będę starał się podawać przykłady kodu, który trzeba wprowadzić, aby skorzystać z danych zmiennych niestandardowych.

Przykłady zmiennych niestandardowych

Przykłady zostaną podane na podstawie poziomów, na których mogą być generowane zmienne niestandardowe.

Poziom użytkownika – wybór wersji językowej strony

Użytkownicy zostają przypisani do danego segmentu zgodnie z wersją językową serwisu, którą wybrali. Modyfikacja kodu śledzącego na stronie, w ramach które istnieje możliwość wyboru języka będzie wyglądała wówczas następująco:

<form onsubmit="_gaq.push(['_setCustomVar', 1, 'wersja-językowa',
this.mymenu.options[this.mymenu.selectedIndex].value, 1],['_trackPageview']); ">

<select name=mymenu>

<option value="arabic">Arabski</option>

<option value="english">Angielski</option>

<option value="franch">Francuski</option>

<option value="spanish">Hiszpański</option>

<input type="submit" name="Submit" value="Submit">

</form>

Powyższy przykład dotyczy stron bardziej „międzynarodowych”. Innym przykładem, znanym z własnego podwórka jest serwis Jakdojade.pl. Po wejściu na stronę ukazuje się nam ekran powitaln, w którym możemy wybrać miasto, w którym szukamy połączenia komunikacji miejskiej. Przy pomocy zmiennych niestandardowych, podobnie jak w powyższym przykładzie możemy nadać użytkownikom etykiety. W tym przypadku użyjemy jednak „onclick” zamiast „onsubmit” w śledzeniu zdarzeń. Przypomnę, że tutaj możesz przeczytać więcej o śledzeniu zdarzeń w Google Analytics.

Poziom sesji – typ użytkownika

Na poziomie sesji można użyć wielu zmiennych niestandardowych, aby zróżnicować użytkowników na podstawie ich zachowania w czasie sesji. Najprostszym przykładem jest rozróżnienie użytkowników na podstawie ich konwersji, czyli np. na tych, którzy cokolwiek kupili (w przypadku sklepu internetowego) i pozostałych. Użytkownik, który kupi cokolwiek będzie „naznaczony” np. etykietą „buyer”.

Dla takiego przykładu zmodyfikowana powinna zostać strona końcowa konwersji (ang. landing page), czyli np. ekran podziękowania za dokonanie zakupu. W związku z tym kod śledzący na takiej podstronie powinien wyglądać następująco.

<script type="text/javascript">

        var _gaq = _gaq || [];

        _gaq.push(['_setAccount','UA-xxxxxxxx-x']);

        _gaq.push(['._setCustomVar(2, "typ-użytkownika", "Buyer", 2)']);

        _gaq.push(['_trackPageview']);

…

</script>

Poziom strony – różne działy

Na tym poziomie zmiennej niestandardowej możesz np. sprawdzić, który dział twojego serwisu jest najbardziej popularny. Załóżmy, że prowadzisz sklep internetowy z odzieżą. Dla poszczególnych kategorii ubrań możesz nadać etykiety. Edytujesz kod źródłowy każdej z podstron.
www.domain.com/damskie.html

<script type="text/javascript">

        var _gaq = _gaq || [];

        _gaq.push(['_setAccount','UA-xxxxxxxx-x']);

        _gaq.push(['._setCustomVar(3, "kategoria", "damskie", 3)']);

        _gaq.push(['_trackPageview']);

…

</script>

www.domain.com/meskie.html

<script type="text/javascript">

        var _gaq = _gaq || [];

        _gaq.push(['_setAccount','UA-xxxxxxxx-x']);

        _gaq.push(['._setCustomVar(3, "kategoria", "meskie", 3)']);

        _gaq.push(['_trackPageview']);

…

</script>

www.domain.com/dzieciece.html

<script type="text/javascript">

        var _gaq = _gaq || [];

        _gaq.push(['_setAccount','UA-xxxxxxxx-x']);

        _gaq.push(['._setCustomVar(3, "kategoria", "dzieciece", 3)']);

        _gaq.push(['_trackPageview']);

…

</script>

I tak dalej:)

Na koniec słowo komentarza, który jest motywem przewodnim większości moich artykułów:) W przypadku zmiennych niestandardowych również nie można mówić o najlepszych praktykach – myślę, że sami dokładnie zdajecie sobie z tego sprawę. W końcu, po co komuś rozróżnienie użytkowników na klientów i nieklientów, jeżeli Twoja strona nie jest „sprzedażowa”.

Podsumowanie

Starałem się jak najprościej wytłumaczyć działanie tej funkcjonalności Google Analytics – mam nadzieję, że mi się udało:) Pamiętam, że sam na początku miałem z tym problem, więc chciałem Wam krok po kroku to pokazać. Jeżeli jednak ciągle nie czujesz istoty zmiennych niestandardowych, to zapraszam do obejrzenia filmu dotyczącego istoty i podstaw tworzenia zmiennych niestandardowych (film jest w języku angielskim i niestety w bardzo słabej jakości dźwięku), ale dla mnie okazał się bardzo pomocny. Pamiętaj też, że jak już się natrudzisz w Google Analytics, to raportowanie będzie już przyjemniejsze dzięki Google Data Studio – programowi, który służy do raportowania danych z różnych usług Google oraz innych, dodanych przez użytkownika źródeł. Integruje dane z wielu narzędzi w jednym miejscu i tworzy na ich podstawie raport, które następnie prezentuje w formie atrakcyjnych wizualnie wykresów. Tak to można analizować! Jak zawsze zapraszam Was do dyskusji w komentarzach.

The post Zrozumieć zmienne niestandardowe w Google Analytics first appeared on Conversion.