W tym roku minie 7 lat od wejścia Google Analytics na rynek. W ciągu tych 7 lat Analytics stał się obowiązującym standardem w branży, stopniowo wypierając rozwiązania konkurencyjne. Jak to wszystko się zaczęło? W jaki sposób Google i jego aplikacja zdołały w ciągu stosunkowo krótkiego przecież okresu czasu zdominować rynek? Zapraszam do zapoznania się z historią Google Analytics :)

Na początku był..

..Urchin. Płatna aplikacja, pozwalająca gromadzić dane na temat ruchu w obrębie serwisu internetowego. Narzędzie to powstało w 1997 roku i potrzebowało tylko kilku lat, aby zająć na rynku stabilną pozycję. Urchin był rozwiązaniem hybrydowym – gromadzone przezeń dane były odczytywane z logów serwera oraz gromadzone za pomocą skryptów śledzących, podpiętych pod poszczególnych podstrony witryny (dowiedz się więcej na temat różnych metod zbierania danych na temat ruchu w obrębie strony internetowej).

Kliknij na zdjęcie, aby powiększyć

W 2004 roku na rynku pojawiła się alternatywna wersja aplikacji Urchin, nosząca nazwę Urchin On-Demand. Grupą docelową nowego narzędzia byli pracownicy działów marketingu, a więc osoby nie posiadające kompleksowej wiedzy na temat technicznych aspektów funkcjonowania serwisu internetowego. Między innymi z tego powodu Urchin On-Demand korzystał wyłącznie ze skryptów śledzących, wpiętych w kod witryny internetowej. Dzięki temu, instalacja i konfiguracja narzędzia nie dość, że mogła zostać przeprowadzona błyskawicznie, to jeszcze możliwe było przeprowadzenie jej bez udziału IT.

Co więcej, ze względu na wymagania wyżej wymienionej grupy docelowej, Urchin On-Demand został wyposażony w szereg funkcjonalności, pozwalających mierzyć i oceniać efektywność witryny WWW nie tylko w kategoriach technicznych, ale również w kategoriach marketingowych. Aplikacja zapewniała m. in. integrację ze wszystkimi popularnymi wówczas platformami reklamowymi, takimi jak Google AdWords.

Google wkracza do gry

W kwietniu 2005 roku Urchin został przejęty przez Google. W listopadzie 2005 roku na rynku pojawił się Google Analytics.

Kliknij na zdjęcie, aby powiększyć

Pierwsza wersja GA pod wieloma względami (interfejs, dostępne funkcjonalności) przypominała Urchin On-Demand. Różnica była w zasadzie jedna – o ile Urchin do końca pozostał narzędziem płatnym, o tyle Google Analytics od początku był dostępny za darmo.

W ciągu kilku kolejnych miesięcy liczba aktywnych kont w usłudze Google Analytics przekroczyła milion. Analityka internetowa (ang. web analytics) stała się dostępna dla każdego.

Dynamiczny rozwój Google Analytics

Podbój rynku w wykonaniu aplikacji Google rozpoczął się w kwietniu 2007 roku, kiedy światło dzienne ujrzała nowa wersja interfejsu Google Analytics.

Nowy interfejs – opracowany przez agencję Adaptive Path – okazał się na tyle udany, że przetrwał w prawie niezmienionej formie przez kolejnych kilka lat i został zastosowany z powodzeniem w obrębie innych aplikacji Google (m. in. panel administracyjny AdWords).

Kliknij na zdjęcie, aby powiększyć

W październiku 2008 roku Analytics został wzbogacony o możliwość definiowania własnych segmentów (ang. advanced segments), równolegle otrzymaliśmy również możliwość definiowania własnych raportów (ang. custom reports). W tym samym czasie udostępniona została również pierwsza wersja biblioteki API, pozwalająca nawiązać komunikację z aplikacją poza interfejsem webowym, dostępnym z poziomu przeglądarki.

Kolejny rok przyniósł kolejne nowości. W marcu 2009 roku Google uruchomiło platformę e-learningową oraz internetowe centrum certyfikacji Google Analytics Individual Qualification – był to pierwszy krok na drodze do wypracowania jednolitych standardów w branży.

W październiku 2009 roku użytkownicy Google Analytics otrzymali możliwość oznaczania wybranych użytkowników przy pomocy etykiet niestandardowych (ang. custom variables), co dodatkowo zwiększyło możliwości w zakresie segmentowania ruchu, oferowane przez aplikację. W tym samym miesiącu udostępniony został również moduł inteligentnej analizy (ang. analytics intelligence), czyli w pełni konfigurowalny asystent analityka, generujący automatyczne powiadomienia o wystąpieniu w obrębie serwisu określonych zdarzeń.

W grudniu 2009 roku światło dzienne ujrzała również nowa, asynchroniczna wersja kodu śledzącego (ang. Google Analytics Tracking Code, GATC). Asynchroniczna wersja kodu śledzącego gwarantowała zerowy wpływ działania skryptu na szybkość ładowania poszczególnych podstron otagowanego serwisu.

Oprócz tego, w 2009 roku otrzymaliśmy kilka pomniejszych usprawnień – m. in. uzyskaliśmy możliwość oznaczania ważnych dla naszego serwisu dat poprzez tworzenie adnotacji bezpośrednio z poziomu Google Analytics.

Cisza przed burzą

W 2010 roku otrzymaliśmy w zasadzie tylko jedną istotną modyfikację w obrębie Google Analytics – chodzi tutaj oczywiście o moduł analityki w treści strony (ang. in-page analytics), czyli funkcjonalność pozwalającą odnieść wszystkie zgromadzone przez aplikację informacje na temat ruchu w obrębie danej strony do jej rzeczywistej zawartości.

Obecnie wiadomo, że była to przysłowiowa cisza przed burzą.

W kwietniu 2011 roku światło dzienne ujrzała nowa wersja interfejsu GA.

Kliknij na zdjęcie, aby powiększyć

W maju 2011 roku Google udostępniło „nową” grupę raportów, noszących nazwę szybkość witryny (ang. site speed), dzięki którym otrzymaliśmy wgląd w techniczne aspekty funkcjonowania naszego serwisu.

W sierpniu 2011 roku użytkownikom Google Analytics udostępniona została kolejna nowa grupa raportów, służąca do pomiaru i oceny efektywności źródeł ruchu – tzw. ścieżki wielokanałowe (ang. multi-channel funnels) wyznaczyły zupełnie nową jakość, jeżeli chodzi o analizę źródeł odesłania. Pojawieniu się nowej grupy raportów towarzyszyła równoległa zmiana definicji sesji – wydarzenie o tyle istotne, że definicja ta była utrzymywana w zasadzie w niezmienionej postaci od początku istnienia Google Analytics.

We wrześniu 2011 roku Google udostępniło moduł analityki w czasie rzeczywistym (ang. real-time analytics), umożliwiający obserwowanie „na żywo” sytuacji w obrębie witryny. Ten miesiąc zostanie jednak zapamiętany z innego powodu – to właśnie wtedy Google ogłosiło, że zamierza wprowadzić płatną wersją GA, przeznaczoną dla najbardziej wymagających użytkowników.

Kolejny miesiąc natomiast z pewnością zostanie na długo w pamięci wszystkich osób zawodowo zajmujących się SEO – począwszy od października 2011 roku, w obrębie raportów generowanych przez Google Analytics pojawiać zaczęło się słowo kluczowe not provided, oznaczające, że dane wyszukiwanie zostało przeprowadzone w trybie bezpiecznym (przy użyciu protokołu SSL) i dane na jego temat nie są dostępne z poziomu GA. Równolegle, użytkownicy Google Analytics uzyskali możliwość połączenia swojego konta GA z odpowiadającym mu kontem w ramach usługi Google Webmaster Tools.

