Co znajdziesz w tym artykule?
Jak analizować kampanie displayowe?
Struktura DoubleClick Manager
Czy użytkownik na pewno widział reklamę?
Czy reklama jest w dobrym miejscu?
Nowe standardy i praktyki poprawy widoczności reklam (viewability) w 2026
Podsumowanie

Jak analizować kampanie displayowe?

Poprawne zbieranie danych jest podstawą skutecznych działań w zakresie analityki internetowej. Odpowiednie otagowanie kampanii displayowych pokaże nam, którzy użytkownicy kliknęli w baner przed wejściem na naszą stronę.

Reklama display, oprócz bezpośredniego generowania ruchu, pełni jednak również inną bardzo ważną rolę. Reklamy graficzne budują wizerunek i świadomość marki lub produktu. Jak pokazują przeprowadzane przez nas analizy ścieżek wielokanałowych medium display jest bardzo często pierwszym krokiem prowadzącym do konwersji.

Wszyscy wiemy jak analizować kampanie i ich efektywność w Google Analytics. Wiemy, które wizyty prowadzą do konwersji i które źródła ruchu oraz kampanie przynoszą nam największe efekty. Jeżeli jednak intensywnie korzystamy z reklamy displayowej umyka nam bardzo duża część informacji, ponieważ nie optymalizujemy tego jak wyświetlają się nasze reklamy.

Dlatego też analizując kampanie displayowe powinniśmy również mieć możliwość odpowiedzi na pytania:

Czy użytkownik faktycznie zobaczył moja reklamę?

Czy może baner wyświetlił się w dolnej części strony do której użytkownik nie zescrollował, jak np. tutaj, na samym dole strony Onet.pl

Czy moje reklamy wyświetlają się w odpowiednim miejscu?

Chyba, żaden producent samochodów nie chciałby, żeby jego reklama wyświetlała się na stronie Fatal Car Accidents.

Rozwiązanie

W tym poście omówię dwie z funkcjonalności narzędzia DoubleClick Campaign Manager (DCM), wchodzącego w skład platformy DoubleClick Digital Marketing (DDM).

Dzięki zastosowaniu narzędzia będziemy mogli sprawdzić czy użytkownik faktycznie zobaczył naszą reklamę (funkcjonalność Active View) oraz czy reklamy wyświetlają się tam gdzie powinny (funkcjonalność Content Verification).

W skład platformy DoubleClick Digital Marketing, wchodzą również inne narzędzia umożliwiające zarządzaniem kampaniami reklamowymi jak np. DoubleClick Bid Manager (DBM), DoubleClick Search (DS.), DoubleClick AdExchange czy DoubleClick Rich Media.

W tym poście omówię dwie funkcjonalności DoubleClick Manager, które pozwalają zweryfikować efektywność, poszczególnych kampanii reklamowych.

Struktura DoubleClick Manager

DoubleClick Manager pozwala na zarządzanie kampaniami displayowymi w Internecie. W ramach Konta tworzymy Reklamodawcę. Dla Reklamodawcy tworzymy Kampanię, w ramach której tworzymy Reklamy oraz Kreacje. Część platformy DDM Raportowanie pozwala przeglądać dane o reklamach traffickowych w DoubleClick Manager.

W części Raportowanie znajduje się karta Weryfikacja, dzięki której możemy przeanalizować poprawność emitowanych kampanii reklamowych. Dwie funkcjonalności, które pomogą nam odpowiedzieć na pytania zaprezentowane we wstępie to Active View oraz Content.

Czy użytkownik na pewno widział reklamę?

Dzięki funkcjonalności Active View, sprawdzimy jaka część reklam display (raportowanych jako wyświetlone) była faktycznie widziana przez użytkowników.

Narzędzie uzna reklamę jako widoczną jeśli co najmniej 50% reklamy było widoczne w części strony widzianej przez użytkownika, przez co najmniej 1 sekundę.

Dzięki temu możemy zidentyfikować i wyeliminować reklamy umieszczane w miejscach, do których większość użytkowników nie dociera i tym samym nie widzi naszych kreacji.

Jeśli rozliczamy się z wydawcami w modelu CPM (koszt za tysiąc wyświetleń), płacąc za każde wyświetlenie to warto, żeby użytkownicy faktycznie mogli zobaczyć umieszczone przez nas reklamy, dzięki czemu zwiększymy efektywność i skuteczności kampanii display.

Czy reklama jest w dobrym miejscu?

Za pomocą funkcjonalności Content Verification, DoubleClick Manager monitoruje zawartość strony internetowej, na której reklama została wyemitowana. Dzięki temu możemy upewnić się, że reklamy nie są wyświetlane na stronach z nieodpowiednimi treściami, jak hazard, przemoc czy treści dla dorosłych.

Istnieją standardowe klasyfikatory (już skonfigurowane w ramach narzędzia), za pomocą których można weryfikować strony na których pojawiły się nasze reklamy, oraz niestandardowe, które możemy sami skonfigurować i dostosować je do swoich potrzeb. Standardowe klasyfikatory oznaczają m.in. następujące tematy: pornografia, wulgaryzmy, alkohol, tytoń, narkotyki, broń, hazard, przemoc, polityka, religia, wypadki transportowe, wymiana plików, tragedia czy hacking.

Klasyfikatory niestandardowe są przydatne, jeśli chcemy wyszczególnić inną kategorię, przy której nie chcemy emitować naszych reklam. Przykładowo producent samochodów może stworzyć klasyfikator „awarie w samochodach”, aby uniknąć pokazywania reklam samochodów przy tego typu artykułach, czy też klasyfikator, który monitoruje, czy reklamy są wyświetlane na stronach, w których wspomniano konkurenta lub prezentująca daną markę w negatywnym świetle.

Można utworzyć dowolną liczbę niestandardowych klasyfikatorów, a następnie zastosować je do całego konta lub do poszczególnych kampanii.

Dzięki możliwości weryfikacji unikniemy sytuacji, że nasza reklama będzie się wyświetlała w nieodpowiednim miejscu jak w przykładzie (trochę przerysowanym ) poniżej:

Nowe standardy i praktyki poprawy widoczności reklam (viewability) w 2026

W 2026 roku viewability nadal pozostaje kluczowym wskaźnikiem dla efektywności kampanii display i video, ale samo spełnienie minimum (50% pikseli widocznych przez 1 sekundę) to często za mało, by realnie ocenić wpływ reklamy na odbiorcę. Średnia widoczność reklam display wynosi ok. 65 %, a wyższe wskaźniki silnie korelują z lepszym rozpoznawaniem marki i skuteczniejszymi konwersjami, szczególnie w kampaniach programatycznych. Dobre praktyki obejmują strategiczne umieszczanie kreacji, optymalizację pod kątem urządzeń mobilnych oraz współpracę z wydawcami, którzy osiągają wyższe standardy viewability – to nie tylko spełnia branżowe normy, ale realnie podnosi efektywność kampanii.

Metody poprawy viewability i zaangażowania użytkownika w kampaniach display

Aby poprawić wskaźnik viewability i zaangażowanie użytkowników, reklamodawcy coraz częściej sięgają po technologie i formaty, które wydłużają czas „in view” oraz aktywizują uwagę. Do skutecznych rozwiązań należą reklamy interaktywne, większe formaty natywne i rewarded ads w aplikacjach, które użytkownicy oglądają dobrowolnie w zamian za bonusy, co przekłada się na wyższe zaangażowanie i viewability.

Równolegle narzędzia analityczne mierzące „time in view” oraz głębokość interakcji (engagement depth) pomagają zrozumieć nie tylko czy reklama była widoczna, ale jak długo przyciągała uwagę odbiorców – a to kluczowe w optymalizacji kampanii pod kątem realnych rezultatów.

Podsumowanie

Jak już ponad 100 lat temu zauważyli pionierzy reklamy Jonhn Wanamaker oraz Lord Leverhulme: „Połowa środków jakie wydaje się na reklamę zostaje zmarnowana. Problem w tym, że nigdy nie wiadomo, która to połowa”.

Dzięki funkcjonalnościom DoubleClick Campaign Managera można przynajmniej częściowo zniwelować te straty, szczegółowo badając czy użytkownik widział reklamę za którą płacimy oraz czy wyświetlają się tam gdzie powinny. Przy wydatkach na reklamę display w wysokości ponad 1 mld zł rocznie, eliminacja naszych banerów z miejsc gdzie większość użytkowników nie będzie miała okazji ich zobaczyć oraz ze stron, treści których mogą przynieść naszej marce więcej szkód niż pożytku, przyniesie znaczące oszczędności.

Jest to pierwszy artykuł z serii w którym przedstawiłem dwie z wielu funkcjonalności DoubleClick Manager. Wkrótce pojawią się kolejne, które pokażą jak analitycy mogą wykorzystać to narzędzie do analizy kampanii.

The post DoubleClick 101: Czy użytkownicy widzieli reklamę, za którą płacisz? first appeared on Conversion.

O ile jednak zasadność stosowania technik segmentacji podczas przeglądania raportów Google Analytics jest powszechnie uznawana, o tyle ustabilizowane podejście do segmentacji (które oczywiście powinno być dopasowane do potrzeb konkretniej firmy) jest stosunkowo rzadko spotykane.

