Blog
Każde zdarzenie GA4, które widzi Twój kontener serwerowy — i skąd bierze się każde z nich
Opublikowano · 4 min czytania
Przepuszczenie GA4 przez kontener serwerowy nie zmienia tego, jakie zdarzenia istnieją. Zmienia się to, że wreszcie widzisz, które docierają — strona kontenera zlicza każdą nazwę zdarzenia, którą przekazuje. Ta lista zaskakuje w obie strony: pojawiają się zdarzenia, których nikt nie konfigurował, a brakuje tych, których się spodziewano. Oba przypadki mają proste wyjaśnienia, gdy tylko wiadomo, skąd bierze się każde zdarzenie.
Cztery zdarzenia, które tag Google wysyła w każdej usłudze
W chwili, gdy tag Google ładuje się z Twoim identyfikatorem pomiaru, płyną cztery zdarzenia bez żadnego ustawienia po drodze. Nic w Analytics ich nie wyłącza i nic w Twoim kontenerze nie musi o nie prosić.
- page_view — jedno na załadowanie strony lub na zmianę trasy w aplikacji jednostronicowej, gdy w strumieniu włączona jest opcja „zmiany strony”.
- session_start — pierwsze trafienie nowej sesji. Sesja kończy się po trzydziestu minutach bezczynności, więc odwiedzający, który wraca dwie godziny później, zaczyna kolejną.
- first_visit — raz na przeglądarkę, w pierwszej sesji, jaką GA4 kiedykolwiek z niej widziało. Wyczyszczenie ciasteczek generuje kolejne.
- user_engagement — wysyłane, gdy strona była na pierwszym planie przez dziesięć sekund lub gdy odwiedzający wychodzi po interakcji. Stąd bierze się czas zaangażowania w GA4.
Jeśli widzisz page_view i nic więcej, tag działa. To nie usterka — to strona, na której nikt jeszcze nie przewinął do samego dołu.
Dziewięć zdarzeń z pomiaru zaawansowanego — i przełącznik, który decyduje, czy dostaniesz choć jedno
Pomiar zaawansowany GA4 zbiera w przeglądarce dziewięć kolejnych zdarzeń, bez tagu dla żadnego z nich. Konfiguruje się je na strumieniu danych, nie w Tag Managerze, i dlatego kontener serwerowy przekazuje je, nie wiedząc, że istnieją.
Każde ma warunek surowszy, niż sugeruje nazwa.
- scroll — raz na stronę i tylko wtedy, gdy widoczne było 90 % wysokości strony. Nie przy dowolnym przewinięciu: przy dotarciu do dołu. Strona krótsza niż okno nigdy go nie wyzwala.
- click — kliknięcie wychodzące, do domeny innej niż bieżąca. Linki wewnętrzne się nie liczą. Zdarzenie nazywa się click, z parametrem outbound; nie ma outbound_click.
- view_search_results — załadowanie strony, której adres URL zawiera parametr wyszukiwania (domyślnie q, s, search, query lub keyword).
- file_download — kliknięcie w link kończący się rozszerzeniem dokumentu, archiwum, pliku audio, wideo lub arkusza kalkulacyjnego.
- form_start i form_submit — pierwsza interakcja z formularzem na stronie i jego wysłanie.
- video_start, video_progress i video_complete — tylko dla osadzonych odtwarzaczy YouTube i tylko gdy osadzenie ma włączone API JS.
A teraz część, która kosztuje tygodnie. Każde z tych dziewięciu zależy od głównego przełącznika pomiaru zaawansowanego w strumieniu, a strumień utworzony przez interfejs Analytics Admin API — a nie w interfejsie Analytics — ma ten przełącznik WYŁĄCZONY. Odczytaj ustawienia przez API, a każda pojedyncza opcja zwraca true; główny przełącznik po prostu nie występuje w odpowiedzi, bo jest false, a API pomija fałszywe wartości logiczne. Konfiguracja wygląda więc na w pełni włączoną i dostarcza wyłącznie page_view.
Odkryliśmy to na własnej usłudze. SignalHost włącza główny przełącznik, gdy tworzy dla Ciebie usługę; jeśli Twoja powstała inaczej, a scroll nigdy nie dociera, otwórz strumień danych w Analytics i sprawdź sam „Pomiar zaawansowany”, a nie opcje pod nim.
Siedem zdarzeń e-commerce, tylko jeśli Twoja strona je wysyła
Zdarzenia handlowe — view_item_list, view_item, add_to_cart, remove_from_cart, begin_checkout, add_payment_info i purchase — to te, na których sklepowi naprawdę zależy, i jedyne na tej stronie, których nic nie wysyła automatycznie. GA4 definiuje nazwy i kształt; Twoja strona musi wypchnąć każde z nich do dataLayer, dokładnie pod tą nazwą, z dołączonym obiektem ecommerce.
Standardowy motyw Shopify tego nie robi. Rdzeń WooCommerce tego nie robi. Robi to aplikacja lub wtyczka do dataLayer, a w Shopify zdarzenia z kasy wymagają Custom Pixel, bo kontener motywu nigdy nie ładuje się na stronach płatności. Gdy w kreatorze SignalHost wybierzesz platformę sklepową, instalujemy regułę i tag zdarzenia GA4 dla każdego z siedmiu, więc w chwili, gdy Twoja strona wypchnie purchase, zdarzenie zostanie przekazane — ale samo wypchnięcie musisz zorganizować Ty. Kolejny artykuł opisuje dokładnie, co zainstalować.
Co zlicza strona kontenera
Każde żądanie pomiarowe przechodzące przez Twój kontener jest zliczane według nazwy zdarzenia, dziennie, przez 400 dni. Zachowywana jest tylko nazwa — nie adres URL, nie identyfikator klienta, ani jeden parametr — i to właśnie pozwala bezpiecznie trzymać ją tak długo. Lista pokazuje, co dotarło do Twojej nazwy hosta, więc odpowiada na pytanie, na które sam Analytics odpowiedzieć nie potrafi: czy przeglądarka w ogóle to wysłała?
Spodziewaj się nierównych liczb. Każde załadowanie strony to page_view; tylko załadowania, które docierają do dołu, to scroll; tylko sesje dłuższe niż dziesięć sekund to user_engagement. Strona z dziesięcioma odsłonami i dwoma zdarzeniami scroll to normalna strona.
Gdy brakuje zdarzenia
Dwa przypadki, a strona kontenera je rozróżnia.
Jeśli zdarzenia nie ma na liście kontenera, Twoja strona nigdy go nie wysłała. Kontener nie może przekazać tego, co nie dotarło. W przypadku zdarzenia standardowego sprawdź przełącznik pomiaru zaawansowanego w strumieniu; w przypadku zdarzenia handlowego sprawdź, czy wypchnięcie do dataLayer następuje, z właściwą nazwą, na stronie, na której powinno.
Jeśli zdarzenie jest na liście kontenera, ale nie ma go w Analytics, dotarło i zostało przekazane, a problem leży po stronie Google: zły identyfikator pomiaru, filtr danych, usługa na innym koncie niż to, na które patrzysz, albo po prostu opóźnienie raportów — czas rzeczywisty pokazuje je w sekundy, raporty standardowe mogą potrzebować doby.