W październiku 2011 roku użytkownikom GA udostępnione zostały również dwa zupełnie nowe raporty, czyli diagram przepływu użytkowników oraz diagram procesu celu (ang. visitors flow, goal flow).

Co teraz?

Jednego możemy być pewni – Google nie powiedziało jeszcze ostatniego słowa i nadal będzie rozwijało swój produkt. Przegląd tego, czego możemy się spodziewać w najbliższej przyszłości jest dostępny w treści jednego z ostatnich postów, który ukazał się na łamach oficjalnego bloga Google Analytics. Brzmi ciekawie, nieprawdaż? :) jakie jest Waszym zdaniem jedno, największe wyzwanie, przed którym stoi obecnie Google, jeżeli chodzi o rozwój Google Analytics? :)

Historia Google Analytics w pigułce is a post from: Conversion blog

Już po raz czwarty mamy przyjemność zaprosić Was do udziału w naszych szkoleniach otwartych, dotyczących wykorzystania Google Analytics i Google Website Optimizer w zarządzaniu działalnością online firmy.

Szkolenia odbędą się w dniach 23-24 lutego 2012 roku w Warszawie. Dla pierwszych uczestników przygotowana została oferta specjalna – jeżeli zarejestrujesz się przed 22 stycznia, za jeden dzień szkoleniowy zapłacisz tylko 470 zł netto, oszczędzając aż 120 zł.

Zarejestruj się na szkolenia Conversion lub czytaj dalej, aby dowiedzieć się więcej na temat prowadzących, programu oraz lokalizacji szkoleń.

Szkolenia prowadzą Mariusz Michalczuk oraz Paweł Ogonowski. Obaj szkolili w trakcie dedykowanych szkoleń zamkniętych przedstawicieli wiodących firm w Polsce – z ich wiedzy skorzystały takie firmy, jak Grupa Pracuj, LUKAS Bank, Sygma Bank, czy Krajowy Rejestr Długów.

Podczas szkoleń otwartych Conversion zdobędziesz konkretne i praktyczne umiejętności w zakresie analizy danych generowanych przez Google Analytics:

• dowiesz się jak przy pomocy Google Analytics oceniać wszystkie rodzaje kampanii marketingowych online,
• dowiesz się jak działa Google Analytics i jak unikać najczęściej popełnianych błędów,
• dowiesz się jak zainstalować i poprawnie skonfigurować Google Analytics,
• poznasz efektywne sposoby na wykorzystanie zaawansowanych funkcjonalności Google Analytics – segmentów zaawansowanych, raportów niestandardowych, śledzenia e-commerce i wielu innych.

Dowiesz się również, jak bezpiecznie testować swoje pomysły na poprawę serwisu przy użyciu Google Website Optimizer:

• dowiesz się jak optymalizacja konwersji wpływa na wzrost przychodu generowanego przez stronę internetową,
• poznasz najpopularniejsze metody testów, ich zalety i wady,
• dowiesz się, jak tworzyć testy w Google Website Optimizer oraz jak efektywnie analizować dane z raportów,
• poznasz metody na identyfikację stron i elementów w ich obrębie, które warto testować,
• poznasz alternatywy dla Google Website Optimizer.

Pamiętaj, że niedługo dostępna będzie wyłącznie nowa wersja Google Analytics. Czwarta edycja naszych szkoleń otwartych będzie w całości oparta na najnowszej wersji narzędzia. Przejdź razem z nami bezboleśnie ze starej do nowej wersji interfejsu Google Analytics.

Szkolenia odbędą się w Warszawie, w centrum konferencyjnym budynku Millenium Plaza przy al. Jerozolimskich 123A – zobacz lokalizację szkoleń na mapie. Sala szkoleniowa jest klimatyzowana i posiada na wyposażeniu bezprzewodowe połączenie z Internetem. Położenie budynku w sąsiedztwie najważniejszych punktów komunikacyjnych miasta (Dworzec Warszawa Centralna, Dworzec Warszawa Zachodnia, Metro Centrum) gwarantuje bezproblemowy i szybki dojazd, także osobom spoza Warszawy.

Cena regularna jednego dnia szkoleniowego to 590 zł netto. Obejmuje ona:

• ponad 5 godzin efektywnego szkolenia Google Analytics lub Google Website Optimizer,
• certyfikat ukończenia szkolenia, wydawany przez Conversion,
• materiały szkoleniowe w formie drukowanej oraz elektronicznej,
• gadżety Conversion: kubek, notes oraz długopis,
• serwis kawowo-ciastkowy.

Dla pierwszych uczestników przygotowana została oferta specjalna – jeżeli zarejestrujesz się przed 22 stycznia, za jeden dzień szkoleniowy zapłacisz tylko 470 zł netto, oszczędzając aż 120 zł.

Wybierając dwa dni szkoleniowe, również korzystasz z oferty promocyjnej i płacisz tylko 940 zł netto, oszczędzając łącznie aż 240 zł.

Przejdź na oficjalną stronę szkoleń Conversion i zarejestruj się.

Zapraszamy!

Szkolenia Google Analytics i Google Website Optimizer, Warszawa, 23-24 lutego 2012 r. is a post from: Conversion blog

Dzisiejszy post to kolejny powrót do podstaw Google Analytics – tym razem zajmiemy się modułem e-commerce. Temat bliski większości z Was, a na tym blogu dotychczas w zasadzie nieobecny – czas najwyższy nadrobić zaległości. Gotowi? Zaczynamy!

Do czego służy moduł e-commerce?

W dużym uproszczeniu, dostępny w obrębie Google Analytics moduł e-commerce służy do śledzenia realizacji celów, dokonywanych w obrębie witryny przez jej użytkowników.

Celowo użyłem w powyższej definicji określenia cel, ponieważ wbrew powszechnej opinii moduł e-commerce ma znacznie więcej zastosowań, niż proste rejestrowanie zamówień (transakcji), składanych za pośrednictwem witryny.

Odpowiednio skonfigurowane śledzenie e-commerce może zostać wykorzystane do pomiaru efektywności każdej w zasadzie witryny, w obrębie której od użytkowników oczekuje się wykonania jak największej liczby określonego rodzaju czynności. Tą czynnością może być złożenie zamówienia, pobranie pliku, wysłanie uzupełnionego formularza kontaktowego, a nawet odwiedzenie określonej podstrony serwisu.

W tym miejscy niektórzy z Was zapewne zastanawiają się..

..czym różni się śledzenie e-commerce od śledzenia celów?

W ramach każdego profilu, stworzonego w ramach danego konta Google Analytics mamy przecież możliwość zdefiniowania do 20 celów, których wypełnienia oczekujemy od użytkownika. Celem może być, podobnie jak w przypadku modułu e-commerce, złożenie zamówienia, pobranie pliku, odwiedzenie określonej podstrony itd.

Poprawnie skonfigurowane śledzenie celów zapewni nam informacje na temat tego, jaki odsetek odwiedzających realizuje w obrębie serwisu określone czynności, jak wyglądają najczęściej wykorzystywane przez internautów ścieżki dojścia do celu, jak funkcjonuje modelowa ścieżka realizacji danego celu, zdefiniowana przez twórców serwisu itd.

Co więcej, każdy ze zdefiniowanych w ramach profilu celów możemy zmonetyzować (przypisać jego realizacji określoną wartość pieniężną), dzięki czemu łatwo określimy, jaki dochód generuje nasza witryna.

Pojawia się w tym miejscu zatem pytanie, po co właściwie dodatkowo konfigurować mamy śledzenie e-commerce?

