Atrybucja konwersji – czym jest i dlaczego jest ważna?
Trzy główne rodzaje atrybucji konwersji
Kluczowe parametry: ekspozycja i okna konwersji
Problem z raportowaniem platform reklamowych
Dlaczego warto stworzyć własny model atrybucji?
Podsumowanie

Atrybucja konwersji – czym jest i dlaczego jest ważna?

Atrybucja konwersji pozwala określić, w jakim stopniu poszczególne kanały marketingowe przyczyniły się do osiągnięcia konwersji. W procesie analizy należy wziąć pod uwagę, czym dokładnie jest atrybucja konwersji, jakie czynniki na nią wpływają, jak różne narzędzia podchodzą do tego zagadnienia oraz jak stworzyć własny model atrybucji dopasowany do indywidualnych potrzeb firmy. W artykule przedstawiam podejście do modelowania atrybucji konwersji w oparciu o autorski model danych oraz praktyczne wskazówki dotyczące wdrożenia efektywnej analizy skuteczności poszczególnych źródeł ruchu.

Modelowanie atrybucji konwersji to złożony temat, który wymaga zrozumienia kilku podstawowych zagadnień. Atrybucja polega na przypisywaniu poszczególnym elementom procesu sprzedażowego określonych cech lub wartości. W kontekście analityki internetowej atrybucja oznacza przypisywanie konwersji konkretnym źródłom ruchu, działaniom marketingowym lub reklamom. Reklamy stanowią jedno z kluczowych „czemu”, którym przypisuje się wpływ na osiągnięcie konwersji. Skuteczne modelowanie atrybucji pozwala zidentyfikować, które działania marketingowe miały realny wpływ na decyzje zakupowe użytkowników. Dzięki temu można lepiej planować budżety reklamowe i optymalizować działania marketingowe w oparciu o twarde dane.

Na przykład podczas wizyty na stronie portalu horyzontalnego można od razu zauważyć dwie reklamy różnych marek. Konwersje można przypisać promocjom wewnętrznym lub reklamom zewnętrznym. Zakup konkretnego produktu, takiego jak smartfon, można przypisać do kilku miejsc: listingu wszystkich produktów marki, całej kategorii, a także do wyników wyszukiwania. W marketingu online można przypisywać różne wartości, takie jak przychód, wizyty czy określone akcje. Te aspekty przekładają się na różne poziomy analizy internetowej: poziom użytkownika, poziom sesji oraz poziom zdarzenia lub konwersji.

Atrybucja konwersji, o której mowa, to najbardziej powszechna metoda przypisywania konwersji do reklamy, z którą miał kontakt użytkownik. Przychód, transakcje lub szerzej – konwersje, przypisujemy do konkretnej reklamy, aby dokładnie policzyć zwrot z tej inwestycji. W marketingu kluczowe jest efektywne wydawanie budżetu i mierzenie efektów.

Trzy główne rodzaje atrybucji konwersji

Warto pamiętać, że istnieją trzy główne rodzaje atrybucji konwersji. Pierwszym z nich jest atrybucja konwersji offline to online lub online to offline. Przykładem takiej atrybucji jest efekt ROPO (Research Online, Purchase Offline). Na przykład, jadąc autostradą, możemy zobaczyć billboard reklamujący określony model samochodu. Następnie sprawdzamy szczegóły tego auta w internecie, umawiamy się na jazdę testową, a ostatecznie decydujemy się na zakup. Efekt ROPO oraz atrybucje offline–online i online–offline są mierzone za pomocą modeli Marketing Mix Modeling. W tego typu analizach wykorzystuje się ekonometrię oraz statystykę.

Drugi rodzaj atrybucji konwersji, z którym często spotykają się firmy, to atrybucja pomiędzy różnymi urządzeniami. Przykładem może być sytuacja, w której użytkownik przegląda produkt na smartfonie podczas podróży komunikacją miejską, a następnie w domu lub pracy kontynuuje research na komputerze i dokonuje zakupu. Kluczowe w tym przypadku jest rozpoznanie użytkownika na różnych urządzeniach. Obecnie technologia coraz lepiej wspiera ten proces.

Trzeci, najczęściej występujący rodzaj atrybucji konwersji dotyczy sytuacji, w której użytkownik korzysta z jednego urządzenia, ale przechodzi przez wiele kanałów komunikacji przed dokonaniem zakupu. Użytkownik często odwiedza witrynę kilka razy z tego samego urządzenia, zanim zdecyduje się na zakup. Liczba wizyt zależy od procesu zakupowego — od czasu, jaki potrzebuje na podjęcie decyzji od pierwszej wizyty do finalizacji zakupu, a także od liczby powrotów na stronę. Im produkt jest bardziej skomplikowany lub droższy, tym proces decyzyjny zwykle trwa dłużej. W analizie zachowań użytkowników warto uwzględniać te różnice, aby lepiej zrozumieć ścieżkę zakupową klientów.

Kluczowe parametry: ekspozycja i okna konwersji

Przed przejściem do modelowania atrybucji należy pamiętać, że w raportach, zwłaszcza tych pochodzących z platform reklamowych, analizujemy kilka istotnych parametrów konwersji. To one decydują o tym, jak przypisujemy przychód lub konwersję do konkretnego kanału czy źródła ruchu.

Pierwszym z nich są ekspozycje na reklamę. Istotne jest, w jaki sposób narzędzie raportuje interakcje użytkownika z reklamą. Możemy mówić o konwersji post-click, gdy użytkownik kliknął w reklamę, lub o konwersji post-view, gdy tylko ją zobaczył. Często pojawia się też pojęcie engaged view, czyli zaangażowanego obejrzenia reklamy, które platformy reklamowe traktują w różny sposób.

Drugim ważnym parametrem jest okno konwersji. Określa ono, ile czasu upłynęło od momentu ekspozycji na reklamę do dokonania konwersji. Różne platformy mogą stosować odmienne okna konwersji, co wpływa na sposób raportowania i interpretacji danych. Przykładowo, okno konwersji może wynosić siedem dni od momentu zobaczenia reklamy. Oznacza to, że konwersja zostaje przypisana, jeśli nastąpi w ciągu siedmiu dni od wyświetlenia reklamy. W przypadku kliknięcia w reklamę okno konwersji może trwać tylko jeden dzień. Różne narzędzia analizują te sytuacje w odmienny sposób.

Problem z raportowaniem platform reklamowych

Google Analytics integruje dane marketingowe i rozpoznaje konwersje po zdefiniowaniu celu lub wdrożeniu kodu śledzącego e-commerce. Analytics identyfikuje źródła ruchu na podstawie parametrów UTM oraz parametrów pochodzących z platform reklamowych (np. FBC Lead, gclid). Agencje mediowe i działy marketingu raportują jednak wyniki kampanii na podstawie danych z paneli poszczególnych platform reklamowych, które działają w oparciu o piksele śledzące.

Platformy reklamowe, takie jak Meta czy Google, dążą do maksymalnego przypisania sobie zasług za wygenerowaną sprzedaż. Każdy kanał i każda platforma, na której prowadzona jest reklama i wydawane są środki, chce wykazać, że inwestycja jest wartościowa. Warto zwrócić uwagę, że raporty przygotowywane przez agencje marketingowe lub osoby odpowiedzialne za konkretne kanały bardzo często — nawet nieświadomie — są niewłaściwie prezentowane.

Osoby zarządzające e-marketingiem w firmie otrzymują kilka raportów z różnych źródeł i napotykają na problem dublowania wyników. Przykładowo, każdy raport może wskazywać sprzedaż na poziomie 200, a po zsumowaniu wyników z poszczególnych raportów okazuje się, że łączna sprzedaż jest pięciokrotnie wyższa, niż rzeczywiście powinna być. Taka sytuacja prowadzi do błędnych wniosków na temat skuteczności poszczególnych kanałów i kampanii.

Dlaczego warto stworzyć własny model atrybucji?

Odpowiednie modelowanie atrybucji oraz analiza danych w jednym, spójnym ekosystemie pozwalają uniknąć rozbieżności i podejmować trafne decyzje biznesowe. Zadaniem przy tworzeniu modelu atrybucji jest rozłożenie przychodów od jednego użytkownika na poszczególne media, które przyprowadziły tego użytkownika. Nie można założyć, że ścieżka jest zawsze liniowa. Takie podejście jest niezbędne, aby prawidłowo policzyć ROI i ROAS (Return on Adspend).

Każde narzędzie raportujące posiada własne modele atrybucji. Największym wyzwaniem w przypadku większości platform reklamowych pozostaje ich nieprzejrzystość – często działają jak „czarne skrzynki”. Przykładem może być model data-driven, który z definicji powinien być najbardziej efektywny, jednak brak jasności co do jego działania sprawia, że trudno w pełni zaufać takim rozwiązaniom. Warto zatem opracować własny model atrybucji, który zapewni pełną kontrolę nad sposobem przypisywania konwersji.

Wykorzystanie Google BigQuery

W pracy z klientami wykorzystujemy gotowy model danych. Stworzenie własnego modelu nie jest możliwe w interfejsie żadnego standardowego narzędzia analitycznego. Konieczne jest skorzystanie z danych granularnych, które zapewnia Google BigQuery. Dane te powinny być przedstawione w formie czytelnych ścieżek konwersji. Dopiero na ich podstawie możliwe jest zdefiniowanie konkretnych reguł przypisywania konwersji. Efektem końcowym jest raport, który pozwala porównywać różne modele atrybucji, na przykład First Leaf Cleaner i Last Non-Direct.

Model danych Conversion

W pracy z naszymi klientami wykorzystujemy gotową logikę, która łączy dane reklamowe z różnych platform oraz clickstream. Stosujemy własne zasady przypisywania źródeł ruchu, analizując parametry UTM i dane z platform reklamowych. Przeprowadzona przez nas analiza wykazała, że panel Google Analytics 4 często niepoprawnie przypisuje źródła ruchu. Przykładowo, po wdrożeniu autorskiego modelu, 33% ruchu wcześniej klasyfikowanego jako Direct zostało poprawnie przypisane do innych źródeł, a udział Google Ads wzrósł o 10%.

W naszym modelu danych zastosowano logikę techniczną, która standaryzuje źródła ruchu. Analizując listę wszystkich źródeł ruchu dostępnych w interfejsie GA4, widać, że z trzech podstawowych parametrów powstaje kilkanaście różnych kombinacji. Dodatkowo nasz model rozpoznaje ruch fraudowy. Jeśli wykryjemy fraudy, wykluczamy je z atrybucji. Wyklikiwanie reklam przez boty nie powinno wpływać na ocenę efektywności kampanii.