Co znajdziesz w tym artykule?
Co to znaczy podejście do segmentacji?
W jaki sposób wypracować podejście do segmentacji w 4 krokach?
Segmentacja klientów w erze sztucznej inteligencji – jak AI zmienia podejście do analizy danych?

Co to znaczy podejście do segmentacji?

Spójrzmy chociażby na liczbę wymiarów i metryk, dostępnych w ramach Google Analytics – które z nich powinny stanowić podstawowe kryteria dzielenia ruchu? A zastosowanie segmentacji? Najczęściej spotykamy punktowe wykorzystanie segmentacji – przy okazji patrzenia na zgromadzone dane, wykorzystujemy mechanizmy drążenia w dół i segmenty zaawansowane w celu lepszego zgłębienia tematu i wyciągnięcia wniosków. Segmentacja, która jest stosowana w taki sposób zazwyczaj nie ma charakteru uniwersalnego i nie decyduje o ogóle działań online – znajduje się na poziomie operacji i stanowi jedno z wielu narzędzi analityka.

Tymczasem, segmentacja powinna stanowić oś pracy z danymi.

Ten problem można spokojnie określić jako typowy dla branży online. Analityka internetowa zaczyna się i kończy na instalacji narzędzi i rozpoczęciu gromadzenia danych.

Guru analityki internetowej, Avinash Kaushik, przy każdej możliwej okazji powtarza, że 90% sukcesu w pracy z danymi to procesy i ludzie, a tylko 10% to narzędzia. Brak ustabilizowanego podejścia do segmentacji to brak jednego z najważniejszych procesów.
Źródło: http://www.speakers.ca/

W jaki sposób wypracować podejście do segmentacji w 4 krokach?

Krok 1.

W pierwszej kolejności, należy zebrać w jednym miejscu wszystkie osoby, które będą wykorzystywały docelową segmentację i zorganizować burzę mózgów, która ma na celu zdefiniowanie kryteriów segmentacji. Firmy posiadają zazwyczaj segmentację offline, którą wykorzystują do definiowania grupy docelowej lub segregowania klientów – na pewno warto potraktować ją jako punkt wyjścia. W dalszej kolejności, można posiłkować się wiedzą na temat branży lub uznanymi praktykami w obszarze online (np. listą i grupowaniem wymiarów w Google Analytics).

Krok 2.

Posiadając listę kryteriów segmentacji, należy przeprowadzić operacjonalizację oraz klasyfikację poszczególnych warunków.

Operacjonalizacja to podanie dla danego kryterium technicznej definicji. W odniesieniu do Google Analytics, operacjonalizacja sprowadza się do przypisania każdemu kryterium z listy wymiarów lub metryk oraz – ewentualnie – zdefiniowaniu wartości progowych. Przykładowo, jeżeli podczas burzy mózgów zapisane zostało kryterium „poziom zaangażowania użytkownika”, to w trakcie operacjonalizacji dobrana zostanie metryka średni czas trwania sesji i ustalone zostaną wartości progowe (np. 0s, 1-10s, 11s+). Operacjonalizacja powinna wskazać, które kryteria segmentacji będą mogły zostać obsłużone z wykorzystaniem aktualnej instalacji Google Analytics, a które będę wymagały rozbudowy śledzenia.

Aby wyjaśnić pojęcie klasyfikacji, należy wrócić do sposobu gromadzenia danych przez Google Analytics i inne podobne narzędzia. Mianowicie, te aplikacje rejestrują interakcje (np. odsłona strony) oraz odwiedziny (czyli ciągi interakcji) plus potrafią grupować odwiedziny (dzięki technologii ciasteczek) i spinać je pod pojęciem użytkownika. Każdy wymiar i każda metryka, dostępne w ramach Google Analytics, jest przypisana albo do konkretnej interakcji (np. średni czas na stronie) albo do całej odwiedziny (np. średni czas trwania sesji) albo do użytkownika (np. przeglądarka). Poszczególnych poziomów wymiarów i metryk nie należy łączyć – technicznie to jest wykonalne, ale w praktyce prowadzi do niewłaściwych wniosków.

Patrząc na listę kryteriów segmentacji, część kryteriów będzie odnosiła się do pojedynczej odwiedziny (np. wspomniany „poziom zaangażowania użytkownika”, który może być różny w ramach kolejnych odwiedzin tego samego użytkownika), a część – do grupy odwiedzin, tj. do użytkownika (np. „przeglądarka użytkownika”, która pozostaje stała w ramach kolejnych odwiedzin tego samego użytkownika). Klasyfikacja to przypisanie danego kryterium do jednej z tych grup. Bardzo rzadko (o ile w ogóle) wynotowane kryteria będą odnosiły się do pojedynczej interakcji.

Krok 3.

Zoperacjonalizowana i sklasyfikowana lista kryteriów segmentacji powinna zostać zweryfikowana – najpierw jakościowo (które kryteria rzeczywiście mają sens i powinny zostać wykorzystane?) a następnie ilościowo, z wykorzystaniem prawdziwych danych, w odpowiednio długim (1 rok lub więcej) okresie czasu. Weryfikacja ma dwa cele.

Po pierwsze, liczba kryteriów segmentacji, aby ta mogła być z powodzeniem wykorzystywana, nie powinna przekroczyć 5-7 warunków. Stąd, bardzo ważne jest pozostawienie tylko najbardziej istotnych kryteriów.

Po drugie, segmenty (przecięcia kryteriów segmentacji) powstałe przy wykorzystaniu tych najbardziej istotnych warunków powinny być heterogenicznie (zróżnicowane) względem najbardziej kluczowego wskaźnika wydajności (najczęściej: współczynnika konwersji lub średniej wartości zamówienia).

Krok 4.

Pozytywne zweryfikowanie listy kryteriów segmentacji tworzy prototyp segmentacji i daje zielone światło do zdefiniowania poszczególnych segmentów oraz opracowania narzędzi segmentacji (najczęściej w formie dedykowanych definicji segmentów zaawansowanych odpowiadających przecięciom kryteriów segmentacji).

Opracowanie narzędzi segmentacji oraz upowszechnienie tych narzędzi w ramach organizacji wieńczą proces opracowywania całej segmentacji, która w obiegu powszechnym określana jest jako segmentacja dwupoziomowa i która wypromowana została przez zespół Semphonic.

Zdefiniowana w ten sposób segmentacja może następnie posłużyć, wespół z ustalonymi kluczowymi wskaźnikami sukcesu, do przygotowania systemu raportowania oraz usprawnienia procesów analityki internetowej, pozwalając na pełne wykorzystanie danych (np. analiza i optymalizowanie media mix, rozwój i optymalizacja witryny). Segmentacja stanowi również dobre podłoże dla opartych o dane person.

Segmentacja klientów w erze sztucznej inteligencji – jak AI zmienia podejście do analizy danych

Nowoczesne narzędzia oparte na sztucznej inteligencji pozwalają tworzyć segmenty klientów dynamicznie – w oparciu o zachowania w czasie rzeczywistym, a nie tylko dane historyczne. Algorytmy machine learning wykrywają wzorce niedostrzegalne dla człowieka, co umożliwia bardziej precyzyjne prognozy potrzeb i dopasowanie komunikacji marketingowej.

Predykcyjna segmentacja z wykorzystaniem machine learning – praktyczne przykłady zastosowań

Teraz kolej na Was – w jaki sposób podchodzicie do segmentacji?

The post Segmentacja to nie tylko segmenty zaawansowane. O właściwym podejściu do segmentacji w 4 krokach first appeared on Conversion.

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

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

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

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

Czym jest Google Tag Manager?

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

Jak zainstalować Google Tag Managera?

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

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

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

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

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

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

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

1. Szybsza strona internetowa

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

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

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

2. Gwarancja otagowania każdej strony

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

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

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

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

Jak przedstawia się struktura Google Tag Managera?

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

Konto i kontenery w GTM

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

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

Typy kontenerów w Google Tag Manager.

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

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

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

Data Layer (warstwa danych w GTM)

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

Jak sobie z tym poradzić?

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

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

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

Jak wygląda warstwa danych w Google Tag Manager?

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

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

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

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

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

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

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

Zmienne w Google Tag Managerze

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

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

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

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

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

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

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

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

Tagi wykorzystywane przez Google Tag Managera

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

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

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

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

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

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

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

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

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

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

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

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

Triggers (tzw. reguły GTM)

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

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

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

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

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

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

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

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

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

Foldery w GTM

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

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

Templates w aplikacji Google Tag Manager

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

Zaawansowane funkcje Google Tag Manager

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

Integracja z Google Analytics

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

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

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

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

Zarządzanie użytkownikami Google Tag Managera

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

Na poziomie konta masz do dyspozycji 2 poziomy uprawnień:

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

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

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

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

Zarządzanie wersjami kontenera w GTM

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

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

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

Środowiska wykorzystywane w GTM

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

Podgląd i debugowanie

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

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

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

Tryb zgody – Consent Mode w Google Tag Manager

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

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

Ustawienia kontenerów w GTM.

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

Ustawienia tagów w GTM.

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

Google Tag Manager – podsumowanie

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

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

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

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

