Event Tracking in mobilen Apps: Grundlagen, Ereignistypen und Einrichtung

Was ist Event Tracking?

Event Tracking ist der Prozess der Erfassung, Speicherung und Analyse diskreter Benutzeraktionen in einer App. Jedes Ereignis besteht aus einem Namen (event_name) und einer Reihe von Parametern (event_params). Beispielsweise hat das Ereignis purchase die Parameter price, currency, product_id, quantity.

Im Gegensatz zum Screen View, der lediglich das Öffnen eines Bildschirms erfasst, beschreibt Event Tracking, was der Benutzer auf diesem Bildschirm genau tut: Er hat die Schaltfläche „Kaufen" gedrückt, den Warenkorb geöffnet, einen Gutscheincode angewendet. Ohne Ereignisse sind die Motivation und der Kontext der Benutzeraktionen nicht nachvollziehbar.

Struktur eines Ereignisses

Jedes Analytics Event enthält Pflicht- und optionale Felder. Pflichtfelder: event_name, event_timestamp, user_id (oder device_id). Optional: Parameter, Kontextbeschreibung.

Der Parameter revenue ist besonders wichtig — er wird an MMP-Plattformen zur automatischen Berechnung von ROAS und LTV übergeben.

Ereignistypen in der mobilen Analytik

Ereignisse werden nach Herkunft und Zweck klassifiziert. Diese Unterteilung hilft, die Datenstruktur zu organisieren und Zugriffsrechte für verschiedene Teams festzulegen.

Automatische Ereignisse (SDK)

SDKs der Analyseplattformen sammeln automatisch Basisereignisse: app_install, app_remove, session_start, screen_view. Firebase Analytics generiert etwa 20 automatische Ereignisse ohne eine einzige Codezeile. Diese Ereignisse decken Basismetriken ab, geben jedoch kein Verständnis der Geschäftslogik.

Benutzerdefinierte Ereignisse (Custom Events)

Benutzerdefinierte Ereignisse machen Event Tracking wertvoll. Sie beschreiben Geschäftsaktionen: add_to_cart, start_subscription, level_complete, share_content, search_performed. Benutzerdefinierte Ereignisse müssen explizit aus dem App-Code gesendet werden.

// Senden eines benutzerdefinierten Ereignisses an 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)

Im Beispiel enthält das Ereignis subscribe_premium vier Kontextparameter. Der Parameter source zeigt, von welchem Bildschirm aus der Benutzer das Abonnement abgeschlossen hat — Onboarding, Einstellungen oder Paywall.

User Properties und Super Properties

Neben Ereignissen umfasst Event Tracking User Properties — Attribute, die an den Benutzer gebunden sind: Abonnementstufe, Land, App-Version. User Property wird einmal gesendet und auf alle nachfolgenden Ereignisse der Sitzung angewendet. Dies ermöglicht die Segmentierung der Analytik, ohne jedem Ereignis Parameter hinzufügen zu müssen.

Super Properties (Amplitude) oder Global Properties (Mixpanel) sind Attribute, die an die Sitzung gebunden sind, nicht an den Benutzer. Sie werden für A/B-Tests verwendet: variant_id wird als Super Property zu allen Ereignissen in der Sitzung hinzugefügt, sodass der Analytiker sieht, zu welcher Gruppe der Benutzer gehört.

Umsatzereignisse

Umsatzereignisse sind eine separate Klasse zur Erfassung von Transaktionen. Sie enthalten Betrag, Währung und Kauftyp (Abonnement, Einmalkauf, Wiederherstellung). MMP-Plattformen (AppsFlyer, Adjust) benötigen Umsatzereignisse zur Berechnung des ROAS.

Laut Branch (2024) erhalten Apps, die Umsatzereignisse korrekt an MMP übermitteln, um 25% genauere Attributionsdaten und können Kampagnen auf Basis des LTV statt des CPI optimieren.

Wie richtet man Event Tracking ein?

Die Einrichtung des Event Tracking erfolgt in drei Phasen: Planung des Ereignisschemas, Integration des SDK, Validierung der Daten.

Phase 1: Ereignisschema-Design

Erstellen Sie eine Event Taxonomy — ein Dokument, das jedes Ereignis beschreibt: Name, Parameter, Auslöser, Verantwortlicher. Beispiel für E-Commerce: order_completed → Parameter: order_id, total_price, items_count, payment_method, shipping_city.

• Jedes Ereignis beantwortet die Frage: Was hat der Benutzer getan?
• Jeder Parameter beantwortet die Frage: In welchem Kontext?
• Vermeiden Sie Ereignisse ohne Parameter — sie sind für die Analyse nutzlos

Phase 2: SDK-Integration

Binden Sie das Analytics SDK in das Projekt ein. Firebase Analytics, Amplitude, Mixpanel — jedes SDK erfordert eine Initialisierung in Application.onCreate(). Beispiel für 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,
      },
    );
  }
}

Die Klasse AnalyticsService zentralisiert das Senden aller Ereignisse. Jede Methode entspricht einer Geschäftsaktion. Dies vereinfacht die Fehlersuche — wenn ein Ereignis nicht ankommt, sucht man nach dem Methodennamen im Code. Bei der Skalierung des Projekts kann die Anzahl der Methoden auf 50–100 ansteigen, aber die Struktur bleibt durch die Gruppierung nach Features lesbar.