W modelu uwzględniamy także logikę biznesową. Analizujemy różne rodzaje ekspozycji, korzystając z domyślnych ustawień lub dodając własne warunki. To elastyczne podejście pozwala odpowiadać na pytania zarządu dotyczące przyjętych założeń i umożliwia szybką modyfikację modelu danych. Model customowy pozwala decydować, czy atrybucja opiera się na danych historycznych, czy na podejściu position based.

Podsumowanie

Własny model atrybucji rozwiązuje nie tylko problem odpowiedniego przypisania źródła ruchu czy właściwego obliczenia zwrotu z inwestycji w poszczególne kanały. Największym wyzwaniem, które obserwuję w wielu firmach, jest niezrozumienie tego, co faktycznie jest raportowane. Każda platforma reklamowa prezentuje własną wersję rzeczywistości, jednak prawdziwy obraz powinien wynikać z indywidualnych potrzeb biznesowych. Platformy reklamowe zawsze będą pokazywać dane korzystne ze swojej perspektywy, więc warto odnosić się do danych płynących bezpośrednio z biznesu.

Własny model atrybucji można stworzyć samodzielnie, korzystając z dostępnych poradników oraz narzędzi takich jak Google BigQuery. Można też skorzystać z gotowego modelu atrybucji, jaki oferujemy w Conversion. Nasze narzędzie pozwala od razu uzyskać rzeczywisty ROAS i ROI dla kampanii marketingowych, co znacząco ułatwia podejmowanie decyzji.

Dzięki spójnemu raportowaniu suma wyników z poszczególnych kanałów zawsze pokrywa się z danymi widocznymi w wewnętrznych systemach firmy. Pozwala to precyzyjnie kontrolować efektywność działań marketingowych i opierać decyzje o inwestycjach na rzetelnych danych. W przypadku pytań lub zainteresowania współpracą zapraszamy do kontaktu.

The post Własny model atrybucja, czyli wszyscy kłamią: Google, Meta czy TikTok. first appeared on Conversion.

Z pewnością nie możemy narzekać na stagnację w świecie analityki internetowej w ostatnich miesiącach. W świetle reflektorów znajdowały się kwestie prywatności oraz “propozycji nie do odrzucenia” ze strony Google’a w temacie migracji z Universal Analytics’a na GA4. We wspomnianych zagadnieniach chyba już wszystko zostało powiedziane. Dlatego dzisiaj na warsztat weźmiemy rozwiązanie, o którym ucichło w ostatnim czasie i nadal nie jest wykorzystywane na większą skalę. Mowa tutaj o Google Tag Manager Server-Side.

Co znajdziesz w tym artykule?
Czym jest GTM Server-Side?
GTM Client-Side vs. Server-Side
Przypadki użycia GTM Server Side
Quo Vadis, GTM?
Nie wszystko złoto, co się świeci… – kilka wad Google Tag Managera Sever-Side
Etapy, przez które musimy przejść w celu uzyskania nowych supermocy
Narzędzie GTM Server-Side – podsumowanie

Czym jest GTM Server-Side?

GTM Server-Side to rozwiązanie od Google’a w zakresie menadżera tagów, które wyprowadza standard śledzenia oraz przekazywanie danych na znacznie wyższy poziom, dając nam tym samym nowe możliwości. W jaki sposób i o co w tym wszystkim chodzi? Tego dowiesz się z tego artykułu!

GTM Client-Side vs. Server-Side

“Nie dość, że muszę się przesiąść na nowy Google Analytics to to samo czeka mnie w przypadku GTM-a?”. Na wstępie uspokajamy – klasyczny Google Tag Manager (client-side) nadal będzie potrzebny, bo to właśnie jego należy zintegrować z GTM Server-Side. Oczywiście, o ile się na to zdecydujesz.

Na początek w skrócie wyjaśnijmy sobie różnice pomiędzy sposobami tagowania: client-side (na nim opiera się klasyczny GTM) oraz server-side. Dotychczas działało to w taki sposób, że mieliśmy ustawiony jakiś tag np. zdarzenie pixela Meta (dawniej Facebook). Po wywołaniu takiego tagu, request zawierający dane o zdarzeniu był przesyłany bezpośrednio do Meta. Poniżej zamieszczamy schemat, który powinien ułatwić zrozumienie opisanej sytuacji.

Tradycyjna konfiguracja strony – GTM Client-Side. Źródło: developers.google.com

W przypadku GTM-a Server-side pojawia się dodatkowy podmiot, który jest odpowiedzialny za zbieranie danych z wywołanych tagów na poziomie kontenera webowego i rozdysponowanie ich do innych narzędzi m.in Google Analytics, Google Ads, czy Meta. Można powiedzieć, że kontener serwerowy to nasz “anioł stróż”, który odpowiada za bezpieczeństwo naszych danych.

Konfiguracja strony przy użyciu GTM Server-Side. Źródło: developers.google.com

Na powyższym schemacie pojawił się “Client” w serwerowym kontenerze. Służy on do odbierania sygnałów (wywołanych tagów) z kontenera webowego. To wszystko może brzmieć dość skomplikowanie, ale wbrew pozorom takie nie jest. Jednak zanim pomyślimy o wdrożeniu tego rozwiązania, warto wiedzieć, dlaczego powinniśmy je rozważyć…

Przypadki użycia GTM Server Side

GTM Server Side sprawdza się tam, gdzie klasyczne tagi przestają wystarczać – np. do konsolidacji wielu źródeł danych (web, CRM, backend) w jednym miejscu, zanim rozdzielisz je do narzędzi analitycznych. Dzięki temu zyskujesz większą elastyczność w transformacji i filtrowaniu danych, a także możliwość sterowania, które fragmenty informacji trafią dalej, a które zatrzymasz lub usuniesz. To użyteczne zwłaszcza w środowiskach wielokanałowych.

Optymalizacja śledzenia konwersji

W kontekście konwersji, server-side tagging pozwala ominąć blokady typu ad blocker czy ograniczenia przeglądarkowe (ITP), co często skutkuje nawet 5-30% wzrostem liczby zarejestrowanych zdarzeń. Dodatkowo możesz wprowadzać logikę atrybucji lub „odświeżać” cookies na serwerze, co wydłuża okno atribucji i umożliwia lepsze przypisanie sprzedaży zwłaszcza w kampaniach z długim cyklem decyzyjnym.

Integracja z narzędziami analitycznymi

Po stronie serwera łatwiej jest integrować różne systemy – na przykład przekazywać dane z GTM do GA4, Meta (przez Conversion API), Piwik PRO czy nawet własnych systemów raportowych – z jednego punktu kontrolnego. W praktyce możesz zbudować logiczne „switchboard” danych: filtruj, wzbogacaj, anonimizuj – i kieruj odpowiednie zestawy danych do właściwych narzędzi, bez dublowania kodów po stronie klienta.

Quo Vadis, GTM?

Na początek zastanówmy się dlaczego powstał taki produkt, jak GTM Server-Side. Z pewnością nowa odsłona Google Tag Manager jest odpowiedzią na coraz większe ograniczeniach w śledzeniu użytkowników po stronie przeglądarek np. ITP (Intelligent Tracking Prevention) w Safari. Zmiany obejmują również blokowanie tzw. ciasteczek obcych (third-party cookies), co będzie skutkowało ograniczeniem śledzenia po stronie narzędzi zewnętrznych m.in. wspomniana już wcześniej Meta. Problem ten zostaje rozwiązany w taki sposób, że wysyłane request’y do naszego serwera są traktowane jako first-party cookie. Oczywiście, aby tak się stało należy skonfigurować customową domenę (temat zostanie poruszony w dalszej części artykułu).

Rozwiązanie opisanych ograniczeń, które pojawiły się wraz ze zwiększoną troską o prywatność użytkowników to nie jedyna zaleta. Poniżej przedstawiamy inne plusy tego rozwiązania:

• Zwiększona kontrola nad przesyłanymi danymi – zyskujemy możliwość decydowania o tym, jakie informacje zostaną dalej przesłane. Przykładowo GTM Server-Side odbiera request, który zawiera wrażliwy parametr, którego nie chcemy udostępniać podmiotom trzecim. Omawiane rozwiązanie pozwala usunąć lub zmodyfikować niepożądany parametr przed przesłaniem danych do kolejnych dostawców.
• Obrona przed Adblock’ami – wraz ze wzrostem świadomości użytkowników możemy zaobserwować popularyzację rozwiązań blokujących śledzenie użytkowników. Standardowo te produkty są nastawione na blokowanie third-party cookies, dlatego gdy nasze żądania są traktowane jako first-party, takowy AdBlock nie zatrzyma naszego śledzenia.
• Poprawa czasu wczytywania strony – zdajemy sobie sprawę jakim jest to istotnym aspektem pod kątem user-experience. Poprzez ograniczenie skryptów podmiotów trzecich nasza strona będzie mniej obciążona, co może korzystnie wpłynąć na czas wczytywania strony. Dodatkowo, dużym atutem GTM-a Server-Side jest to, że możemy na podstawie odebranego, jednego request’a rozdysponować dane do kilku innych podmiotów.
• Wzbogacanie danych – oprócz modyfikowania na danych na poziomie jednego źródła, możemy je łączyć z danymi z innego źródła przed ostatecznym przesłanie ich do jakiegoś dostawcy. Przykładem może być połączenie danych z Google Analytics z danymi z CRM, a następnie przesłanie pełniejszego obrazu do danego dostawcy.

Nie wszystko złoto, co się świeci… – kilka wad Google Tag Managera Sever-Side

Można się zastanawiać “skoro to rozwiązanie rozstrzyga tych kilka bieżących problemów to dlaczego jest tak stosunkowo mało popularne pod kątem wdrożeń”? Produkt jest już na rynku od około dwóch lat, a fazę beta opuścił na przełomie września i października 2021 r. Pomimo tego, rzadko możemy spotkać zaimplementowane to rozwiązanie nawet u dużych klientów. Z czego to wynika? Omówmy kilka wad/trudności związanych z tym rozwiązaniem:

