Eventy w Firebase jak je wykorzystać w marketingu dla aplikacji Unity, Android i iOS

Podczas konsultacji marketingowych i szkoleń, które prowadzę, najczęstszym problemem marketerów i analityków jest poprawne zrozumienie zdarzeń (eventów). Są one absolutnie kluczowe w przypadku analityki i promocji zarówno stron WWW, jak i aplikacji mobilnych. Ten artykuł ma na celu ułatwić Ci zrozumienie architektury eventów i parametrów w Google Analytics 4 (GA4) oraz jego mobilnym silniku Google Analytics for Firebase (GA4F). Proces ich wdrażania i logiki jest dzisiaj w pełni zunifikowany.

Model oparty na zdarzeniach pojawił się pierwotnie w Firebase dla aplikacji mobilnych, a następnie zrewolucjonizował analitykę webową, stając się fundamentem dzisiejszego Google Analytics 4 (które zastąpiło starego Universal Analytics). Logika mierzenia działań użytkownika jest dziś spójna dla obu platform.

Zdarzenia (Events) – serce Google Analytics 4 i Firebase

W odróżnieniu do historycznego Google Analytics, analityka w GA4 oraz Firebase opiera się w 100% na zdarzeniach (eventach) i parametrach, zamiast na sesjach i odsłonach. Widać to doskonale, gdy połączymy naszą aplikację mobilną z wgranym Firebase SDK ze strumieniem danych (data stream) w panelu GA4.

Czym dokładnie jest zdarzenie? Zdarzenie (event) to zdefiniowana interakcja w aplikacji lub na stronie o określonej nazwie, która jest rejestrowana przez GA4 / Firebase SDK. Daje nam ono możliwość analizowania, ilu użytkowników* wykonało daną akcję oraz jak często to robili w określonym czasie. Dodatkowo każde zdarzenie może mieć przypisane szczegółowe parametry, o których przeczytasz w dalszej części tekstu.

*Kim jest użytkownik według Firebase i GA4? To najczęściej synonim jednej instancji aplikacji (App Instance ID) lub przeglądarki (Client ID), chyba że wdrożysz User-ID dla osób zalogowanych. Przykłady:

• Jeżeli aplikacja została zainstalowana na urządzeniu A, odinstalowana i zainstalowana ponownie na tym samym urządzeniu A, dla podstawowej analityki to 2 różni użytkownicy (zmieniło się ID instancji).
• Zainstalowałeś aplikację na starym smartfonie, a potem kupiłeś nowy i zainstalowałeś ją ponownie. Bez wdrożenia funkcji User-ID (czyli logowania), w raportach GA4 zobaczysz dwóch różnych użytkowników.

To dzięki poprawnie zdefiniowanym eventom jesteśmy w stanie budować zaawansowane grupy odbiorców (Audiences) do Google Ads oraz precyzyjnie mierzyć skuteczność kampanii. Maksymalna liczba unikalnie nazwanych zdarzeń przesyłanych z aplikacji mobilnej to 500 (na stronach Web ten limit zniesiono). Dlatego tak ważne jest, aby projektować analitykę mądrze i opierać ją na parametrach.

Podział zdarzeń w analityce GA4 i Firebase (GA4F)

Zdarzenia w Google Analytics 4 możemy podzielić na 4 podstawowe rodzaje ze względu na ich sposób wdrożenia:

• Automatyczne – zbierane samoistnie po zaimplementowaniu Firebase SDK w aplikacji lub tagu GA4 na stronie (np. session_start, first_open).
• Udoskonalony Pomiar (Enhanced Measurement) – działające na stronach WWW zdarzenia, które można włączyć suwakiem w panelu (np. scroll, pobrania plików, kliknięcia w linki wychodzące).
• Rekomendowane (Standardowe) – zalecane przez Google nazwy zdarzeń (np. purchase, add_to_cart, level_up). Warto z nich korzystać w pierwszej kolejności. Lista rekomendowanych zdarzeń dostępna tutaj.
• Niestandardowe (Custom) – własne eventy o unikalnych nazwach, zdefiniowane całkowicie przez nas, dopasowane do specyfiki biznesu.

WAŻNE DLA AI ANALITYKI! Zdarzenia rekomendowane powinny być zawsze priorytetem. Jeżeli mierzymy sprzedaż w aplikacji mobilnej, należy użyć standardowego eventu purchase, a nie tworzyć własnego np. zakup_w_aplikacji. Ułatwi to algorytmom Google (machine learning / Gemini AI) lepsze zrozumienie Twojego biznesu, co przełoży się na skuteczną optymalizację kampanii i dokładniejsze predykcje w GA4.

Zdarzenie a parametr w GA4 – jaka jest różnica?

