Belajar Mobile Developer - Analytics & Crash Reporting

#Pendahuluan

Aplikasi sudah rilis — tapi perjalanan baru dimulai. Di episode 19 ini kita membangun observability: memahami apa yang pengguna lakukan (analytics), apa yang rusak (crash reporting), dan bagaimana mengubah aplikasi tanpa menunggu rilis berikutnya (remote config). Aplikasi tanpa telemetry berjalan buta: kalian tidak tahu bug, tidak tahu fitur mana yang dipakai.

Mengapa ini prioritas? Karena post-release adalah tempat fitur menemui kenyataan: crash hanya terjadi di device tertentu, fitur baru tidak dipakai siapa pun, dan pengguna keluar di langkah ketiga. Data menjawab semua itu — selama kalian mengukur dengan benar.

#Crash Reporting: Firebase Crashlytics

Crashlytics adalah standar industri untuk crash reporting. Ia menangkap stack trace, device, OS, dan konteks crash:

Integrasi Crashlytics (Android)

FirebaseApp.initializeApp(this)
 
FirebaseCrashlytics.getInstance()
    .setCrashlyticsCollectionEnabled(true)

Sertakan konteks supaya crash bisa dipahami:

Menambahkan konteks crash

Crashlytics.getInstance().setCustomKey("workout_id", workout.id)
Crashlytics.getInstance().setCustomKey("steps", steps)
 
// Untuk error yang tertangkap tapi kritis
Crashlytics.getInstance().recordException(RuntimeException("sync gagal: $msg"))

Data penting per crash: impacted users (jumlah pengguna terdampak), fatal vs non-fatal, dan grouping otomatis (crash yang sama dikelompokkan). Prioritaskan yang paling banyak terdampak, bukan yang paling baru.

#Analytics: Memahami Perilaku

Analytics menjawab: fitur apa yang dipakai? Di mana pengguna berhenti? Firebase Analytics (gratis) atau Mixpanel/PostHog (lebih dalam).

Event analytics Fitku

FirebaseAnalytics.getInstance(this).apply {
    logEvent("workout_started") {
        param("workout_type", "running")
        param("duration_min", 30)
    }
    logEvent("purchase") {
        param("item", "pro_subscription")
        param("value", 99999)
    }
}

#Metrik yang Wajib Diukur

Satu aturan emas: definisikan event sebelum menulis kode, dan beri nama konsisten (screen_view_*, action_*). Event yang semrawut menghasilkan data yang tidak bisa dibandingkan.

#Funnel: Temukan Titik Kehilangan

1. Install        100%
2. Buka beranda   92%   ← 8% hilang saat launch
3. Daftar akun    61%   ← 31% hilang di form
4. Start workout  48%   ← 13% hilang di onboarding
5. Return D7      22%

Setiap penurunan besar adalah tempat untuk diperbaiki — misal form daftar terlalu panjang atau onboarding membingungkan. Data funnel mengarahkan perhatian tim ke masalah yang berdampak.

#Remote Config

Remote Config mengubah perilaku aplikasi dari server tanpa rilis — sangat berharga untuk perbaikan cepat dan eksperimen.

Remote Config (Firebase)

val config = FirebaseRemoteConfig.getInstance()
config.setDefaultsAsync(mapOf("challenge_bonus" to 100))
 
config.fetchAndActivate().addOnCompleteListener {
    val bonus = config.getLong("challenge_bonus")
    uiState.update { it.copy(challengeBonus = bonus) }
}

Kegunaan nyata:

• Feature flags: aktifkan fitur bertahap (misal AI coach untuk 10% pengguna).
• Nilai tuning: threshold, limit, durasi — tanpa menunggu review store.
• Kill switch: matikan fitur yang bermasalah dalam hitungan menit.
• A/B test: coba dua variasi onboarding dan bandingkan konversi.

#Observability Cross-Platform

• Flutter: firebase_crashlytics, firebase_analytics, firebase_remote_config resmi.
• RN/Expo: @react-native-firebase/crashlytics atau expo-firebase; alternatif Sentry (@sentry/react-native) sangat populer.
• Native iOS: FirebaseCrashlytics + MetricKit (metrik performa bawaan Apple).

Semua provider punya konsep sama: SDK diinisialisasi di awal app, event dikirim ke dashboard, dan remote config dibaca di runtime.

#Common Pitfalls Observability

• Terlalu banyak event: ribuan event "info" membuat dashboard berisik dan data makin mahal. Ukur yang menjawab keputusan.
• Log PII: email, nama, atau lokasi presisi di analytics = pelanggaran privasi (episode 20). Anonimkan/agregasi.
• Mengabaikan non-fatal: non-fatal yang sering (misal network timeout) bisa lebih merusak UX daripada crash langka.
• Remote config tanpa audit: perubahan tanpa catatan sulit dilacak — dokumentasikan tiap key.
• Membaca metrik tanpa konteks: DAU turun bisa karena musim libur atau bug — selidiki sebelum panik.

#Penutup

Pada episode 19 ini, kalian telah membangun mata dan telinga aplikasi:

• Crashlytics dengan konteks & rutinitas triase regression.
• Analytics event terstruktur + funnel untuk menemukan titik kehilangan pengguna.
• Remote config & feature flags untuk perubahan tanpa rilis.
• Disiplin: ukur yang menjawab keputusan, jangan log PII, dan audit remote config.

Di episode 20 selanjutnya kita selaraskan dengan aturan: Privacy & Compliance Mobile — permission model, GDPR, dan data minimization untuk Fitku. Sampai jumpa!