Google Analytics oferuje wiele możliwości analizy kampanii, jednak są to analizy post click, natomiast, to co działo się przed kliknięciem np. ile razy użytkownik zobaczył daną reklamę, pozostaje w GA kompletnie niewidoczne. Dzięki centralizacji kampanii w ramach DoubleClick Campaign Managera będziemy mogli analizować nie tylko interakcje w postaci klików, ale również interakcje w postaci odsłon.

Zanim przejdziemy do tego jak analitycy mogą wykorzystać DoubleClick Campaign Managera do analizy kampanii, w drugim poście z serii DoubleClick 101, omówię możliwości pozostałych narzędzi wchodzących w skład platformy DoubleClick Digital Marketing (DDM), oraz jak przebiega cały proces, tworzenia, konfiguracji i publikacji kampanii.

Platforma DDM

W skład platformy DDM, wchodzą narzędzia umożliwiające zarządzaniem kampaniami reklamowymi, w formatach (display, ppc oraz rich media):

1. DoubleClick Campaign Manager (DCM),

2. DoubleClick  Search (DS),

3. DoubleClick Bid Manager (DBM),

4. DoubleClick Studio

DoubleClick Campaign Manager (DCM)

Centralna część platformy, w której koordynujemy całość naszych działań marketingowych, typu Display. W ramach DCM-a tworzymy reklamodawcę, kampanie oraz poszczególne reklamy. Tutaj również tworzymy listy remarketingowe, ustawiamy parametry kampanii jak np. czas trwania, użyte kreacje oraz planujemy jak dane reklamy mają się wyświetlać, ustawiając np. targetowanie geograficzne . Po skonfigurowaniu wszystkich parametrów kampanii generujemy kody, które wysyłamy do wydawcy aby umieścił ja na stronie.

W ramach DCM znajduje się również narzędzie do raportowania, zawierające m.in. funkcjonalności w ramach zakładki Verification: Action View oraz Content (link do posta DCM 1), oraz funkcjonalności pozwalające na optymalizację kampanii np. poprzez automatyczne zwiększanie liczby wyświetleń kreacji które generują najwięcej kliknięć.

Standardowo do DCM-a raportują się kampanie display, rich media oraz search, jest jednak możliwość skonfigurowania kampanii mailingowych, tak aby informacja o otwarciach, czy kliknięciach również raportowała się do DCM-a.

W ramach DCM dostępne są funkcje zarządzania kreacjami rich media, raportowania efektów kampanii w oparciu o formaty, jak np. interaktywne wideo oraz funkcje automatycznej optymalizacji kampanii, zwiększającej skuteczność kampanii reklamowych.

DoubleClick  Search (DS)

Ta część platformy DDM służy do tworzenia i zarządzania kampaniami w wyszukiwarkach. Narzędzie wygląda analogicznie do tego w Google Adwords, jednak dodatkowo, możemy w ramach jednej platformy zarządzać kampaniami w innych wyszukiwarkach, oraz importować i synchronizować kampanie z Google AdWords, Microsoft adCenter oraz Yahoo Search Marketing. DS zawiera dodatkowo narzędzia do optymalizacji kampanii.

DoubleClick Bid Manager (DBM)

DBM umożliwia zakup powierzchni reklamowych, w których będziemy publikować reklamy display oraz rich media  skonfigurowane w ramach kampanii w DCM.

Zakup odbywa się w ramach Programmatic buying, czyli zautomatyzowanej metody masowego zakupu powierzchni reklamowej.

Reklamodawca może kupować powierzchnie reklamowe wystawione przez wydawców w systemie aukcyjnym, gdzie cena ustalana jest dynamicznie w zależności od popytu. Istnieje również możliwość zakupu powierzchni bezpośrednio od wydawcy (zawierając umowę, i ustalając stałą cenę w ramach programmatic buying) jednak zakup za stałą stawkę jest na razie mało popularny i stanowi drugorzędną opcję.

W ramach DBM swoje powierzchnie oferują praktycznie wszyscy najwięksi wydawcy. Konfiguracja kampanii publikowanej u wielu wydawców w wielu sieciach w jednym narzędziu umożliwi porównanie skuteczności i dalszą optymalizacje naszych wysiłków reklamowych. W Polsce za pomocą DBM-a można kupować w ramach Programmatic buying od następujących wydawców:  Onet, Interia, Facebook, o2, YouTube, NK.pl, WP.pl, Money.pl, Gazeta.pl, TVN.

DoubleClick Studio

DoubleClick Studio to narzędzie za pomocą którego agencje kreatywne przygotowujące kreacje mogą dodawać swoje prace bezpośrednio do DCM a dzięki temu oszczędzić czas na przekazywanie materiałów graficznych do zarządzających kampanią, usprawnić proces komunikacji (przekazywanie uwag) oraz zarzadzanie różnymi wersjami poszczególnych reklam.

Proces

1. 1. Agencja kreatywna tworzy kreacje i za pomocą D Studio (1) wrzuca swoje prace do DCM, gdzie zarządzający kampanią akceptuje poszczególne wersje oraz przyporządkowuje je do poszczególnych kampanii.
   2. Zarządzający kampaniami w wyszukiwarkach importuje  do DS kampanie skonfigurowane w ramach różnych wyszukiwarek (2a),  tak by móc nimi zarządzać razem z kampaniami display i rich media w ramach DCM-a (2b).
   3. Zarządzający kampanią wykupuje powierzchnie reklamowe zgodnie z celami kampanii.
   4. W ramach DCM wszystkie elementy składane są w całość. Zarządzający kampanią konfiguruje jakie reklamy, w jakim czasie i gdzie się będą pojawiać oraz do jakiej grupy mają dotrzeć.
   5. Kody dla poszczególnych reklam zastają wysłane do wydawcy, który publikuje je u siebie na stronie, lub reklamodawca udostępnia swoje reklamy do DBMa (wcześniej należy kupić powierzchnie reklamowe przez DBM). W tym drugim przypadku synchronizacja kodu emisyjnego odbywa się automatycznie i nie trzeba nic dodatkowo wysyłać.
   6. Informacje o tym ile razy reklama została wyświetlona w poszczególnych miejscach zostają przesłane do DCM, gdzie można je przeanalizować, oraz automatycznie z pomocą  lub samodzielnie optymalizować kampanie.
   7. Opcjonalnie DCM-a można zintegrować z Google Analytics Premium, tak, aby również w ramach tego narzędzia raportowały się dane z kampanii w DCM. Możliwe jest również połączenie w drugą stronę, czyli z GAP do DBM, co również stanowi cenną funkcjonalność, wykorzystywaną przez klientów GAP.

Struktura DoubleClick Manager

DoubleClick Manager pozwala na zarządzanie kampaniami displayowymi w Internecie. W ramach Konta tworzymy Reklamodawcę. Dla Reklamodawcy tworzymy Kampanię, w ramach której tworzymy Reklamy oraz Kreacje. Część platformy DDM Raportowanie pozwala przeglądać dane o reklamach traffickowych w DoubleClick Manager.

W części Raportowanie znajduje się karta Weryfikacja, dzięki której możemy przeanalizować poprawność emitowanych kampanii reklamowych. Dwie funkcjonalności, które pomogą nam odpowiedzieć na pytania zaprezentowane we wstępie to Active View oraz Content.

Czy użytkownik widział reklamę?

Dzięki funkcjonalności Active View, sprawdzimy jaka część reklam display (raportowanych jako wyświetlone) była faktycznie widziana przez użytkowników.

Narzędzie uzna reklamę jako widoczną jeśli co najmniej 50% reklamy było widoczne w części strony widzianej przez użytkownika, przez co najmniej 1 sekundę.

Dzięki temu możemy zidentyfikować i wyeliminować reklamy umieszczane w miejscach, do których większość użytkowników nie dociera i tym samym nie widzi naszych kreacji.

Jeśli rozliczamy się z wydawcami w modelu CPM (koszt za tysiąc wyświetleń), płacąc za każde wyświetlenie to warto, żeby użytkownicy faktycznie mogli zobaczyć umieszczone przez nas reklamy, dzięki czemu zwiększymy efektywność i skuteczności kampanii display.

Czy reklama jest w dobrym miejscu?

Za pomocą funkcjonalności Content Verification, DoubleClick Manager monitoruje zawartość strony internetowej, na której reklama została wyemitowana. Dzięki temu możemy upewnić się, że reklamy nie są wyświetlane na stronach z nieodpowiednimi treściami, jak hazard, przemoc czy treści dla dorosłych.

Istnieją standardowe klasyfikatory (już skonfigurowane w ramach narzędzia), za pomocą których można weryfikować strony na których pojawiły się nasze reklamy, oraz niestandardowe, które możemy sami skonfigurować i dostosować je do swoich potrzeb. Standardowe klasyfikatory oznaczają m.in. następujące tematy: pornografia, wulgaryzmy, alkohol, tytoń, narkotyki, broń, hazard, przemoc, polityka, religia, wypadki transportowe, wymiana plików, tragedia czy hacking.