• • Koszty utrzymania – jak mówi słynne przysłowie “jeśli nie wiadomo, o co chodzi to chodzi o pieniądze”. O ile samo utworzenie GTM Server-Side nic nie kosztuje, o tyle utrzymanie serwerów w środowisku chmurowym Google już tak. Standardowa implementacja opierająca się na App Engine to koszt 30-40$ miesięcznie za instancję. Zazwyczaj rekomendowane jest włączenie minimum 3 instancji (domyślnie 3-6 z autoscaling’iem), co potraja ten wydatek. Oczywiście, można na własną rękę przetestować mniejszą liczbę instancji i sprawdzić, jak będzie się ona sprawdzać pod kątem wydajność i wyrzucanych błędów.
    Jeżeli powyższe koszty Cię przestraszyły to na ratunek przychodzi alternatywne rozwiązanie oparte o Cloud Run. Ta opcja wyróżnia się możliwością skalowania, która zazwyczaj przekłada się na niższe koszty. Rozwiązanie jest polecane zwłaszcza dla stron cechujących się mniejszym obciążeniem (ilością przesyłanych hitów). W przypadku serwisów, na których “sporo się dzieje” może okazać się, że “stałe koszty” App Engine mogą być bardziej opłacalne niż koszty Cloud Run za rzeczywiste wykorzystanie zasobów.
  • Ograniczona liczba zasobów partnerów – jeżeli jesteśmy zaznajomieni z klasycznym GTM-em to patrząc na listę dostępnym template’ów pod konfigurację tagów w Server-Side, możemy stwierdzić, że jest ona dość uboga i tak naprawdę zawiera tylko zasoby od Google’a (oprócz HTTP Request).
    Jednak po wejściu do “Community Template Gallery” mamy dostęp do zasobów, które pozwalają przesyłać dane m.in. do Facebook’a, czy TikTok’a. Należy tutaj wykazywać się ostrożnością… Zanim skorzystamy z danego rozwiązania powinniśmy je zweryfikować np. poprzez sprawdzenie, kto zrealizował dany projekt.

Lista dostępnych template’ów pod konfigurację tagów. Źródło: developers.google.com

• Ograniczona wiedza techniczna – nie ma co się oszukiwać, że to środowisko jest bardziej skomplikowane niż GTM Client-Side. Zwłaszcza, że do starszego rozwiązania już się przyzwyczailiśmy i co niektórzy mogliby je “wyklikiwać” z zamkniętymi oczami. Tutaj na barki analityków są wkładane nowe obowiązki, takie jak konfiguracja środowiska chmurowego, ustawienie i zmapowanie nowej subdomeny, czy nowy standard konfiguracji z poziomu GTM-a, z którym trzeba się zaznajomić.
  Na pocieszenie mamy dostęp do szczegółowej dokumentacji od Google’a oraz do przynajmniej kilku wartościowych tutoriali, które znacznie ułatwią wejście w ten nowy świat.

Etapy, przez które musimy przejść w celu uzyskania nowych supermocy

1. Utworzenie kontenera GTM Server-Side

Ten etap możemy uznać za zdecydowanie najłatwiejszy. W momencie, w którym zdecydujemy się na utworzenie nowego kontenera wystarczy przejść na zakładkę “Administracja” i na poziomie kontenera kliknąć “+”. Po takiej interakcji pojawi się okno, w którym możesz wybrać rodzaj kontenera.

Jak utworzyć kontener GTM Server-Side?

Następnie możesz skorzystać z automatycznego skonfigurowania serwera tagowania. Po wybraniu tej opcji pojawi się zapytanie o konto rozliczeniowe na Google Cloud Platform, co oznacza rozpoczęcie 2. etapu…

2. Utworzenie konta GCP oraz konfiguracja sposobu płatności

Jeżeli jeszcze nie masz konta Google Cloud Platform, co oznacza, że nie było możliwości podłączenia płatności w poprzednim kroku i tym samym utworzenia projektu to będziesz zmuszony zrobić to teraz. W Internecie znajduje się wiele poradników jak to zrobić, dlatego w tym artykule nie będziemy tego zgłębiać.

Po utworzeniu konta i podłączeniu płatności możesz dokończyć konfigurację GTM-a Server-Side.

Jak utworzyć konto GCP oraz skonfigurować płatności?

Proces tworzenia po stronie systemu może zająć co najmniej kilka minut, dlatego zanim go przetestujesz musisz uzbroić się w cierpliwość.

3. Przygotowanie i przetestowanie pierwszych tagów

Jeżeli już masz ustawione odpowiednie tagi w GTM-ie Client-Side to proces możesz zacząć od stworzenia odpowiedniego Client’a z poziomu Server-Side, który będzie odbierał sygnały z klasycznego GTM-a. Zostanie on również wykorzystany w regule wywoływania tagów przekazujących dane do konkretnych narzędzi.

Tak wygląda lista dostępnych domyślnych Client’ów:

Lista dostępnych domyślnych Client’ów z poziomu GTM Server-Side.

Przykładowo możemy wybrać GA4. Jako regułę wywoływania tagu możemy ustawić “Niestandardowe”, a następnie ustawić warunek “Client Name” zawiera/równa się “GA4”

Konfiguracja Clienta w GTM Server-Side.

W tym przykładzie ostatnim elementem będzie utworzenie tagu.

Tworzenie tagów w GTM Server-Side.

Teraz musimy wrócić do naszego GTM-a Client-Side i włączyć przesyłanie danych do serwerowego kontenera:

Włączenie opcji przesyłanie danych.

Oprócz tego, podstawiamy URL dla serwera kontenerowego. Jeżeli jeszcze nie działałeś w kwestii zmiany customowej domeny to możesz podstawić domyślny URL wygenerowany przy tworzeniu kontenera – tryb testowy w App Engine. Możesz go znaleźć w głównym widoku swojego Server-Side po kliknięciu ID kontenera (GTM-xxx) na pasku nawigacyjnym. Tam znajduje się pole o nazwie “Domyślny adres URL”. Po podstawieniu tego URL-a w tagu na kontenerze Client-Side możemy go zapisać i rozpocząć debuggowanie, poprzez włączenie trybu podglądu na obu kontenerach. Dodatkowo, możesz to zweryfikować po stronie konsoli oraz w request’ach na poziomie App Engine.

Warto dodać, że taka konfiguracja pozwala na przechwytywanie wszystkich zdarzeń z Google Analytics 4.

4. Włączenie instancji produkcyjnych oraz konfiguracja customowej domeny

W przypadku włączenia instancji produkcyjnych będziemy musieli skorzystać z konsoli na poziomie GCP zwanej “Cloud Shell”. Po wprowadzeniu kilku komend będziemy mogli uruchomić nasze instancje produkcyjne. Pojawią się pytania m.in czy chcemy włączyć autoscalling oraz w przypadku wyrażenia zgody o minimalną i maksymalną liczbę instancji. W witrynie Google Developers znajduje się dokładny opis, jakie komendy należy wprowadzić: https://developers.google.com/tag-platform/tag-manager/server-side/script-user-guide

Na poziomie ustawień App Engine możemy również skonfigurować customową domenę (o zaletach wspominaliśmy już wcześniej). Będziemy musieli ustawić nazwę subdomeny, do której będą wysyłane request’y. Wymagana będzie również weryfikacja własności do danej subdomeny. Na sam koniec należy zaktualizować rekordy DNS, zgodnie z instrukcją występującą podczas konfiguracji.

Narzędzie Server side tagging od Google – podsumowanie

W rzeczywistości, w której spotykamy się z coraz większymi restrykcjami pod kątem śledzenia użytkowników, wydaje się, że to narzędzie może nas wynieść na wyższy poziom analityczny. Oczywiście, wiąże się ono z dodatkowymi kosztami. Jednak sam musisz zdecydować, czy wartość, którą wnosi jest godna poniesionych “strat”. Z pewnością będziemy oczekiwać na nowe udoskonalenia np. template’y, które pozwolą bezpośrednio przekazywać dane do innych systemów.
Zachęcam również do zainteresowania się tym tematem, aby obyło się bez niepotrzebnych stresów, kiedy obudzimy się w świecie totalnie odciętym od third-party cookies.

Mamy nadzieję, że udało mi się przekonać Cię do przetestowania tego rozwiązania! Jeśli zastanawiasz jak wykorzystać te narzędzia w Twojej firmie – pogadajmy!

The post Server side tagging – czym jest i jak działa? first appeared on Conversion.

Czym jest Google Tag Manager Server-side (ssGTM)?
Główne korzyści z wdrożenia GTM Server-side
Jak GTM Server-side wpływa na proces zbierania danych i infrastrukturę?
Kto powinien rozważyć wdrożenie GTM Server-side?
GTM Server-side krok po kroku – jak wdrożyć?
GTM Server-side a prywatność, RODO i dokładność danych
Najczęstsze błędy przy konfiguracji ssGTM
Podsumowanie

Czym jest Google Tag Manager Server-side (ssGTM)?

Google Tag Manager Server-side, w skrócie GTM Server-side lub ssGTM, to technologia umożliwiająca zbieranie danych po stronie serwera. Wszystkie żądania wysyłane do narzędzi zewnętrznych, szczególnie do narzędzi marketingowych czy pikseli śledzących, nie są wysyłane bezpośrednio z przeglądarki użytkownika. Najpierw trafiają na serwer, skąd są przekazywane dalej.

Dotychczas, w tradycyjnym podejściu, żądania trafiały bezpośrednio z przeglądarki użytkownika do zewnętrznych narzędzi. Warto przyjrzeć się temu procesowi na konkretnym przykładzie. W poniższej analizie wykorzystam serwis modivo.pl. Korzystając z konsoli przeglądarki oraz zakładki „Sieć”, można zobaczyć wszystkie interakcje serwisu z domenami zewnętrznymi. Po przeładowaniu strony modivo.pl pojawiają się różne połączenia z zewnętrznymi serwisami, takimi jak Adform.net, Analytics Tik-Tok, Google Ads czy DoubleClick. Są to żądania wychodzące z przeglądarki użytkownika do domen trzecich, szczególnie do narzędzi analitycznych i marketingowych.

Zawężając te żądania tylko do tych związanych z Google Analytics, widać funkcję “Collect”. W tym przypadku można zauważyć żądania wysyłane do region1.analytics.google.com. Wśród żądań sieciowych pojawiają się nie tylko te kierowane do google.com, ale również żądania wysyłane do domeny d-api.modivo.pl. Pierwsze żądanie, szczególnie w przypadku Google Analytics, wychodzi z przeglądarki do serwera Modivo, a domeną docelową jest d-api.modivo.pl. Na modivo.pl wdrożono śledzenie serwerowe, gdzie informacje trafiające do serwera są odpowiednio przetwarzane, a następnie przekazywane dalej – w tym przypadku do Google Analytics. GTM Server-side to instancja Google Tag Managera zainstalowana na serwerze, która obsługuje cały ruch przesyłany z przeglądarki użytkownika. Na poziomie serwera osoba odpowiedzialna za wdrożenie decyduje, jakie informacje i w jakiej formie trafią do narzędzi zewnętrznych.

Szczegółowe wyjaśnienie działania GTM Server-side znajduje się w osobnym materiale, do którego link zamieszczono w opisie. Materiał ten wyjaśnia zależności pomiędzy klientem (przeglądarką), serwerem oraz wykorzystywanymi narzędziami marketingowymi.

Główne korzyści z wdrożenia GTM Server-side