Podstawowym argumentem, przemawiającym za modułem e-commerce jest fakt, że w ramach pojedynczej sesji każdy ze zdefiniowany celów może zostać przez użytkownika wykonany tylko jeden raz. Kolejne realizacje – jeżeli mają miejsce w ramach tej samej sesji – nie są liczone przez Google Analytics.

W tym miejscu z pomocą przychodzi poprawnie skonfigurowany moduł e-commerce, który rejestruje każdą realizację celu, mającą miejsce w ramach serwisu. Jednocześnie, śledzenie e-commerce umożliwia zapisanie szeregu dodatkowych informacji na temat wykonanej przez użytkownika czynności, które nie są rejestrowane przez moduł śledzenie celów.

Zdecydowanie najczęściej spotykanym zastosowaniem modułu e-commerce jest śledzenie zamówień, składanych przy pomocy serwisu WWW – w dalszej części posta skoncentrujemy się zatem na tym aspekcie jego wykorzystania.

Wdrożenie modułu e-commerce

Implementacja modułu e-commerce jest stosunkowo łatwa.

Krok pierwszy to aktywacja śledzenie e-commerce w obrębie wybranego przez nas profilu. Podobnie jak klasyczne śledzenie celów, funkcjonowanie modułu e-commerce jest ściśle powiązane z konfiguracją konkretnego profilu. Możemy to wykorzystać i udostępniać wybranym użytkownikom naszego konta Google Analytics tylko dane, dotyczące ruchu na temat w serwisie – dane sprzedażowe natomiast gromadzić w obrębie odrębnego profilu, widocznego tylko dla nas.

Aktywacja śledzenia e-commerce odbywa się w ramach panelu ustawień profilu poprzez wybór opcji Witryna e-commerce z listy rozwijalnej Śledzenie e-commerce.

Kliknij na zdjęcie, aby powiększyć

Krok drugi to identyfikacja tzw. thank you page, czyli podstrony w obrębie naszego serwisu, będącej potwierdzeniem złożenia zamówienia.

Kliknij na zdjęcie, aby powiększyć

Krok trzeci to umieszczenie w kodzie podstrony, potwierdzającej złożenie zamówienia, zmodyfikowanego skryptu śledzącego Google Analytics.

W stosunku do wersji standardowej kodu śledzącego, widzimy tutaj trzy dodatkowe funkcje, odpowiadające za rejestrację wykonanej przez użytkownika czynności.

Wywoływana jako pierwsza funkcja _addTrans gromadzi ogólne dane na temat wykonanej czynności i zapisuje je w postaci pliku cookie na dysku użytkownika – w naszym wypadku gromadzone są dane na temat złożonego zamówienia. Funkcja ta definiowana jest następująco:

Poniżej, informacje na temat poszczególnych parametrów:

• orderId – unikalny numer zamówienia, parametr obowiązkowy,
• affiliation – nazwa affilianta (pośrednika), dzięki któremu doszło do transakcji,
• total – całkowita wartość zamówienia, parametr obowiązkowy,
• tax – wartość podatku,
• shipping – wartość kosztu dostawy,
• city – miasto, które należy przypisać do zamówienia,
• state – region (województwo), które należy przypisać do zamówienia,
• country – państwo, które należy przypisać do zamówienia.

Google Analytics wymaga, aby tylko parametry oznaczone jako obowiązkowe posiadały zdefiniowaną wartość. Pozostałe z parametrów przekazywanych do funkcji _addTrans muszą zostać uwzględnione w jej wywołaniu, ale nie jest konieczne definiowanie dla nich wartości, tzn. można w ich miejsce przekazać do funkcji wartości puste, oznaczone przez parę apostrofów ‘’.

Kolejna funkcja, czyli _addItem, umożliwia zgromadzenie kolejnej porcji danych i dopisanie ich do już utworzonego pliku cookie. W przypadku śledzenia składanych zamówień, funkcja _addItem zbiera szczegółowe dane na temat każdego rodzaju produktu, wchodzącego w skład danego zamówienia i w związku z tym powinna być wywołana osobno dla każdego rodzaju produktu, zamówionego przez internautę.

Funkcja _addItem definiowana jest następująco:

Znaczenie poszczególnych parametrów:

• orderId – unikalny numer zamówienia, umożliwia przypisanie danego produktu do konkretnego zamówienia, parametr obowiązkowy,
• sku – kod produktu, parametr obowiązkowy,
• name – nazwa produktu, parametr obowiązkowy,
• category – kategoria, do której należy produkt,
• price – cena jednostkowa produktu, parametr obowiązkowy,
• quantity – ilość produktów danego rodzaju, wchodzących w skład zamówienia, parametr obowiązkowy.

W przypadku funkcji _addItem, zdecydowana większość parametrów ma charakter obowiązkowy – konieczne jest więc zdefiniowanie dla nich konkretnych wartości. Ponownie również parametry nieobowiązkowe muszą zostać uwzględnione w wywołaniu funkcji, możliwe jest jednak przekazanie w ich miejsce wartości pustej.

Ostatnia z dodatkowych funkcji to _trackTrans.

Jest to funkcja bezparametrowa, a jej wywołanie powoduje nawiązanie komunikacji z serwerem Google oraz wysłanie informacji na temat wykonanej przez użytkownika czynności, zapisanych dotychczas w lokalnie utworzonym pliku cookie – w naszym przypadku wysyłany jest komplet informacji na temat złożonego zamówienia.

A co jeżeli nasza witryna nie zawiera strony potwierdzającej złożenie zamówienia?

Spokojnie, wtedy implementacja modułu e-commerce także jest wykonalna – opisane powyżej funkcje mogą zostać wywołane również poza kodem śledzącym Google Analytics, np. w ramach zdarzenia onclick, wywoływanego po kliknięciu przycisku, odpowiadającego za finalizację transakcji:

Jak wykorzystać moduł e-commece?

Poprawnie skonfigurowany moduł śledzenia e-commerce daje nam szereg dodatkowych możliwości analitycznych, wykraczających poza możliwości oferowane przez standardowe śledzenie celów.

Pomiar efektywności poszczególnych źródeł ruchu

Przede wszystkim, aktywacja śledzenia e-commerce powoduje, że większość standardowych raportów w obrębie Google Analytics zostanie wyposażona w dodatkową zakładkę – obok informacji, pochodzących z modułu śledzenia celów, pojawią się informacje pochodzące z modułu e-commerce. Dobrym przykładem są raporty należące do grupy Źródła, np. raport Źródła -> Cały ruch.

Kliknij na zdjęcie, aby powiększyć

Po skonfigurowaniu śledzenia e-commerce, pomiar efektywności poszczególnych źródeł ruchu może obejmować również analizę informacji, pochodzących z modułu e-commerce. Patrząc na powyższy przykład, jesteśmy bez trudu w stanie zidentyfikować najbardziej dochodowe źródło odesłania – jest nim witryna ceneo.pl, która w analizowanym okresie czasu przyczyniła się bezpośrednio do wygenerowania 773 zamówień na kwotę ponad 150 000 zł.

Informacje, pochodzące z modułu e-commerce są uwzględniane także w obrębie raportów z grupy Ścieżki wielokanałowe, które dają możliwość dalszego pogłębienia analizy efektywności źródeł odesłania.

Raportowanie i pomiar efektywności sprzedaży

Aktywacja modułu e-commerce daje nam dostęp do kilku raportów dedykowanych, niedostępnych w standardowej konfiguracji Google Analytics.

Kliknij na zdjęcie, aby powiększyć

Raport Skuteczność produktu to raport typowo sprzedażowy – zajmująca centralne miejsce tabela wyświetla podstawowe dane sprzedażowe w podziale na poszczególne produkty i/lub kategorie produktowe. Na tej podstawie – przykładowo – łatwo jesteśmy w stanie określić, że produkt, który w analizowanym okresie czasu sprzedawał się najlepiej, to komplet 100 szt. płyt DVD+R firmy Extreme.