Klasyfikatory niestandardowe są przydatne, jeśli chcemy wyszczególnić inną kategorię, przy której nie chcemy emitować naszych reklam. Przykładowo producent samochodów może stworzyć klasyfikator „awarie w samochodach”, aby uniknąć pokazywania reklam samochodów przy tego typu artykułach, czy też klasyfikator, który monitoruje, czy reklamy są wyświetlane na stronach, w których wspomniano konkurenta lub prezentująca daną markę w negatywnym świetle.

Można utworzyć dowolną liczbę niestandardowych klasyfikatorów, a następnie zastosować je do całego konta lub do poszczególnych kampanii.

Dzięki możliwości weryfikacji unikniemy sytuacji, że nasza reklama będzie się wyświetlała w nieodpowiednim miejscu jak w przykładzie (trochę przerysowanym ) poniżej:

Testowanie skuteczności kreacji oraz placementów w DoubleClick Manager

W DoubleClick Manager można porównać skuteczność kreacji tak jak w testach A/B. W ramach testowania narzędzia na blogu Conversion umieściłem dwa typy banerów, w dwóch miejscach na stronie:

Baner 250 x 250 umieszczony na blogu Conversion, za pomocą Double Click Campaign Managera na sidebarze.

Baner 200 x 200 umieszczony na blogu Conversion, za pomocą Double Click Campaign Managera w stopce.

Dla każdego typu banera opublikowane zostały po dwie kreacje:

Kreacje – baner 250 x 250 umieszczony na blogu Conversion, za pomocą Double Click Campaign Managera w stopce (stary oraz nowy – od lewej)

Kreacje – baner 200 x 200 umieszczony na blogu Conversion, za pomocą Double Click Campaign Managera w stopce.

Obie reklamy były wyświetlone na każdej stronie bloga, także baner 250 x 250 oraz 200 x 200 wyświetliły się taką samą ilość razy. DoubleClick Manager posiada różne opcje rotacji kreacji w ramach jednej reklamy. Kreacje mogą być na przykład wyświetlane w określonej kolejności. Albo jedna z nich może się wyświetlać dwa razy częściej niż pozostałe. Można też ustawić rotację w taki sposób, by kreacje o największej skuteczności były wyświetlane częściej niż inne. DoubleClick Manager rotuje kreacje przy użyciu wag, które można wpisać ręcznie lub skonfigurować tak, by były dostosowywane na podstawie skuteczności i innych czynników.

W mojej kampanii kreacje również wyświetlały się w równych proporcjach, także każdy z banerów był wyświetlony praktycznie taką samą liczbę razy:

Wyniki testowej kampanii – liczba kliknięć wobec liczby wyświetleń.

Jak widzimy baner 200 x 200 wygenerował bardzo mało kliknięć, mimo wyświetleń (tej kwestii będzie się należało przyjrzeć bliżej), natomiast baner 250 x 250 , okazał się znacznie bardziej skuteczny. Kreacja (Nowa) dla banera 250 x 250 okazała się pawie 3 razy bardziej skuteczna (jeśli chodzi o CTR – Click Through Rate) od starej wersji.

Należy również dodać, że poniższe wnioskowania, służą jedynie pokazaniu funkcjonalności narzędzia oraz mechanizmu wnioskowania i opierają się na niewielkiej liczbie danych z kampanii testowej. W przypadku prawdziwego testu należałoby dodatkowo zbadać czy wyniki są istotne statystycznie.

Wiemy już, że w obu przypadkach nowe kreacje okazały się skuteczniejsze od starych, także grafik który je projektował wykonał dobrą robotę ;).

Dlaczego jednak nowy baner 200×200 miał Click Through Rate (CTR) na poziomie 0,14%, skoro ten sam baner w wymiarach 250 x 250 wygenerował CTR na poziomie 0,78%?

Po pierwsze sprawdźmy czy nasze reklamy są faktycznie widziane przez użytkowników, co możemy zrobić korzystając z zakładki Weryfikacji DoubleClick Manager.

Wyniki testowej kampanii – realna liczba wyświetleń.

Okazuje się, banery 200×200 były widziane znacznie mniej niż banery 250 x 250, 3% wobec 75%.
Także licząc CTR na podstawie viewable impressions mamy:
Nowy baner 200 x 200 – 3479 x 3% = 104, CTR = 5/104 = 4,79%
Nowy baner 250 x 250 – 3453 x 75% = , CTR = 27/2589 = 1,04%

Jak można się było domyślić większość użytkowników, którzy odwiedzili stronę nie miała okazji zobaczyć banera na samej dole strony (200×200). Jednak ci którzy już tam dotarli chętniej klikali w nowy baner, który wygenerował wyższy CTR 4,79% wobec 1,04%. To, że CTR jest wyższy nie wynika raczej z tego, że reklama 200×200 jest lepsza, ale z faktu, że tylko mały % użytkowników dotarł do końca strony, a Ci, którzy już tam dotarli byli dużo bardziej zaangażowani i dlatego chętniej kliknęli (banery na górze widzieli natomiast wszyscy).

W dalsze kolejności można by przeanalizować jak poszczególne kreacje i reklamy przełożyły się na sprzedaż – zarówno jako krok prowadzący bezpośrednio do konwersji oraz jako kroki wspomagające konwersje analiza ścieżek wielokanałowych, ale to już temat na kolejny post.

Alert Geo

Przygotowując ten artykuł, w części dotyczącej raportowania zauważyłem alert mówiący o tym, że część moich reklam była wyświetlona poza obszarem który wybrałem w ramach geo-targetowania (kraj: Polska).

Wyniki testowej kampanii – alert o reklamach wyświetlanych poza obszarem geo-targetowania

W tym wypadku, nie ma to większego znaczenia, gdyż wszystkie reklamy były umieszczone w ramach własnego portalu. Jednak gdybym prowadził kampanie u zewnętrznego wydawcy, na którą planuję wydać 1 mln. zł, w ciągu kolejnego miesiąca, to ten jeden alert (odpowiednio wcześnie zauważony) pozwoli mi wyeliminować stratę w wysokości 5,57% wydanej kwoty, czyli oszczędzić ponad 55 tys. zł.

Podsumowanie

Platforma DDM umożliwia zarządzanie całością działań związanych z tworzeniem (od kreacji przez miejsce publikacji do raportowania wyników) kampanii reklamowych display, rich media oraz search, poszczególne elementy platformy zawierają funkcje optymalizujące działania na poszczególnych etapach oraz raportowanie wyników i weryfikacje tego czy np. nasze reklamy są faktycznie widziane przez użytkowników i czy wyświetlają się w odpowiednich miejscach.

Wkrótce kolejne artykuły z serii DoubleClick 101, które pokażą jak analitycy mogą wykorzystać to narzędzie do analizy kampanii.

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

The post DoubleClick 101: Jakie możliwości daje platforma DoubleClick Digital Marketing first appeared on Conversion.

Jakie są główne przyczyny złej jakości danych w organizacji?

Zagrożenie #1 – Brak kompetencji

Czynnikiem, który potęguje zagrożenia płynące z posiadania danych słabej jakości jest brak kompetencji analitycznych w organizacji. W dobie, w której biznes w głównej mierze opiera się na danych płynących z różnych źródeł, posiadanie w zasobach ludzkich zespołu analityków pozwala czerpać z tych danych maksymalne korzyści. Obecnie wiele firm zatrudnia tzw. „ludzi renesansu”, którzy odpowiedzialni są w firmie za działania analityczne od A do Z. Jest to też zjawisko potencjalnie niebezpieczne, szczególnie że aktualnie dysponujemy olbrzymimi zasobami informacji, które muszą zostać w poprawny sposób zgromadzone i przetworzone – co wymaga bardzo szerokiego wachlarza kompetencji od czysto technicznych po matematyczno-analityczne.

Zagrożenie #2 – Brak narzędzi

Innym problemem z jakim borykają się organizacje jest brak wdrożonych narzędzi służących do analizy. Skutkuje to tym, że analizowanie zbiorów danych bardzo rozciąga się w czasie generując niepotrzebne koszty. Oczywistym jest, że w ślad za rosnącymi kosztami maleje zwrot z wszelkich inwestycji. Inną bolączką firm, które wdrożyły u siebie analitykę internetową jest fakt, że opierają swoje działania w tym zakresie na bardzo rozbudowanych instalacjach, które są, tak naprawdę, dla nich zbędne, bo nie są w stanie wykorzystać ich całego potencjału. Ponownie, utrzymanie takich instalacji kosztuje – zwrot z inwestycji maleje.

Zagrożenie #3 – Brak procesów

Z drugiej strony stoją przedsiębiorstwa, które mają w swoich szeregach zespół analityków i wdrożone narzędzia do zbierania i przetwarzania danych. Co w takim przypadku może pójść nie tak jak powinno? Bardzo ważną kwestią jest ciągłe utrzymywanie procesów, które gwarantują poprawność zbieranych danych. Możemy zatrudnić odpowiednich ludzi, dać im najlepsze narzędzia, ale bez wiedzy o tym jak sprawić by dane które analizują były zawsze poprawne wszystkie ich wysiłki pójdą na marne.

The post Sposoby na minimalizację ryzyka nietrafionych decyzji biznesowych dzięki poprawnym danym first appeared on Conversion.

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

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

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

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

Istota próbkowania

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

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

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

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

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