Wśród najczęściej pojawiających się pytań dotyczących GTM Server-side przewija się kwestia głównych korzyści tego rozwiązania. Wśród najważniejszych korzyści warto wymienić bezpieczeństwo danych. W przypadku przesyłania wrażliwych informacji do narzędzi zewnętrznych, kluczowe znaczenie ma optymalizacja kampanii w oparciu o marżę czy zysk z produktu, a nie jedynie przychód. Brak śledzenia po stronie przeglądarki sprawia, że marża nie jest przekazywana bezpośrednio, co chroni firmę przed ujawnieniem jej poziomu na rynku. Marża zostaje dołączona na poziomie serwera i dopiero wtedy przesyłana do narzędzi marketingowych.

Bezpieczeństwo danych dotyczy również wzbogacania informacji marketingowych o wartości wrażliwe, takie jak marża czy LTV (życiowa wartość klienta). Dodatkowo, rozwiązanie to pozwala na filtrowanie i anonimizację danych już na poziomie serwera. Dzięki temu możliwa jest pełna kontrola nad tym, jakie informacje są przekazywane do narzędzi trzecich, co ułatwia spełnienie wymagań RODO. Pierwszym aspektem jest bezpieczeństwo. Kolejnym czynnikiem jest szybkość ładowania witryny. Nie ma potrzeby wdrażania wszystkich pikseli po stronie kodu śledzącego, szczególnie w Google Tag Manager Client-side. Im więcej kodów, tym dłużej przeglądarka je przetwarza, co wpływa na wydłużenie czasu ładowania strony. Na szybkość ładowania wpływa również liczba komunikacji, jakie przeglądarka użytkownika nawiązuje z serwerami zewnętrznymi. Każda taka komunikacja, nawet jeśli trwa tylko milisekundy, sumuje się i może prowadzić do zauważalnych opóźnień.

W praktyce, korzystając z rozwiązania server-side, tylko jedna informacja wychodzi z przeglądarki użytkownika do serwera, a następnie to serwer przejmuje obsługę i rozsyła dane do poszczególnych narzędzi. Trzecim argumentem, który przemawia za wdrożeniem Google Tag Manager Server-Side, jest poprawa efektywności kampanii marketingowych. Przekazywanie marży zamiast przychodu pozwala na skuteczniejszą optymalizację kampanii reklamowych. Dzięki temu działania marketingowe koncentrują się na maksymalizacji zysku, a nie jedynie na wzroście przychodów, co jest kluczowe z perspektywy firmy.

Wdrożenie Serversite umożliwia korzystanie z ciasteczek First Party zamiast Third Party Cookies. To szczególnie istotne, ponieważ niektóre przeglądarki, zwłaszcza Safari na iOS, wykorzystują systemy ochrony prywatności, które znacznie skracają czas życia ciasteczek zewnętrznych. Wykorzystując GSM, można wydłużyć żywotność ciasteczek, co ułatwia skuteczne śledzenie użytkowników i pozwala lepiej rozumieć ich zachowania w świecie marketingu.

Kolejną zaletą jest dokładniejsze śledzenie użytkowników. Rozwiązania takie jak Serversite pozwalają zminimalizować wpływ adblocków, które blokują niektóre dane przesyłane z przeglądarki. Dzięki temu uzyskujemy pełniejszy obraz skuteczności kampanii i zachowań użytkowników na stronie. Jeśli zakodujemy wszystkie potrzebne informacje, które trafiają na serwer, na przykład w przypadku Modivo jest to domena wewnętrzna Modivo, d-api, a nie domena DoubleClick, to na poziomie serwera można dalej przesyłać te dane. Dzięki temu informacje rzadziej są blokowane, a narzędzia zewnętrzne, szczególnie analityczne, nie tracą dostępu do danych.

Dokładniejsze śledzenie wynika również ze zwiększenia żywotności ciasteczek. Niektóre przeglądarki, takie jak Safari, ograniczają żywotność ciasteczek do 7 dni. Przy odpowiedniej konfiguracji można jednak wydłużyć ten czas nawet do 18 miesięcy.

Jak GTM Server-side wpływa na proces zbierania danych i infrastrukturę?

Często pojawia się pytanie, jak działa proces zbierania danych w GTM Server-side. Kluczową zasadą działania Server-side jest to, że przeglądarka użytkownika nie odpowiada już za wysyłanie informacji analitycznych i marketingowych do różnych narzędzi. Zamiast tego z przeglądarki wychodzi jedna paczka wszystkich informacji do serwera, a następnie na poziomie serwera dane są rozsyłane dalej. GTM Server-side wymaga dodatkowej infrastruktury, czyli serwera, na którym uruchamiana jest instancja GTM Server-side. Najczęściej wdrażamy GTM Server-side w ramach Google Cloud Platform, korzystając głównie z usługi Cloud Run. Standardowo można wykorzystać również instancję App Engine, jednak przy dużym ruchu takie rozwiązanie staje się nieskalowalne.

W portfolio Conversion znajdują się także wdrożenia na innych platformach chmurowych, takich jak Microsoft Azure – konkurencyjne rozwiązanie wobec Google Cloud Platform – oraz AWS, czyli chmura Amazon. Dzięki temu możliwe jest dopasowanie infrastruktury do indywidualnych potrzeb i preferencji klientów.

Kto powinien rozważyć wdrożenie GTM Server-side?

Wdrożenie Google Tag Manager Server-side warto rozważyć przede wszystkim w branży e-commerce oraz w dużych firmach prowadzących działalność online. Rozwiązanie to adresuje potrzeby biznesów, którym zależy na bezpiecznym, precyzyjnym i odpornym na blokady systemie śledzenia. GTM Server-side sprawdza się szczególnie tam, gdzie istotne są ograniczenia związane z blokadami cookies w przeglądarkach oraz coraz bardziej zaawansowane mechanizmy ochrony prywatności.

Firmy decydują się na wdrożenie GTM Server-side, gdy chcą przesyłać bardziej wrażliwe dane biznesowe, na przykład informacje o marżach. Rozwiązanie to polecane jest także dla organizacji z rozbudowanym, długim procesem zakupowym, gdzie kluczową rolę odgrywa remarketing.

Szczególne znaczenie GTM Server-side zyskuje w przypadku serwisów, których użytkownicy korzystają głównie z przeglądarek Apple, takich jak Safari czy urządzeń z systemem iOS. Te platformy znane są z restrykcyjnego podejścia do ochrony prywatności, przez co ciasteczka mają bardzo krótki okres ważności. W efekcie, przy długim procesie zakupowym, trudniej zidentyfikować powracającego użytkownika. GTM Server-side pozwala na skuteczniejsze zarządzanie danymi i lepsze śledzenie ścieżki klienta, co przekłada się na efektywniejsze działania marketingowe i analityczne.

GTM Server-side krok po kroku – jak wdrożyć?

Jak wdrożyć GTM Server-side krok po kroku? Proces składa się z czterech głównych etapów.

Pierwszym krokiem jest audyt obecnego śledzenia w GTM Client-side, czyli tego, które wysyła dane marketingowe i analityczne z poziomu przeglądarki użytkownika. Celem audytu jest mapowanie wszystkich tagów, reguł i zmiennych, które powinny być dalej przekazywane. Często okazuje się, że większość tych elementów jest niepotrzebna lub nieużywana. To dobry moment, aby odchudzić kontener Client-side, co pozytywnie wpływa na szybkość ładowania serwisu.

Drugim krokiem jest wybór rozwiązania serwerowego. Należy zdecydować, czy wdrożenie będzie oparte o Cloud Run, najprostszy App Engine, czy inne narzędzie obsługujące serwerową wersję GTM. Gdy decyzja zostanie podjęta, można przejść do konfiguracji wybranej instancji serwerowej. W trzecim kroku śledzenie przenoszone jest z Client-side na server-side. Czwarty krok to testowanie i weryfikacja, czy śledzenie działa prawidłowo. To cztery kroki, które z pozoru wydają się proste, jednak wymagają czasu na realizację.

GTM Server-side a prywatność, RODO i dokładność danych

Pojawia się pytanie: czy GTM Server-Side zastępuje klasyczny GTM Client-side, czyli wdrożenie z poziomu przeglądarki? GTM Server-side nie zastępuje rozwiązania Client-side. Informacje o użytkowniku muszą zostać najpierw zebrane w przeglądarce i przesłane do serwera. GTM Server-side jest kolejnym etapem po GTM Client-side. Standardowy GTM Client-side zbiera dane i wysyła paczkę informacji do serwera, a następnie po stronie serwera następuje dalsze przetwarzanie i przekierowanie tych informacji. Client-side i Serve-Side to bezpłatne rozwiązania. Pojawia się jednak kwestia kosztów korzystania z GTM Server-Side. W przypadku Client-side, poza samą konfiguracją i przeniesieniem śledzenia, obsługa Server-Side wymaga większych kompetencji technicznych. Przekłada się to na wyższy koszt obsługi. Dodatkowo pojawia się koszt utrzymania serwera – to serwer przejmuje wysyłanie informacji, a jako wirtualna maszyna generuje opłaty.

Szczegółowe informacje o kosztach można znaleźć w dedykowanych materiałach, gdzie przedstawiono konkretne wyliczenia.

Kolejną ważną kwestią jest wpływ GTM Server-Side na prywatność i zgodność z RODO. W Client-side implementujemy na stronie skrypt, np. piksel śledzący, który automatycznie zbiera dane z serwisu i przesyła je do narzędzi firm trzecich. W tym modelu nie mamy pełnej kontroli nad tym, jakie informacje trafiają do tych narzędzi. Z perspektywy RODO kluczowa jest pełna kontrola nad danymi, które są wysyłane. W przypadku wykorzystania Google Tag Managera w wersji serwerowej ta kontrola jest znacznie większa. Pozwala to na anonimizację danych osobowych, które trafiają do serwerów firm trzecich, takich jak Meta czy Google. Dodatkowo można ograniczyć przesyłanie nadmiarowych informacji, które nie są istotne z perspektywy prowadzonych kampanii. Firmy trzecie i wydawcy reklam często gromadzą te dane i wykorzystują je na własny użytek. GTM Server-side wpływa na dokładność danych analitycznych na kilka sposobów.

Po pierwsze, ogranicza wpływ AdBlocków na zbieranie danych, szczególnie w przypadku Google Analytics. AdBlocki zazwyczaj blokują ruch rozpoznając charakterystyczne fragmenty kodu wysyłane bezpośrednio z przeglądarki użytkownika. W rozwiązaniu serwerowym dane trafiają najpierw na nasz serwer, gdzie mogą zostać zanonimizowane lub zaszyfrowane, a następnie przekazane dalej do narzędzi analitycznych. Dzięki temu ryzyko zablokowania informacji przez AdBlocki jest znacznie mniejsze.