Kliknij na zdjęcie, aby powiększyć

Raportem sprzedażowym jest także raport Skuteczność sprzedaży – ponownie centralne miejsce zajmuje tabela, tym razem jednak przedstawia ona przychody w ujęciu dziennym, osiągnięte w poszczególnych dniach analizowanego okresu czasu. Wykorzystując mechanizm sortowania szybko wskażemy najbardziej dochodowy dzień w ramach interesującego nas okresu – w tym przypadku jest to 13 grudnia.

Zakładki, znajdujące się w górnej części raportu Skuteczność sprzedaży, pozwalają zmienić parametr, którego dzienne wartości wyświetlane są w tabeli – do wyboru mamy jeszcze m. in. średnią wartość zamówienia.

Analiza cyklu życia klienta

Ciekawym raportem dedykowanym, dostępnym po aktywacji modułu e-commerce, jest raport Czas do zakupu.

Kliknij na zdjęcie, aby powiększyć

Pozwala on nam dowiedzieć się, ile czasu oraz ile wizyt w naszym serwisie potrzebują użytkownicy, aby złożyć zamówienie. Przykładowo, analiza powyższych danych pozwalam nam stwierdzić, że w analizowanym okresie czasu aż 1394 transakcje (czyli ponad 84% ogólnej ich liczby) miało miejsce już w ramach pierwszej wizyty w serwisie.

A co z witrynami nietransakcyjnymi?

Na początku napisałem, że możliwości modułu e-commerce zdecydowanie wykraczają poza proste rejestrowanie składanych w serwisie zamówień oraz że celem, którego realizacje śledzimy w ramach modułu e-commerce może być wiele innych czynności, podjętych przez użytkownika.

A zatem, w jaki sposób odnieść to wszystko, co napisałem później na temat wdrażania modułu e-commerce oraz sposobów jego wykorzystania, do witryny nietransakcyjnej? Co zrobić, jeżeli przy pomocy śledzenia e-commerce chcemy śledzić np. pobrania plików?

Proces wdrożeniowy przebiega w analogiczny sposób, jednakowa jest metodyka analiz – wszystko, co musimy zrobić, to nadać zgromadzonym informacjom interpretację, zgodną ze specyfiką naszej witryny.

Przy pomocy modułu e-commerce chcemy śledzić pobrania plików? Nie ma problemu. Musimy tylko określić, co jest tutaj „zamówieniem” (zapewne pobranie pliku), a co „produktem” (niechybnie konkretny plik, który został pobrany). No i musimy wiedzieć, ile każdy „produkt” jest dla nas warty. Przydatna w tym momencie będzie wiedza, dotyczące monetyzacji serwisu nietransakcyjnego.

Podsumowanie

Moduł e-commerce stanowi cenne uzupełnienie standardowego modułu śledzenia celów, ponieważ pozwala rejestrować wszystkie realizacje celów, które miały miejsce w obrębie witryny.

Celów, ponieważ wbrew powszechnie panującej opinii śledzenie e-commerce dotyczyć może dowolnego rodzaju czynności, możliwej do podjęcia w ramach witryny – niekoniecznie musi to być złożenie zamówienia.

Wykorzystujecie śledzenie e-commerce do gromadzenia danych na temat swojej witryny? Śledzicie składane w serwisie zamówienia, czy też może wykorzystujecie moduł e-commerce w niestandardowy sposób? Zachęcam do dyskusji.

Zachęcam również do śledzenia naszego bloga – pod koniec miesiąca opublikuję drugi tekst na temat modułu e-commerce, w którym opiszę kilka bardziej zaawansowanych rozwiązań, związanych z wykorzystaniem śledzenia e-commerce. Będzie między innymi na temat obsługi zewnętrznych płatności :)

Powrót do podstaw: Moduł e-commerce w Google Analytics is a post from: Conversion blog

Ja jednak dzisiaj będę chciał nie wychodzić poza własne podwórko i przedstawić 5 naj… postów na naszym blogu w różnych kategoriach.

5 najczęściej komentowanych postów w 2011 roku

Cieszy nas fakt, że coraz częściej komentujecie nasze artykuły – zawsze zachęcamy do tego. Bardzo fajne jest również to, że zaczynacie zadawać pytania dotyczące Waszych problemów – jak widać po poniższym rankingu najczęściej dotyczą one pracy z Google Analytics. Pamiętajcie, że żadne pytanie nie pozostanie bez odpowiedzi, dlatego zachęcamy do dzielenia się własnymi doświadczeniami.

1. Google Analytics w czasie rzeczywistym (real-time)
2. Lepszy sposób na śledzenie kampanii wewnętrznych w Google Analytics
3. Śledzenie kliknięć w Lubię to! i naturalnych udostępnień na Facebooku i w Google Analytics
4. Jak połączyć Google Analytics z systemami CRM?
5. Zmiana definicji wizyty w Google Analytics

5 najczęściej czytanych postów w 2011 roku

Tutaj, jak widać, sytuacja jest trochę przewrotna – najczęściej czytanym artykułem jest post dotyczący poniekąd zagadnień statystycznych. Warto zwrócić uwagę, że nie wszystkie posty pochodzą z 2010 (naturalnie rzecz biorąc mają one przewagą nad publikacjami z 2011 ze względu na pełny rok obecności na blogu). Widać również, że poszukujecie sposobów na mierzenie działań prowadzonych w Social Media…

1. Reguła 3 sigm – podstawa funkcjonowania alertów w Google Analytics
2. Śledzenie kliknięć w Lubię to! i naturalnych udostępnień na Facebooku i w Google Analytics
3. Instalacja Google Analytics na stronie (fan page’u) na Facebooku
4. Śledzenie urządzeń mobilnych za pomocą fotokodów (QR codes) w Google Analytics
5. Fanpage Trender – lepsze statystyki dla Facebooka

5 najdłużej czytanych postów w 2011 roku

Mowa tutaj oczywiście o średnim czasie spędzonym na stronie danego postu. Jak dla mnie, nie ma tutaj wielkiego zaskoczenia – najdłużej czytane są posty, które osobiście uważam za bardzo techniczne, na których przyswojenie po prostu trzeba poświęcić więcej czasu. W tajemnicy powiem, że napisanie takiego artykułu zajmuje znaaacznie więcej czasu niż go się czyta…

1. Reguła 3 sigm – podstawa funkcjonowania alertów w Google Analytics
2. Praktyczne wprowadzenie do wyrażeń regularnych (regex)
3. Co mi się nie podoba w nowym interfejsie Google Analytics
4. Śledzenie kliknięć w Lubię to! i naturalnych udostępnień na Facebooku i w Google Analytics
5. 15 zasad tworzenia dobrych formularzy

Jak widać w powyższych kategoriach część postów powtarza się. Jest to dla nas poniekąd wskazanie, co Was interesuje. Z drugiej strony dostępna jest ankieta KISSinsights, dzięki której możecie zgłaszać zapotrzebowanie na tematy – jak już część z Was się przekonała sugestie brane są pod uwagę i na blogu pojawiają się artykuły o wskazane przez Was treściach:)

Konkurs!

Wbrew trendowi „końcowo-rocznemu” ostatni postem na naszym blogu nie jest podsumowanie mijającego roku ani prognozy na przyszły rok. Nie oznacza to jednak, że może tego zabraknąć.

Ogłaszamy konkurs na najciekawszą prognozę dotyczącą świata internetu (oczywiście najchętniej analityki internetowej i optymalizacji konwersji, ale może być również SEM, SEO, Social Media, Startupów i wszystkiego, co jest związane z globalną siecią, a w czym czujecie się najlepiej).