Zdarzenie (Event) to najprościej mówiąc główna akcja, którą wykonuje użytkownik, np. kończy poziom gry, dokonuje zakupu, rejestruje się.

Parametr to dodatkowa informacja (cecha) opisująca to konkretne zdarzenie. Może mieć wartość tekstową lub liczbową. W darmowej wersji GA4 dla jednej usługi możesz zarejestrować 50 niestandardowych wymiarów (parametry tekstowe) i 50 niestandardowych danych (parametry liczbowe).

Przykład e-commerce: Przeanalizujmy event purchase (zakup w aplikacji). Załóżmy, że użytkownik kupuje e-booka „Sztuka Gotowania” za 100 zł.

Event purchase ma powiązane ze sobą parametry:
item_category: ebook
item_name: Sztuka Gotowania
value: 100
currency: PLN
transaction_id: numer transakcji np. TX12345

Wszystkie powyższe parametry dostarczają niezbędnego kontekstu do prostej akcji „kupiono”.

Tworząc własne parametry, należy pamiętać, aby nie używać przedrostków zarezerwowanych dla systemu, takich jak: „firebase_”, „google_” oraz „ga_”.

Jak bezbłędnie wdrożyć zdarzenia GA4 w aplikacji? – 7 kroków

Jeżeli pracujesz nad wdrożeniem nowej analityki, zalecam spotkanie ze wszystkimi osobami korzystającymi z danych w firmie. Zawsze warto to skonsultować z doświadczonym analitykiem.

Najlepszą praktyką na rynku (tzw. best practice) jest wdrażanie analityki przy użyciu Google Tag Managera (GTM). Tworzy się osobne kontenery dla strony WWW, aplikacji iOS i Androida. Ułatwi to w przyszłości zarządzanie tagami bez konieczności ciągłego angażowania programistów w kolejne aktualizacje sklepowe (App Store / Google Play).

1. Ustalcie roboczo, co faktycznie chcecie mierzyć. Wypiszcie kluczowe zdarzenia, na podstawie których będziecie budować listy remarketingowe dla Google Ads oraz leśne ścieżki użytkownika. Zbieranie „wszystkiego” bez planu mija się z celem.
2. Stwórzcie jednolity Measurement Plan w Excelu. Przyjmijcie jeden schemat nazewnictwa, np. snake_case (male_litery_z_podkreslnikiem). W osobnych kolumnach opiszcie precyzyjnie dla developera, w którym dokładnie momencie ekranu dane zdarzenie (tzw. trigger) ma się odpalać.
3. Zaplanujcie parametry, aby nie dublować eventów. Zamiast tworzyć zdarzenia level_1_complete, level_2_complete, zróbcie jedno zdarzenie level_complete z parametrem liczbowym level_number. Oszczędza to limity i drastycznie ułatwia późniejsze raportowanie.
4. Sprawdźcie listę z rekomendowanymi zdarzeniami Google. Nie twórzcie własnych eventów, jeśli istnieje już natywny odpowiednik (np. używamy add_to_cart, a nie dodanie_do_koszyka).
5. Przekażcie gotowy plik (najlepiej Google Sheets) programistom do implementacji w kodzie aplikacji.
6. Debugowanie! Po zaimplementowaniu usiądźcie z developerami i skorzystajcie z narzędzia DebugView w GA4. Pozwala ono na podglądanie przychodzących zdarzeń i błędów w czasie rzeczywistym.
7. Jeśli wszystko w DebugView działa bez zarzutu – aplikacja może zostać opublikowana w sklepach Google Play i App Store.

Pamiętaj, że nowe zdarzenia pojawią się w standardowych raportach GA4 zazwyczaj z opóźnieniem do 24 godzin (dlatego testowanie w DebugView jest tak kluczowe!). Gdy dane zaczną spływać, będziesz mógł zasilić nimi systemy reklamowe.

3 kluczowe, automatyczne zdarzenia w aplikacji mobilnej:

Zdarzenia te są gotowe od razu po wpięciu podstawowego SDK, bez pisania dodatkowego kodu:

• first_open – niezbędne przy kampaniach UAC (Universal App Campaigns). Informuje o pierwszym otwarciu aplikacji po jej instalacji, co pozwala Google Ads optymalizować stawki za pozyskanie użytkownika.
• session_start – określa moment startu nowej sesji, pozwalając mierzyć zaangażowanie i źródła powrotów (retencji).
• screen_view – automatycznie mierzy ekrany przeglądane przez użytkownika, ułatwiając budowanie lejków konwersji i mapowanie ścieżek w aplikacji.

Szkolenie GA4 i Firebase? A może konsultacje?

Przeczytaj również powiązany artykuł – Czym jest Firebase w 2026 roku? Marketing aplikacji mobilnych i Unity, w którym opisałem szerszy kontekst wykorzystania tego narzędzia w dzisiejszych realiach.