Ten artykuł jest naprawdę długi (ale jednocześnie warty przeczytania). Dlatego pozwól, że tym razem pominę wstęp i od razu przejdę do konkretów (a jest ich całkiem sporo!)
Poznaj definicję zdarzeń w Google Analytics. Dowiedz się, co i w jaki sposób warto śledzić, a także poznaj kluczowe zagadnienia związane z ich konfiguracją.
P.S. Na końcu czeka na Ciebie kilka konkretnych PRO TIPÓW, które znacznie ułatwią Ci event tracking w Twojej organizacji.
Co znajdziesz w tym artykule?
Czym są i do czego służą zdarzenia w Google Analytics?
Jakie zdarzenia warto śledzić za pomocą narzędzia od Google?
Jak prezentowała się struktura zdarzeń w UA, a jak obecnie wygląda w przypadku GA4? Opis zmian i różnic.
Zaawansowane podejścia do śledzenia zdarzeń GA4: najlepsze praktyki i trend server-side w 2025/2026
Na co warto zwrócić uwagę podczas definiowania zdarzeń w GA4?
Do wyboru, do koloru. Jakie rodzaje zdarzeń znajdziesz w Google Analytics 4?
Co zrobić, jeśli nie udało Ci się znaleźć odpowiedniego zdarzenia?
Event tracking a GA4. W jaki sposób z niego korzystać?
Jak zaimplementować zdarzenia w Google Analytics 4?
Jak jeszcze możesz przeprowadzić proces implementacji zdarzeń w GA4?
Gdzie w GA4 znaleźć już skonfigurowane zdarzenia?
Testy wykonane i co dalej?
Event tracking w Google Analytics 4 – podsumowanie i zakończenie
Zanim dasz się porwać technologicznemu wirowi, dotyczącemu zdarzeń w Google Analytics, zacznijmy od nieco luźniejszego wstępu. Co sprawia, że uznajemy dany dzień za udany? Myślę, że gdybyśmy zebrali wszystkie potencjalne odpowiedzi, to z pewnością łączyłby je jeden wspólny mianownik, czyli: “coś się działo” czyt. wystąpiło jedno lub pojawiło się więcej zdarzeń, które nas “pochłonęły” lub sprawiły, że po prostu dobrze się bawiliśmy.
I wiesz co? Nie inaczej jest w przypadku Google Analytics. Abyśmy mogli dobrze się “bawić” podczas analizowania ruchu na naszej stronie internetowej – potrzebujemy do tego zdarzeń. No, chyba że lubisz, gdy w Twoich raportach widnieją same zera. Wówczas wystarczy, że utworzysz usługę GA i tak już ją zostawisz. 😊 Kończąc to odrobinę swobodniejsze wprowadzenie – pozwól, że przejdę do konkretów.
O ile, w przypadku Universal Analytics mieliśmy do wyboru, czy chcemy urozmaicać nasze raporty, poprzez śledzenie zdarzeń (jeden z kilku rodzajów hitów), o tyle w przypadku GA4 można powiedzieć, że zostaliśmy postawieni pod analityczną ścianą. Wszystko przez fakt, że każda interakcja podjęta przez użytkownika w Google Analytics automatycznie otrzymuje miano “zdarzenia”.
Właśnie dlatego na pytanie “po co śledzić zdarzenia w Google Analytics?” możemy odpowiedzieć pół żartem, pół serio: “tak”. 😉 Tak, ponieważ to właśnie dzięki dobrze zdefiniowanym oraz prawidłowo skonfigurowanym zdarzeniom zyskasz szczegółowe informacje na temat tego, jakie interakcje są podejmowane na Twojej stronie – w jakiej ilości oraz z jaką częstotliwością.
To naturalne, że z poziomu artykułu nie jestem w stanie zaproponować Ci gotowej listy zdarzeń, która będzie idealnie dopasowana do charakteru Twojego serwisu, specyfiki biznesu, aż wreszcie – Twoich potrzeb. W związku z tym poniżej znajdziesz kilka przykładowych interakcji, które z pewnością warto rozpatrzyć jako potencjalne zdarzenie:
Jeżeli korzystasz z obu tych narzędzi jednocześnie (stosując tzw. dual-tagging) – z całą pewnością udało Ci się dostrzec pewne różnice w strukturze występujących tam zdarzeń.
W Universal Analytics masz do wykorzystania 3 podstawowe wymiary rozróżniające, a także metrykę, która określa wartość zdarzenia. Oczywiście, możesz również definiować wymiary oraz metryki niestandardowe, jednak w tym miejscu mam na myśli strukturę, która występuje domyślnie.
Jeżeli chodzi o wspomniane wymiary – w ich zakres wchodzą: kategoria, akcja oraz etykieta. Dodatkowo możesz określić tzw. “nie-interakcyjność” danego zdarzenia, której ustawienie na “0” sprawi, że w przypadku wywołania takiego zdarzenia sesja użytkownika nie będzie uznana jako odrzucenie.
A jak to wszystko wygląda w Google Analytics 4? W tym miejscu narzędzie pozostawia Ci sporo swobody. W nowej wersji Analyticsa nie ma standardowych wymiarów zdarzeń (czyli “kategorii”, “akcji” i “etykiety”). W zamian masz do wykorzystania aż do 25 parametrów – i to na poziomie przesyłanego zdarzenia. Niektóre z nich są przesyłane w sposób automatyczny (np. page_location, czy page_referrer), co sprawia, że nie musisz ich dodatkowo definiować.
Aczkolwiek, jeżeli zależy Ci na wzbogaceniu poszczególnych zdarzeń, a rekomendowane parametry przez Google nie spełniają w pełni Twoich oczekiwań – pamiętaj, że zawsze możesz zdefiniować własne parametry (maksymalna ilość znaków nazwy to 40). Informacje o pozostałych limitach odnoszących się do omawianych zdarzeń znajdziesz bezpośrednio na stronie Google – w tym miejscu.
Poza klasycznym śledzeniem zdarzeń w GA4, w 2025–2026 coraz większe znaczenie zyskują praktyki, które poprawiają jakość danych i odporność pomiaru na ograniczenia prywatności – np. server-side tracking oraz odpowiednie filtrowanie ruchu wewnętrznego. Specjaliści zalecają konfigurację odpowiednich okresów retencji danych, wykluczanie ruchu testowego oraz stosowanie dedykowanych zmiennych i modeli machine learning, by unikać „szumu” i uzyskiwać bardziej wiarygodne wskaźniki zaangażowania i konwersji.
Podczas mojej pracy bardzo często spotykam się z problemem, w którym zauważam, że spora część osób nie chce odchodzić od struktury opisywania zdarzeń i dalej używa parametrów takich jak np.: event_category, czy event_label. Takie podejście wynika głównie z przyzwyczajenia do Universal Analytics.
Oczywiście, w GA4 można przepisać te zdarzenia z UA dosłownie “jeden do jednego” (poza nie-interakcyjnością – ta funkcjonalność zniknęła wraz ze zmianą podejścia do zaangażowania użytkowników w Google Analytics 4).
Aczkolwiek, zamiast kurczowo trzymać się starych rozwiązań – uważam, że warto wykorzystać proces migracji do przemyślenia obecnej struktury zdarzeń i dostosowania jej do nowych standardów. To trochę tak, jakbyśmy po zakupie nowego samochodu przekładali silnik z poprzedniego, ponieważ “stary silnik dobrze się sprawdzał”. 🙂
Słysząc, że więcej zdarzeń oznacza także więcej danych do analizy – z pewnością możesz stwierdzić, że w takim razie chcesz śledzić… WSZYSTKO! Pomijając już fakt, że takie podejście nie jest najlepszym rozwiązaniem – na początku warto sprawdzić, jakie możliwości daje Google na “dzień dobry”.
Pierwszą kategorią zdarzeń, które warto wyróżnić, są zdarzenia automatyczne. Wraz z zaimplementowaniem Google Analytics (np. poprzez gtag, GTM-a, czy SDK Google Analytics pod Firebase) niektóre eventy same będą się “odkładać”. Przykładem takiego zdarzenia jest, chociażby session_start, który samoistnie jest wywoływany (“doklejany”) przed pierwszą interakcją na stronie w ramach danej sesji.
W obrębie automatycznych możemy wyodrębnić całkiem sporą grupę zdarzeń, które wchodzącą w zakres tzw. Enhanced Measurement (pełną listę znajdziesz tutaj). Ich plusem jest to, że możemy je w łatwy sposób wyłączyć z poziomu ustawień streama (Administracja w interfejsie). A tak już całkiem poważnie – to oczywiście nie jest to ich jedyna zaleta.
Mianowicie, ten wbudowany moduł pozwala śledzić kilka ciekawych interakcji, takich jak page_view, scroll (po przewinięciu 90% strony), czy click (w linki wychodzące). Jest to z pewnością bardzo ciekawe rozwiązanie dla biznesów wchodzących w świat analityki internetowej, ale również kilka z tych opcji z pewnością można wykorzystywać przy bardziej zaawansowanych wdrożeniach.
Przy tym wszystkim należy pamiętać o weryfikacji poszczególnych zdarzeń np. przy pomocy DebugView. Szczególnie nie warto ufać automatycznym zdarzeniom, które dotyczą formularzy lub video. Kto konfigurował śledzenie formularzy z poziomu GTM-a przy użyciu domyślnego listenera – ten doskonale wie, o co chodzi. 😊
Jeżeli zdarzenie, które Cię interesuje, nie znajduje się na liście wszystkich automatycznych zdarzeń lub też wybrane zdarzenie nie spełnia Twoich oczekiwań (np. pod kątem przekazywanych parametrów) – musisz wziąć pod uwagę drugą kategorię zdarzeń. Są nimi wszelkie eventy, które wymagają implementacji.
Google przygotował specjalną listę rekomendowanych zdarzeń, które zostały dopasowane do konkretnych branż (np. szeroko pojętej sprzedaży online), aby w ten sposób ułatwić swoim użytkownikom pracę. Pełna lista rekomendowanych zdarzeń jest dostępna pod tym adresem.
Jeśli klikniesz w konkretne zdarzenie – Twoim oczom ukaże się szczegółowa specyfikacja, w której znajdziesz strukturę potencjalnego zdarzenia oraz zalecane lub wymagane parametry.
Ze wspomnianej listy warto korzystać np. w momencie, gdy chcesz rozszerzać śledzenie. Nic nie stoi na przeszkodzie, aby zdefiniować całkowicie nową nazwę zdarzenia. Z własnego doświadczenia jednak wiem, że zdecydowanie lepiej podejść do tego “z głową”. Tak, aby szerokie możliwości i spora dowolność nie okazały się Twoim największym wrogiem.
P.S. Pamiętaj o limicie 500 unikalnych nazw zdarzeń dla aplikacji. Początkowo ten limit dotyczył również stron webowych, ale na szczęście został zniesiony.
Jeśli po dotarciu do tej części artykułu w Twojej głowie zrodził się pomysł: “Chcę zostać bohaterem w Google Analytics i zaimplementować go własnoręcznie” – poniżej czeka na Ciebie gotowa instrukcja.
Jednym z najwygodniejszych i najszybszych sposobów jest… powierzenie tego zadania specjalistom od Conversion. Wówczas wystarczy, że skontaktujesz się z nami, przekażesz niezbędne informacje, a my zajmiemy się całą resztą. Nieskromnie dodam, że akurat to rozwiązanie jest unikalne i z pewnością nie znajdziesz go w specyfikacji. Właśnie dlatego postanowiłem od niego zacząć! 😀
A teraz żarty na bok… (chociaż moje zaproszenie do współpracy z Conversion jest jak najbardziej na serio!). W końcu jesteśmy pierwszą w Polsce firmą – specjalizującą się w analityce internetowej oraz optymalizacji konwersji. Więc jeśli korzystać z usług, to z najlepszych!
Musisz wiedzieć, że możliwości implementowania takich zdarzeń jest co najmniej kilka. Najważniejsze z nich zawarłem w poniższych punktach.
Ulubionym (dla każdego analityka internetowego) jest wdrażanie zdarzeń przy użyciu GTM-a. W jego interfejsie znajdziesz gotowy template pod tag zdarzenia, w którym możesz m.in. wpisać wybraną nazwę zdarzenia, ustawić parametry oraz podpiąć regułę wywołującą dane zdarzenie. W tym wszystkim nie zapomnij, aby odnieść się do tagu konfiguracyjnego.
Oczywiście, każde zdarzenie rządzi się swoimi prawami i wymaga odpowiedniego podejścia. Jednak temat konfigurowania zdarzeń to materiał na dedykowany wpis, a nawet cały tutorial. Dlatego w tym miejscu jedynie o nim wspomniałem.
Możesz również wykorzystać do tego celu tag Google (gtag.js), który umieścisz bezpośrednio w kodzie strony. W tym przypadku należy przygotować dedykowane kody zdarzeń (zgodnie ze specyfikacją), a następnie dodać je od razu na stronie.
W większości przypadków (jeśli nie korzystasz z popularnych CMSów typu WordPress), proces ten będzie wymagał wsparcia specjalistów od IT. No, chyba że znasz się na rzeczy i masz odpowiednie dostępy do strony.
Jeżeli nie, a Twoi deweloperzy są dość mocno obłożeni – takie rozwiązanie może okazać się dość problematyczne. Zwłaszcza jeśli weźmiesz pod uwagę ewentualne zmiany i konieczność aktualizowania kodu w przyszłości, chociażby po to, aby wzbogacać śledzenie).
To z kolei nieco alternatywne rozwiązanie, które nie wymaga implementacji GA4 w środowisku, z którego pochodzą dane. Polega na przesyłaniu tzw. requestów HTTP o ustalonej strukturze (oto przykład jak zbudować potencjalny request).
Tego rodzaju podejście stosuje się zazwyczaj w specyficznych scenariuszach, do których możemy zaliczyć: przesyłanie konwersji ze sklepu offline oraz interakcje server-to-server. Stanowi również “jakieś” wyjście w przypadku ograniczeń technicznych przy osadzaniu kodów śledzących.
Oprócz wspomnianych powyżej rozwiązań, w przypadku aplikacji warto korzystać z Analytics SDK dla Firebase.
Nie samą konfiguracją człowiek żyje. Gdy już uda Ci się przebrnąć przez cały proces konfiguracji – wreszcie przyjdzie wyczekiwany moment, w którym zobaczysz owoce swojej ciężkiej pracy. W tym miejscu małe wtrącenie:
Oczywiście, do dyspozycji masz również znane i lubiane – raporty w czasie rzeczywistym. Jednak na potrzeby testowania, DebugView jest zdecydowanie lepszym miejscem.
Gdy stwierdzisz, że Twoje śledzenia działa zgodnie z planem, to z pewnością zechcesz zobaczyć inne raporty związane ze zdarzeniami. Domyślny raport znajdziesz w sekcji Raporty -> Zaangażowanie -> Zdarzenia.
Do dyspozycji masz również Eksploracje, w których możesz przygotować raporty “szyte na miarę” – odwzorować standardowy raport lub stworzyć zupełnie nowy.
Jeżeli udało Ci się dotrwać do końca tego artykułu – nie mam innego wyjścia, jak tylko Ci pogratulować oraz… wręczyć nagrodę! Na zakończenie mojego długiego i merytorycznego (mam nadzieję!) wywodu o event trackingu w GA4 przygotowałem kilka prawdziwych PRO TIPÓW, które znacznie ułatwią Ci korzystanie ze zdarzeń w GA4. Zapoznaj się z nimi i korzystaj do woli!
Jeżeli tego nie zrobisz, to przychody (np. w raportach “Generowanie przychodu”) będą wyzerowane. Łatwo się na to naciąć, jeśli wykorzystujesz warstwy danych pod standard Universal Analytics
Takie opóźnienie może wystąpić na przykład w przypadku przerwania połączenia z Internetem. Batchowanie oznacza, że zdarzenia są grupowane i wysyłane paczkami do GA4. Jednak mamy kilka wyjątków np. nie dotyczy konwersji, które są wysyłane natychmiast po wystąpieniu.
Wynika to z progowania (“thresholding”), które pojawia się w przypadku włączonej identyfikacji użytkowników opartej o Google Signals. Domyślnie ustawiona “Tożsamość na potrzeby raportowania” to “Mieszana”, w której skład wchodzi również identyfikacja na podstawie Google Signals.
Jeżeli jest to w Twoim przypadku problematyczne, a dodatkowo nie dostrzegasz wartości dodanej w takim trybie identyfikacji – możesz rozważyć przełączenie się na (dobrze Ci znaną z Universal Analytics), identyfikację opartą na urządzeniu (client_id).
Aby to zrobić, należy wejść do sekcji Administracja -> Tożsamość na potrzeby raportowania i wybrać opcję Zależne od urządzenia. Zmiana jest retroaktywna i w każdej chwili możesz powrócić do wcześniejszych ustawień – bez trwałego oddziaływania na dane.
Zwłaszcza jeżeli przesyłasz wymiary cechujące się dużą unikalnością wartości. Według Google za takie wymiary należy uznać parametry, które przekazują powyżej 500 niepowtarzalnych wartości na dzień.
Pewnie zastanawiasz się, w jaki sposób możesz zidentyfikować ten problem? Jeżeli w raporcie na poziomie wymiaru zauważysz (other) to wiedz, że “coś się dzieje”. Nie będę wchodzić w dalsze szczegóły, ponieważ jest to dość rozbudowany temat. Jednak zachęcam, aby o tym pamiętać i zanim coś zdefiniujesz jako parametr – zastanów się, czy nam jest potrzebny lub czy nie warto pogrupować jego wartości.
Co ciekawe, warto to zrobić również w przypadku parametrów przesyłanych w ramach zdarzeń Enhanced Measurement (np. search_term). Bez tego działania nie otrzymasz do niego dostępu z poziomu Looker Studio (domyślny connector) oraz np. w podsumowaniu raportu standardowego (w sekcji “Eksploracje” ta grupa parametrów jest dostępna bez dodatkowych modyfikacji).
Mam nadzieję, że udało mi się przekonać Cię do przetestowania tego rozwiązania! Jeśli wiedzę zawartą w tym artykule uważasz za wartościową to koniecznie sprawdź wpis na naszym blogu mówiący o tym dlaczego warto wdrożyć Google Tag Managera!
Tagi:
Historie sukcesów
Ostatnie wpisy na blogu
