In-App-Events

Definition: In-App-Events sind spezifische Nutzeraktionen innerhalb einer mobilen App die als Ereignisse (Events) getrackt und an Analytics- oder Attribution-Plattformen übermittelt werden. Jedes Event hat einen Namen (z. B. «purchase», «level_complete», «add_to_cart») und optionale Parameter (Kaufbetrag, Produkt-ID, Level-Nummer). In-App-Events sind die Grundlage für: Attribution (welche Kampagne hat welche In-App-Aktion ausgelöst?), ROAS-Berechnung (Return on Ad Spend auf Basis echter Kaufwerte), LTV-Modellierung, automatisierte Gebotsstrategien in Google UAC und Meta und die Auslösung von Re-Engagement-Kampagnen. SDKs von Firebase, AppsFlyer, Adjust, Mixpanel und Amplitude implementieren das Event-Tracking auf Client-Seite; Server-to-Server (S2S) Events sind für sicherheitskritische Events (Kauf-Bestätigung) der bevorzugte Ansatz. Apple bietet zudem «In-App Events» als Store-Feature: Entwickler können zeitlich begrenzte Events (Verkäufe, neue Features, Challenges) direkt im App Store anzeigen lassen.

Erläuterung

Die Qualität aller Marketing-Entscheidungen hängt direkt von der Qualität des Event-Trackings ab. Ein fehlerhafter Purchase-Event (doppelte Zählung, falscher Revenue-Parameter) führt zu falschen ROAS-Werten und damit zu fehlgeleiteten Budget-Entscheidungen. Ein guter Event-Tracking-Plan und sorgfältiges Testing vor dem Live-Gang sind deshalb keine optionale Qualitätsarbeit – sie sind geschäftskritisch.

Event-Taxonomie und Standard-Events

Firebase/Google Standard-Events: first_open (automatisch), session_start (automatisch), purchase (Revenue-Event, Parameter: value, currency, transaction_id), add_to_cart, begin_checkout, sign_up, login, level_up, share; standardisierte Namen erleichtern Google UAC-Integration; automatisch in Google Ads als Conversion-Ziele nutzbar
AppsFlyer Standard-Events: af_purchase (value, revenue, currency, content_id), af_add_to_cart, af_login, af_complete_registration, af_level_achieved, af_tutorial_completion; AppsFlyer-spezifische Namen map zu Partner-Events in Ad-Netzwerken; automatische Weiterleitungs-Konfiguration an Meta, TikTok, Google etc.
Custom Events: Eigene Event-Namen für produktspezifische Aktionen; Beispiel: workout_completed (Fitness-App), recipe_saved (Koch-App), document_signed (Business-App); Konvention: snake_case, beschreibend, keine Leerzeichen; Attribute: Parameter die zusätzlichen Kontext liefern (workout_type: «yoga», duration_minutes: 30)
Event-Hierarchie: Top-of-Funnel: app_open, session_start, tutorial_begin; Mid-Funnel: registration, add_to_cart, wishlist_add, content_view; Bottom-of-Funnel: purchase, subscription_start, trial_start; Revenue-Events: echte Kaufbestätigungen mit Currency und Value; Retention-Events: Day-7-Login, Feature-Usage-Events

Technische Implementierung

Client-Side SDK (Standard): SDK im App-Code (iOS/Android); Event-Call bei Nutzeraktion: Analytics.logEvent("purchase", parameters: {...}); SDK puffert Events und sendet gebündelt; einfach zu implementieren; Risiko: Client-Side-Manipulation, doppelte Zählung durch Netzwerkfehler-Retries; für meisten Non-Revenue-Events ausreichend
Server-to-Server (S2S) Events: Backend-Server sendet Events direkt an MMP-API nach Bestätigung der Transaktion; kein Client-Side-Code für kritische Events; verhindert doppelte Zählung (Idempotenz-Key); IDFA/GAID als Matching-Identifier übergeben; empfohlen für: Käufe, Abonnement-Events, kritische Conversion-Events; AppsFlyer S2S API, Adjust S2S Event-Endpoint
Event-Testing: Firebase DebugView: Echtzeit-Event-Monitoring auf verbundenem Gerät; AppsFlyer TestKit / Adjust Testing Console: Event-Verifikation vor Go-live; Charles Proxy / mitmproxy: HTTP-Intercept für Event-Payload-Analyse; Staging-Umgebung: Test-App mit Test-API-Keys vor Production-Release; ohne Testing: hohe Fehlerrate in Produktion
SKAdNetwork Conversion Values: Für iOS ohne IDFA-Zustimmung; 6-Bit-Wert (0–63) kodiert Post-Install-Aktionen; MMP definiert Mapping: Wert 1 = Registration, Wert 5 = Kauf unter 10 €, Wert 10 = Kauf über 50 €; Apple sendet Conversion Value nach Attributions-Timer an Ad-Netzwerk; komplexes Setup via AppsFlyer oder Adjust SKAN-Dashboard

Events für ROAS-Optimierung und Ad-Plattformen

Meta CAPI (Conversions API): Server-seitige Event-Übermittlung an Meta; ersetzt Pixel für iOS-Attribution; kombiniert mit AEM (Aggregated Event Measurement); maximal 8 priorisierte Events für iOS-Attribution; Deduplizierung via Event-ID zwischen Client und Server möglich
Google UAC tCPA-Optimierung: Purchase-Events als Optimierungs-Ziel für Google UAC; tCPA: Ziel-Cost-per-Purchase; Algorithmus optimiert Bidding auf Nutzer die wahrscheinlich kaufen; mind. 50 Conversion-Events pro Kampagne pro Woche für stabile Lernphase; zu wenige Events: undurchsichtige Bidding-Entscheidungen
Apple App Store In-App Events: Nicht zu verwechseln mit Analytics-Events; Store-Feature: Marketing-Events im App-Store-Listing anzeigen; Typen: Wettbewerbe, neue Features, Verkäufe, Premieren, Challenges; erscheint auf App-Seite und in Today/Games/Apps-Tabs; zeitlich begrenzt (max. 31 Tage); eingereicht via App Store Connect; erhöht Sichtbarkeit ohne neue Version

Praxistipp: Erstellen Sie einen Event-Tracking-Plan (Tabelle: Event-Name, Trigger, Parameter, SDK, verantwortliche Person) bevor die Entwicklung beginnt. Definieren Sie maximal 20–30 Core-Events – zu viele Events erzeugen Datenlärm und erschweren die Analyse. Implementieren Sie Purchase-Events immer Server-to-Server um doppelte Zählung zu vermeiden: ein Netzwerkfehler auf Client-Seite mit Retry kann sonst denselben Kauf zweimal loggen und Ihren ROAS verfälschen. Testen Sie jeden Event vor dem Release mit Firebase DebugView oder dem AppsFlyer TestKit – ein unentdeckter Tracking-Fehler der eine Woche in Produktion läuft, kostet Sie eine Woche Optimierungs-Datenbasis.