Metrik adalah kontrak
Dalam riset TI dan software engineering, metrik bukan sekadar angka yang dilaporkan di akhir eksperimen. Metrik adalah kontrak antara peneliti dan pembaca: ia mendefinisikan apa yang dimaksud "berhasil" dan apa yang dimaksud "gagal."
Seorang peneliti menulis hipotesis "sistem yang diusulkan memiliki performa lebih baik dibanding baseline." Performa diukur dari apa? Akurasi? Precision? F1-score? Waktu respons? Dan jika dipilih akurasi — akurasi terhadap apa? Apakah distribusi datanya seimbang? Jika tidak, apakah akurasi masih representatif?
Pemilihan metrik harus dilakukan sebelum eksperimen berjalan, bukan setelah melihat data dan memilih metrik yang kebetulan menghasilkan angka bagus. Praktik terakhir ini disebut "cherry-picking metrics" dan merupakan pelanggaran etika penelitian yang sangat halus namun berbahaya.
Measurement Alignment Model
Setiap pengukuran yang valid harus bisa ditelusuri dari masalah riset sampai ke hasil akhir tanpa "lompatan logis" di tengah jalan:
Problem → Concept (Abstraksi): masalah riset diekstrak menjadi konsep yang akan diselidiki. Contoh: "pengguna meninggalkan aplikasi setelah 3 hari" → konsep: user retention atau user engagement. Satu masalah bisa mengandung lebih dari satu konsep.
Concept → Variable (Operasionalisasi): konsep abstrak diterjemahkan menjadi variabel yang bisa diobservasi. User engagement bisa dioperasionalisasikan menjadi "jumlah sesi per minggu," "durasi rata-rata sesi," atau "jumlah fitur yang digunakan per sesi."
Variable → Metric (Kuantifikasi): variabel diberi satuan pengukuran yang spesifik. "Durasi rata-rata sesi" diukur dalam menit. "Waktu respons" diukur dalam milidetik (atau p95 latensi).
Metric → Data (Pengumpulan): metrik diaplikasikan pada subjek eksperimen untuk menghasilkan data aktual.
Data → Result (Analisis): data diproses melalui uji statistik untuk menghasilkan temuan yang menjawab research question.
Ancaman: construct validity
Ancaman terbesar dalam pengukuran adalah ketidaksesuaian antara apa yang ingin diukur dan apa yang sebenarnya diukur. Ini disebut ancaman terhadap construct validity.
Contoh: peneliti ingin mengukur "kemudahan penggunaan sistem." Lalu ia menggunakan waktu penyelesaian tugas sebagai metrik. Apakah waktu yang singkat berarti sistem mudah digunakan? Belum tentu — bisa juga karena pengguna sudah terbiasa dengan antarmuka yang mirip, bukan karena sistemnya intuitif.
Ancaman construct validity ini tidak terdeteksi dari analisis statistik. Ia hanya bisa dicegah dengan refleksi kritis pada tahap operasionalisasi: apakah variabel ini benar-benar mewakili konsep yang ingin diukur?
Memilih metrik yang tepat untuk TI
Beberapa panduan umum:
- Untuk sistem klasifikasi dengan kelas tidak seimbang: pilih F1-score, tidak cukup hanya akurasi
- Untuk perbandingan kinerja sistem: latensi p95 lebih informatif dari rata-rata (outlier tersembunyi)
- Untuk sistem rekomendasi: precision@K dan NDCG lebih relevan dari akurasi mentah
- Untuk uji usability: gabungan SUS score dan task completion rate lebih kuat dari satu metrik saja
- Untuk sistem machine learning: selalu laporkan confidence interval, bukan hanya titik estimasi
Rantai dari masalah ke metrik yang tidak terputus adalah fondasi eksperimen yang valid. Jika ada satu link yang lemah, seluruh hasil bisa dipertanyakan.
