7 Metrik Game Analytics untuk Menilai Kualitas Data
Kualitas data game menentukan apakah keputusan produk bisa dipercaya. Tujuh metrik berikut membantu tim data menilai seberapa sehat data yang masuk sebelum dipakai untuk analisis.
Metrik game analytics untuk kualitas data membantu tim mengetahui apakah angka di dashboard layak dipakai untuk mengambil keputusan. Fokusnya pada seberapa lengkap, konsisten, dan cepat peristiwa pemain tercatat. Tanpa pemeriksaan ini, tim produk bisa memperbaiki fitur yang salah karena datanya keliru.
1. Cakupan peristiwa (event coverage)
Cakupan peristiwa mengukur berapa persen kejadian penting di game yang benar-benar terkirim ke sistem analitik. Cara praktis: ambil sampel sesi pemain, lalu bandingkan dengan catatan klien. Jika tombol beli item tidak memicu event di sebagian sesi, angka konversi akan selalu rendah tanpa alasan yang jelas.
Sebelum menghitung cakupan, tim perlu merapikan definisi peristiwa. Daftar peristiwa yang baku memudahkan pengecekan, dan langkah menyusunnya dibahas di panduan audit game analytics langkah demi langkah.
2. Rasio duplikasi peristiwa
Event ganda muncul ketika klien mengirim ulang data setelah koneksi putus, atau saat SDK dan server sama-sama mencatat kejadian yang sama. Hitung jumlah peristiwa dengan ID unik yang sama dibagi total peristiwa pada periode tertentu. Rasio di atas satu persen biasanya cukup mengganggu saat menghitung pendapatan atau retensi harian.
Perhatikan juga perbedaan sumber data. Setiap sumber punya pola duplikasi sendiri, seperti dijelaskan saat membandingkan sumber data game analytics untuk pemula.
3. Latensi pengiriman data
Latensi adalah jarak waktu antara peristiwa terjadi dan data tersedia di gudang data. Untuk live ops, latensi beberapa jam masih bisa diterima. Untuk pemantauan harian seperti penjualan item terbatas, latensi di atas satu jam membuat tim kehilangan kesempatan merespons.
Catat latensi pada persentil ke-50 dan ke-95, bukan hanya rata-rata. Satu antrean yang macet bisa menahan ribuan peristiwa sekaligus dan merusak rata-rata keseluruhan.
4. Proporsi nilai kosong pada atribut kunci
Kolom seperti level pemain, versi aplikasi, platform, dan negara sering kosong di sebagian peristiwa. Hitung persentase nilai kosong hanya untuk atribut yang dipakai dalam analisis. Jika versi aplikasi kosong di 30 persen data, perbandingan performa antarversi jadi tidak bisa dipercaya.
Atribut dengan banyak nilai kosong kadang menandakan urutan pengiriman yang salah: peristiwa terkirim sebelum data pengguna selesai dimuat. Periksa urutan inisialisasi SDK di klien sebagai langkah pertama.
5. Konsistensi ID pengguna
Sebuah game biasanya punya beberapa jenis ID: ID perangkat sebelum login, ID akun setelah login, dan ID sesi. Metrik konsistensi mengukur berapa persen peristiwa yang bisa dipetakan ke satu ID akun. Nilai rendah membuat analisis kohort dan funnel kacau karena satu pemain tampak sebagai beberapa orang.
- Hitung rasio peristiwa tanpa ID akun yang valid.
- Periksa berapa banyak akun yang punya lebih dari satu ID perangkat aktif dalam sehari.
- Cek apakah proses penggabungan ID berjalan setiap hari, bukan hanya saat migrasi.
Persoalan ID ini juga muncul saat menyusun retention curve per segmen pemain, terutama jika segmen dibentuk dari perangkat, bukan akun.
6. Kelengkapan parameter peristiwa
Setiap peristiwa punya parameter wajib, misalnya nama item, jumlah, dan mata uang untuk transaksi. Metrik ini menghitung berapa persen peristiwa yang membawa seluruh parameter wajib sesuai kamus data. Peristiwa tanpa parameter tetap masuk, tetapi tidak bisa dipakai untuk analisis rinci.
Bandingkan hasilnya dengan daftar parameter di kamus data tim. Selisih antara definisi dan data yang masuk biasanya menunjukkan perubahan kode yang tidak diperbarui di dokumentasi.
7. Keselarasan angka lintas sistem
Angka pendapatan di dashboard analitik sering berbeda dengan laporan penyedia pembayaran atau toko aplikasi. Ukur selisih relatif antara kedua sumber setiap hari. Selisih di bawah satu persen masih wajar karena perbedaan waktu potong dan pengembalian dana.
Selisih yang melebar biasanya berasal dari kurs mata uang, potongan biaya platform, atau transaksi yang gagal tetapi tetap tercatat sebagai pembelian. Catat penyebabnya agar tim tidak menuduh sistem analitik salah tanpa bukti.
Cara memakai ketujuh metrik ini
Jalankan pemeriksaan pada rentang waktu yang sama setiap minggu, lalu simpan hasilnya sebagai deret waktu. Yang dicari adalah perubahan, bukan angka tunggal. Lonjakan duplikasi setelah rilis versi baru lebih berguna sebagai peringatan dibanding nilai duplikasi hari ini.
Untuk tim kecil, tiga metrik pertama sudah cukup menjadi alarm awal. Tambahkan sisanya ketika laporan mulai dipakai untuk keputusan berbiaya, seperti penjadwalan promo atau perubahan ekonomi dalam game.
Pertanyaan yang Sering Diajukan
Seberapa sering metrik kualitas data perlu diperiksa?
Mingguan sudah cukup untuk sebagian besar tim. Pemeriksaan harian masuk akal hanya untuk metrik latensi dan duplikasi selama masa rilis besar atau event live ops.
Apa yang harus dilakukan jika cakupan peristiwa rendah?
Mulai dari peristiwa yang paling memengaruhi keputusan, biasanya pembelian dan penyelesaian level. Periksa urutan inisialisasi SDK, lalu uji ulang pada beberapa perangkat dan versi sistem operasi yang berbeda sebelum menyimpulkan ada bug.
Apakah angka berbeda dengan laporan toko aplikasi selalu masalah?
Tidak selalu. Perbedaan waktu potong laporan, pengembalian dana, dan potongan biaya platform memang membuat angka tidak identik. Yang perlu diwaspadai adalah selisih yang membesar dari waktu ke waktu tanpa penjelasan.
