Event Tracking w aplikacjach mobilnych: co to jest, typy zdarzeń i jak skonfigurować

Co to jest Event Tracking?

Event Tracking — to proces zbierania, przechowywania i analizy dyskretnych działań użytkownika w aplikacji. Każde zdarzenie składa się z nazwy (event_name) i zestawu parametrów (event_params). Na przykład zdarzenie purchase ma parametry price, currency, product_id, quantity.

W przeciwieństwie do Screen View, który rejestruje fakt otwarcia ekranu, Event Tracking opisuje, co dokładnie użytkownik robi na tym ekranie: kliknął przycisk „Kup”, otworzył koszyk, zastosował kod promocyjny. Bez zdarzeń nie da się zrozumieć motywacji i kontekstu działań użytkownika.

Struktura zdarzenia

Każde Analytics Event zawiera pola obowiązkowe i opcjonalne. Obowiązkowe: event_name, event_timestamp, user_id (lub device_id). Opcjonalne: parametry, opis kontekstu.

Parametr revenue jest szczególnie ważny — przekazywany jest do platform MMP w celu automatycznego obliczania ROAS i LTV.

Typy zdarzeń w analityce mobilnej

Zdarzenia klasyfikowane są według pochodzenia i przeznaczenia. Podział pomaga zorganizować strukturę danych i przypisać prawa dostępu dla różnych zespołów.

Zdarzenia automatyczne (SDK)

SDK platform analitycznych automatycznie zbierają podstawowe zdarzenia: app_install, app_remove, session_start, screen_view. Firebase Analytics generuje około 20 automatycznych zdarzeń bez ani jednej linijki kodu. Te zdarzenia pokrywają podstawowe metryki, ale nie dają zrozumienia logiki biznesowej.

Zdarzenia niestandardowe (Custom Events)

Zdarzenia niestandardowe — to co czyni Event Tracking wartościowym. Opisują one działania biznesowe: add_to_cart, start_subscription, level_complete, share_content, search_performed. Zdarzenia niestandardowe wymagają jawnego wysłania z kodu aplikacji.

// Wysyłanie zdarzenia niestandardowego w Firebase
val bundle = Bundle().apply {
    putString(AnalyticsParam.ITEM_ID, "prod_789")
    putString(AnalyticsParam.ITEM_NAME, "Premium Subscription")
    putString(AnalyticsParam.CURRENCY, "USD")
    putDouble(AnalyticsParam.PRICE, 29.99)
    putString(AnalyticsParam.SOURCE, "onboarding_screen")
}
FirebaseAnalytics.getInstance(this)
    .logEvent("subscribe_premium", bundle)

W przykładzie zdarzenie subscribe_premium zawiera cztery parametry kontekstu. Parametr source pozwala zrozumieć, z którego ekranu użytkownik dokonał subskrypcji — onboarding, ustawienia czy paywall.

User Properties i Super Properties

Oprócz zdarzeń, Event Tracking obejmuje User Properties — atrybuty przypisane do użytkownika: poziom subskrypcji, kraj, wersja aplikacji. User Property wysyłany jest raz i stosowany do wszystkich kolejnych zdarzeń sesji. Pozwala to segmentować analitykę bez dodawania parametrów do każdego zdarzenia.

Super Properties (Amplitude) lub Global Properties (Mixpanel) — atrybuty przypisane do sesji, a nie do użytkownika. Używane do testów A/B: variant_id jako Super Property dodawany jest do wszystkich zdarzeń w sesji, a analityk widzi, do której grupy należy użytkownik.

Revenue-zdarzenia

Revenue-zdarzenia — oddzielna klasa do rejestracji transakcji. Zawierają kwotę, walutę i rodzaj zakupu (subskrypcja, jednorazowy zakup, przywrócenie). Platformy MMP (AppsFlyer, Adjust) wymagają revenue-zdarzeń do obliczania ROAS.

Według danych Branch (2024), aplikacje prawidłowo przekazujące revenue-zdarzenia do MMP otrzymują o 25% dokładniejsze dane dotyczące atrybucji i mogą optymalizować kampanie pod kątem LTV, a nie CPI.

Jak skonfigurować Event Tracking?

Konfiguracja Event Tracking przebiega w trzech etapach: planowanie schematu zdarzeń, integracja SDK, walidacja danych.

Etap 1: Projektowanie schematu zdarzeń

Stwórz Event Taxonomy — dokument, w którym opisane jest każde zdarzenie: nazwa, parametry, wyzwalacz wysyłki, właściciel. Przykład dla e-commerce: order_completed → parametry: order_id, total_price, items_count, payment_method, shipping_city.

• Każde zdarzenie odpowiada na pytanie: co zrobił użytkownik?
• Każdy parametr odpowiada na pytanie: w jakim kontekście?
• Unikaj zdarzeń bez parametrów — są bezużyteczne do analizy

Etap 2: Integracja SDK

Podłącz Analytics SDK do projektu. Firebase Analytics, Amplitude, Mixpanel — każde SDK wymaga inicjalizacji w Application.onCreate(). Przykład dla Flutter:

import 'package:firebase_analytics/firebase_analytics.dart';

class AnalyticsService {
  final _analytics = FirebaseAnalytics.instance();

  Future<void> logPurchase({
    required String productId,
    required double price,
    required String currency,
  }) async {
    await _analytics.logEvent(
      name: 'purchase_completed',
      parameters: {
        'product_id': productId,
        'price': price,
        'currency': currency,
        'timestamp': DateTime.now().millisecondsSinceEpoch,
      },
    );
  }
}

