Mobile Game Analytics Events Setup (Levels, Purchases, Retention)
Mobile game analytics without proper event taxonomy becomes useless numbers. Typical picture: Firebase or Amplitude has 300 events, but answering "why did Day-7 retention drop from 18% to 11%?" is impossible—needed data either wasn't collected or was collected with wrong parameters.
Game Event Architecture
Taxonomy built on three levels: session events, progression events, monetization events. This isn't just categorization—determines which funnels and cohort slices you can build.
Session events — session_start, session_end with session_duration_seconds. On session_end record termination reason: backgrounded, crashed, voluntary_quit. Distinguishes real churn from technical issues.
Progression events critical for retention analysis. Minimum param set for level_start / level_complete / level_fail:
// Android Kotlin + Firebase Analytics
val bundle = Bundle().apply {
putString("level_id", "world2_level07")
putInt("level_number", 23) // global ordinal
putInt("attempt_number", attemptCount) // attempts on this level
putString("difficulty", "hard")
putInt("player_score_before", currentScore)
putInt("coins_before", coinBalance)
putLong("time_in_level_ms", elapsed)
}
Firebase.analytics.logEvent("level_complete", bundle)
attempt_number — often forgotten field. Without it can't measure frustration point: how many tries before player leaves.
Monetization events — must be purchase with parameters Google/Facebook require for ROAS attribution:
// iOS Swift
Analytics.logEvent(AnalyticsEventPurchase, parameters: [
AnalyticsParameterCurrency: "USD",
AnalyticsParameterValue: 1.99,
AnalyticsParameterItemID: "coin_pack_medium",
AnalyticsParameterItemName: "500 Coins",
AnalyticsParameterItemCategory: "currency",
AnalyticsParameterTransactionID: receipt.transactionIdentifier,
"attempt_number_at_purchase": attemptCount, // custom
"level_id_at_purchase": currentLevelId
])
level_id_at_purchase and attempt_number_at_purchase show at which "pain point" of progression conversion happens. Direct insight for monetization design.
Retention Events: What Actually Matters
D1/D7/D30 retention auto-calculates in Firebase, Amplitude, GameAnalytics—if user is correctly identified. Main mistake: using installationId instead of userId after auth. After login call:
Firebase.analytics.setUserId(userId) // Firebase
amplitude.setUserId(userId) // Amplitude
Without this one user counts as multiple—retention underestimates, conversions duplicate.
For retention analysis also important daily_login event with days_since_install param. Don't rely only on system Session Start—background app doesn't generate session, but user could "return" without opening.
Verification Tools
Just adding logEvent isn't enough—verify events arrive with correct params:
| Tool | Purpose |
|---|---|
| Firebase DebugView | Real-time event viewing on specific device |
| Amplitude Event Inspector | Schema validation, user property checks |
| GameAnalytics Validator | Game-specific validation |
| Charles Proxy / mitmproxy | Intercept and inspect raw payload |
DebugView in Firebase—mandatory QA tool. Device registered via adb shell setprop debug.firebase.analytics.app YOUR_PACKAGE_NAME and all events appear real-time with params.
Common Mistakes That Cost Dearly
level_number as string instead of number. Seems minor until trying to build funnel "avg attempts by level"—aggregation breaks.
Logging events in background thread without checking. Firebase.analytics.logEvent on iOS works from any thread, but on Android some SDKs require main thread—check version docs.
Excessive events. 300 events in project is almost always problem. Google Analytics 4 limits 500 unique event names per Firebase project. Aggressive-tracking games hit this limit.
What's Included
- Event taxonomy design for specific genre and game mechanics
- Tracking implementation on Unity / native iOS (Swift) / native Android (Kotlin)
- User properties and identification setup after auth
- QA each event via DebugView / Event Inspector
- Documentation with event and parameter descriptions
Timeline
Taxonomy design and implementation for game with 20–40 events: 3–6 days depending on game mechanics complexity. Cost calculated individually.