Próbkowanie w Google Analytics

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

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

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

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

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

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

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

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

Co to znaczy „duży ruch”?

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

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

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

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

Precyzja próbkowania

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

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

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

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

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

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

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

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

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

Jak możemy się przed tym bronić?

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

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

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

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

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

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

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

Podsumowanie

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

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

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

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

Rozwiązanie

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

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

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

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

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

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

Dane będą raportowane na poziomie:

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

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

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

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

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

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

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

Wdrożenie Measurement Protocool

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

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

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

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

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

Przykładowy kod w treści maila:

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

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

Fragmenty pozostałe:

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

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

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

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

Wdrożenie kodów Universal Analytics

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

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

Kod:

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

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

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

Podsumowanie

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

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

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

Źródło: http://www.statista.com/statistics/266210/number-of-available-applications-in-the-google-play-store/

Natomiast liczba aplikacji dostępnych w Apple Appstore wyniosła 1,3 mln we wrześniu 2014:

Źródło: http://www.statista.com/statistics/263795/number-of-available-apps-in-the-apple-app-store/

Rosnąca liczba aplikacji mobilnych, sprawia, że rośnie również zapotrzebowanie na prawidłowe śledzenie zachowania użytkowników aplikacji.

Aby sprawdzić poprawność kodów śledzących w ramach witryny internetowej wystarczy przeglądarka rozbudowana o klika dodatkowych wtyczek.

Przygotowanie specyfikacji pod śledzenie aplikacji jest zazwyczaj proste (nie odbiegające od specyfikacji dla witryny). To co może sprawić trudność to sprawdzenie czy dział IT wszystko poprawnie zakodował oraz to, czy aplikacja wysyła w hitach poprawne informacje do Google Analytics.

W tym poście przedstawię jak stworzyć środowisko testowe, aby sprawdzić poprawność śledzenia aplikacji Android oraz iOS, bez konieczności posiadania różnych modeli telefonów.

I. Narzędzia i uruchamianie aplikacji Android

Do sprawdzenia śledzenia aplikacji konieczne będą 2 elementy: emulator, za pomocą którego stworzymy wirtualny telefon, na którym będziemy testować aplikację oraz odbiornik, za pomocą którego będzie można podejrzeć hity, które aplikacja wysyła do Google Analytics. W przypadku aplikacji rolę emulator spełni oprogramowanie Genymotion, natomiast rolę odbiornika Android Device Monitor, będący częścią Android Studio.

Poniżej instrukcja instalacji i konfiguracji środowiska do testowania aplikacji Android:

1. Instalacja emulatora Androida – Genymotion, który można pobrać tutaj.

Przed instalacją, konieczne jest założenie konta na Genymotion.
Genymotion umożliwi stworzenie wirtualnego telefonu, na którym będziemy testować aplikację.

2. Instalacja wirtualnej maszyny Virtualbox, którą można pobrać tutaj.

3. Instalacja Android Studio, którą można pobrać tutaj. Android Studio zawiera w sobie Android Device Monitor, który umożliwi podgląd hitów, które aplikacja wysyła do Google Analytics.

Aby zainstalować Android Studio, konieczne będzie wcześniejsze pobranie i zainstalowanie pakietu Java SE Development Kit 7 update 76, który można znaleźć: na tej stronie

Update 76 znajduje się w dalszej części strony:

Na tym etapie, a przed instalacją Android Studio warto zrestartować komputer.
Gdy wszystkie elementy są już zainstalowane możemy przystąpić do stworzenia środowiska testowego.

4. Uruchamiamy i logujemy się do Genymotion, w którym stworzymy wirtualny telefon do testowania aplikacji Android.

5. Następnie wybieramy wersję systemu Android oraz model urządzenia który chcemy „stworzyć”:

Lub też wybieramy z listy, przykładowo Custom Phone – 4.4.4 – API19 – 768×1280.

5. Na kolejnym screenie możemy zobaczyć parametry tworzonego telefonu:

6. Utworzony telefon, pojawi się w Genymotion. Uruchamiamy go klikając przycisk 'Start’.

7. Do debugowania śledzenia w aplikacji w wersji Android konieczna będzie jej wersja zapisana jako plik .apk z włączoną w możliwością debugowania (musi być w kodzie ustawiona flaga: android:debuggable=”true”).

8. Aplikację „instalujemy” na naszym telefonie, przeciągając i upuszczając plik .apk na okno Genymotion z odpalonym telefonem.

Możemy już testować samą aplikację na naszym nowo utworzonym telefonie. Nam zależy jednak na zobaczeniu szczegółowych informacji, wysyłanych w poszczególnych hitach do Google Analytics. W tym celu uruchamiamy odbiornik.

9. Uruchamiamy Android Studio i wybieramy 'Start a new Android Studio Project’. Na kolejnych ekranach klikamy 'Next’ aż uruchomi się ekran aplikacji. W górnej belce klikamy w ikonę Android Device Monitor. Sam program Android Studio możemy w tym momencie już zamknąć.

10. W Android Device Monitor, w oknie Devices powinien być widoczny stworzony przez nas telefon.

Natomiast w oknie LogCat możemy przeglądać informację wysyłane przez aplikacje która jest aktualnie uruchomiona. Tutaj znajdują się również poszczególne hity wysyłane do Google Analytics.

II. Narzędzia i uruchamianie aplikacji iOS

Do sprawdzenia śledzenia aplikacji iOS również konieczne będą 2 elementy: emulator, za pomocą którego stworzymy wirtualny telefon, na którym będziemy testować aplikację oraz odbiornik, za pomocą którego będzie można podejrzeć hity, które aplikacja wysyła do Google Analytics. W przypadku aplikacji iOS rolę emulator spełni oprogramowanie iOS Simulator będący częścią Xcode, natomiast rolę odbiornika plik system.log.

Poniżej instrukcja instalacji i konfiguracji środowiska do testowania aplikacji iOS:

1. Instalujemy Xcode, do pobrania z Appstore. Dzięki iOS Simulator będącego częścią Xcode będziemy mogli stworzyć wirtualny telefon na którym uruchomimy i przetestujemy aplikację. W przypadku systemu iOS będziemy potrzebowali pliku .app.

Aby aplikacja, którą chcemy przetestować była dostępna w stworzonym przez nas telefonie musimy ją umieścić w odpowiednim folderze.

Wgrywamy aplikacje – plik z rozszerzeniem .app do folderu w ścieżce:
Biblioteki / Developer / CoreSimulator / Devices / 833164BB-EC1C-40C9-8EAA-DDBEC3E15C34 / data / Containers / Bundle / Application / 774C5791-3D3C-42D6-A3EC-EE1F6D051969 /

Należy kliknąć w przycisk ‘Idź’ z menu górnego:

A następnie nacisnąć i przytrzymać klawisz ‘ALT’ wtedy pojawi się opcja przejścia do Biblioteki w którą klikamy. A następnie umieszczamy plik .app w odpowiednim folderze.

Teraz po uruchomieniu symulatora iOS, aplikacja będzie czekała w telefonie:

III. Debugowanie aplikacji Android

1. Najlepiej umieścić obok siebie okno Android Device Monitor oraz wirtualnego telefonu z uruchomioną aplikacją Android którą testujemy. Dzięki temu, widzimy dokładnie, jaki hit do Google Analytics jest wysyłany przy wykonaniu danej akcji w aplikacji:

2. Obserwując poszczególne hity, możemy sprawdzić, czy informacje wysyłane do Google Analytics są poprawne. Poniżej przykładowy hit zawierający nr konta UA, oraz nazwę danego ekranu ‘Aktualności’:

3. W ramach hitów przekazują się również zdarzenia. Poniżej przykładowy hit, w którym Kategoria i Akcja i Etykieta Zdarzenia przekazane są za pomocą zmiennych: ec, ea i el:

IV. Debugowanie aplikacji iOS

1. Aby zobaczyć szczegółowe informacje, wysyłane w poszczególnych hitach do Google Analytics należy włączyć odbiornik, którego role w przypadku aplikacji iOS spełni plik system.log. Uruchamiamy log symulatora. Należy kliknąć w przycisk ‘Idź’ z menu górnego:

A następnie nacisnąć i przytrzymać klawisz ‘ALT’ wtedy pojawi się opcja przejścia do Biblioteki w którą klikamy.
W Bibliotece wybieramy system.log, który znajduje się na ścieżce Biblioteka / Logs / CoreSimulator / 833164BB-EC1C-40C9-8EAA-DDBEC3E15C34 / system.log

2. Odbiornik jest już gotowy, teraz możemy włączyć aplikację. Uruchamiamy w Xcode iOS Simulator:

Co sprawi, że otworzy się wirtualny telefon z systemem iOS. Ponieważ przenieśliśmy plik z aplikacją do odpowiedniego folderu, będzie ona dostępna i gotowa do testowania.

3. Najlepiej umieścić obok siebie okno system.log oraz wirtualnego telefonu z uruchomioną aplikacją iOS którą testujemy. Dzięki temu, widzimy dokładnie, jaki hit do Google Analytics jest wysyłany przy wykonaniu danej akcji w aplikacji.

4. Obserwując poszczególne hity, możemy sprawdzić, czy informacje wysyłane do Google Analytics są poprawne. Poniżej przykładowy hit zawierający nr konta UA, oraz nazwę danego ekranu ‘Aktualności’:

W ramach hitów przekazują się również zdarzenia. Poniżej przykładowy hit, w którym Kategoria i Akcja i Etykieta Zdarzenia przekazane są za pomocą zmiennych: ec, ea i el:

Podsumowanie

Jak widać testowanie śledzenia poprawności aplikacji Android oraz iOS wymaga pobrania i zainstalowania odpowiednich narzędzi: emulatora telefonu oraz odbiornika, w którym możemy przeglądać informacje wysyłane do Google Analytics, w dwóch wersjach dla Androida oraz dla IOS. Stworzenie odpowiedniego środowiska, to jednak jednorazowy wysiłek, i gdy już jest gotowe sprawdzanie poprawności śledzenia dla aplikacji nie powinno być bardziej kłopotliwe niż dla stron internetowych.

The post Debugowanie aplikacji Android oraz iOS pod kątem śledzenia w Google Analytics first appeared on Conversion.

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

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

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

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

#1 Super Dashboardy

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

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

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

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

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

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

#2 Efektywne zarządzanie konfiguracją

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

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

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

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

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

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

#3 Integracja baz danych

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

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

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

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

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

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

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

Co to jest wartość życiowa klienta?

Wartość życiowa klienta (CLV) to suma przychodów, jakie klient wygeneruje dla firmy przez cały okres trwania relacji. Wyliczenie tego wskaźnika dla całego okresu współpracy między klientem a firmą, który może trwać nawet kilkadziesiąt lat, byłoby czasochłonne oraz obarczone dużym ryzykiem uzyskania błędnego wyniku, dlatego CLV liczy się zwykle dla krótszego przedziału czasowego, np. 12 miesięcy. Pozwala to zniwelować wpływ takich czynników jak zmiana oferty czy działania konkurencji. W praktyce więc jeśli klient co 3 miesiące kupuje w Twoim sklepie internetowym soczewki kontaktowe, za które płaci każdorazowo 100 zł, to jego CLV w okresie 12 miesięcy wynosi 4 * 100 zł = 400 zł.

Oczywiście powyższe obliczenie jest uproszczone i ma na celu wstępne zarysowanie koncepcji. CLV ma szerokie zastosowanie – jeśli wiesz, ile wart jest dla Ciebie klient, jesteś w stanie skuteczniej decydować, ile pieniędzy możesz przeznaczyć na konkretne działania, aby firma była rentowna.

Do czego wykorzystać wartość życiową klienta?

Znając wartość CLV możesz podjąć na podstawie danych wiele decyzji bazujących do tej pory na przeczuciu bądź ogólnej estymacji. Przede wszystkim CLV pozwala Ci stwierdzić, jak duże nakłady na pozyskanie klienta oraz utrzymywanie z nim relacji możesz ponieść. Dzięki temu określisz maksymalny budżet na działania PPC przy którym nadal opłaca Ci się pozyskiwać klientów.

Na przykład wiedząc, że średnio dział obsługi klienta poświęca 5 godzin miesięcznie na kontakt z klientem, a godzina pracy tego działu kosztuje Cię 40 zł, możesz to porównać z przychodami, jakie w ciągu roku klient wygeneruje dla Twojej firmy i zdecydować, czy na pewno taki kanał wsparcia jest opłacalny. Jeśli nie, to być może bardziej opłaca się stworzyć obszerny dział pomocy na stronie internetowej i tam kierować klientów, którzy nie przynoszą firmie dostatecznie dużo pieniędzy.

No właśnie – jak określić, ile nakładów maksymalnie na pozyskanie i obsługę konkretnego klienta? Z pomocą przychodzi tutaj segmentacja, która powinna być nieodłącznym elementem wyliczania CLV. Wyliczenie uśrednionej wartości dla całej populacji klientów nie pozwoli Ci na wyciągnięcie wniosków pozwalających na skuteczniejsze działanie. A im bardziej skomplikowane jest Twoje portfolio produktów i im większe są różnice pomiędzy poszczególnymi grupami klientów, tym ważniejsza będzie segmentacja i wyliczenie osobnego CLV dla każdego z segmentów, jakie zidentyfikujesz.

Jeśli prowadzić biznes internetowy, to jedną z podstawowych segmentacji jest podział użytkowników wobec źródeł ruchu. Pozwoli Ci to dostrzec różnice w CLV zaangażowanych klientów (pozyskanych np. poprzez newsletter) oraz klientów pozyskanych poprzez serwisy zakupów grupowych, którzy prawdopodobnie chcieli tylko skorzystać z promocji i już nie wrócą do Twojej firmy, ponieważ będą woleli wybrać ofertę promocyjną konkurencji. Taka segmentacja daje Ci informację o tym, które źródło pozyskiwania klientów jest skuteczniejsze i gdzie lepiej alokować budżet na promocję firmy – w pracownika dbającego o jakość kampanii e-mail marketingowych, czy w prowizję dla serwisu zakupów grupowych.

Jak wyliczyć wartość życiową klienta?

Do wyliczenia CLV prowadzą dwie drogi – pierwsza z nich to metody oparte o dane historyczne, natomiast druga to analizy predykcyjne. Analizy predykcyjne polegają na estymowaniu przyszłych przychodów na bazie dobranych kryteriów i wymagają tworzenia zaawansowanych modeli, dlatego na potrzeby tego wpisu przedstawię dwie metody oparte o dane historyczne. Te sposoby są szybsze i mniej skomplikowane. Mają oczywiście swoje wady, ale pozwolą Ci w krótszym czasie rozpocząć podejmowanie decyzji w oparciu o CLV.

Na początku warto jeszcze wspomnieć o tym, jak nie należy liczyć CLV. Najprostszym sposobem wydaje się bowiem podzielenie sumy przychodów na liczbę klientów. Nigdy tego nie rób – uśrednione w ten sposób dane w żaden sposób nie pomogą Ci podjąć właściwych decyzji.

Średni przychód na użytkownika

Na przykład jeśli klient o imieniu Weronika dokonał pierwszego zakupu na kwotę 100 zł w marcu, a następnie dokonał dwóch kolejnych zakupów na kwotę 70 zł każdy w kwietniu, to jego średnia miesięczna wartość wynosi:

(100 zł + 70 zł + 70 zł) / 2 = 120 zł

Jeśli klient o imieniu Adam dokonał w styczniu zakupu na kwotę 200 zł, a kolejnego zakupu na kwotę 80 zł dokonał dopiero w kwietniu, to jego średnia miesięczna wartość wynosi:

(200 zł + 80 zł) / 4 = 70 zł

Uśredniając ten wynik uzyskujesz wartość ARPU w ujęciu miesięcznym:

(70 zł + 120 zł) / 2 = 95 zł

Aby poznać CLV dla okresu 12 miesięcy, wystarczy pomnożyć uzyskany wynik:

95 zł * 12 = 1140 zł

Metoda średniego przychodu na użytkownika (ang. Average Revenue per User) to prosty i szybki sposób na wyliczenie wartości życiowej klienta (ang. Customer Lifetime Value). Dzięki niej obliczysz, ile pieniędzy średnio wydają klienci na Twoje usługi, co pomoże Ci podejmować trafne decyzje związane z pozyskiwaniem i obsługą klientów.

Oczywiście przy obliczaniu ARPU w Twojej firmie wykorzystasz dane o większej liczbie klientów, więc wyliczenie CLV potrwa dłużej, ale wciąż będzie oparte o przedstawione wzory. Zaletą tej metody jest szybkość i prostota. Jej wada to fakt, że nie bierze pod uwagę podziału na nowych i powracających klientów a także zmian w ich zachowaniu. Posiadając wartość ARPU nie jesteś w stanie określić, która z grup klientów ma większy wpływ na końcową wartość wskaźnika. Np. bazując na ARPU nie dostrzeżesz spadku przychodów w grupie powracających klientów (czyli spadku ich lojalności), jeśli jednocześnie szybko rosną przychody generowane przez nowych klientów. Wskaźnik pozostanie w miejscu, więc sytuacja na pozór będzie wyglądać normalnie, a prawdziwe problemy będą dla Ciebie niewidoczne.

Analiza kohort