Klasa AnalyticsService centralizuje wysyłkę wszystkich zdarzeń. Każda metoda odpowiada działaniu biznesowemu. Upraszcza to wyszukiwanie wysyłki — jeśli zdarzenie nie przychodzi, szukasz po nazwie metody w kodzie. Przy skalowaniu projektu liczba metod może wzrosnąć do 50–100, ale struktura pozostaje czytelna dzięki grupowaniu według funkcji.

Etap 3: Walidacja przez DebugView

Firebase DebugView pozwala widzieć zdarzenia w czasie rzeczywistym na urządzeniu programisty. Włącz tryb: adb shell setprop debug.firebase.analytics.app your.package. Wszystkie zdarzenia pojawią się w konsoli Firebase z opóźnieniem mniejszym niż 5 sekund.

Po włączeniu DebugView otwórz aplikację i wykonaj scenariusz testowy — rejestrację, zakup, przeglądanie katalogu. W konsoli sprawdź: czy wszystkie zdarzenia zostały wysłane, czy parametry są prawidłowe, czy nie ma duplikacji. Amplitude oferuje podobne narzędzie — Amplitude Debugger dla iOS i Android.

Automatyczna walidacja przez CI/CD — kolejny poziom jakości. Dodaj do pipeline’u skrypt, który sprawdza, czy każde zdarzenie ze schematu zostało wysłane przynajmniej raz podczas testowego przebiegu. Zapobiega to wdrażaniu wersji z pominiętymi zdarzeniami i oszczędza czas inżynierów QA.

Najlepsze praktyki nazewnictwa zdarzeń

Nazewnictwo zdarzeń — najbardziej niedoceniany aspekt Event Tracking. Nieprawidłowa nazwa sprawia, że analityka staje się bezużyteczna, gdy w projekcie jest więcej niż 50 zdarzeń.

Standard Object + Action

Używaj wzorca object_action (małe litery, snake_case): product_added, cart_opened, payment_failed, subscription_cancelled. Obiekt — encja, działanie — czasownik w czasie przeszłym. Czyta się to jak zdanie: „produkt dodany”, „koszyk otwarty”.

• product_viewed, nie „tap_on_product_card” (zdarzenie — rezultat, nie działanie)
• order_completed, nie „successful_payment_transaction” (krótko i jasno)
• level_started, nie „begin_level_with_parameters” (bez zbędnych słów)

Zakazane wzorce

NIE używaj spacji („Add to Cart”), CamelCase („AddToCart”), kropki („add.to.cart”), łącznika („add-to-cart”). Większość SDK zaleca snake_case. NIE używaj nazw elementów UI („btn_submit_clicked”) — zdarzenie powinno być biznesowe, nie techniczne.

Dla prefiksu dodawaj nazwę funkcji lub ekranu: onboarding_step_completed, checkout_payment_selected. Pozwala to filtrować zdarzenia według funkcjonalności w raportach.

Typy parametrów zdarzeń

Parametry dzielą się na trzy typy: string (wartość), number (liczba do agregacji), boolean (flaga). Parametry string zawierają dane kategoryczne: kraj, źródło ruchu, nazwa produktu. Parametry number służą do metryk: cena, ilość, czas trwania. Parametry boolean oznaczają stan: is_trial, is_promo_applied.

Unikaj przekazywania obiektów lub tablic w jednym parametrze — platformy analityczne nie potrafią ich parsować. Zamiast JSON-stringa w jednym polu przekaż kilka płaskich parametrów. Na przykład zamiast items_count_total przekaż osobno items_count i total_price.

Platformy dla Event Tracking

Wybór platformy Event Tracking zależy od skali projektu i zespołu. Rozważmy trzy warianty różnych poziomów.

Firebase Analytics (bezpłatnie, do 500 zdarzeń)

Firebase — standardowy wybór dla startupów. Bezpłatny limit — 500 różnych event_name, nieograniczona liczba parametrów. Integracja z BigQuery dla niestandardowej analityki. Minusy: ograniczona segmentacja, brak automatycznego łączenia zdarzeń w sesje.

Amplitude (Pro od 1000 USD/mies.)

Amplitude — platforma do analityki produktowej. Obsługuje Behavioural Cohorts, Funnel Analysis, Pathfinder. Pozwala tworzyć wirtualne zdarzenia z kombinacji rzeczywistych. Integruje się z 50+ narzędziami przez Segment.

Segment (od 120 USD/mies.)

Segment — middleware do zarządzania zdarzeniami. Wysyłasz zdarzenia do Segment, a on rozdziela je do 300+ narzędzi. Przydatny w enterprise, gdzie jednocześnie używane są Firebase, Amplitude, Mixpanel, Braze i Salesforce.

PostHog (alternatywa open-source)

PostHog — open-source’owa platforma analityki produktowej z własnym Event Tracking. Obsługuje autokapturę zdarzeń, nagrywanie sesji i feature flags. Wdrażana na własnym serwerze, co jest kluczowe dla projektów z GDPR lub danymi poufnymi. Oferuje kompatybilne z Pythonem API dla potoków ETL.

Dla projektów Flutter zalecane jest flutterfire_analytics + Amplitude przez plugin amplitude_flutter. Dla React Native — react-native-firebase + mixpanel-react-native.