Kolejną korzyścią jest możliwość wzbogacenia danych trafiających do analityki o informacje z wewnętrznych systemów firmy. Najczęściej są to dane kosztowe, dotyczące marży na produktach lub informacje o segmentach użytkowników. Dzięki temu możliwa jest bardziej szczegółowa analiza oraz lepsza segmentacja danych, co przekłada się na skuteczniejsze wyciąganie wniosków i podejmowanie decyzji biznesowych. W przypadku kilku serwisów często pojawia się pytanie, czy dla każdego z nich należy budować osobny kontener serwera Google Tag Manager (GTM). To zagadnienie z obszaru bardziej zaawansowanych konfiguracji, wymagające indywidualnego podejścia. Budowa osobnego serwerowego GTM dla każdego serwisu na różnych domenach może wpłynąć na koszty utrzymania środowiska chmurowego. Każda domena wymaga wtedy własnego serwera, co zwiększa złożoność i wydatki związane z infrastrukturą.

Dla jednego z klientów, dużej organizacji z wieloma domenami, przygotowaliśmy studium przypadku, w którym zarekomendowaliśmy pozostanie przy jednym serwerze. Każda sytuacja wymaga jednak indywidualnej analizy – nie istnieje uniwersalne rozwiązanie.

Najczęstsze błędy przy konfiguracji ssGTM

Warto również omówić najczęstsze błędy popełniane przy konfiguracji ssGTM (Server-Side Google Tag Manager).

#1 Problem z czyszczeniem list remarketingowych

 
Podczas migracji z Client-side do Server-side często obserwujemy problem z czyszczeniem list remarketingowych. Wynika to z natychmiastowej migracji ciasteczek z warstwy klienckiej na serwerową, co prowadzi do utraty ciągłości remarketingu.

#2 Zła lokalizacja serwera

 
Kolejnym częstym błędem jest zła lokalizacja serwera, która spowalnia działanie i zwiększa koszty związane z transferem danych między serwerami. Konfiguracja serwera to w pełni zagadnienie cloudowe. Wybór lokalizacji serwera ma kluczowe znaczenie – od niej zależy zarówno wydajność, jak i koszty utrzymania. Duplikowanie danych w wielu regionach dodatkowo je zwiększa. Dla mniejszych serwisów nie stanowi to dużego problemu, jednak w przypadku dużych organizacji niewłaściwa lokalizacja serwera może generować znaczne i niepotrzebne koszty.

Podsumowanie

Podsumowując, pojawiło się wiele pytań dotyczących GTM Server-side. Jeśli zabrakło odpowiedzi na interesujące zagadnienie, warto zostawić je w komentarzu – każde pytanie zostanie przekazane do zespołu analitycznego Conversion i nie pozostanie bez odpowiedzi. W przypadku bardziej złożonych przypadków lub wyzwań związanych z GTM Server-side, zachęcam do kontaktu oraz skorzystania z bezpłatnej konsultacji. Wśród omawianych pytań można znaleźć wiele praktycznych wskazówek i rozwiązań związanych z wdrożeniem tego narzędzia.

The post GTM Server-Side – 12 najczęstszych pytań i odpowiedzi first appeared on Conversion.

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

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

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

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

Co to jest Data Layer?

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

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

Przykłady zastosowania warstwy danych

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

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

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

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

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

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

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

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

Jak wygląda warstwa danych?

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

’ProductName’ – oznacza nazwę produktu na danej podstronie

‘Brand’ – oznacza markę danego produktu

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

’Price’ – oznacza cenę danego produktu

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

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

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

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

I tak dalej, i tak dalej.

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

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

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

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

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

Dlaczego warto postawić na wdrożenie poprzez GTM?

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

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

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

Krok 1: przygotuj plan warstwy danych

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

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

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

Krok 2: zaimplementuj

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

<script>

DataLayer.push ({

‘price’: ‘19,99’

‘category’: ‘obuwie’

‘product’: ‘trampki’

‘size’: ‘45’

});
</script>

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

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

Krok 3: rozwijaj i optymalizuj

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

Wykorzystanie warstw danych w e-commerce

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

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

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

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

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

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

Data Layer – podsumowanie

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

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

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

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

W pierwszym odcinku podcastu „Date with Data Talks” Mariusz Michalczuk rozmawia z Piotrem Wernerem – analitykiem z wieloletnim doświadczeniem w e-commerce. Podczas rozmowy omawiają swoją nietypową ścieżkę zawodową, kluczowe momenty rozwoju analityki oraz doświadczenia związane z wdrożeniami narzędzi analitycznych, takimi jak GA4, Consent Mode i Google Tag Manager.

Przywitanie i przedstawienie gościa
Początki kariery w e-commerce
Kluczowe momenty w rozwoju analityki
Case Study: Consent Mode w Orange
Narzędzia do analityki i integracji danych
Wyzwania współpracy biznes-IT
Plany zawodowe i rozwój
Podsumowanie głównych wniosków

Przywitanie i przedstawienie gościa

Mariusz Michalczuk: Drodzy słuchacze, witam was w pierwszym odcinku podcastu Date with Data Talks, czyli podcastu skierowanego od praktyków do praktyków, od praktyków danych do praktyków wykorzystania danych w marketingu, w e-commerce. Moim i Waszym gościem, pierwszym gościem w tym podcaście jest Piotr Werner.
Piotrek, bardzo dziękuję, że przyjąłeś moje zaproszenie. Może opowiedz kilka słów o sobie i przejdziemy dalej do rozmowy.

Piotr Werner: Cześć, dzień dobry. Ja też bardzo dziękuję za to zaproszenie, Mariusz. Kilka słów o sobie. Mąż, ojciec, analityk. Może na początek wystarczy.

Początki kariery w e-commerce

Mariusz Michalczuk: Opowiedz trochę, jak się w ogóle twoja przygoda z analityką zaczęła. Jak to wyglądało, jakie były twoje pierwsze kroki, jak rozwijałeś się do miejsca, w którym dzisiaj się znajdujesz.

Piotr Werner: Myślę, że moja ścieżka była nieco niestandardowa. Powiedziałbym, że przechodziłem od ogółu do szczegółów. Zacząłem już ponad dekadę temu pracować w e-commerce, a początkowo nie są to stanowiska związane z analityką. Zaczynałem od najprostszych ról, takich jak opisywanie produktów. To jeszcze były czasy, kiedy ręcznie należało umieszczać słowa kluczowe w kampaniach Google Ads. Krok po kroku nauczyłem się kolejnych obszarów: content marketingu, kampanii SEM, SEO. Też analityka w pewnym momencie się pojawiła. Na początku zajmowałem się różnymi aspektami prowadzenia e-commerce’u, zarówno tymi frontowymi, jak i zakulisowymi, np. kwestiami dostawy czy płatności. Po kilku latach zacząłem zarządzać e-commerce’ami. Zawsze czułem się lepiej w świecie liczb niż w kreatywnym. Pamiętam, że gdy pracowałem w mydlarni Cztery Szpaki, razem z koleżanką odpowiadającą za kreatywną stronę marketingu – porywające opisy produktów, artykuły, kampanie reklamowe – żartowaliśmy, że ja jestem gościem tych „nudnych” spraw. Dla mnie te „nudne” kwestie pozostają nadal interesujące. W pewnym momencie stwierdziłem, że całościowe spojrzenie na e-commerce przestaje wystarczać, bo szczegóły, począwszy od SEO, a potem analityki, były na tyle obszerne, że chciałem się w nie zagłębić. Najpierw skupiłem się mocno na SEO i jego technicznej stronie, a traf chciał, że na pewnym etapie mojej kariery, oprócz zarządzania zespołem SEA, otrzymałem zespół analityki. To był czas, kiedy zacząłem samodzielnie interesować się tym zagadnieniem. Stwierdziłem, że zarządzanie jest mało inspirujące i trzeba iść głębiej. Czytałem, robiłem kursy, zadawałem pytania, aż w końcu zdecydowałem, że chcę zająć się wyłącznie analityką. I tak to trwa do dziś.

Kluczowe momenty w rozwoju analityki

Mariusz Michalczuk: Ja pamiętam początki, kiedy w 2010 roku analityka była domeną ludzi pracujących w SEO oraz PPC, bo bez danych wykonywanie ich pracy było utrudnione. Twoja ścieżka jest bardzo kompletna. Pamiętam, że zanim założyliśmy Conversion, miałem okazję uczestniczyć w managerskim programie w Banku Millennium, gdzie przez dwa lata rotowaliśmy między departamentami, zaczynając od oddziału detalicznego – kasa, sprzedaż kredytów, lokaty, itp.

Piotr Werner: Szkoła Toyoty.

Mariusz Michalczuk: To nawet nie wiedziałem, że to tak się nazywa, ale uważam, że to świetne podejście. A powiedz mi, jaki był kluczowy moment, który ukształtował twoje podejście do analityki? Kiedy pomyślałeś, że bez danych w e-commerce i marketingu ani rusz?

Piotr Werner: Na każdym etapie wydawało mi się, że bez danych i liczb jest ciężko. Gdybym musiał wskazać jeden punkt kulminacyjny, to był webinar, podczas którego zaprezentowano GA4. Oczywiście wcześniej korzystałem z Analyticsa, ale wtedy po raz pierwszy świadomie pomyślałem: “wow, w tym kierunku chcę iść”. Drugi, mniej pozytywny moment dotyczył content marketingu – widziałem różnicę między podejściem opartym na danych przy szukaniu tematów i parametrach artykułów a twardym wyciąganiem liczb, przygotowywaniem statystyk, pisaniem dokumentacji, pracami technicznymi, jak data layer czy blue tag manager. Zauważyłem dwa zupełnie różne kierunki i ten bardziej techniczny bardziej mi odpowiadał.

Case Study: Consent Mode w Orange

Mariusz Michalczuk: Wspomniałeś o content marketingu. Jak wtedy, jako obserwator, oceniano te działania – czy data miały wpływ na ocenę efektywności?

Piotr Werner: Content marketing był mocno sprzężony z liczbami. Od samego początku planowanie tematów, artykułów, ich długość, nasycenie słowami kluczowymi czy grupy docelowe opierały się na konkretnych narzędziach, nie tylko tych SEO, ale również narzędziach analitycznych badających demografię dostępnych klientów. Jeśli moja poprzednia odpowiedź sugerowała, że wybierasz między content marketingiem a danymi, to nie o to mi chodziło. Content marketing dobrze współgra z danymi, choć niekoniecznie z bardziej technicznymi kwestiami.

