Podstawą jest zdarzenie, nie odsłona

Cała różnica siedzi w jednym miejscu. Universal Analytics zbudowano wokół sesji i odsłon — miały własne typy trafień, a raporty były gotowymi widokami na te typy. Dlatego istniała osobna zakładka o zachowaniu, osobna o konwersjach i osobna o zdarzeniach: każda odpowiadała innej kategorii danych.

W nowej właściwości wszystko jest zdarzeniem. Odsłona jest zdarzeniem, kliknięcie jest zdarzeniem, zakup jest zdarzeniem. Różnią się nazwą i parametrami, nie klasą. Skoro dane nie dzielą się na kategorie, nie ma z czego zrobić zakładek odpowiadających tym kategoriom.

To brzmi jak abstrakcja, ale wynika z tego bardzo konkretna zmiana w pracy. Zamiast wybierać raport pasujący do pytania, opisuję pytanie wymiarami i wskaźnikami. Więcej wolności, mniej gotowych odpowiedzi — i znacznie dłuższy start.

Widoków nie ma i nie będzie

To najboleśniejsza zmiana dla każdego, kto pracował na kilku widokach jednej właściwości: jeden surowy, jeden z wykluczonym ruchem wewnętrznym, jeden na podkatalog, jeden testowy.

Nowa struktura ma dwa poziomy: właściwość i strumień danych. Strumień to źródło — witryna, aplikacja — a nie perspektywa na dane. Filtrowanie danych jest, ale bardzo wąskie: dotyczy ruchu wewnętrznego i ruchu deweloperskiego. Nie zrobisz filtrem widoku obejmującego wyłącznie jedną kategorię produktów.

W praktyce zastępuje to trzy rzeczy: porównania w raportach, odbiorcy definiowani na podstawie warunków oraz eksploracje z własnymi segmentami. Działa, ale zmienia sposób myślenia — perspektywa nie jest już właściwością zbioru danych, tylko czymś, co nakładasz przy każdym pytaniu.

Jest też konsekwencja, o której trzeba pamiętać przy ustawianiu filtra ruchu wewnętrznego: dane odfiltrowane nie wracają. Nie ma widoku surowego w tle, więc filtry ustawiam ostrożnie i tylko wtedy, gdy naprawdę wiem, co odcinam.

Wskaźniki, które zniknęły albo znaczą coś innego

Tutaj rodzi się najwięcej nieporozumień, bo część nazw została, a definicje się zmieniły.

• Współczynnika odrzuceń nie ma w nowej właściwości. Zamiast niego jest współczynnik zaangażowania, liczony na podstawie sesji zaangażowanych — czyli takich, które trwały dłużej niż ustalony próg, miały co najmniej dwie odsłony albo konwersję. To nie jest ta sama liczba odwrócona i nie należy jej tak porównywać.

• Średni czas trwania sesji ustąpił średniemu czasowi zaangażowania. Nowa metryka liczy czas, w którym karta była faktycznie aktywna, więc bywa wyraźnie niższa niż stary odpowiednik.

• Unikalne odsłony nie mają bezpośredniego zamiennika — są wyświetlenia i użytkownicy, a resztę składa się samodzielnie.

• Sesje liczą się inaczej. Nie ma restartu sesji o północy ani przy zmianie kampanii, a sam wskaźnik jest szacowany. To wystarcza, żeby dwie właściwości mierzące ten sam ruch nigdy nie pokazały identycznych liczb.

Wnioski z tego są dwa i oba niewygodne. Po pierwsze, porównywanie wskaźnika ze starego narzędzia z podobnie nazwanym w nowym jest błędem metodologicznym. Po drugie, cele w raportach zarządu trzeba przedefiniować, zanim ktoś zacznie tłumaczyć spadek „jakości ruchu” zmianą narzędzia.

Cele stały się zdarzeniami oznaczonymi jako konwersje