Remedium na wady ARPU jest analiza kohort. Kohorta to grupa klientów, która dokonała pierwszego zakupu (lub zrealizowała inny cel, np.

Analiza kohort to metoda obliczania CLV, która uwzględnia podział przychodów uzyskanych od konkretnych grup klientów w podziale na kolejne miesiące. Ta metoda umożliwia sprawdzenie jaka część przychodu pochodzi od nowych klientów, a jaka od powracających, jak przedstawia się dynamika zmian między przychodami z tych dwóch grup oraz jak klienci zachowują się wraz z kolejnymi miesiącami od dokonania zakupu. Pozwala też dokładniej niż w przypadku ARPU estymować przychody w kolejnych miesiącach.

Dzięki analizie kohort dowiesz się, jak wygląda CLV w podziale na poszczególne miesiące licząc od pierwszego zakupu dokonanego przez klienta. Pozwoli Ci to zaobserwować trend i przewidzieć, ile faktycznie zarobisz przez kolejne 4 miesiące w odniesieniu do liczby klientów na poszczególnych etapach. Możesz np. wyciągnąć taki wniosek, że pierwsze dwa miesiące nie przynoszą zbyt wysokich przychodów, ponieważ klient chce wypróbować Twoje produkty bez inwestowania wielu pieniędzy, ale gdy się do nich przekona, to w trzecim miesiącu składa duże zamówienie.

Na podstawie takich danych możesz podjąć decyzję o zintensyfikowaniu działań budujących zaufanie do Twoich produktów oraz firmy w pierwszych dwóch miesiącach od pozyskania klienta, tak aby zwiększyć wartość zamówień składanych w trzecim miesiącu bądź zwiekszyć liczbę klientów, którzy w kolejnych miesiącach zdecydują się na zakup.

Analiza kohort pozwala Ci też zidentyfikować trend i obszary Twojej działalności wymagające poprawy. Jeśli widzisz, że wraz z upływem czasu klienci coraz mniej wydają w kolejnych miesiącach, oznacza to, że powinieneś popracować nad ich lojalnością identyfikując, co wpływa na ich mniejszą powracalność oraz znaleźć na to rozwiązanie.

Do wad analizy kohort w kontekście CLV trzeba zaliczyć fakt, że nie sprawdza się ona w momencie gdy rynek szybko się zmienia lub gdy firma dynamicznie rośnie. Klienci pozyskiwani na początkowym etapie istnienia firmy, czyli tzw. early adopters, różnią się od klientów pozyskiwanych na kolejnych etapach. Np. jeśli sprzedajesz aplikację w modelu SaaS i na początku działalności była ona niedopracowana, to pozyskani wtedy klienci prawdopodobnie szybko zrezygnowali z usługi. Zakładając, że po kilku miesiącach aplikacja działała sprawnie i pozyskiwani pół roku po starcie klienci przedłużali abonament, to analiza kohort z pierwszych kilku miesięcy wskazywałaby na przychody sporo mniejsze, niż rzeczywiste.

Teraz Twoja kolej!

Oblicz CLV dla swoich klientów korzystając z jednej z przedstawionych wyżej metod, najlepiej uwzględniając podział na segmenty. Dzięki temu będziesz mógł podejmować skuteczniejsze decyzje dotyczące np. wydatków na pozyskiwanie ruchu czy oferowanego wsparcia posprzedażowego.

Jeśli chcesz zyskać przewagę konkurencyjną dzięki zwiększaniu współczynnika konwersji oraz zwiększyć zysk swojej witryny bez wydawania kolejnej złotówki na reklamę, skontaktuj się z Conversion by poznać nasze podejście. Więcej o optymalizacji współczynnika konwersji dowiesz się pobierając przygotowane przez nas bezpłatne poradniki, raporty oraz case studies.

The post Jak obliczyć wartość życiową klienta (Customer Lifetime Value)? first appeared on Conversion.

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

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

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

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

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

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

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

Po pierwsze: otaguj swoje linki

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

Po drugie: Skonfiguruj zbiór danych

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

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

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

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

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

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

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

Po trzecie: Przygotuj swoje dane

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

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

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

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

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

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

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

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

Co dalej?

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

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

Źródło: shufflepoint.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Raporty porównawcze (benchmarking)

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

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

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

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

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

Możliwość filtrowania botów

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

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

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

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

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

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

Diagnostyka

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

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

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

Google Analytics Demos & Tools

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

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

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

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

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

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

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

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

Raportowanie zbiorcze w Google Analytics Premium

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

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

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

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

Integracja Google Analytics Premium z DoubleClick

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

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

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

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

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

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

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

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

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

The post 10 nowości, które pojawiły się w Google Analytics w 2014 roku first appeared on Conversion.

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

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

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

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

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

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

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

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

1. 1. Wirtualne odsłony:

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

1. 1. Zmienne niestandardowe:

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

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

• Wirtualne odsłony:

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

• Zmienne niestandardowe:

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

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

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

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

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

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

Poniżej skrypt:

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

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

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

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

}

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

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

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

a. Śledzenie:

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

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

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

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

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

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

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

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

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

Najczęściej popełniane błędy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Zdarzenia na przeładowanie

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

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

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

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

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

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

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

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

Błędy w ustawieniach domen dla ciasteczek

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

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

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

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

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

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

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

UTM w kampaniach wewnętrznych

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

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

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

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

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

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

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

Jak poprawnie tagować kampanie wewnętrzne?

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

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

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

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

Niepoprawne śledzenie transakcji

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kokpity menedżerskie, określane również jako dashboardy, są świetnym sposobem na bieżące monitorowanie najważniejszych wskaźników naszej strony. Zamiast przekopywać się przez niezliczone raporty, które oferuje nam Google Analytics, możemy bezpośrednio przejść do indywidualnego kokpitu i zapoznać się z najważniejszymi dla nas informacjami dotyczącymi strony oraz obserwować, jaki wpływ na wskaźniki w długim okresie czasu mają podejmowane przez nas działania.

Wskaźniki prezentowane na dashboardach określamy jako KPI – Key Performance Indicators, tłumaczone jako Kluczowe Wskaźniki Wydajności albo Sukcesu. KPI mierzą naszą efektywność w realizacji celów operacyjnych oraz strategicznych – wskazują, czy działania, które podejmujemy zbliżają nas do założonych celów i stanowią obiektywną ocenę podejmowanych przez nas działań. A z kolei w ich monitorowaniu i przystępnej wizualizacji wspomoże Cię Google Data Studio.

Odpowiedni wybór wskaźników w naszych dashboardach jest bardzo istotny, gdyż pozwala na:

• ukierunkowanie naszej energii oraz zasobów na działania, które są dla nas najistotniejsze, i nie marnotrawienie ich na działania, które nie pomagają w realizacji założonej strategii,
• szybsze podejmowanie decyzji dotyczących rozwoju strony dzięki szybkiemu i łatwemu dostępowi do najważniejszych dla nas informacji,
• lepszą priorytetyzację zadań,
• usprawnienie komunikacji w firmie dzięki temu,
• lepsze wykorzystanie dostępnych zasobów, dzięki informacji zwrotnej jak podejmowane działania wpływają na realizację naszych celów.

Stworzenie KPI oraz dashboardów menedżerskich jest ostatnim etapem w całym procesie tworzenia Kluczowych Wskaźników Wydajności. Zanim przystąpimy do określenia naszych celów oraz związanych z nimi wskaźników, bardzo ważne jest, abyśmy zrozumieli, jakie są najważniejsze dla nas obszary biznesowe oraz elementy naszej strony.

Cały proces tworzenia KPI składa się z 6 etapów, które przedstawia poniższy wykres.

Proces tworzenia wskaźników KPI składa się z 6 etapów – budowa KPI według powyższego schematu zagwarantuje, że stworzone wskaźniki będą odpowiadały naszym celom strategicznym i operacyjnym.

Przeprowadzenie całego procesu według powyższego planu zagwarantuje, że stworzone wskaźniki będą odpowiadały naszym celom strategicznym i operacyjnym.

Dzisiaj chciałabym opowiedzieć Wam o pierwszym etapie w procesie tworzenia Kluczowych Wskaźników Wydajności – o warsztatach KPI, które obejmują swoim zakresem trzy pierwsze etapy na powyższym wykresie.

Głównym celem warsztatów KPI jest zmapowanie i ustrukturyzowanie najważniejszych obszarów biznesowych naszej strony internetowej i prowadzonego biznesu. Przykładowo: najważniejszym celem strony internetowej, która oferuje buty, jest sprzedaż produktów. Możemy jednak wyróżnić wiele strategii, które pozwolą nam zwiększyć sprzedaż: (1) możemy zwiększać środki wydawane na działania marketingowe w Internecie i poprzez te działania zwiększać ogólny ruch na stronie albo (2) możemy przeznaczyć więcej zasobów na wykorzystanie naszych dotychczasowych klientów poprzez oferowanie ich atrakcyjnych cenowo produktów. W przypadku zarówno (1) jak i (2) strategii będziemy zwracać uwagę na kompletnie inne informacje, które do nas spływają ze strony. Właśnie zmapowaniu takich obszarów biznesowych służą warsztaty KPI. Ponadto każda z osób, która pracuje przy stronie może mieć swoje własne cele wyznaczone przez prowadzony zakres działań.

Informacje zebrane w trakcie takich warsztatów stanowią następnie podstawę dla analityków do ustrukturyzowania celów strategicznych i operacyjnych strony, a następnie przypisania im wskaźników, które określałyby poziom ich wykonania. Warsztaty zatem mają być źródłem informacji na temat najważniejszych obszarów biznesowych oraz celów strony. W przypadku wszystkich analiz – im dokładniejsze dane uda nam się zebrać, tym lepszy będzie końcowy wynik naszych badań. Dokładnie ta sama zasada przyświeca warsztatom KPI – im lepiej zrozumiemy model biznesowy danej strony, tym lepsze wskaźniki jesteśmy w stanie zaproponować do oceny realizacji strategii biznesowej.

Metodykę przeprowadzania takich warsztatów zaproponował Steve Jackson.

