Passkey sering dijual sebagai solusi login yang lebih aman dan lebih mulus. Masalahnya, banyak tim berhenti di implementasi. Akibatnya, mereka tahu passkey sudah aktif, tapi nggak tahu apakah fitur itu benar-benar dipakai, berhasil, atau malah bikin user kabur di titik tertentu.
Kalau tim produk, security, dan growth di tempatmu masih debat soal dampak passkey, jawabannya bukan opini. Jawabannya ada di passkey analytics. Begitu layer pengukuran ini rapi, kamu bisa membuktikan kenaikan keamanan, mengukur drop UX, lalu menemukan bottleneck rollout sebelum skalanya makin besar.
Jawaban Singkat. Passkey analytics adalah kerangka ukur untuk melihat seberapa banyak user mendaftar passkey, berhasil login, pindah ke fallback, lalu churn saat recovery. Kalau empat metrik ini dipantau per device, OS, browser, dan cohort, tim bisa tahu apakah passkey benar-benar memperbaiki keamanan tanpa merusak konversi.
Apa itu passkey analytics, dan kenapa penting?
Passkey analytics adalah sistem pengukuran untuk seluruh perjalanan autentikasi berbasis passkey. Fokusnya bukan cuma jumlah user yang klik tombol, tetapi apa yang terjadi setelah itu, dari enrollment sampai recovery akun.
Ini penting karena adopsi passkey jarang gagal total. Biasanya, yang terjadi justru lebih licin, funnel tampak sehat dari luar, tetapi ada kebocoran besar di segmen tertentu. Misalnya, Android lama sukses rendah. Atau Safari iCloud Keychain tinggi saat enroll, tetapi fallback usage melonjak saat login lintas perangkat.
Empat metrik inti yang wajib kamu ukur
1. Enrollment rate
Ini mengukur berapa persen user yang berhasil menambahkan passkey setelah ditawari. Jangan hanya ukur impression ke click. Ukur sampai passkey benar-benar tersimpan.
- Formula dasar: completed enrollments ÷ eligible users
- Pecah per dimensi: OS, browser, device, geografi, cohort akuisisi
- Sinyal bahaya: prompt tampil tinggi, completion rendah
2. Login success rate
Ini metrik paling dekat ke pengalaman user harian. Kalau login success turun, trust ikut turun. Karena itu, success rate harus dibaca bersama error reason, bukan angka agregat saja.
- Formula dasar: successful passkey logins ÷ initiated passkey logins
- Lihat juga: median time to authenticate, retry count, abandon rate
- Sinyal bahaya: success rate global bagus, tetapi buruk di browser tertentu
3. Fallback usage
Ini mengukur seberapa sering user keluar dari alur passkey lalu pindah ke OTP, password, magic link, atau recovery lain. Banyak tim mengira fallback rendah selalu bagus. Padahal belum tentu.
Kalau fallback usage nol, bisa jadi user memang lancar. Namun bisa juga karena opsi fallback tersembunyi, sehingga user malah drop sebelum selesai. Jadi, bacalah metrik ini bersama abandonment.
- Formula dasar: fallback logins ÷ initiated passkey logins
- Pisahkan: user memilih fallback, sistem memaksa fallback, passkey unavailable
- Sinyal bahaya: fallback rendah, abandon tinggi
4. Recovery churn
Ini metrik yang paling sering hilang, padahal paling mahal. Recovery churn menunjukkan berapa banyak user yang masuk recovery flow lalu tidak kembali menyelesaikan akses akun.
- Formula dasar: unrecovered users after recovery start ÷ recovery-start users
- Pisahkan: lost device, new device, revoked credential, account lock
- Sinyal bahaya: recovery berhasil teknis, tetapi user tidak kembali aktif
Framework sederhana, ukur dengan model ELSF
Agar datamu gampang dibaca lintas tim, pakai model ELSF, yaitu Enroll, Login, Switch, Fix. Ini lebih berguna daripada dashboard yang terlalu penuh event.
- Enroll: impression, accept, create, complete
- Login: prompt shown, auth success, auth fail, duration, retries
- Switch: fallback chosen, fallback forced, fallback success
- Fix: recovery start, recovery complete, recovery churn, re-enroll
Kenapa model ini kuat? Karena ia menghubungkan security, UX, dan growth dalam satu bahasa. Security bisa melihat penurunan password exposure. Produk bisa melihat friction. Growth bisa melihat dampak ke retention dan conversion.
Insight yang sering terlewat, fallback tinggi belum tentu buruk
Banyak dashboard memberi alarm saat fallback usage naik. Padahal, dalam rollout awal, fallback yang sehat justru bisa menyelamatkan conversion. Yang lebih berbahaya adalah fallback tak terlihat, karena user bingung, stuck, lalu pergi.
Jadi, targetmu bukan menghapus fallback secepat mungkin. Targetmu adalah mengurangi fallback yang dipicu kegagalan teknis, sambil mempertahankan fallback yang membantu user menyelesaikan login. Ini beda besar, dan biasanya jadi titik buta tim yang terlalu fokus pada angka adopsi.
Event apa saja yang perlu dicatat?
Kalau implementasimu memakai WebAuthn atau platform passkey lain, event minimum berikut sudah cukup untuk analisis yang tajam:
- passkey_offer_viewed
- passkey_enroll_started
- passkey_enroll_completed
- passkey_login_started
- passkey_login_completed
- passkey_login_failed
- fallback_selected
- fallback_forced
- recovery_started
- recovery_completed
- passkey_reenrolled
Setiap event sebaiknya membawa properti seperti platform, browser, OS version, credential type, RP ID, network hint, dan cohort user. Dokumentasi teknis passkey dan WebAuthn bisa kamu cek di WebAuthn Guide, spesifikasi resmi W3C WebAuthn, serta praktik implementasi dari FIDO Alliance.
Cara membaca dashboard tanpa tertipu angka agregat
Angka rata-rata sering menenangkan, tetapi sering juga menipu. Karena itu, selalu pecah dashboard ke beberapa irisan penting.
- Per perangkat: mobile vs desktop
- Per OS dan browser: iOS Safari, Android Chrome, Windows Edge, macOS Safari
- Per status user: baru, returning, high-value, admin, risky
- Per konteks login: same-device, cross-device, recovery-driven
Kalau kamu sudah memakai WordPress atau sistem login lain yang mulai melirik passkey, artikel WP Pakai Passkeys: Login Tanpa Password, Apakah Sudah Aman? bisa jadi bacaan lanjutan untuk sisi implementasi dan risiko praktisnya.
Patokan sehat untuk rollout awal
Nggak ada benchmark universal yang cocok untuk semua produk. Namun, untuk rollout awal, kamu bisa pakai arah evaluasi berikut:
- Enrollment rate naik, artinya prompt dan edukasi bekerja
- Login success stabil atau naik, artinya UX tidak rusak
- Fallback forced turun, artinya reliabilitas passkey membaik
- Recovery churn turun, artinya user tidak hilang saat pindah device atau kehilangan akses
Kalau enrollment naik tetapi recovery churn ikut naik, rolloutmu belum matang. Kalau login success tinggi tetapi fallback forced tetap tinggi di segmen tertentu, berarti ada bottleneck teknis yang belum dibereskan.
FAQ
Apakah passkey analytics cuma penting untuk tim security?
Tidak. Tim security butuh bukti penurunan risiko. Tim produk butuh bukti friction. Tim growth butuh dampak ke retention, activation, dan conversion. Semuanya bertemu di metrik yang sama.
Berapa metrik minimum untuk mulai?
Mulai dari empat inti ini, enrollment rate, login success, fallback usage, dan recovery churn. Setelah itu, tambahkan segmentasi per device, OS, browser, lalu alasan kegagalan.
Kenapa recovery churn sering lebih penting daripada enrollment rate?
Karena enroll yang tinggi belum menjamin user bisa kembali masuk saat ganti perangkat atau kehilangan akses. Recovery churn yang jelek bisa menghapus keuntungan dari adopsi passkey yang tampak bagus di awal.
Apakah fallback harus dihilangkan setelah passkey stabil?
Biasanya tidak. Fallback tetap perlu, tetapi harus diposisikan sebagai jalur aman dan terukur. Fokusnya adalah mengurangi fallback karena kegagalan teknis, bukan menghapus opsi bantuan untuk user.
Pada akhirnya, passkey bukan proyek UI kecil. Ini perubahan besar pada cara user membuktikan identitas. Tanpa analytics, timmu cuma menebak. Dengan passkey analytics yang rapi, kamu bisa menunjukkan mana peningkatan keamanan yang nyata, mana gesekan UX yang masih bisa diterima, dan mana bottleneck rollout yang harus dibenahi lebih dulu.
Kalau kamu sedang merancang atau mengaudit rollout passkey, simpan artikel ini sebagai checklist awal. Lalu, bagikan ke tim produk, security, dan growth supaya semua melihat funnel yang sama.
