Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
Nowa wersja Google Analytics jest dostępna od kilku miesięcy i większość osób, z którymi rozmawiam, zdążyła już założyć usługę „na wszelki wypadek”. Potem otwiera raporty, nie znajduje niczego, do czego przywykła, i zamyka kartę.
Rozumiem tę reakcję, ale wynika ona z błędnego założenia. Ludzie traktują nowe Analytics jako odświeżony interfejs starego narzędzia. To nie jest odświeżony interfejs. To inny sposób zapisu danych, w którym podstawową jednostką nie jest wizyta, tylko pojedyncze zdarzenie.
Póki dane zbierane są równolegle, nie ma pośpiechu. Warto natomiast zrozumieć tę różnicę już teraz, bo od niej zależy, jak układa się pomiar konwersji i jak potem interpretuje się liczby.
Stary model opiera się na hierarchii: użytkownik zawiera sesje, sesja zawiera odsłony i interakcje. Wszystko, co widzisz w raportach, jest agregowane wewnątrz tej struktury.
Sesja jest sztucznym pojemnikiem o umownych granicach. Kończy się po trzydziestu minutach bezczynności, o północy albo w momencie zmiany źródła ruchu. Dlatego użytkownik, który wchodzi z reklamy, wraca po godzinie z zakładek i finalizuje zakup, zostawia w danych dwie sesje i jedną transakcję przypisaną do drugiej z nich.
Z tej konstrukcji wynikają wskaźniki, które wszyscy znamy. Współczynnik odrzuceń to udział sesji z jedną interakcją — dlatego strona z jednym długim artykułem, który ktoś przeczytał w całości, wypada w tym mierniku fatalnie. Średni czas na stronie liczy się z odstępów między odsłonami, więc ostatnia strona wizyty ma z definicji czas zerowy.
Model sesyjny dobrze pasował do serwisów, w których użytkownik przechodzi między dokumentami. Znacznie gorzej pasuje do aplikacji i stron, gdzie cała aktywność dzieje się w jednym widoku.
W nowym modelu zapisywane są zdarzenia i nic ponad to. Odsłona strony jest zdarzeniem. Przewinięcie ekranu jest zdarzeniem. Kliknięcie w link wychodzący, uruchomienie filmu, wysłanie formularza, zakup — wszystko to jest zdarzeniem tego samego typu.
Zniknął podział na kategorię, akcję i etykietę, który w starym Analytics był obowiązkowym gorsetem. Teraz zdarzenie ma nazwę i dowolny zestaw parametrów. Zamiast wciskać trzy informacje w trzy z góry ustalone pola, dokładasz tyle parametrów, ile potrzebujesz, i nazywasz je po swojemu.
Sesja nie zniknęła zupełnie — jest wyliczana na podstawie zdarzenia rozpoczęcia sesji i nadal pojawia się w części raportów. Przestała jednak być fundamentem, na którym opiera się cała struktura danych. Zmienił się też sposób pomiaru zaangażowania: w miejsce współczynnika odrzuceń pojawiła się sesja zaangażowana, definiowana przez czas na stronie, liczbę odsłon lub wystąpienie zdarzenia konwersji.
Dla mnie najważniejsza praktyczna konsekwencja jest inna. W starym modelu każde nowe mierzenie wymagało decyzji, w które pole to wpisać. W nowym po prostu wysyłasz zdarzenie z parametrami i dopiero potem decydujesz, co z niego pokażesz w raporcie.
W Universal Analytics cel definiowało się na poziomie widoku i mógł nim być adres strony, czas trwania sesji, liczba odsłon albo zdarzenie. Limit wynosił dwadzieścia celów na widok i przy większych wdrożeniach bywał ciasny.
W nowym modelu nie ma celów w tym rozumieniu. Jest lista zdarzeń i przełącznik, którym oznaczasz wybrane z nich jako konwersje. Jeśli chcesz mierzyć wysłanie formularza, wysyłasz zdarzenie o własnej nazwie i oznaczasz je jako konwersję — koniec konfiguracji.
Brzmi to prościej i faktycznie jest, ale ma dwa skutki, o których warto wiedzieć. Pierwszy: cel oparty na adresie strony podziękowania trzeba przełożyć na zdarzenie, bo takiego typu celu już nie ma. Drugi: konwersje w nowym modelu liczą się domyślnie za każdym wystąpieniem, a nie raz na sesję, więc liczby po migracji potrafią nie zgadzać się ze starymi i to nie jest błąd wdrożenia.
Piszę o tym otwarcie, bo to główna przyczyna rozczarowań. Nowa usługa jest młoda i część rzeczy, do których jesteśmy przywiązani, po prostu w niej jeszcze nie działa albo działa inaczej.
Po drugiej stronie jest rzecz, która w starym Analytics była płatna: eksport surowych danych do hurtowni. Dostępny bez dodatkowych opłat, z zapisem na poziomie pojedynczych zdarzeń. Dla firm, które potrafią to wykorzystać, to najmocniejszy argument za wcześniejszym wdrożeniem.
Moja rekomendacja dla klientów jest w tym momencie ostrożna i sprowadza się do trzech punktów.
Zbieraj dane w nowej usłudze równolegle, nie zamiast. Stare Analytics działa, raportowanie firmowe stoi na nim od lat i nie ma powodu tego ruszać. Nowa usługa potrzebuje natomiast historii — im wcześniej zacznie zbierać, tym szybciej będzie z niej pożytek, bo danych nie da się uzupełnić wstecz.
Przy okazji wdrożenia zrób porządek w planie pomiaru. Wypisz, jakie działania na stronie faktycznie mają znaczenie dla firmy, i tylko te zdarzenia zaplanuj. Widziałem już kilka wdrożeń, w których przeniesiono trzysta zdarzeń ze starej konfiguracji, z czego nikt nie oglądał trzystu.
I nie porównuj liczb między usługami wskaźnik do wskaźnika. Różnią się definicje sesji, momentu przypisania konwersji i modelu atrybucji. Zestawienia, które próbują dowieść, że „nowe Analytics zaniża ruch o dwanaście procent”, zwykle porównują dwie różne rzeczy i prowadzą do złych wniosków.
Są sytuacje, w których nie odkładałbym tematu na później.
Pierwsza to firma, która ma aplikację mobilną obok strony i chce widzieć jednego użytkownika w obu miejscach. Stary model tego praktycznie nie umiał, nowy jest pod to zaprojektowany.
Druga to sklep planujący w najbliższych miesiącach przebudowę pomiaru, wymianę systemu tagowania albo wdrożenie warstwy danych. Skoro i tak ktoś będzie grzebał w tagach, taniej zrobić to raz i od razu poprawnie w obu usługach.
Trzecia to zespół, który już dziś odbija się od limitów starego narzędzia — próbkowania w większych raportach albo limitu celów. Tam nowy model rozwiązuje realny problem, a nie tylko przygotowuje na przyszłość.
Wszystkim pozostałym mówię to samo: założyć, wdrożyć podstawowe zdarzenia, pilnować, żeby zbierało dane, i wrócić do tematu, gdy narzędzie dojrzeje. Kolejność jest ważniejsza niż pośpiech.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |