Wróć do bloga

Blog

Każde zdarzenie GA4, które widzi Twój kontener serwerowy — i skąd bierze się każde z nich

Opublikowano · Zaktualizowano · 5 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.

Szesnaście zdarzeń, które może wysłać tylko Twoja strona

Zdarzenia, które przynoszą pieniądze — sprzedaż, lead, rejestracja — to jedyne na tej stronie, których nic nie wysyła automatycznie. GA4 definiuje ich nazwy i kształt; Twoja strona musi wypchnąć każde z nich do dataLayer, dokładnie pod tą nazwą, w chwili, gdy do niego dochodzi.

W każdym kontenerze SignalHost na szesnaście z nich czekają już reguła i tag zdarzenia GA4:

  • Dziewięć dla ścieżki zakupowej sklepu: view_item_list, view_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info i purchase, każde z dołączonym obiektem ecommerce.
  • Pięć dla leadów: generate_lead, contact, schedule, submit_application i subscribe.
  • Dwa dla rejestracji: sign_up i start_trial.

Standardowy motyw Shopify nie wypycha żadnego z nich, podobnie jak rdzeń WooCommerce: 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. W chwili, gdy Twoja strona wypchnie jedno z nich, tag jest gotowy, by je przekazać — samo wypchnięcie musisz zorganizować Ty, a artykuł o Shopify i WooCommerce opisuje dokładnie, co zainstalować.

Przycisk „Obsługiwane zdarzenia” na karcie „Zdarzenia” Twojego kontenera wymienia je wszystkie, wraz z tym, co oznacza każde z nich i co wypchnąć. Jeśli Twój kontener już wysyła któreś z nich do GA4 własnym tagiem, SignalHost zostawia to zdarzenie Twojemu tagowi, zamiast liczyć je dwa razy.

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.

Dwie rzeczy sprawią, że obie listy nigdy nie zgodzą się dokładnie. Odwiedzający, który nie odpowiedział na Twój baner, nadal wysyła każde zdarzenie — jako ping bez ciasteczek — a kontener je liczy, podczas gdy Analytics je odrzuca; strona pokazuje obie liczby, żeby było widać, która jest którą. A session_start i first_visit nigdy nie pojawiają się na stronie kontenera: przeglądarka nie wysyła ich jako zdarzeń, ustawia dwie flagi na pierwszym page_view, a Analytics wytwarza te zdarzenia po swojej stronie.

Nad listą karta zlicza, ile z tych szesnastu zdarzeń dotarło w ciągu ostatnich 30 dni, więc to, którego Twoja strona zapomniała wysłać, od razu rzuca się w oczy.

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 jednego z szesnastu 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.

Zaczynasz od zera? Jak skonfigurować Google Tag Manager po stronie serwera, krok po kroku.

Przestań tracić dane przez blokery

Zacznij bezpłatnie. Uruchom pierwszy kontener w kilka minut.