Analytics and Crash Reporting for Android Apps

Many apps track either everything (thousands of meaningless events) or nothing. Good instrumentation starts from questions: where do new users drop off, which features drive retention, which crashes affect most users, and adds just enough events to answer them.

The observability stack

Designing analytics events

1. Write the questions first: "What % of new users create their first note within a day?"
2. Define a small event set: verbs in snake_case, with consistent parameters.
3. Document it in a tracking plan, and review new events in PRs.

sealed class AnalyticsEvent(val name: String, val params: Map<String, Any> = emptyMap()) {
    data object SignUpCompleted : AnalyticsEvent("sign_up_completed")
    data class NoteCreated(val source: String) : AnalyticsEvent("note_created", mapOf("source" to source))
    data class PaywallViewed(val placement: String) : AnalyticsEvent("paywall_viewed", mapOf("placement" to placement))
    data class PurchaseCompleted(val productId: String) : AnalyticsEvent("purchase_completed", mapOf("product_id" to productId))
}

interface Analytics { fun log(event: AnalyticsEvent) }

class FirebaseAnalyticsLogger(private val fa: FirebaseAnalytics) : Analytics {
    override fun log(event: AnalyticsEvent) {
        fa.logEvent(event.name, Bundle().apply {
            event.params.forEach { (k, v) ->
                when (v) {
                    is String -> putString(k, v)
                    is Long -> putLong(k, v)
                    is Int -> putLong(k, v.toLong())
                    is Double -> putDouble(k, v)
                }
            }
        })
    }
}

A typed wrapper prevents typos, makes events searchable in code, and lets you swap providers, or use a no-op in tests and debug builds.

Crash reporting that helps you fix things

// Custom keys and breadcrumbs make crashes reproducible (never include personal data)
Firebase.crashlytics.setCustomKeys {
    key("feature_flag_new_checkout", flags.isEnabled(Flag.NEW_CHECKOUT))
    key("current_screen", "Checkout")
}
Firebase.crashlytics.log("Tapped Pay with UPI")      // breadcrumb

// Non-fatal: important failures that didn't crash
try {
    paymentRepository.confirm(orderId)
} catch (e: PaymentException) {
    Firebase.crashlytics.recordException(e)
    showPaymentError()
}

• Upload R8 mapping files so stack traces are readable. The Crashlytics Gradle plugin can do this.
• Triage by users affected and trend after release, not just event counts.
• Use Android Studio's App Quality Insights to jump from crash clusters to source.

Privacy and consent

• Never log personal data (names, emails, phone numbers, message content) in events or crash logs.
• Respect consent requirements in your markets, and provide an opt-out (for example setAnalyticsCollectionEnabled(false)).
• Disclose analytics and crash SDKs in the Play Data safety form and privacy policy.
• Disable collection in debug builds to keep data clean.

From data to decisions

Frequently asked questions

Conclusion

Instrument with intent: a small, documented event set for product questions, crash reporting with context and non-fatals for engineering, Android vitals for system health, and privacy by design throughout.

Next step: launch your own product with Building and Launching an Android App as a Solo Developer.