Mariusz Michalczuk: Ok, dobra. A powiedz mi teraz, skoro po 2019 roku, po ogłoszeniu GA4 – jeszcze wtedy jako App + Web – twoja ścieżka skręciła bardziej ku twardej analityce, czy możesz przytoczyć przykład sytuacji, w której dane doprowadziły do istotnej zmiany w organizacji, w której pracowałeś lub pracujesz nadal?

Piotr Werner: Zapytałeś o okres od 2019 roku, a ja przytoczę przykład z 2023. Opowiadamy o nim na ostatnim e-commerce evencie – to historia z Orange’a. Po niepozornym wdrożeniu Consent Mode zauważyliśmy spadek ruchu. Nic dziwnego – użytkownicy decydują się na akceptację ciasteczek lub nie, więc część odpowiada “nie”. Ruch spadł jednakowo nierówno we wszystkich kanałach – źródła wizerunkowe ucierpiały bardziej, a te domykające sprzedaż, takie jak SEO czy SEM, utrzymały się na podobnym poziomie. Druga zaskakująca kwestia: mimo spadku ruchu, transakcje utrzymały się na tym samym poziomie. Hipoteza, że użytkownicy, którzy nie chcą dokonać zakupów, odrzucają ciastka, okazała się naiwną – zajrzeliśmy w dane i odkryliśmy metrykę “no choice rate”, czyli współczynnik wyświetleń Cookie Bannera, podczas których nie podjęto żadnej akcji. Podczas gdy ponad 90% użytkowników, decydując się, akceptowało ciastka, ponad połowa wyświetleń Cookie Bannera kończyła się zamknięciem strony bez działania.

Mariusz Michalczuk: Okej, i standardowo rozumiem, że użytkownicy bez zgody nie byli śledzeni.

Piotr Werner: Tak, stosowaliśmy tzw. Basic Consent Mode – brak zgody oznaczał brak akcji. Gdy odkryliśmy wysoki odsetek takich przypadków, postanowiliśmy szukać dalej i skorzystaliśmy z narzędzia do weryfikacji jakości ruchu. Chcieliśmy sprawdzić, jaki ruch “odbija się” od Cookie Bannera. Nasze wstępne badania (POC) wykazały, że w niektórych źródłach aż 90% sesji oceniano jako sztuczne – narzędzie oceniało zachowanie użytkowników według kryteriów behawioralnych i technicznych, takich jak ruchy myszką, fingerprint, recaptcha, itp. Zauważyliśmy kampanie, w których kilkanaście tysięcy użytkowników wykonywało identyczne ruchy myszką i sekwencje kliknięć. Mieliśmy mnóstwo kampanii kończących się na Cookie Bannerze z powtarzalnymi wzorcami, gdzie np. banner wyświetlał się, a użytkownik zjeżdżał na sam dół strony – co w Advanced Consent Mode wywołałoby efekt zaangażowanej sesji. Te wyniki zmieniły nasze podejście do płatnego ruchu, zwłaszcza z sieci afiliacyjnych, gdzie setki, a nawet tysiące wydawców pozyskują ruch być może w sposób maszynowy. Drugim wnioskiem była nauka integracji danych między Ads a Analytics poprzez GCLID i BigQuery, co pozwoliło ocenić odsetek kliknięć przeradzających się w sesję. Często displayowe kreacje, nastawione na budowanie marki, padały celem botów, co obniżało efektywność.

Narzędzia do analityki i integracji danych

Mariusz Michalczuk: Mam podobne doświadczenia. Pamiętam pierwsze cookie bannery i Cookie Management Platform u naszych klientów, kiedy jeszcze po pierwszym wyroku TSUE nie było jasne, czy ciasteczka są legalne. Po zakwestionowaniu legalności przez Schrems 2 firmy zaczęły traktować to poważnie – gdy użytkownik nie zgadzał się, nie wykorzystywano ciasteczek, co powodowało wzrost współczynników odrzuceń. A skoro transakcje nie spadły, a ruch spadł, to wyglądało korzystnie we współczynniku konwersji. Gdyby nie analiza, mogliśmy dojść do błędnych wniosków. A czy mógłbyś podzielić się narzędziem do jakościowej analizy, które możliwe jest łatwo wykorzystać?

Piotr Werner: Jedno z narzędzi, które polecam, to Traffic Watchdog. To polska firma obecna na rynku od kilkunastu lat. Testowaliśmy różne narzędzia, ale ostatecznie zdecydowaliśmy się na Traffic Watchdoga – również w formule Proof of Concept. Pierwsze POC miały ograniczone dane, potem przeszliśmy do testu pełnej funkcjonalności. Nie mogę się odnieść do wyników, bo odszedłem z Orange przed zakończeniem testów. Korzystaliśmy też z narzędzia do analityki jakościowej – Quantum Metric, które pozwala na analizę jakościową przy zachowaniu wysokiej wierności danych ilościowych (osiągnęliśmy 99% zgodności między danymi z Analytics i Quantum Metric). Oczywiście są też bardziej popularne i tańsze rozwiązania, jak Hotjar czy Clarity, choć o ograniczonych możliwościach. Dla porównania – parametr User Agent, przesyłany do Google Analytics, pozwala nam wyłapać segmenty słabiej konwertujących sesji.

Mariusz Michalczuk: Podchodzimy do tego z perspektywy ilościowej, ale narzędzia Traffic Watchdog i Quantum Metric są wartościowe. Jeśli słuchacze chcą zweryfikować, czy u nich nie występują dziwne ruchy, warto z nich skorzystać. A propos narzędzi – jakie inne technologie lub rozwiązania analityczne wykorzystywałeś w pracy, które pomogły wesprzeć pracę analityczną i biznes?

Piotr Werner: Obawiam się, że będę tu dość przewidywalny – oczywiście narzędzia ze znaku google’owskiego. Jestem ogromnym fanem Google Tag Managera. Uważam, że odpowiednio wykorzystany GTM pozwala wyciągnąć z witryny niemal wszystko, czego potrzebujemy. W Orange konfiguracja GA4 w GTM-ie zawierała ponad 40 parametrów niestandardowych przesyłanych przy każdym zdarzeniu, co umożliwiało łączenie danych między systemami. Można było np. przesyłać wartości ciasteczek jako parametry do GA4.

Mariusz Michalczuk: Po to, żeby później połączyć wszystko między systemami.

Piotr Werner: Dokładnie. Mogliśmy konsultować te dane z zespołem IT – gdy pojawiały się wątpliwości co do segmentu użytkowników lub błędów na stronie, łatwo łączyliśmy sesje z Quantum Metric i konsultowaliśmy problemy. Google Tag Manager, który dla wielu marketingowców jest standardem, oferuje ogromne możliwości. Wspomnę też o BigQuery – zacząłem się go uczyć cztery lata temu i nadal odkrywam nowe możliwości. BigQuery umożliwia zaawansowaną analizę surowych danych, porównanie ich z danymi z Analytics i budowanie dedykowanej analityki. A na koniec, mimo rosnącej zaawansowania technologicznego, nie wolno zapominać o Microsoft Excel. Dobra tabela przestawna z surówki potrafi wyciągnąć sensowne wnioski.

Wyzwania współpracy biznes-IT

Mariusz Michalczuk: Pamiętam, że na LinkedIn wrzuciłem artykuł o NFZ w Nowej Zelandii, gdzie zarządzali budżetem za pomocą jednego arkusza Excela i błąd w jednej komórce spowodował duże zniekształcenia. W kontekście współpracy z IT, często widzimy, że element serwisu „nie działa”, mimo że dla działu technicznego wszystko wydaje się działać. Połączenie danych ilościowych z jakościowymi, np. z nagrań sesji, pozwala zobaczyć konkretne problemy. Dzięki temu argument “u mnie działa” jest trudniejszy do utrzymania.

Piotr Werner: Dokładnie. Nawet nie wchodząc w skomplikowane funkcje Quantum Metric, podobne efekty można uzyskać w Hotjarze – przesyłając parametr Hotjar session ID do Analyticsa i tworząc segment użytkowników spotykających się z błędami, które następnie przekazujemy zespołowi IT. Wspomniałem już o GTM i BigQuery, ale warto jeszcze dodać, że wyzwanie stanowi komunikacja między zespołami. Często analitycy i dział IT są zamknięci w swoich systemach. Analityk, dostając wymagania do Data Layer, powinien zadawać pytanie: „po co ci to?”. Mnie w Orange nauczyło to podejście – zamiast zbierać skomplikowane dane, warto zacząć od podstawowych współczynników, jak konwersja, liczba zamówień, ruch w poszczególnych kanałach. W biznesie kluczowe jest tworzenie interdyscyplinarnych zespołów, które rozumieją wspólny cel, komunikują się i uczą odpowiedzialnych liderów, nie bojących się pytać o sens wdrażanych rozwiązań. Często nawet AI, jak ChatGPT, nie zastąpi refleksji i dialogu między działami.

Mariusz Michalczuk: Myślę, że jako analitycy naszym zadaniem jest dopytywanie biznesu, żeby wspólnie znaleźć najlepsze rozwiązania.

Piotr Werner: Zdecydowanie. Analityk, dostając pytanie o dane lub wymagania do Data Layer, powinien zapytać: „po co ci to?”. Mamy mnóstwo systemów, które zbierają liczby, ale nie pomagają w decyzjach. Pamiętam, że w Orange dostałem prośbę o śledzenie, ile osób po kliknięciu przycisku „formy dostawy” zmieniało ścieżkę między Inpost a paczkomatem. Zapytałem wprost – po co to? Okazało się, że wymaganie przyszło z góry, bez konkretnego planu wykorzystania. Dlatego analitycy powinni dążyć do uproszczenia systemów, zaczynając od podstawowych metryk, które umożliwiają dalsze analizy i trafne decyzje.

Plany zawodowe i rozwój

Mariusz Michalczuk: Opowiedziałeś o łączeniu danych ilościowych z jakościowymi przy użyciu narzędzi zaczynających się od GTM, przez BigQuery, aż po analizę błędów w narzędziach jakościowych. A co z marketingiem przed pozyskaniem użytkownika? Czy możesz podać przykład, gdzie analiza wykazała fraudowy charakter ruchu i pozwoliła zaoszczędzić budżet oraz poprawić kampanię?

Piotr Werner: Tak, taki przykład jest klasyczny. Analiza efektywności budżetu marketingowego oraz przeliczanie wyników na poszczególne kanały pozwoliły nam przesunąć część budżetu – w tym przypadku na Google Ads. W efekcie, w ciągu kolejnego kwartału współczynnik konwersji wzrósł o kilkadziesiąt punktów procentowych. To pokazało, że odpowiednia analiza i wykorzystanie danych może realnie wpłynąć na oszczędności i poprawę wyników.