W starym Analyticsie cel był osobnym obiektem konfiguracji: docelowy adres, czas trwania sesji, liczba stron, zdarzenie. Limit dwudziestu celów na widok był realnym ograniczeniem projektu.

Teraz konwersja to przełącznik przy zdarzeniu. Zdarzenie musi istnieć w danych, więc kolejność pracy się odwraca: najpierw pomiar, potem oznaczenie. Nie ustawisz konwersji „wejście na stronę podziękowania” bez zdarzenia, które to wejście reprezentuje — trzeba je najpierw utworzyć, choćby jako zdarzenie własne oparte na warunku adresu.

Dla mnie to zmiana na lepsze, bo wymusza porządek w nazwach zdarzeń. Ale przy migracji oznacza, że listy celów nie przenosi się jeden do jednego. Trzeba ją przepisać, a przy okazji wyrzucić połowę pozycji, których nikt nie oglądał od dwóch lat.

Raporty standardowe są ubogie celowo

To najważniejsza rzecz do zrozumienia i najczęściej pomijana w rozmowach o migracji.

Gotowe raporty w nowej właściwości to zestaw podstawowy, przewidziany jako punkt wejścia, nie jako komplet. Cała analiza mieszka w eksploracjach: swobodna forma, ścieżki, lejki, nakładanie się segmentów. Ścieżkę użytkownika, która wcześniej była jednym z gotowych widoków przepływu, tutaj składam sam — i wychodzi z tego narzędzie lepsze, tylko wymaga nauki.

Ta zmiana ma cenę, o której trzeba mówić klientowi wprost. Osoba, która wcześniej raz w tygodniu otwierała ten sam gotowy raport, po migracji nie otworzy go wcale. Ktoś musi przygotować jej zestaw eksploracji albo dashboard w Google Data Studio i utrzymywać go w czasie.

Dane też potrafią wyglądać inaczej niż w rzeczywistości

Poza układem interfejsu są trzy mechanizmy, które zmieniają liczby, a nie widać ich na pierwszy rzut oka.

Progi danych — przy włączonych sygnałach Google raport potrafi ukryć wiersze o małej liczbie użytkowników, żeby nie dało się zidentyfikować osoby. Widać wtedy sumę, ale nie rozbicie, a przy małym ruchu to bywa dotkliwe.

Ograniczenie liczby unikalnych wartości — po przekroczeniu limitu wymiar zwija resztę do jednego wiersza zbiorczego. Kto ma tysiące adresów z parametrami, zobaczy to szybko.

Okres przechowywania danych — domyślnie dwa miesiące dla danych o użytkownikach i zdarzeniach, do zmiany na czternaście w ustawieniach właściwości. To ustawienie nie działa wstecz. Sprawdzam je w każdej nowej właściwości jako pierwsze, bo naprawa po pół roku jest niemożliwa.

Co z tym zrobić w praktyce

Podejście, które sprawdza się u mnie, ma trzy kroki i żaden nie polega na odtwarzaniu starego interfejsu.

Pierwszy: spisz raporty, z których ktokolwiek naprawdę korzysta. Nie te, które istnieją — te, na które ktoś patrzy i podejmuje decyzje. Lista skraca się zwykle do kilku pozycji i to ona jest zakresem migracji.

Drugi: dla każdej pozycji z listy ustal, jakim zdarzeniem i jakim wymiarem opisać to pytanie w nowym modelu. Część odwzorujesz w raportach standardowych, część w eksploracji, część będzie wymagała domierzenia czegoś, czego dziś nie zbierasz.

Trzeci: przez najbliższe miesiące zbieraj dane w obu narzędziach równolegle i nie próbuj uzgadniać liczb. Stare narzędzie służy do raportowania roku, nowe do budowania historii, którą będziesz mieć po 1 lipca 2023. Kto zacznie zbierać dopiero w czerwcu przyszłego roku, wejdzie w nowe narzędzie bez żadnego punktu odniesienia — i to jest jedyny błąd w tej migracji, którego nie da się później naprawić.