Dla osoby, która zostawi w komentarzu do artykułu najciekawszą (naszym zdaniem) predykcję przewidzieliśmy roczną prenumeratę magazynu MARKETER+ Przewodnik po marketingu za darmo!

Na odpowiedzi czekamy do 5 stycznia 2012. Rozwiązanie konkursu nastąpi 9 stycznia.

Liczymy na Waszą inwencję!

Życzenia

Korzystając z okazji zbliżającego się Nowego roku, w imieniu całego zespołu Conversion składam najserdeczniejsze życzenia – wszelkiej pomyślności w 2012 roku, dużo zdrowia i sukcesów zarówno w życiu prywatnym jak i zawodowym (tutaj oczywiście jak największych wzrostów współczynnika konwersji).

Do usłyszenia w 2012 roku!!!

5 naj… postów na Conversion blog w 2011 roku is a post from: Conversion blog

Nie wiedzieliśmy czy analizowana przez nas strona jest zazwyczaj drugą, trzecią czy może dziesiątą stroną podczas wizyty użytkownika. Nie mogliśmy w łatwy sposób grupować podobnych stron, aby przeanalizować przepływ użytkowników pomiędzy stronami kategorii, stronami produktowymi a koszykiem.

Jeżeli już udało nam się takie dane zebrać i wyeksportować do excela w celu dalszej analizy, natrafialiśmy na problem z tworzeniem segmentów.

Od niedawna większość z tych problemów zniknęła dzięki wprowadzeniu do Google Analytics nowych raportów: przepływu użytkowników i procesu celu (osobiście wolę anglojęzyczne nazwy bo polskie tłumaczenia są ciężkostrawne ;))

Dlaczego to rozwiązanie jest lepsze niż wszystkie inne?

Szczerze powiedziawszy ścieżki użytkowników nie są żadną nowością w analityce internetowej. Już wcześniej były one dostępne w wielu narzędziach. Były jednak one przy tym bardzo mocno krytykowane. Dlaczego? Ponieważ nie było w nich praktycznie żadnego grupowania – z pierwszej strony na której był duży ruch, rozbijał się on na dziesiątki stron co uniemożliwiało efektywna analizę (zachęcam do przeczytania artykułu Avinasha, który głębiej opisuje ten problem).

Raporty przygotowane przez zespół Google Analytics są inne. Dzięki inteligentnemu grupowaniu podstron, możliwościom szybkiej segmentacji (wcześniej segmentacja ścieżek zajmowała dużo czasu) oraz genialnej wizualizacji zapewniają możliwość wnikliwej analizy. Niestety na ten moment raportów nie da się eksportować. Są one jednak przewidziane dla analityków, którzy mają wyciągać wnioski, a nie drukować raporty ;)

Przepływ użytkowników

Raport przepływu użytkowników (znajdziemy go w sekcji Odbiorcy) pokazuje nam ścieżki, które obierają na naszych stronach odwiedzający. Widzimy gdzie ta podróż się zaczęła (domyślnym wymiarem jest źródło wejścia), gdzie była kontynuowana i na jakich stronach została zakończona.

Kliknij na zdjęcie, aby powiększyć

Na powyższym raporcie widzimy strony początkowe na których użytkownicy rozpoczęli swoje odwiedziny. W tym przypadku widzimy jakie były źródła odwiedzin (wymiar).

Oczywiście w trakcie analizy możemy zmieniać domyślny wymiar w ramach którego dane są posegmentowane. Co więcej możemy wykorzystywać dodatkowe segmentacje oraz grupowanie stron.

Cały raport jest niezwykle interaktywny. Najeżdżając kursorem na wybraną grupę podstron dowiadujemy się o jej szczegółach:

Po kliknięciu, możemy wybrać jedną z opcji w celu dalszej analizy: wyróżnić ruch przez dany węzeł, badać ruch przez ten węzeł lub poznać szczegóły grupy.

Kliknij na zdjęcie, aby powiększyć

Jeżeli czujemy się zbytnio przytłoczeni danymi możemy zmniejszyć szczegółowość pokazywanych połączeń (lub wręcz przeciwnie ją zwiększyć jeśli potrzebujemy dokładniejszych informacji).

Kliknij na zdjęcie, aby powiększyć

Klikając na badanie ruchu przez dany węzeł będziemy mogli analizować ten wycinek: źródła ruchu użytkowników, kolejne odwiedzane strony. Całość możemy dowolnie segmentować:

Kliknij na zdjęcie, aby powiększyć

Jak możemy wykorzystać te dane?

Dzięki szybkiemu podglądowi źródeł ruchu i ich przełożenia na ścieżki użytkowników na naszej witrynie możemy w szybki sposób zwiększać jej efektywność.

Wprowadziliśmy niedawno nową stronę i chcemy sprawdzić czy jej treść realizuje cele użytkowników i jak dystrybuuje ruch? Proszę bardzo (klikając na trybik możemy zdefiniować grupę stron):

Bez tych raportów mielibyśmy znacznie większy problem z dotarciem do tego typu danych a także wniosków, które dzięki nim możemy uzyskać.

Proces celu

Proces celu to drugi z raportów, które w nowy sposób wizualizują przepływ użytkowników w naszym serwisie (dostępny w sekcji Konwersje > Cele). Raport ten w nowy, bardziej przystępny sposób prezentuje nam ścieżki, które definiujemy w trakcie konfiguracji celów (niestety na razie wspiera tylko strony – zdarzenia pojawią się wkrótce). Widzimy tam przepływ użytkowników pomiędzy poszczególnymi krokami:

Kliknij na zdjęcie, aby powiększyć

Niewątpliwym plusem w porównaniu do poprzedniej wersji ścieżek (wciąż dostępnych) jest łatwość segmentacji a dzięki temu porównania ścieżek w danym wymiarze:

Kliknij na zdjęcie, aby powiększyć

Dodatkowym plusem jest to, że możemy analizować każdy pojedynczy krok ścieżki wprzód i w tył (z której strony użytkownicy weszli do danego kroku i gdzie się udali).

Najważniejszym, z naszego punktu widzenia, udogodnieniem jest to, że dane w raporcie dostępne są wstecz. Co to oznacza? Oznacza to ni mniej ni więcej, że odrazu po skonfigurowaniu ścieżki, widzimy przepływ użytkowników w jej obrębie. Nie musimy już czekać na zebranie się danych tak jak w klasycznej wizualizacji ścieżek (świetne lekarstwo dla zapominalskich ;))

Jak możemy wykorzystać te dane?

Czy kiedykolwiek zdarzyło się Wam, że ścieżka do złożenia zamówienia nie działała pod jedną przeglądarką? Teraz w łatwy sposób dostrzeżecie ten błąd dzięki raportowi Proces celu:

Kliknij na zdjęcie, aby powiększyć

Zastanawiacie się czy istnieją kroki w ścieżce do których użytkownicy często powracają (co może świadczyć o błędzie w procesie)? Teraz w łatwy sposób to dostrzeżemy:

Kliknij na zdjęcie, aby powiększyć

Podsumowując

Zespół Google Analytics wprowadza ostatnimi czasy zmiany w szalonym tempie. Jednak widać, że nowości te nie są przedwczesnymi, niedopracowanymi premierami, lecz naprawdę dobrze dopracowanymi, przemyślanymi rozwiązaniami.

Na koniec zostawiłem kilka braków:

1. nie możemy zapisać grupowania stron, które zrobiliśmy – zawsze trzeba robić to od nowa (jeżeli chcemy uzyskać stałe raporty, najlepiej wykorzystać API)
2. nie można zapisać stworzonego w trakcie analizy wymiaru (ponownie, może nam pomóc API)
3. dane są niestety próbkowane (lekarstwem może być zaznaczanie krótszego okresu czasu lub zgadnijcie… API :))
4. nie możemy eksportować danych, które widzimy (tak jak wspominałem, jako analitycy jesteśmy tutaj od analizy i przedstawiania wniosków, a nie drukowania raportów, więc w sumie nie wiem czy nie zaliczyć tego in plus ;))
5. w raporcie Procesu celu analizowaną metryką są odwiedziny – szkoda, że nie można jej zmienić na unikalnych użytkowników (czasami w sklepach zakupy przebiegają dłużej niż jedną sesję, a wtedy UU jest lepszą metryką).

Jednak wciąż, pomimo wyżej wymienionych ograniczeń, nowe raporty przepływu użytkowników i procesu celu są genialne. Jestem pewien, że pozwolą Wam przeprowadzać naprawdę mądre analizy w wyniku których na pewno uda się Wam wyciągnąć tony wniosków. Mieliście już okazję z nich korzystać? Jak oceniacie je do tej pory?

Przepływ użytkowników i proces celu w Google Analytics is a post from: Conversion blog

Nie trzeba chyba tłumaczyć, że wiadomość szczególnie zabolała specjalistów zajmujących się optymalizacją stron internetowych pod wyszukiwarki – zaczęto nawet przepowiadać kres SEO… W poniższym artykule przedstawię, jakie po pewnym czasie my widzimy zmiany w ruchu naszych serwisów oraz co można zrobić w obliczu takiej sytuacji.

Motyw wprowadzenia szyfrowania

Zanim przejdziemy do przyjrzenia się skutkom omawianej zmiany kilka na temat motywacji Googla do wprowadzenia takiego rozwiązania, które na pierwszy rzut oka jest zupełnie bezsensownym (przynajmniej jak dla mnie). Jednak gigant z Mountain View zasłania się bezpieczeństwem użytkowników.

Bezpieczeństwo w tym wypadku to jest „słowo-klucz”:) Google chce, aby informacje na temat użytkowników zalogowanych do usługi były jeszcze bardziej chronione (kodowane) – w końcu w historii nie raz zarzucono Gigantowi zbyt słabą politykę ochrony danych osobowych. Dzieje się to poprzez zastosowania certyfikatu SSL, co dla zalogowanych użytkowników skutkuje przeniesieniem na protokół https (możecie się sami przekonać będąc zalogowanym do konta Google).

Warto zaznaczyć, że przekierowanie NIE następuje jeszcze dla www.google.pl.

Skutki widoczne gołym okiem

Pierwszym i najbardziej widocznym skutkiem wprowadzonych zmian jest pojawienie się w naszych raportach słowa kluczowego not provided. Jeżeli zajrzymy do naszych raportów źródeł ruchu, a szczegółowo do: Źródła odwiedzin > Źródła > Wyszukiwanie > Bezpłatne i w polu filtra wybierzemy not provided, to zauważymy, że zmiana rzeczywiście miała miejsce 19 października.

Kliknij na screen, aby powiększyć

Jak wygląda to z technicznego punktu widzenia? Będąc zalogowanym do produktu Google (nie musi to być Gmail – równie dobrze może to być nasza firmowa poczta, jeżeli korzystamy z Google Apps), po skorzystaniu z wyszukiwarki Google i przejściu na stronę docelową nie mamy informacji o słowie kluczowym, którego użyliśmy. Jest to widoczne (a raczej niewidoczne) w naszym ciasteczku __utmz. Załóżmy, że wpisałem „analityka internetowa” w wyszukiwarce i przeszedłem na stronę www.conversion.pl. Moje ciasteczko zawiera następującą informację.

Jak widać, jest to słowo not provided – to samo, które pojawia się w naszych raportach.

Dla sprawdzenia Googla zrobiłem test i po wylogowaniu się z poczty wykonałem analogiczne czynności. Tym razem wchodząc na witrynę, w ciasteczku __utmz zobaczyłem słowo kluczowe, które wcześniej użyłem w wyszukiwarce.

Oczywiście w przypadaku Google AdWords i ruchu CPC powyższa sytuacja nie ma miejsca – ciekawe dlaczego – jak myślicie?:) W związku z tym, możemymy używać naszych kampanii linków sponsorowanych niejako do testowania słów kluczowych.

Wpływ na ruch organiczny

W różnych źródłach można znaleźć różne dane na temat tego, w jakim stopniu odczujemy ruch z fraz kluczowych not provided w naszych kontach. Oto kilka screenów z raportów słów kluczowych, a na sam koniec tabela podsumowująca wybrane statystyki odwiedzin z zaszyfrowanymi słowami kluczowymi.

Jak widać, ruch przychodzący za pośrednictwem słowa not provided za każdym razem przyjmuje trend wzrostowy. Oczywiście ma on różny wygląd oraz poziom – uzależniony od udziału ruchu organicznego w całości ruchu w serwisie. Poniższa tabela przedstawia udział słowa kluczowego not provided w całości ruchu pochodzącego z wyszukiwania organicznego.

Jak widać, w żadnym z powyższych serwisów udział słów kluczowych not provided nie przekracza 2% całego ruchu organicznego. Jest to zjawisko pozytywne, lecz pamiętajmy, że słowa kluczowe „ucinane” są tylko dla Google.com. Nie wiemy, co stanie się z ruchem, jeżeli również polska domena wyszukiwarka zostanie przekierowana na bezpieczne połączenie.

Patrząc na witryny zagraniczne np. Avinash Kaushik na swoim blogu odnotował aż 18% udział słowa kluczowego w całości ruchu pochodzącego z wyników organicznych Google (klikając na link zostaniesz przeniesiony do jego artykułu na ten temat). Weźmy jednak pod uwagę, że na zachodzie (zwłaszcza w USA) użytkownicy dużo częściej korzystają z produktów Google, a więc są do nich zalogowaniu surfując w sieci.

Jaki to będzie miało wpływ w analizach?

Trudno powiedzieć, jak to będzie wyglądało w długim okresie. Obecnie, przy takich udziałach słowa kluczowego not provided nie powinno mieć to wielkiego wpływu na analizy, chociaż wiadomo – na pewno uszczknie nam część informacji o naszym ruchu.

W momencie przekierowania Google.pl na https może nam to konkretnie namieszać – zwłaszcza biorąc pod uwagę udział wyszukiwarki w naszym rynku. Biorąc dodatkowo wszechobecność Googla pod różnymi postaciami (Gmail, Google Apps, Google+), to może się okazać, że proporcja not provided do całości ruchu organicznego może ulec zmianie. Jest to jednak bardzo czarna wizja… bo jak podałem wcześniej przykład bloga Avinasha Kaushika, to przy dużej adopcji produktów Google ruch za pośrednictwem not provided sięga 20%, to podejrzewam, że przy przekierowaniu polskiego Google na https nie osiągniemy takich poziomów:)

Co zrobić?

Z technicznego punktu widzenia tak naprawdę nie możemy nic z tym zrobić – pozostaje nam pogodzić się z tą sytuacją….

W związku z tym, pozostaje nam kilka rozwiązań:

• stosować zaawansowany segment niestandardowy, który będzie wykluczał słowo kluczowe not provided z ruchu organicznego,

Kliknij na screen, aby powiększyć

• stworzyć alert niestandardowy, który będzie informował nas np. o wzroście odwiedzin za pośrednictwem słowa kluczowego not provided,

Kliknij na screen, aby powiększyć

• stworzyć raport niestandardowy, który będzie pomagał nam śledzić ruch TYLKO ze słowa kluczowego not provided,

Kliknij na screen, aby powiększyć