Phase 3: Validierung mit DebugView

Firebase DebugView ermöglicht die Echtzeit-Anzeige von Ereignissen auf dem Entwicklergerät. Aktivieren Sie den Modus: adb shell setprop debug.firebase.analytics.app your.package. Alle Ereignisse erscheinen mit weniger als 5 Sekunden Verzögerung in der Firebase-Konsole.

Öffnen Sie nach der Aktivierung von DebugView die App und führen Sie ein Testszenario aus — Registrierung, Kauf, Katalogdurchsicht. Überprüfen Sie in der Konsole: ob alle Ereignisse gesendet wurden, ob die richtigen Parameter übergeben werden, ob es Dubletten gibt. Amplitude bietet ein ähnliches Tool — Amplitude Debugger für iOS und Android.

Automatische Validierung durch CI/CD ist die nächste Qualitätsstufe. Fügen Sie der Pipeline ein Skript hinzu, das prüft, ob jedes Ereignis aus dem Schema mindestens einmal während des Testlaufs gesendet wurde. Dies verhindert die Auslieferung von Versionen mit fehlenden Ereignissen und spart Zeit der QA-Ingenieure.

Best Practices für die Ereignisbenennung

Die Benennung von Ereignissen ist der am meisten unterschätzte Aspekt des Event Tracking. Ein falscher Name macht die Analytik nutzlos, sobald das Projekt mehr als 50 Ereignisse umfasst.

Standard Object + Action

Verwenden Sie das Muster object_action (Kleinbuchstaben, snake_case): product_added, cart_opened, payment_failed, subscription_cancelled. Das Objekt ist die Entität, die Aktion das Verb in der Vergangenheitsform. Dies liest sich wie ein Satz: „Produkt hinzugefügt", „Warenkorb geöffnet".

• product_viewed, nicht "tap_on_product_card" (Ereignis ist das Ergebnis, nicht die Aktion)
• order_completed, nicht "successful_payment_transaction" (kurz und klar)
• level_started, nicht "begin_level_with_parameters" (ohne überflüssige Wörter)

Verbotene Muster

Verwenden Sie KEINE Leerzeichen ("Add to Cart"), CamelCase ("AddToCart"), Punkte ("add.to.cart"), Bindestriche ("add-to-cart"). Die meisten SDKs empfehlen snake_case. Verwenden Sie KEINE UI-Elementnamen ("btn_submit_clicked") — das Ereignis sollte geschäftlich, nicht technisch sein.

Fügen Sie als Präfix den Feature- oder Bildschirmnamen hinzu: onboarding_step_completed, checkout_payment_selected. Dies ermöglicht das Filtern von Ereignissen nach Funktionalität in Berichten.

Arten von Ereignisparametern

Parameter werden in drei Typen unterteilt: string (Wert), number (Zahl zur Aggregation), boolean (Flag). String-Parameter enthalten kategoriale Daten: Land, Traffic-Quelle, Produktname. Number-Parameter dienen als Metriken: Preis, Menge, Dauer. Boolean-Parameter markieren Zustände: is_trial, is_promo_applied.

Vermeiden Sie die Übergabe von Objekten oder Arrays in einem einzigen Parameter — Analyseplattformen können diese nicht parsen. Übergeben Sie statt eines JSON-Strings in einem Feld mehrere flache Parameter. Beispielsweise übergeben Sie items_count und total_price getrennt statt items_count_total.

Plattformen für Event Tracking

Die Wahl der Plattform für Event Tracking hängt vom Umfang des Projekts und vom Team ab. Betrachten wir drei Optionen auf verschiedenen Ebenen.

Firebase Analytics (kostenlos, bis zu 500 Ereignisse)

Firebase ist die Standardwahl für Startups. Das kostenlose Limit liegt bei 500 verschiedenen event_name, unbegrenzte Anzahl von Parametern. Integration mit BigQuery für benutzerdefinierte Analytik. Nachteile: eingeschränkte Segmentierung, keine automatische Verknüpfung von Ereignissen in Sitzungen.

Amplitude (Pro ab 1.000 $/Monat)

Amplitude ist eine Plattform für Produktanalytik. Unterstützt Behavioural Cohorts, Funnel Analysis, Pathfinder. Ermöglicht die Erstellung virtueller Ereignisse aus Kombinationen realer Ereignisse. Integriert sich mit 50+ Tools über Segment.

Segment (ab 120 $/Monat)

Segment ist eine Middleware zur Ereignisverwaltung. Sie senden Ereignisse an Segment, das sie an 300+ Tools verteilt. Nützlich in Enterprise-Umgebungen, in denen gleichzeitig Firebase, Amplitude, Mixpanel, Braze und Salesforce verwendet werden.

PostHog (Open-Source-Alternative)

PostHog ist eine Open-Source-Plattform für Produktanalytik mit eigenem Event Tracking. Unterstützt automatische Ereigniserfassung, Session Recording und Feature Flags. Wird auf einem eigenen Server bereitgestellt, was für Projekte mit GDPR oder vertraulichen Daten entscheidend ist. Bietet eine Python-kompatible API für ETL-Pipelines.

Für Flutter-Projekte empfehlen wir flutterfire_analytics + Amplitude über das Plugin amplitude_flutter. Für React Native — react-native-firebase + mixpanel-react-native.