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.
Najczęstsze pytanie, jakie słyszę po przejściu klienta na nową właściwość Analytics, brzmi: „gdzie jest mój panel?”. Ten sam ekran, który przez lata otwierał w poniedziałek rano, żeby w trzydzieści sekund zobaczyć, ile było transakcji i z jakich kanałów. W GA4 tego ekranu nie ma i nikt go nie przeniesie za nas.
Dobra wiadomość jest taka, że da się zbudować coś równoważnego, a przy odrobinie pracy nawet lepszego. Zła — że składa się to z kilku różnych mechanizmów rozrzuconych po interfejsie, a żaden z nich nie nazywa się „panelem”. Trzeba wiedzieć, do czego służy biblioteka, kiedy sięgnąć po eksplorację, a kiedy w ogóle wyjść z Analytics do zewnętrznego narzędzia raportowego.
Poniżej opisuję, jak podchodzę do tego na kontach, które prowadzę. Termin „pulpit” traktuję tu roboczo — jako jeden ekran, na którym widzę stan konwersji bez klikania po pięciu raportach.
Warto zacząć od uczciwego ustawienia oczekiwań, bo to oszczędza godzinę szukania. W Universal Analytics panele były osobną sekcją: dodawało się widżety, wybierało wskaźnik, typ wykresu, filtr, i powstawał ekran złożony z klocków. Można było taki panel zaimportować z galerii i udostępnić.
W GA4 nie ma ani tej sekcji, ani widżetów, ani galerii. Google nie zapowiedział ich powrotu, więc nie ma na co czekać. Zamiast jednego miejsca mam trzy narzędzia, które razem pokrywają to samo zadanie:
Jest jeszcze jedna różnica organizacyjna: biblioteka jest widoczna tylko dla osób z prawem edycji właściwości. Osoba z dostępem do samego czytania danych zobaczy efekt naszej pracy w menu, ale sama nie zmieni układu. W praktyce to zaleta — mniej bałaganu w nawigacji.
Pulpit jest tylko sposobem wyświetlania. Jeśli pod nim leży bałagan, przyspieszy dostęp do złych liczb, i to jest gorsze niż brak pulpitu.
W GA4 nie ma celów w dawnym rozumieniu — konwersja to zdarzenie oznaczone jako konwersja w ustawieniach właściwości. Zanim złożę jakikolwiek widok, przechodzę listę zdarzeń i sprawdzam trzy rzeczy. Czy jako konwersje oznaczone są wyłącznie działania o znaczeniu biznesowym, a nie wszystko, co dało się zmierzyć. Czy nazwy zdarzeń są spójne i czytelne dla kogoś, kto nie wdrażał pomiaru. Czy zdarzenia z wartością — zakup, wysłany formularz z przypisaną wartością leada — faktycznie tę wartość przekazują.
Osobno pilnuję jednej pułapki: zdarzenie zliczane jest za każdym jego wystąpieniem. Jeśli ktoś kliknie przycisk telefonu trzy razy w jednej sesji, w raporcie zobaczysz trzy konwersje. To nie błąd wdrożenia, tylko sposób działania narzędzia, ale trzeba o tym pamiętać przy projektowaniu karty, bo inaczej pulpit będzie systematycznie zawyżał wynik i nikt nie zrozumie dlaczego.
Dopiero gdy lista konwersji jest krótka i przemyślana, przechodzę do budowania widoku.
Biblioteka znajduje się na dole lewego menu w sekcji raportów. Można w niej edytować kolekcje dostarczone przez Google albo — i tak robię zawsze — utworzyć własną, żeby nie psuć domyślnego układu.
Kolekcja to zestaw tematów i raportów widocznych w menu. W środku umieszczam raport przeglądowy, czyli ekran zbudowany z kart, oraz kilka raportów szczegółowych. Raport przeglądowy jest tym, co najbardziej przypomina panel: wybieram karty z gotowej listy, ustawiam ich kolejność, część z nich mogę przełączyć na inny wymiar albo inny okres. Na moim standardowym pulpicie konwersji są zwykle karty z liczbą konwersji w czasie, z rozbiciem konwersji na zdarzenia, z przychodem oraz z pozyskiwaniem ruchu w podziale na domyślną grupę kanałów.
Karty mają ograniczenia, których nie obejdziesz: nie zbudujesz własnej od zera i nie każdą parę wymiaru z metryką da się w niej ustawić. To nie jest kreator raportów, tylko wybór z listy.
Gotową kolekcję trzeba opublikować. Do tego momentu widzi ją wyłącznie autor, a nie ma nic bardziej frustrującego niż tłumaczenie klientowi przez telefon, gdzie ma kliknąć raport, którego u siebie nie ma. Po publikacji kolekcja pojawia się w menu wszystkich osób z dostępem do właściwości.
Karty pokazują stan. Do odpowiedzi „skąd to się wzięło” służy raport szczegółowy — wykres plus tabela z wymiarem głównym i metrykami.
Tutaj mam znacznie więcej swobody niż w kartach. Mogę utworzyć nowy raport szczegółowy, wybrać wymiar podstawowy i dodatkowy, ustawić kolumny, dołożyć filtr. Na pulpicie konwersji trzymam zwykle dwa takie raporty: jeden po źródle i medium sesji, drugi po stronie docelowej. W obu dokładam filtr na konkretne zdarzenie konwersji, bo widok „wszystkie konwersje razem” prawie nigdy nie prowadzi do decyzji.
Czego w raportach standardowych nie znajdziesz, a wielu osobom brakuje: gotowego współczynnika konwersji sesji. Trzeba go policzyć samodzielnie albo zbudować odpowiednią tabelę w eksploracji. Sam liczę go poza narzędziem, bo i tak porównuję dane z kosztami z Google Ads.
Drugi mechanizm, który zmienia wartość takiego raportu, to porównania. Zamiast segmentów z Universal Analytics w raportach standardowych włączam porównania — na przykład nowi kontra powracający, ruch mobilny kontra desktop, jeden kanał kontra pozostałe. Wykres i tabela pokazują wtedy kilka serii obok siebie. Warto wiedzieć, że porównanie ustawiam na czas pracy z raportem; nie zapisuje się ono na stałe w kolekcji, więc jeśli klient ma je widzieć zawsze, lepszym rozwiązaniem jest osobny raport z filtrem.
Są pytania o konwersje, na które pulpit z kart odpowiedzieć nie umie, i nie ma sensu go do tego naginać.
Kiedy chcę wiedzieć, na którym kroku ludzie odpadają, buduję eksplorację lejkową. Definiuję kroki jako zdarzenia, wybieram lejek zamknięty albo otwarty — zamknięty wymaga przejścia kroków po kolei, otwarty pozwala wejść w środku — i patrzę na spadki między krokami. To jedna z niewielu rzeczy, które w GA4 są wyraźnie lepsze niż w poprzedniej wersji, bo lejek składam z dowolnych zdarzeń, bez definiowania go z góry w ustawieniach.
Do pytania „co ludzie robili przed konwersją” służy eksploracja ścieżki. Zaczynam od zdarzenia konwersji i idę wstecz. Przydaje się też nakładanie segmentów, gdy sprawdzam, czy grupa, która konwertuje, pokrywa się z grupą, którą kupuję w kampaniach.
Jedna uwaga organizacyjna: eksploracji nie wstawię do kolekcji obok kart. Żyją w osobnej sekcji i domyślnie widzi je tylko autor — jeśli mają być częścią cotygodniowego przeglądu, trzeba je jawnie udostępnić i dopisać do listy rzeczy, które ktoś ma otworzyć. Dlatego traktuję je jako uzupełnienie pulpitu, nie jego element.
Granica jest dla mnie prosta. Jeśli pulpit ma służyć mnie albo osobie, która pracuje w Analytics, zostaje w bibliotece. Jeśli ma trafić do zarządu, do klienta albo łączyć dane z kilku źródeł, buduję go w Google Data Studio.
Powód jest jeden: w Analytics nie zestawię konwersji z kosztem z Google Ads i pozycjami z Search Console na jednym ekranie, ani nie wyślę tego automatycznie mailem w formie, którą ktoś naprawdę otworzy. Data Studio to potrafi, a łącznik do GA4 jest dostępny.
Trzeba tylko znać dwa ograniczenia, o które łatwo się potknąć. Po pierwsze, nie każdą kombinację wymiaru i metryki narzędzie policzy — część par jest niedopuszczalna i wykres pokaże błąd, którego treść niewiele wyjaśnia. Po drugie, przy większej liczbie elementów na stronie i krótkim odświeżaniu można wejść w limity zapytań do API i raport zacznie się ładować kilkanaście sekund. Trzymam więc jeden ekran z kilkoma wykresami, a nie dwanaście stron.
Jest jeszcze argument kalendarzowy. Google ogłosił w marcu, że Universal Analytics przestanie zbierać dane z początkiem lipca przyszłego roku. Każdy raport zbudowany dziś na starej właściwości ma więc datę ważności — jeśli mam składać pulpit od nowa, składam go na danych z GA4, nawet jeśli historia jest jeszcze krótka.
Zbudowany pulpit bardzo szybko zaczyna być traktowany jak wyrocznia, dlatego przy przekazywaniu go klientowi mówię wprost, czego z niego nie wyczyta.
Liczby konwersji z Analytics nie zgadzają się i nie będą zgadzać z liczbami w Google Ads. To dwa różne systemy pomiaru: Google Ads przypisuje konwersję do dnia kliknięcia, Analytics do dnia zdarzenia, okna atrybucji i strefy czasowe też mogą się różnić. Do rozliczania kampanii używam danych z Google Ads, do rozumienia zachowania na stronie — danych z Analytics. Zestawianie obu w jednej kolumnie i szukanie winnego rozbieżności to strata czasu.
Do tego dochodzi model atrybucji. W raportach GA4 domyślnie działa ostatnie kliknięcie w ujęciu wielokanałowym — czyli zasługa idzie do ostatniego kanału innego niż wejście bezpośrednie. Inne modele obejrzysz w sekcji reklam, w porównaniu modeli, ale pulpit oparty na standardowych kartach pokazuje właśnie ten domyślny. Kanały budujące świadomość na początku ścieżki będą w nim wyglądały słabiej, niż na to zasługują, i warto o tym powiedzieć, zanim ktoś na tej podstawie wyłączy kampanię.
Ostatnia rzecz to świeżość danych. Zdarzenia z ostatnich godzin nie są jeszcze w pełni przetworzone, więc porównywanie dzisiejszego popołudnia z wczorajszym pełnym dniem nie ma sensu. Ustawiam na pulpicie zakres od kilku dni wstecz i uczę tego wszystkich, którzy z niego korzystają.
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 |