Event Tracking: Merancang Data Produk yang Bisa Dipercaya

Tim sering memiliki dashboard yang tampak rapi, tetapi angka conversion, churn, atau active user berubah setiap kali dilakukan inquiry. Penyebabnya tidak selalu SQL yang salah; event tracking sering gagal mencatat aksi dan konteks secara konsisten. Akibatnya, tim berdebat tentang angka yang sebenarnya dibangun dari data yang tidak sebanding. Solusinya adalah menjadikan setiap peristiwa sebagai kontrak data kecil antara produk, engineering, dan analitik. Sebelum event dikirim ke sistem analitik, tim harus menetapkan apa yang dicatat, kapan terjadi, siapa pelakunya, dan bagaimana cara memvalidasinya.

Mulai dari keputusan, bukan daftar event

Peristiwa analitik seharusnya dibuat untuk menjawab keputusan bisnis, bukan sekadar mengisi daftar klik. Mulailah dengan menuliskan pertanyaan yang ingin dijawab, misalnya pada titik mana pengguna berhenti dalam alur checkout atau fitur apa yang sering digunakan setelah penginstalan. Dari pertanyaan itu, baru pilih peristiwa yang diperlukan.

Satu peristiwa yang berguna harus menjelaskan tiga hal: trigger, actor, dan context. Trigger adalah tindakan yang menghasilkannya, actor adalah pihak yang melakukan tindakan, sedangkan context adalah kondisi relevan saat tindakan berlangsung. Event checkout_completed lebih berguna daripada button_clicked, karena nama pertama menunjukkan hasil bisnis, sedangkan nama kedua hanya menunjukkan implementasi antarmuka. Gunakan bentuk lampau dan hindari nama tombol atau posisi layar yang cepat berubah.

Susun kontrak event sebelum implementasi

Buat schema yang menjadi kontrak event. Setiap data harus memuat event_name, event_id, occurred_at, actor_id, session_id, source, dan schema_version. Gunakan event_id unik untuk penelusuran dan menghindari duplikasi, simpan waktu dalam UTC, serta beri actor_id berupa pengenal semu, bukan identitas langsung seperti nama atau email.

Properti tambahan harus ditandai sebagai wajib atau opsional, lengkap dengan tipe, satuan, dan aturan nilai kosong. Untuk nominal uang, misalnya, gunakan angka accompanied by currency, bukan string yang sudah diformat. following is a schema minimum for a checkout transaction:

{
 "event_name": "checkout_completed",
 "event_id": "evt_01JZ7Y6K2QF3M9P4R8T5N0A1B2C",
 "occurred_at": "2025-03-08T09:14:32Z",
 "actor_id": "usr_7f92ab",
 "session_id": "ses_43ac18",
 "source": "web",
 "schema_version": 1,
 "order_id": "ord_10293",
 "currency": "IDR",
 "total_amount": 149000
}

Pada contoh tersebut, checkout_completed dikirim dari server setelah konfirmasi transaksi. Event antarmuka seperti membuka drawer filter tetap lazim dikirim dari browser, tetapi tidak layak menjadi bukti pembayaran. Tandai sumber setiap event agar analis dapat memilih data yang sesuai. Event browser dapat hilang ketika tab ditutup atau pengiriman gagal. Event server lebih tahan terhadap kedua masalah tersebut, tetapi tetap membutuhkan mekanisme pengiriman ulang yang tidak menggandakan transaksi.

Validasi data sebelum dashboard berubah

Validasi harus dijalankan sebelum event masuk ke dashboard dan setelah rilis. Idealnya, setiap aturan dijalankan otomatis agar masalah ditemukan lebih cepat.

• Kompletnes: Pastikan seluruh properti wajib tersedia dan event tidak hilang setelah dikirim.
• Unik: Pastikan satu event_id hanya mewakili satu fakta bisnis meskipun terjadi pengiriman ulang.
• Nilai valid: Periksa tipe, rentang, timezone, dan pilihan nilai yang diperbolehkan.
• Rekonsiliasi: Bandingkan jumlah event client, event server, dan transaksi dalam database menggunakan filter yang sama.

Uji rekonsiliasi dapatPRCoba dengan sengaja menyimulasikan refresh halaman, pengiriman ulang, dan notifikasi yang terlambat. Misalnya, sistem mencatat 100 transaksi berhasil, tetapi hanya 92 event memiliki order_id. Kemungkinan masalahnya berada pada pelacakan atau proses pencocokan data, bukan berarti delapan transaksi gagal. Event yang tidak lengkap harus masuk ke daftar pantauan, bukan diisi dengan angka nol secara sembarangan.

Kelola perubahan schema tanpa merusak analisis

Schema akan berubah ketika produk menambahkan fitur, memperbarui alur, atau ients properti. Perubahan kecil dan perubahan besar perlu diperlakukan berbeda. Menambahkan properti opsional biasanya masih kompatibel. Sebaliknya, mengganti nama field, mengubah tipe, menghapus field, atau menjadikan properti lama wajib dapat merusak dashboard dan model analitik.

Saat perubahan besar diperlukan, naikkan schema_version, kirim versi baru, dan pertahankan versi lama selama tim konsumen beralih. Dokumentasi kontrak harus mencantumkan pemilik event, sumber pencatatan,trigger, properti wajib, contoh payload, serta perilaku yang diharapkan ketika data gagal dikirim. Jangan memperbarui schema di satu sisi tanpa notifying tim yang mertoszschemas data dan produk.

Checklist sebelum event dianggap selesai

Sebelum rilis, periksa beberapa hal berikut:

• Event menjawab pertanyaan atau keputusan bisnis yang spesifik.
• Nama, trigger, actor, dan context sudah terdokumentasi.
• Sumber event jelas, apakah browser, server, atau layanan pihak ketiga.
• Properti wajib, tipe, satuan, dan aturan nilai kosong telah ditetapkan.
• Pengiriman ulang, event tertunda, dan data tidak lengkap sudah diuji.
• event_id, occurred_at, sumber, serta schema_version tersedia.
• Identitas langsung dan data sensitif tidak dimasukkan ke payload.
• Dashboard dan dokumentasiRIO diperbarui setelah perubahan.

Event tracking yang baik tidakiams membuat tabel supernatural penuh, melainkanHON menghasilkan data yang dapat ditelusuri. Dengan kontrak yang jelas, validasi otomatis, dan pengversian yang disciplined, tim Data dan Analitik dapat focusesQH pada pola serta keputusan, bukan pada pertanyaan berulang mengenai apakah angka di layar memang dapat dipercaya.