Mariusz Michalczuk: A jak wygląda Twoja dalsza ścieżka zawodowa? Skoro przeszedłeś od pracy w e-commerce przez program typu Toyota, do głębokiej analityki, jakie masz plany na najbliższą przyszłość?

Piotr Werner: W jednym z poprzednich pytań wspomniałem już o moim odejściu z Orange. Obecnie zaczynam karierę w białostockiej firmie – cateringu dietetycznym Kuchnia Vikinga. Moim zadaniem będzie budowa analityki internetowej, a prawdopodobnie również offline. Podejdę do tego od szczegółu do ogółu i z powrotem.

Mariusz Michalczuk: Super, mega fajnie. Cieszę się, że będziesz mógł wykorzystać wszystkie zdobyte lekcje z Orange oraz poprzednich ról, by stworzyć analitykę “od podstaw” na nowym, dziewiczym terenie. Podsumowując nasze spotkanie – to bardzo wartościowa rozmowa. Dziękuję za wskazówki i życzę sukcesów w nowej roli. Mam nadzieję, że nasze doświadczenia będą pomocne także dla słuchaczy.

Piotr Werner: Ja też bardzo dziękuję za zaproszenie. Cieszę się i trzymam kciuki za Conversion. Mam wrażenie, że dopiero się rozkręcaliśmy, ale nie chcemy zanudzić słuchaczy. Dziękuję, Mariusz, za dobre słowo. Dziękuję wszystkim za wysłuchanie podcastu. Dobrego dnia i do usłyszenia.

Podsumowanie rozmowy

Rozmowa z Piotrem Wernerem pokazuje nietypową, ale kompletną ścieżkę rozwoju w e-commerce – od prostych ról operacyjnych po zaawansowaną analizę danych. Kluczowymi momentami były przełomowe wydarzenia, takie jak webinar prezentujący GA4, a także doświadczenia zdobyte przy wdrożeniach Consent Mode, które ujawniły istotne problemy z jakością ruchu. W dyskusji podkreślono znaczenie narzędzi analitycznych, takich jak Traffic Watchdog, Quantum Metric, Google Tag Manager, BigQuery i Excel, oraz konieczność ścisłej współpracy między działami technologicznymi i biznesowymi. Głównym przesłaniem jest, że zaczynając od solidnych fundamentów i prostych metryk, można budować bardziej zaawansowane systemy analityczne, co wpływa na poprawę efektywności kampanii i optymalizację budżetu marketingowego.

The post Piotr Werner w Date With Data Talks – rozmowa o danych first appeared on Conversion.

Czas to pieniądz – szczególnie w przypadku biznesów internetowych, gdzie w kontekście dostarczania najlepszych rozwiązań liczy się każdy dzień. Musisz być na bieżąco, ponieważ rzeczy dzieją się błyskawicznie. Jeśli nie nadążasz za zmianami w świecie marketingu – wypadasz z gry.

Technologie marketingowe oferują nowe możliwości, ale jednocześnie wymagają wiele czasu i wysiłku ze strony marketingowca.

Załóżmy, że chcesz przetestować nową afiliację aby osiągnąć cel dotyczący kwartalnego ruchu. Jesteś przekonany, że błyskawicznie przyniesie Ci mnóstwo ruchu, ponieważ oferta sprzedawcy wygląda na wyjątkowo lukratywną. Ale jest jeden haczyk: CPS jako model rozliczeń. Twój kontrahent nie rozpocznie pracy, dopóki nie dostanie kodu wdrożonego na Twojej stronie. Musi śledzić ruch na stronie / zamówienia, które dostarcza.

Ile zajmie Twojemu działowi IT wdrożenie kilku linijek kodu na stronę? Jeśli uda mu się to zrobić w 3 dni, możesz uważać się za szczęściarza.

Niestety bardzo często okazuje się, że kilka tygodni to bardziej realny termin. Podczas gdy kilka linijek kodu tkwi w poczekalni, Twoja firma traci pieniądze.

Wyobraź sobie, że masz więcej niż jednego kontrahenta zapewniającego Ci ruch na stronie i właśnie zamierzasz przeprowadzić testy A/B, zanim podejmiesz decyzję. Czy masz kilka tygodni do zmarnowania, zanim dział IT opracuje skrypt, który obsłuży wszystkie strony i tagi, aby należycie zmierzyć wyniki?

Kolejki i terminy ustalane przez dział IT są zmorą marketingowców. Przeciążony dział IT nie uwija się szybko z wdrożeniem tagów, dlatego tracisz na efektywności.

Pozwól, że opowiem Ci historię o jednym z naszym klientów. Zmagaliśmy się z bardzo wysokim wskaźnikiem wyjść (ang. Exit rate) na stronach kategorii. Dział marketingu nie był w stanie poradzić sobie z problemem.

Obyty marketingowiec zaproponował wdrożenie krótkiej ankiety w celu zebrania danych jakościowych. Bingo! Odpowiedzi klientów doprowadziły nas do źródła problemu, którym okazała się komunikacja. Użytkownicy źle rozumieli nazwę kategorii na liście i opuszczali stronę. Drobne usprawnienie (zmiana nazwy kategorii) doprowadziło do spadku wskaźnika porzuceń o 58% oraz do wzrostu współczynnika konwersji.

To jednak nie wszystko, co powinieneś wiedzieć o tej historii. Realizacja pomysłu owego marketingowca zajęła ponad 3 miesiące, a kod ankiety wyglądał tak:

(function(w) {
w['_sv'] = {trackingCode: 'VTqUuBoMVSeYYbrHvjlryVOGjvPorMGw'};
var s = document.createElement('script');
s.src = '//api.survicate.com/assets/survicate.js';
s.async = true;
var e = document.getElementsByTagName('script')[0];
e.parentNode.insertBefore(s, e);
})(window);

Skąd tak duże opóźnienie? Marketingowiec musiał poczekać aż dział IT umieści na stronie kod ankiety.

Przemyślmy to. A co, jeśli ów obyty marketingowiec z naszej historii mógłby wdrożyć kod samodzielnie? Współczynnik porzuceń zmniejszyłby się w ciągu kilku dni, a przez dodatkowe 2 miesiące mógłby pracować nad kolejnym świetnym rozwiązaniem, które przyniosłoby wzrost współczynnika konwersji.

Nasza historia mogłaby mieć szczęśliwe zakończenie, jeśli tylko firma korzystałaby z systemu do zarządzania tagami.

Lekarstwo: Google Tag Manager

Czy chcesz zaznać napędzanego danymi, zręcznego podejścia do marketingu? Uzyskasz to, jeśli tylko zdecydujesz się na system do zarządzania tagami.

Google Tag Manager pozwala marketingowcom z łatwością wdrażać kody, które pozwalają na śledzenie stron trzecich, analizę, raportowanie, remarketing, śledzenie konwersji, optymalizację i wiele więcej.

Jak to działa? Po wdrożeniu jednego znacznika narzędzia wszystkie inne kody są wdrażane i zarządzane przez interfejs w przeglądarce internetowej – bez potrzeby ponownej ingerencji w stronę!

Google Tag Manager działa jak kontener dla wszystkich skryptów na Twojej stronie. Oparty jest na warunkach, które uruchamiają poszczególne tagi na stronie. Każdy z tagów wysyła powiadomienie do narzędzia analitycznego. Możesz w kilka kliknięć skonfigurować narzędzie tak, że gdy użytkownik wejdzie na konkretne strony lub wykona konkretne działania – system wywoła np. skrypt konwersji lub skrypt remarketingowy. Sprytnemu użytkownikowi Google Tag Managera uda się nawet wstawić do skryptów dynamiczne elementy (jak np. wartość zamówienia czy zakupione produkty) bez potrzeby kontaktu z IT.

Osiągaj lepsze rezultaty. Szybciej.

Szukasz zwrotu inwestycji z systemu zarządzania tagami?

Sprzedawcy gotowi są pomóc Ci zdobywać, konwertować i zatrzymywać więcej użytkowników. W internecie znajdziesz nadmiar świetnych rozwiązań, zaczynając od map cieplnych (ang. Heatmap), przez śledzenie ruchu kursora, aż po zaawansowaną automatyzację marketingu.

Każdy usługodawca oferuje swój sposób na optymalizację, analizę lub personalizację – każdy z nich wymaga jednak osadzenia tagów. Zaczynając od skryptów śledzących, przez skrypty ad-serverów, remarketingowe i pixele konwersji. Źródło.

Możesz wdrożyć tagi tego samego dnia i w efekcie podnieść sprawność marketingu. Narzędzie monetyzuje się błyskawicznie, a najlepsze rozwiązania mogą przynieść ponadprzeciętne rezultaty już na samym początku.

Według raportu zatytułowanego ‘ROI of Tag Management’, 76% użytkowników TMS (systemów do zarządzania tagami) jest w stanie wdrożyć skrypty tego samego dnia roboczego. 47% ludzi, którzy wdrażają tagi z pomocą działów IT, jest w stanie zrobić to nie szybciej niż w tydzień.” Źródło.

Redukuj koszty

Długie czekanie nie czyni szczęśliwym ani Ciebie, ani działu IT. Zamiast wdrażania prostych i monotonnych tagów, dział IT mógłby włożyć więcej wysiłku w projekty strategicznie, które budują wartość przedsiębiorstwa. Korzystając z Google Tag Managera odciążasz dział IT i podnosisz opłacalność.

Przyspiesz swoją stronę

TRUSTe donosi, że 50 czołowych pod względem wielkości ruchu stron internetowych w Zjednoczonym Królestwie posiada średnio 14 skryptów śledzących. Ta liczba musi mieć znaczenie dla szybkości strony.

Google Tag Manager ładuje skrypty asynchronicznie oraz usuwa śledzenie z kodu HTML, co znacznie przyspiesza czas ładowania się strony. To proste rozwiązanie jednego z największych problemów optymalizacji konwersji – czasu ładowania strony.

Zapewnij jakość danych

Gdy system jest scentralizowany, nie jesteś zmuszony do wdrażania każdej linijki kodu osobno. Po prostu tworzysz regułę, która później uruchamia tag na każdej podstronie. To znaczy, że jesteś w stanie zapewnić rzetelne dane i odpowiednie śledzenie.

Czy kiedykolwiek musiałeś zmierzyć się z sytuacją, w której web developer przypadkowo usunął kod śledzący, niszcząc tym samym Twoje dane? Możesz być pewien, że to już nigdy się nie zdarzy.

Czy jesteś gotowy przenieść marketing na wyższy poziom? Nie trać czasu – podaruj swoim marketingowcom niezależność i wolność, na które zasługują.

