Czym różni się model zdarzeniowy w GA4 od modelu opartego na sesjach w Universal Analytics?

Dwa różne sposoby patrzenia na ruch

Baner wejsciowyParallax

Czym różni się model zdarzeniowy w GA4 od modelu opartego na sesjach w Universal Analytics?

Dwa różne sposoby patrzenia na ruch

Autor nie posiada zdjęcia
Tomasz Piasecki
27 kwietnia 2021

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.

Jak liczy Universal Analytics

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.

Zdarzenie jako jednostka podstawowa

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.

Konwersje przestają być celami

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.

Czego jeszcze brakuje

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.

  • Widoki — nie ma odpowiednika widoków ze starego Analytics, a filtrowanie ruchu wewnętrznego rozwiązuje się inaczej. Kto opierał strukturę raportowania na kilkunastu widokach, musi ją przemyśleć od nowa.
  • Okres przechowywania danych — domyślnie krótszy niż w starym narzędziu i z twardym górnym limitem. Dane starsze niż ten limit nie będą dostępne w raportach eksploracyjnych, więc porównania rok do roku wymagają własnego archiwum.
  • Gotowe raporty — jest ich mniej i część analiz trzeba złożyć samodzielnie w sekcji eksploracji. To potężne narzędzie, ale wymaga innego sposobu pracy niż klikanie po gotowych zestawieniach.

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.

Co robić dzisiaj

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.

Kto powinien się pospieszyć

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.

Podziel się tym artykułem z innymi!

Twitter Facebook Linke.din
Autor nie posiada zdjęcia
Tomasz Piasecki
Specjalista Google Ads / SEM
Zajmuję się kampaniami Google Ads i widocznością stron w wyszukiwarce. Na blogu UDI Group piszę o tym, jak ustawienia kampanii i decyzje techniczne przekładają się na realne wyniki. Staram się tłumaczyć mechanizmy, a nie tylko podawać gotowe przepisy.