• bardziej szczegółowo analizować raporty stron docelowych wobec słów kluczowych not provided i próbować na ich podstawie domyśleć się słowa kluczowego, którego użyli użytkownicy, aby trafić na te strony,
• nie zapominać o Google Webmaster Tools, ponieważ w Narzędziach dla webmasterów ciągle mamy podane wszystkie słowa kluczowe, które ściągają do nas użytkowników,
• używać raportów kampanii linków sponsorowanych, aby patrzeć, które słowa kluczowe ściągają na naszą stronę najwięcej użytkowników i czy nasze strony docelowe są odpowiednio do nich dopasowane,

lub jak proponuje SEOmoz pisać o tym na naszych blogach, fanpageach, Twitterach itp. wyrażając swoje niezadowolenie z tego faktu, a być może Wielki Brat nas posłucha i zmienią swoje podejście:)

Jestem ciekawy, jak u Was wygląda udział not provided w całości organicznego? Czy można już zauważyć jakieś trendy z tym związane?

Not provided w raportach słów kluczowych Google Analytics is a post from: Conversion blog

Często spotykamy się z tego typu pytaniami w trakcie rozpoczynania pracy z częścią naszym Klientów. Niestety Polska to nie USA i liczba użytkowników odwiedzających serwisy w niektórych niszach jest nie tak duża.

Ten artykuł stanowi część drugą Buyers’ Guide by Conversion. Tutaj zapoznanie się z poprzednią częścią: Jaki model współpracy wybrać w ramach projektu optymalizacji konwersji? – warto to zrobić przed lekturą poniższego artykułu.

Magiczna granica wielkości ruchu

zdjęcie od FHgitarre

Zaczęliście się pewnie zastanawiać czy istnieje coś takiego jak magiczna granica ruchu, który pozwoli na testy?

Niestety muszę Was rozczarować, ponieważ takiej granicy nie ma. Dlaczego? Ponieważ możliwość testowania zależy nie tylko od wielkości ruchu, ale też od jego specyfiki, czyli obecnego współczynnika konwersji. Zależy również od tego jaki wzrost współczynnika konwersji oczekujemy. Dlatego, mówiąc o granicy wielkości ruchu, myślimy bardziej o jego parametrach (dowiedz się na czym dokładnie polega statystyka w testach A/B i jakie elementy ruchy brane są pod uwagę).

Sklep internetowy może mieć współczynnik konwersji poniżej 1%, a strona docelowa kampanii ubezpieczyciela ponad 8%. Jeżeli w obu przypadkach będziemy planowali wzrosty o 30%, granice liczby odwiedzin będą się znacząco różniły. Do ich wyliczenia możemy wykorzystać kalkulator długości trwania testu.

Jeżeli miałbym polecić niepisaną zasadę, która rozdziela serwisy na których uda Wam się przeprowadzić testy w rozsądnym okresie czasu (10-14 dni) to powiedziałbym, że potrzebujecie ok. 100 konwersji na każdą testowaną kombinację na tydzień.

Czyli, jeżeli planujecie test A/B w którym będzie tylko wersja oryginalna i jedna wersja testowa, to będziecie potrzebowali do tego około 200 konwersji w dwa tygodnie. Można powiedzieć, że to 200 konwersji w 2 tygodnie jest absolutnym minimum do przeprowadzania testów (bo nie możemy testować mniejszej liczby różnych rzeczy niż 2 – sprawdźcie o czym jeszcze trzeba pamiętać przed rozpoczęciem testów A/B i wielowymiarowych.

Co jeśli takiego ruchu nie posiadamy?

Na pewno nie wszyscy z Was opiekują się stronami, które spełniają warunek 200 konwersji w dwa tygodnie. W takim przypadku przeprowadzanie testów jest zazwyczaj niemożliwe.

Mateusz pisał, że istnieją dwa modele rozliczania się za współprace z firmą w zakresie projektu optymalizacji konwersji:

• rozliczanie za efekt końcowy projektu – gdy wynagrodzenie firmy doradczej uzależnione jest od ostatecznego wyniku potwierdzonego testami A/B lub wielowymiarowymi (a nie porównaniem dwóch okresów!)
• rozliczanie za wkład pracy – gdy wcześniej ustalone wynagrodzenie jest wypłacane po zakończeniu projektu za godziwie wykonaną pracę

Jeżeli testy w obrębie witryny można przeprowadzać, to wtedy pierwsza z wymienionych wyżej opcji jest znacznie lepsza. Dlaczego? Ponieważ daje gwarancje uzyskanych wyników. Niestety, nigdy gdy nie jest tak, że 100% rekomendacji jest trafionych. Właśnie dzięki testowaniu, rozliczenie za efekt pozwala zminimalizować ryzyko „wdepnięcia” w te nietrafione rekomendacje.

Z drugiej strony, jeżeli testów nie możemy przeprowadzać, możemy:

1. postarać się zwiększyć ruch na czas trwania testów – ważne jest, aby pozyskać ruch analogiczny do tego, który na co dzień odwiedza nasz serwis
2. rozliczyć się za wkład pracy

W przypadku braku możliwości przeprowadzania testów, często pojawia się trzecie rozwiązanie. Jest to pokusa, aby rozliczyć się za „efekt końcowy” projektu optymalizacji konwersji. Albo agencje, albo klienci proponują, aby sukces był liczony w inny sposób – za pomocą porównania dwóch okresów czasu – przed wdrożeniem poprawek i po ich wdrożeniu.

W artykule o modelu współpracy przy projektach optymalizacji konwersji przeczytacie, dlaczego to podejście jest niepoprawne, a jego wyniki są wypaczane przez czynniki zewnętrzne.

Dlaczego więc, pojawia się czasem pokusa wśród firm, aby podsunąć potencjalnemu Klientowi model współpracy w modelu opartym o sukces gdy testów przeprowadzać się nie da?

Zazwyczaj model ten daje wyższe wynagrodzenie za przeprowadzone prace. Jeżeli dzięki pracy udowodniony jest wzrost sprzedaży o kilka tysięcy złotych to łatwiej jest uzasadnić Klientowi wysoką zapłatę za projekt.

Jednak tak jak pisaliśmy, przy porównaniu dwóch okresów czasu istnieje bardzo wiele innych czynników, które mogły wpłynąć na wzrost współczynnika konwersji. Jeżeli poprawa strony miała na to mały wpływ, to będąc klientem możemy płacić agencji za sukces, na który miała znikomy wpływ.

Dość powiedzieć, że pewnego razu w trakcie spotkania z Klientem dowiedzieliśmy się o agencji, która gwarantowała podniesienie współczynnika konwersji w jego sklepie internetowym bez przeprowadzania testów. Sposób liczenia wzrostu z porównaniem dwóch okresów był niepoprawny, ale najzabawniejszy był fakt, że agencja planowała wdrożyć zmiany w połowie listopada. Jest to okres kiedy w branży w której działał ten sklep internetowy współczynnik konwersji z okazji przedświątecznej gorączki rokrocznie wzrastał o kilkadziesiąt procent. Prawda, że był to bezpieczny ruch ze strony firmy doradczej? :)

Kliknij na zdjęcie, aby powiększyć

Jaki jest przebieg projektu w obu modelach: rozliczenia za efekt oraz rozliczenia za włożoną pracę

W obu modelach, działania, które są podejmowane są niemal identyczne. W przypadku rozliczenia za efekt kroki są następujące:

1. zebranie danych i wnikliwa analiza (analiza danych ilościowych – Google Analytics, jakościowych – ankiety, testy użyteczności, analiza ekspercka)
2. zaplanowanie usprawnień użyteczności i przekazu marketingowego (ustalenie priorytetów i wybór niektórych z nich do testów)
3. przygotowanie szkiców proponowanych zmian
4. przygotowanie projektów graficznych (po stronie Klienta lub firmy doradczej)
5. wybór narzędzia do testów, ich zaprogramowanie i przeprowadzenie
6. analiza wyników testu i powrót do kroku pierwszego