Jeśli chcesz uczynić swój dział marketingu cyfrowego niezależnym od IT, ale potrzebujesz wsparcia ekspertów (Google Analytics czy Google Tag Manager), skontaktuj się z nami. Zrobimy wszystko, co w naszej mocy, aby spełnić Twoje oczekiwania. Jesteśmy certyfikowanym partnerem Google w zakresie Google Analytics oraz Google Tag Managera.

The post Dział e-marketingu niezależny od IT? To da się zrobić z pomocą Google Tag Managera! first appeared on Conversion.

Chcesz nauczyć się efektywnie wykorzystywać Google Analytics oraz Google Tag Managera? Chcesz dowiedzieć się jak optymalizować swój serwis i zwiększyć współczynnik konwersji? Jeśli tak, to weź udział w praktycznych szkoleniach z Google Analytics, Google Tag Managera i Optymalizacji Współczynnika Konwersji, które prowadzimy w październiku w Warszawie.

• Nauczymy Cię jak zwiększać ROI z prowadzonych działań marketingowych.
• Pokażemy Ci jak przeprowadzać zaawansowane analizy z wykorzystaniem niestandardowych funkcjonalności.
• Nauczymy Cię jak śledzić zachowanie Twoich użytkowników i dopasować serwis do ich potrzeb.
• Przedstawimy niezawodne techniki zwiększania współczynnika konwersji.

Dołącz do setek zadowolonych uczestników szkoleń!

Już niedługo będziemy mogli śmiało powiedzieć, że z zakresu analityki internetowej i optymalizacji współczynnika konwersji szkolimy pokolenia. Dlaczego? Ponieważ to już 10. edycja naszych szkoleń. Program szkoleń zmieniamy z każdą edycją, aby jak najbardziej odpowiadał trendom w naszej branży. Tym razem jest podobnie – program rozszerzyliśmy z 3 do 4 dni, dodając jeden pełny dzień poświęcony Google Tag Managerowi. Całość tym razem wygląda następująco.

Pierwszy dzień będzie poświęcony Google Analytics na poziomie średniozaawansowanym. Nauczymy Cię m.in. jak:

• zrozumieć interfejs Google Analytics, kluczowe metryki, wskaźniki i pojęcia,
• efektywnie analizować dane płynące z serwisu i zwiększać zysk firmy,
• w praktyce korzystać z najważniejszych funkcjonalności Google Analytics przydatnych w codziennej pracy.

Zapisz się na szkolenia teraz.

Drugiego dnia wejdziemy na wyższy poziom obsługi Google Analytics i pokażemy Ci jak:

• wykorzystać zaawansowane funkcjonalności narzędzia – zaawansowane raporty, segmenty niestandardowe oraz wyrażenia regularne,
• zautomatyzować pracę z Google Analytics,
• wdrażać zaawansowane śledzenie użytkowników.

Zapisz się na szkolenia teraz.

Trzeci dzień będzie w całości poświęcony Google Tag Managerowi. Przez ponad 6 godzin będziemy dzielić się naszą wiedzą i pokazywać Ci:

• jak działa Google Tag Manager i jak za jego pomocą wdrożyć niestandardową konfigurację Google Analytics – m.in. zdarzenia, wirtualne odsłony, wymiary niestandardowe, grupowanie treści, a także takie elementy jak śledzenie pogody, scrollowanie ekranu, odtwarzanie filmów na YouTubie oraz tzw. ”chytry” toplayer (czyli taki, który pojawia się użytkownikowi w momencie opuszczania serwisu),
• jak korzystać z Google Tag Managera w sposób, który usprawni proces analizy i pozwoli wygenerować oszczędności związane z odciążeniem działu IT. Jak już niejednokrotnie wspominaliśmy (np. tutaj) – jedną z największych zalet Google Tag Managera jest możliwość ominięcia działu IT przy wdrażaniu skryptów, co owocuje w dużą oszczędność czasu.

Zapisz się na szkolenia teraz.

Ostatni, czwarty dzień będzie poświęcony optymalizacji współczynnika konwersji. Nasz ekspert:

• omówi najlepsze techniki stosowane przy optymalizacji współczynnika konwersji,
• opowie o całym procesie z pomocą przykładów „z życia wziętych” oraz case studies,
• nauczy Cię jak prowadzić testy A/B przy wykorzystaniu różnych narzędzi, m.in. Eksperymentów Google Analytics, Optimizely oraz Visual Website Optimizera.

Zapisz się na szkolenia teraz.

Brzmi jak spora dawka wiedzy? Mamy nadzieję, że tak. Warto wiedzieć, że szkolenia odbędą się w Centrum Konferencyjnym Zielna przy ul. Zielnej w Warszawie, czyli w samym centrum miasta, 20 metrów od stacji metra Świętokrzyska. Bez problemu dojedziesz na szkolenia z każdego miejsca w Warszawie. Jeśli natomiast przyjeżdżasz z innego miasta – wtedy z Dworca Centralnego dojdziesz na szkolenia w 10 minut. Ja nie mogę sobie wyobrazić lepszej lokalizacji, a Ty? Dlatego zarejestruj się już teraz, bo liczba miejsc jest ograniczona (tylko 20 miejsc na każdy dzień!).

Odbierz darmowy audyt Google Analytics oraz dostęp do ciekawych webinarów

Jeden pełny dzień poświęcony Google Tag Managerowi to nie jedyna nowość. Tym razem każdemu z uczestników szkoleń oferujemy także ekskluzywny dostęp do Conversion’s Excellence Academy. Jest to bezpłatny i nieograniczony dostęp do wyjątkowych webinarów, z których czerpać wiedzę ma przyjemność tylko limitowana liczba osób – nasi klienci. Webinary organizujemy raz na kwartał i w ich trakcie przekazujemy know-how budowany przez nas w trakcie tysięcy godzin przepracowanych przy komercyjnych projektach.

Dla wszystkich uczestników szkoleń z Google Analytics albo Google Tag Managera przeprowadzamy również darmowy audyt instalacji Google Analytics. Następnie na szkoleniach będziemy uczyć jak naprawić najczęściej występujące w instalacji błędy oraz jak zachować poprawność danych. Regularna cena takiego audytu wynosi 1000 zł, jednak uczestnicy naszych szkoleń dostają go całkowicie za darmo. Dowiedz się więcej o nowościach.

Dlaczego warto?

W trakcie dziesięciu edycji szkoleń zdobyliśmy grono zadowolonych klientów. Jedną z nich jest Magdalena Pietrzak pracująca w iStore: „Szkolenie z analityki internetowej i optymalizacji konwersji zostało przeprowadzone na najwyższym poziomie. Ogromne uznania dla prowadzących – Pana Mariusza Michalczuka i Pawła Ogonowskiego, który swoją niebywałą wprost wiedzę z zakresu analityki internetowej potrafili przekazać w ciekawy i przystępny sposób. Pełne przykładów prezentacje pozwoliły lepiej zrozumieć omawiane zagadnienia. Szkolenie organizowane przez Conversion w 100% zaspokoi potrzeby wszystkich osób, którym zależy na efektywniejszym prowadzeniu działań w Internecie.”

Wśród naszych zadowolonych Klientów znajduje się także Monika Kumińska Specjalista ds. Marketingu Centrum Kompleksowej Rehabilitacji Konstancin: „Polecam udział w szkoleniach organizowanych przez firmę Conversion wszystkim osobom, które są zainteresowane analityką webową i optymalizacją konwersji. Szkolenia przygotowane i przeprowadzone w sposób profesjonalny i rzetelny, wiedza przekazywana w sposób dostępny, poparta licznymi case studies i bardzo ciekawie przekazana. Organizacja na wysokim poziomie, dogodna lokalizacja szkoleń, przygotowane pomocne materiały potrzebne podczas szkolenia oraz otwarci i pomocni prowadzący gwarantują lepsze przyswojenie wiedzy”.

Teraz i Ty masz szansę dołączyć do grona naszych uczniów, a następnie zadowolonych Klientów. Jeśli nie wiesz, które szkolenie jest dla Ciebie najlepsze – nie martw się! Staramy się wyjść naprzeciw wszystkim Twoim możliwym wątpliwościom i dlatego opracowaliśmy krótkie badanie, dzięki któremu będziemy mogli doradzić, które szkolenie jest dla Ciebie najlepsze. Ankietę znajdziesz tutaj, a jej wypełnienie nie zajmie Ci więcej niż 5 minut. Po jej wypełnieniu możesz liczyć na nasz telefon.

Jeśli natomiast musisz uzyskać akceptację i budżet na szkolenie oraz chcesz przekonać kogoś w swojej firmie, że warto Cię na nie wysłać – chętnie Ci w tym pomożemy. Przygotowaliśmy specjalny e-mail, który możesz wysłać do swojego szefa lub działu HR. Nie pozostawi on żadnych wątpliwości, że zdobyta wiedza wpłynie na lepsze wyniki Twojej pracy i całej firmy.

A jeśli nie chcesz iść na szkolenia sam – zaproś znajomych. Przy rejestracji więcej niż jednej osoby oferujemy dodatkowy rabat w wysokości 5%.

Nie trać czasu i zarejestruj się już dziś!

The post Kolejna edycja praktycznych szkoleń otwartych z Google Analytics, Google Tag Managera i Optymalizacji Współczynnika Konwersji 12-15 października 2015 w Warszawie first appeared on Conversion.

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

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

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

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

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

#1 First things first

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

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

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

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

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

#2 Podstawowe błędy

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

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

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

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

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

#3 Bezpieczniki

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

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

#4 Śledzenie wszystkiego

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

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

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

#5 Rozszerzony e-commerce

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

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

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

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

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 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.

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

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

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

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

Dobre narzędzia to dobry początek.

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

Po pierwsze: narzędzia i dane

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

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

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

Wybór narzędzi analitycznych

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

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

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

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

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

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

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

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

Integracja danych

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

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

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

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

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

Prezentacja danych

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

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

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

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

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

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

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

Po drugie: ludzie

Avinash Kaushik pisze o zasadzie 10 / 90.

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

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

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

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

Dlaczego kompetentny zespół jest tak ważny?

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

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

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

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

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

Po trzecie: procesy

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

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

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

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

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

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

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

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

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

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

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

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

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

Typy odbiorników

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

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

Odbiornik licznika

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

Odbiornik kliknięć

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

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

Odbiornik kliknięć linków

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

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

Odbiornik przesyłanych formularzy

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

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

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

Rejestrator błędów JavaScript

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

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

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

Tag nasłuchiwania historii

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

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

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

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

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

Dodanie tagu odbiornika

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

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

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

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

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

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

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

Dodanie tagu zdarzenia Google Analytics

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

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

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

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

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

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

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

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

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

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

Łyżka dziegciu

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

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

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

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

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

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

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