Miałam okazję parę razy przeprowadzać warsztaty oparte na tej metodyce i rezultaty za każdym razem były bardzo dobre – dokładne poznanie wymagań i potrzeb osób bezpośrednio pracujących przy stronie pozwalało stworzyć wskaźniki, które najlepiej odpowiadały ich potrzebom i specyfice ich pracy.

Warsztaty składają się z trzech części i każda część odpowiada kolejnemu etapowi w procesie tworzenia KPI:

1. pierwszy etap: określenie udziałowców
2. drugi etap: stworzenie modelu REAN
3. trzeci etap: pytania biznesowe

Pierwszy etap: określenie udziałowców

Na samym początku przydzielamy osoby obecne na warsztatach do jednej z trzech grup:

Właściciele budżetu – są to osoby, które decydują, jak ulokować dostępny budżet. Przykładowo właścicielem budżetu jest najczęściej szef działu marketingu, który na podstawie dostępnych informacji podejmuje decyzje, w które projekty zainwestować dostępne środki, a z których projektów zrezygnować.

Właściciele biznesu – są to osoby odpowiedzialne za poprawę działania określonego obszaru biznesu w Internecie. Przykładowo właścicielem biznesu jest osoba, która zajmuje się sprowadzaniem ruchu na stronę czy osoba odpowiedzialna za content.

Osoby techniczne – osoby, które odpowiadają za utrzymanie serwisu. Są to najczęściej specjaliści IT, których głównym zadaniem jest zapewnienie, że serwis działa poprawnie dla wszystkich użytkowników.

Każda z osób obecnych na warsztacie, po przydzieleniu do odpowiedniej grupy udziałowców, powinna następnie opisać, czym zajmuje się na co dzień i jakie decyzje podejmuje. Wszystkie te informacje zapisujemy na tablicy, żeby osoby obecne na warsztatach mogły się im przyjrzeć i w razie potrzeby uszczegółowić bądź dodać kolejne informacje.

Pierwszy etap warsztatów pomaga nam w zrozumieniu roli każdej osoby obecnej na warsztatach w procesie kreowania strategii biznesu w Internecie. Dzięki tym informacjom wiemy, jak przypisać stworzone w późniejszym etapie KPI do konkretnych osób. Efektywnym rozwiązaniem jest, aby każda z osób posiadała swój własny kokpit menedżerski – dzięki temu będzie mogła skupić się jedynie na KPI, które odnoszą się do jej celów.

Drugi etap: stworzenie modelu REAN

Kolejnym etapem warsztatów jest stworzenie modelu REAN dla omawianego biznesu internetowego. Jest to model, który pozwala na usystematyzowanie wszystkich działań marketingowych prowadzonych zarówno w Internecie, jak i poza nim.

REAN obejmuje następujące działania:

REACH – pozyskiwanie: są to wszystkie działania skierowane (1) na zachęcenie użytkowników do odwiedzenia naszej strony oraz (2) na zbudowanie wizerunku marki wśród grupy docelowej. Przykładowo tutaj wpadają wszystkie działania marketingowe w Internecie – reklamy tekstowe czy banery, które przekierowują użytkowników na naszą stronę. W tej grupie znajdą się również działania SEO oraz w Facebook jako źródła, z których przychodzą do nas użytkownicy.

ENGAGE – zaangażowanie: obejmuje swoim zakresem wszystkie interakcje użytkownika z naszą stroną i produktem, które mają mu pomóc w podjęciu decyzji o tym, czy jest zainteresowany tym, co mu oferujemy. Przykładowo dla stron produktowych może to być obejrzenie filmików prezentujących cechy sprzedawanego produktu, dla bloga będzie to przeczytanie najnowszych wpisów, które mają zachęcić użytkownika do subskrypcji.

ACTIVATE – aktywacja: oznacza, że użytkownik skonwertował, czyli dokonał działania, które jest głównym celem istnienia danej strony internetowej. Przykładowo może to być: zakup produktu, pozostawienie swoich danych kontaktowych czy zapisanie się na newsletter.

NURTURE – pielęgnowanie: są to wszystkie działania, które podejmujemy, aby utrzymać i ponownie aktywować naszych klientów. Przykładem takich działań mogą być karty stałego klienta czy specjalne rabaty na kolejne zakupy.

REAN obejmuje wszystkie fazy, w których znajduje się użytkownik w swojej drodze do spełnienia celów istnienia danej strony internetowej. Kompleksowe podejście modelu pozwala na zmapowanie, a następnie przeanalizowanie, wszystkich prowadzonych działań.

W trakcie warsztatów dzielimy tablicę na cztery części i na każdej z nich wpisujemy jeden z czterech elementów modelu:

W trakcie omawiania etapu REACH rozdajemy każdemu uczestnikowi warsztatu karteczki (najlepiej, aby każdy uczestnik miał inny kolor) i prosimy o wypisanie najważniejszych według nich źródeł pozyskiwania użytkowników. Gdy uczestnicy skończą wypisywanie źródeł ruchu – zbieramy karteczki, grupujemy według odpowiedzi i przyklejamy w odpowiednie miejsce na tablicy. Następnie rozmawiamy o wyborach naszych uczestników – nierzadko zdarza się, że uczestnicy mają bardzo odmienne zdania na temat, które ze źródeł ruchu są najbardziej popularne i najważniejsze dla ich biznesu.

W momencie, gdy temat się wyczerpie, przechodzimy do ENGAGE. W tym przypadku prowadzimy rozmowę z uczestnikami, w jaki sposób próbują zaangażować użytkowników, którzy już znaleźli się na ich stronie i przekonać ich do spełnienia głównego celu strony. Wszystkie odpowiedzi zapisujemy na tablicy.

W przypadku ACTIVATE postępujemy podobnie jak dla REACH – każdy uczestnik otrzymuje karteczki, na których ma wypisać cele strony. Główny cel, dla którego została stworzona strona, jest zawsze jasny dla wszystkich osób zaangażowanych w biznes. Inaczej wygląda sytuacja w przypadku celi pośrednich – takich, których spełnienie przez użytkownika przybliża go do spełnienia głównego celu strony. Przykładem celu pośredniego może być zapisanie się na newsletter z najnowszymi ofertami na stronie sprzedającej buty.

W przypadku omawiania NURTURE ponownie prowadzimy dyskusję z uczestnikami, jakimi sposobami starają się aktywować swoich dotychczasowych klientów. Nierzadko zdarza się, że ten etap interakcji z użytkownikiem jest najbardziej zaniedbany, a czasem nawet całkiem pominięty przy planowaniu działań marketingowych.

Zebranie wszystkich prowadzonych działań na jednej tablicy pozwala osobom pracującym przy danym biznesie na kompleksowe spojrzenie na prowadzone działania i zastanowienie się, czy wszystkie etapy modelu są adresowane w odpowiedni sposób.

Po zbudowaniu takiego modelu mamy pełną informację o tym, jakie działania są prowadzone przez zespół, jak również które z nich są postrzegane jako najistotniejsze.

Trzeci etap: pytania biznesowe

Trzeci etap warsztatów stanowią pytania biznesowe. Prosimy użytkowników, aby wymienili pytania dotyczące strony, na które chcieliby uzyskać odpowiedź. Chodzi o takie informacje, które pomogą im w podejmowanie decyzji i prowadzeniu swoich działań. Możemy również poprosić uczestników wcześniej, aby przed warsztatami przygotowali sobie taką listę pytań.

Głównym celem tego etapu jest zrozumienie, które informacje pochodzące ze strony są szczególnie istotne dla uczestników.

Warto jest poprosić uczestników, aby podawali wszystkie pytania, również te, na które myślą, że nie ma szansy uzyskać odpowiedzi. To już jest zadanie dla analityka w późniejszym etapie, aby sprawdzić, na które z zadanych pytań możemy uzyskać odpowiedzi. Przykładowo uczestnicy mogą chcieć wiedzieć, jaka pogoda była danego dnia, np. jeżeli sprzedają lody albo stroje kąpielowe na swojej stronie. Dzięki Google Tag Manager i odpowiedniej konfiguracji przekazanie tych danych do GA jest już możliwe, czego uczestnicy badań mogą nie wiedzieć.

Wszystkie pytania zapisujemy na tablicy.

Efekt – mnóstwo informacji o modelu biznesowym

Po tak przeprowadzonych warsztatach posiadamy wszystkie informacje, które są nam potrzebne do wypracowania KPI:

• • Znamy zakres obowiązków wszystkich osób pracujących w zespole,
  • Wiemy, jakie działania są obecnie prowadzone i które z nich są najistotniejsze,
  • Wiemy, jakich informacji potrzebują uczestnicy, aby podejmować decyzje dotyczące ich działań.

Kolejny etap należy do analityków, którzy na podstawie dostarczonych informacji przeprowadzą kategoryzację pytań biznesowych i wypracują wskaźniki, które następnie przydzielą do odpowiednich osób.

Dzięki kompleksowemu podejściu zapewnimy, że stworzone KPI będą odpowiadały specyfice biznesu i będą stanowiły podstawę do podejmowania decyzji biznesowych.

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

The post KPI – od czego zacząć? first appeared on Conversion.