Kroki przy optymalizacji konwersji rozliczanej za wkład pracy różnią się niewiele. Dokładnie różnią się dwoma elementami:

• w kroku drugim w przypadku rozliczenia za czas projektowy nie wybiera się jedynie kilku zmian do wdrożenia, lecz wdraża się wszystkie, które wynikły w trakcie badań z kroku pierwszego
• z racji braku przeprowadzania testów krok piąty i szósty nie są realizowane

Oznacza to, że w projektach rozliczanych za przepracowany czas, efektem końcowym są szkice zmian lub gotowy, poprawiony projekt graficzny serwisu. Są w nim wdrożone wszystkie rekomendacje, które poprawiają problemy użytkowników wykryte na podstawie badań i analiz przeprowadzonych w kroku pierwszym.

Niemal na pewno ich wdrożenie przyniesie wzrost współczynnika konwersji. Niewątpliwym plusem jest szybkość realizacji takiego projektu.

Niestety, nikt, nigdy nie może być w 100% pewny czy zaproponowane na podstawie takiego badania zmiany rzeczywiście podniosą współczynnik konwersji (ani tym bardziej o ile). Rodzi to niepewność, która może być zlikwidowana tylko za pomocą testów a/b albo wielowymiarowych. Dzięki nim wiemy czy i o ile wzrósł współczynnik konwersji w wyniku zmian zaproponowanych w efekcie pracy.

Podsumowując: co nam pozostaje?

1. Jeżeli mamy wystarczająco duży ruch – 200 konwersji w dwa tygodnie – przy optymalizacji konwersji powinniśmy rozliczać się z agencjami w modelu opartymi o sukces potwierdzony poprzez testy A/B lub wielowymiarowe. Tutaj znajdziecie więcej wskazówek na ten temat
2. Jeżeli nie mamy wystarczająco dużego ruchu – rozliczajmy się w wynagrodzeniu za wykonaną pracę, której efektem najlepiej, żeby były rekomendacje w postaci szkiców i tekstów na Twojej witrynie, a nie suchy raport wypisujący same wnioski z badania (lub zgrubnie wskazujący błędy)

Pamiętajmy przy tym: optymalizacja konwersji to nie (tylko) poprawa użyteczności!

Jaki model współpracy wybrać: co jeśli nie możemy przeprowadzać testów? is a post from: Conversion blog

Jeżeli przynajmniej na jedno z tych pytań odpowiedziałeś twierdząco, to powinieneś mieć armię wtyczek do Twoich przeglądarek, które ułatwiają Ci codzienną pracę.

Poniżej znajdziesz wybrane rozszerzenia do przeglądarek Firefox oraz Chrome, które pomagają mi w codziennej pracy z Google Analytics. Krótko opiszę, co jest dzięki nim możliwe i jak mogą pomóc Ci w śledzeniu Twoich użytkowników. Mam nadzieję, że będzie to dla Was również inspiracja do dalszych poszukiwań usprawnień.

Jestem przekonany, że jest więcej rozszerzeń, które pomogą każdemu kto zajmuje się analityką internetową, dlatego będę wdzięczny jeżeli w komentarzu zostawicie swoje uwagi na ten temat:) Ja sam podaję tutaj wtyczki, które działają tylko w nowej wersji Google Analytics, ponieważ zgodnie z zapowiedziami ma ona zostać na stałe włączona od stycznia, bez możliwości przejścia do starej wersji.

Zazwyczaj podane wtyczki dostępne są w internecie dla obu przeglądarek – ja jednak prezentuję po jednej dla każdej, zaznaczając czasami odpowiednika.

Analytics Helper

• Przeglądarka: Google Chrome (ściągnij wtyczkę)
• Odpowiednik dla Firefoxa: GA?
• Wykorzystanie: Wtyczka wykrywa czy na danej stronie zainstalowany jest kod śledzący Google Analytics. Wtyczka powie nam również, jaki jest indywidualny numer UA oraz która wersja kodu śledzącego jest zainstalowana na stronie. Dowiemy się z niej również czy kod śledzący jest osadzony we właściwym miejscu.

GA copy and paste

• Przeglądarka: Google Chrome (ściągnij wtyczkę)
• Odpowiednik dla Firefoxa: Goal copy (działa w starej wersji GA)
• Wykorzystanie: Dzięki wtyczce możemy kopiować filtry pomiędzy kontami i cele pomiędzy profilami oraz kontami. Wtyczka bardzo ułatwia pracę, ponieważ każdy nowo utworzony profil, to profil czysty – wszystkie ustawienia konfiguracyjne musimy wprowadzić „z palca”.

Straight to Google Analytics

• Przeglądarka: Google Chrome (ściągnij wtyczkę)
• Wykorzystanie: Wtyczka po prostu przenosi nas bezpośrednio do strony logowania po wpisaniu adresu www.google.com/analytics. Standardowo w pierwszej kolejności musimy kliknąć na duży niebieski przycisk „Zaloguj się do analytics” – moim zdaniem niepotrzebnie, jeżeli posiadam już konto:P

RegEx Checker

• Przeglądarka: Google Chrome (ściągnij wtyczkę)
• Wykorzystanie: Dzięki wtyczce szybko możemy zwalidować nasze wyrażenia regularne, które np. chcemy użyć w filtrach niestandardowych lub celach z dopasowaniem do wyrażenia regularnego.

Edit this cookie

• Przeglądarka: Google Chrome (ściągnij wtyczkę)
• Wykorzystanie: Wtyczka umożliwia podglądanie ciasteczek, a jak dobrze wiemy, to one właśnie niosą informacje, które następnie są dostępne w naszych interfejsach. Jeżeli skonfigurowaliśmy nasz kod śleądzy na bardziej zaawansowanym poziomie (np. instalując zmienne niestandardowe), to dzięki tej wtyczce szybko przekonamy się czy wszystko działa poprawnie.

HttpFox

• Przeglądarka: Firefox (ściągnij wtyczkę)
• Odpowiednik dla Chrome’a: Google Analytics Debugger – w rzeczywistości nie jest do właściwy odpowiednik tej wtyczki, ale używam go w tym samym celu:)
• Wykorzystanie:Wtyczka pokaże nam, jakie informacje wysyłane są do serwera Google Analytics ze strony, na której jesteśmy. Nagranie wysyłanych rządań pozwoli nam np. ocenić poprawność implementacji wirtualnych odsłon nie czekając na spłynięcie danych do naszego interfejsu.

Kliknij na screen, aby powiększyć

Jak widać Google Chrome opanował moje zestawienie. Nie znaczy to jednak, że daje ona więcej wtyczek ułatwiających korzystanie z Google Analytics. Fakt ten wynika raczej z tego, że większość wtyczek dla Firefoxa nie uwzględnia jeszcze nowej wersji Google Analytics.

Teraz Wasza kolej! Jakich wtyczek używacie we współpracy z Google Analytics i w czym one Wam pomagają. Zachęcam do dzielenia się doświadczeniami!

6 wtyczek, które turbodoładują Google Analytics is a post from: Conversion blog

Google Analytics dostarcza nam masę danych ilościowych na temat interakcji użytkowników z naszymi serwisami. Spotykamy się z problemem, że tych danych jest za dużo i nie wiemy co z nimi robić.

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?

Jak połączyć Google Analytics z systemami CRM? is a post from: Conversion blog

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

Wykluczenie wybranych słów z ruchu organicznego

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

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

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

_addIgnoredOrganic na witrynie Conversion.pl

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

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

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

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

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

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

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

Weryfikacja _addIgnoredOrganic

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

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

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

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

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

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

Podsumowanie

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

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

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

Czy funkcja _addIgnoredOrganic działa? is a post from: Conversion blog