---
url: 'https://www.corbado.com/id/blog/authentication-process-mining'
title: 'Penambangan Proses Autentikasi: Disiplin CIAM Selanjutnya'
description: 'Penambangan proses autentikasi (authentication process mining) mengubah log kejadian kunci sandi menjadi perjalanan login yang dioptimalkan. Pelajari disiplin observabilitas CIAM ini.'
lang: 'id'
author: 'Vincent Delitz'
date: '2026-05-19T14:51:05.331Z'
lastModified: '2026-05-20T06:04:24.198Z'
keywords: 'penambangan proses autentikasi, perjalanan pengguna autentikasi, observabilitas CIAM, autentikasi step-up, optimasi perjalanan auth, authentication process mining'
category: 'Passkeys Strategy'
---

# Penambangan Proses Autentikasi: Disiplin CIAM Selanjutnya

## Key Facts

- **Penambangan proses autentikasi** memetakan **rekonstruksi log kejadian** bergaya
    **Celonis**, yang diformalkan oleh **IEEE Task Force on Process Mining** untuk alur
    kerja **ERP** pada tahun **2010-an**, ke dalam seremonial login kunci sandi. - Hal ini
    membutuhkan **lapisan observabilitas sisi klien**. Log **IDP** mencatat **upaya**,
    **keberhasilan**, dan **kegagalan** di sisi server serta melewatkan **Conditional
    UI**, permintaan biometrik, pemilihan **manajer kredensial** (credential manager), dan
    pengabaian diam-diam. - Dalam penerapan yang diamati, hanya sekitar **30%** pengguna
    yang memenuhi syarat mengikuti **jalur bahagia kunci sandi yang dirancang**, dan
    **tingkat keberhasilan agregat 92%** secara rutin menutupi **tingkat pengabaian 40%**
    pada jalur kunci sandi itu sendiri. - **Lima varian penyimpangan teratas** biasanya
    menyumbang **85%** dari seluruh penyimpangan, sehingga perbaikan yang ditargetkan
    lebih mendorong adopsi daripada pengujian A/B apa pun pada jalur bahagia. - Model
    kejadian memerlukan **3 jenis inisiasi** (`text-field`, `one-tap`, `cui`), **6 kelas
    hasil**, dan **inventaris kredensial** yang disegmentasi berdasarkan **transportasi**
    dan autentikator (**Apple**, **Google Password Manager**, **iCloud Keychain**,
    **Windows Hello**, **YubiKey**). - Data penambangan proses mengubah **autentikasi
    step-up** dari aturan OTP yang kaku - hambatan pada **95%** lalu lintas sah untuk
    menangkap **5%** yang mencurigakan - menjadi **keputusan dengan skor risiko**
    (risk-scored) yang berkelanjutan. - Tidak ada **IDP** yang menyediakan ini secara
    bawaan: **Okta**, **Ping**, **ForgeRock**, dan **Auth0** memiliki **control plane**,
    sementara penambangan proses adalah **disiplin data-plane**, membuat **analisis
    varian**, **deteksi pergeseran kohort**, dan **pengecekan kesesuaian** wajib bagi tim
    analitik CIAM pada tahun **2027**.

## 1. Pengantar

Kunci sandi (passkeys) mendorong CIAM maju. Tim terbaik mulai menginstrumentasi perjalanan
login dari ujung ke ujung, mengklasifikasikan kesalahan yang belum pernah mereka catat
sebelumnya, dan melihat telemetri sisi klien untuk pertama kalinya. Sebagian besar tim
identitas belum sampai di sana: belum ada lapisan observabilitas
[autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) yang nyata, tidak ada
grafik kejadian per sesi, tidak ada data seremonial sisi klien. Upaya, keberhasilan, dan
kegagalan di sisi server masih menjadi gambaran keseluruhan.

Penambangan proses [autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password)
(authentication process mining) adalah langkah logis berikutnya, tetapi hanya setelah data
kejadian yang mendasarinya ada. Tanpa lapisan observabilitas, tidak ada yang bisa
ditambang. Dengan adanya hal itu, disiplin baru menjadi tersedia. Ini meminjam langsung
dari penambangan proses bisnis (business process mining), yang mengubah log kejadian ERP
mentah menjadi alur kerja yang dioptimalkan pada tahun 2010-an. Saat diterapkan pada
identitas, ini membandingkan perjalanan login yang dirancang dengan perjalanan yang
sebenarnya dialami, memunculkan jalur penyimpangan, dan kemudian menutup celah tersebut
dengan [autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) step-up yang
terperinci, aturan penekanan (suppression rules), atau perubahan UX yang diukur secara
ujung ke ujung (end-to-end).

Artikel ini membingkai ulang apa yang seharusnya dibangun oleh tim CIAM di atas lapisan
observabilitas autentikasi.

### 1.1 Pertanyaan yang Dijawab oleh Artikel ini

Dalam artikel ini, kita membahas pertanyaan-pertanyaan berikut:

1. Apa yang dilakukan penambangan proses untuk BPM, dan apa paralel langsungnya untuk
   autentikasi?
2. Mengapa peluncuran kunci sandi memunculkan celah ini, dan mengapa log autentikasi tidak
   pernah cukup dengan sendirinya?
3. Seperti apa sebenarnya model kejadian penambangan proses autentikasi dari ujung ke
   ujung?
4. Bagaimana penambangan proses terhubung ke autentikasi step-up dan otorisasi yang
   terperinci?
5. Apa artinya ini bagi lanskap vendor CIAM dan bagi tim identitas yang sudah memiliki
   IDP?

## 2. Apa yang Dilakukan Penambangan Proses untuk BPM

### 2.1 Dari Log Kejadian hingga Proses yang Dioptimalkan

Penambangan proses bisnis muncul dari kesadaran bahwa setiap ERP, CRM, atau sistem tiket
menulis log kejadian yang, ketika direkonstruksi, mengungkapkan alur kerja yang
sebenarnya, bukan yang ada di wiki. Pesanan pembelian yang seharusnya melewati tiga
pemberi persetujuan ternyata melewati dua di antaranya 40% dari waktu tersebut. Alur klaim
yang didokumentasikan sebagai garis lurus berulang pada dirinya sendiri sebanyak lima kali
untuk 18% klaim. Alat penambangan proses seperti yang dipopulerkan oleh Celonis membangun
kembali grafik tersebut dari kejadian berstempel waktu dan memungkinkan operator
menanyakan pertanyaan baru: di mana proses yang dialami menyimpang dari proses yang
dirancang, dan apa biaya dari penyimpangan tersebut?

### 2.2 Paralel dalam Autentikasi

Autentikasi memiliki struktur yang sama. Setiap login adalah rangkaian kejadian berstempel
waktu: halaman dimuat, pengidentifikasi dimasukkan, tantangan dipilih, biometrik diminta,
asersi dikembalikan. Paralel strukturalnya tepat. Perbedaan praktisnya adalah bahwa, tidak
seperti ERP atau CRM, data kejadian ini belum berada di log IDP Anda - setidaknya tidak
dalam bentuk terperinci yang dibutuhkan penambangan proses. IDP mencatat hasil masuk
(sign-in) dan metode yang digunakan. Mereka tidak mencatat seremonial sisi klien di
bawahnya: pemanggilan [Conditional UI](https://www.corbado.com/glossary/conditional-ui), permintaan biometrik,
pemilihan manajer kredensial, pengabaian diam-diam sebelum permintaan mencapai server.
Lapisan pra-asersi tersebut harus diinstrumentasi di lapisan SDK front-end dan dirakit
kembali menjadi grafik per sesi sebelum penambangan proses dapat beroperasi di atasnya.

Setelah datanya ada, teknik yang sama berlaku: perjalanan kunci sandi yang dirancang vs.
perjalanan kunci sandi yang dialami, alur pemulihan yang dirancang vs. alur pemulihan yang
dialami, step-up yang dirancang vs. step-up yang dialami. Disiplin akademis seputar
pekerjaan ini semakin matang. Titik masuk yang berguna adalah
[Process Mining Manifesto](https://www.tf-pm.org/resources/manifesto) dari IEEE Task Force
on Process Mining, yang menjabarkan pengecekan kesesuaian (conformance checking), analisis
varian, dan peningkatan sebagai tiga teknik inti. Masing-masing memetakan secara
satu-ke-satu pada autentikasi.

## 3. Mengapa Peluncuran Kunci Sandi Memunculkan Celah Tersebut

### 3.1 Kunci Sandi Memaksa Tim untuk Memikirkan Ulang Pencatatan Frontend

Autentikasi kata sandi klasik mencatat tiga hal di sisi server: upaya, keberhasilan,
kegagalan. Itu cukup untuk menjalankan sistem kata sandi, karena mode kegagalannya
sederhana: pengguna salah mengetik string, dan upaya berikutnya berhasil atau tidak.
Dengan kunci sandi, momen kritis berpindah ke frontend:
[Conditional UI](https://www.corbado.com/glossary/conditional-ui) terpicu, browser memutuskan apakah akan
memunculkan prompt, manajer kredensial menawarkan pilihan, tantangan biometrik berhasil
atau ditutup. Semua ini terjadi pada perangkat konsumen, sebelum asersi mencapai backend.

Pergeseran itulah yang menyebabkan banyak tim kini memikirkan ulang cara mereka mencatat
perilaku sisi klien. Tanpa instrumentasi frontend, mereka tidak dapat melihat mengapa
pengguna churn, langkah apa yang diambil pengguna sebelum login, atau apa yang sebenarnya
terjadi ketika upaya login tidak selesai. Log server hanya menunjukkan ketidakhadiran,
bukan penyebabnya. Lihat pembahasan mendalam kami tentang observabilitas autentikasi untuk
taksonomi kejadian lengkapnya.

### 3.2 Celah antara Perjalanan yang Dirancang dan Perjalanan yang Dialami

Setelah tim memiliki kejadian sisi klien, mereka bisa melihat sesuatu yang baru:
perjalanan kunci sandi yang dirancang (mendarat di halaman login, melihat tombol kunci
sandi, ketuk, autentikasi, selesai) digunakan oleh mungkin 30% pengguna yang memenuhi
syarat. 70% sisanya menyimpang melalui bidang kata sandi, login sosial, tautan ajaib
(magic links), atau ditinggalkan sepenuhnya. Itu adalah masalah penambangan proses, bukan
masalah pencatatan (logging). Sejumlah kode kesalahan WebAuthn tambahan tidak akan menutup
celah itu dengan sendirinya.

### 3.3 Mengapa Log Autentikasi Tidak Pernah Cukup

Log autentikasi dengan sendirinya memberi tahu Anda hasilnya. Mereka tidak memberi tahu
Anda jalurnya. Tingkat keberhasilan login sebesar 92% di semua metode dapat menyembunyikan
tingkat pengabaian 40% di jalur kunci sandi dan tingkat pengabaian 15% di jalur kata
sandi, yang pada akhirnya terlihat "baik-baik saja". Penambangan proses menolak rata-rata
tersebut. Ini bersikeras untuk melihat setiap varian secara terpisah dan kemudian
memeringkat varian berdasarkan frekuensi, biaya, dan tingkat kegagalan.

## 4. Seperti Apa Sebenarnya Penambangan Proses Autentikasi

### 4.1 Model Kejadian: Proses, Kejadian, dan Klasifikasi Hasil

Unit analisisnya bukanlah kejadian tunggal, melainkan sebuah **proses**: satu upaya login
atau penambahan kredensial penuh di perangkat konsumen, dari saat permukaan auth dimuat
hingga saat sesi selesai atau ditinggalkan. Setiap proses berisi aliran kejadian
terperinci, membawa metadata pengidentifikasi, dan berakhir pada klasifikasi hasil yang
lebih kaya daripada sekadar "berhasil atau gagal" biner.

**Metadata proses.** Setiap proses memiliki ID proses dan stempel waktu (timestamp). Ini
terikat pada aplikasi, OS, browser, dan merek perangkat. Ini ditandai dengan kategori
pengunjung (pengguna nyata, penguji manual, penguji otomatis, belum diklasifikasikan)
sehingga otomatisasi dan lalu lintas bot dapat disegmentasikan sebelum metrik apa pun
dihitung. Ini juga membawa skor proses dan jumlah kejadian, yang merupakan dua sinyal
paling sederhana untuk "seberapa kompleks sesi khusus ini."

**Inisiasi login.** Setiap proses mencatat bagaimana alur dimulai. Jenis inisiasi utama
adalah `text-field` (pengguna mengetik pengidentifikasinya), `one-tap` (pengidentifikasi
yang disimpan digunakan kembali), dan `cui` (Conditional UI memunculkan kredensial tanpa
klik tombol eksplisit). Inisiasi adalah sebuah dimensi, bukan metrik: penerapan yang sama
dapat terlihat sangat berbeda pada kohort `cui` dibandingkan pada kohort `text-field`, dan
membuat rata-rata di antara keduanya menyembunyikan perilaku yang justru ingin diungkapkan
oleh penambangan proses.

**Klasifikasi hasil.** Alih-alih "berhasil" atau "gagal," hasilnya adalah salah satu dari
beberapa kelas yang memetakan ke perilaku yang berbeda. Contoh untuk kunci sandi adalah
sebagai berikut:

- `completed` - seremonial selesai dan pengguna diautentikasi.
- `filtered-explicit-abort` - pengguna melihat prompt dan secara eksplisit membatalkan.
- `filtered-implicit-abort` - pengguna pergi atau habis waktu tanpa memutuskan.
- `filtered-passkey-intel` - lapisan kecerdasan sisi klien secara sengaja menekan jalur
  kunci sandi, biasanya karena kombinasi perangkat/OS diketahui bermasalah.
- `filtered-no-start` - alur tidak pernah melampaui langkah awal.
- `not-loaded` - permukaan auth tidak pernah selesai memuat.

Seremonial penambahan (pembuatan kredensial) memiliki klasifikasi paralel, termasuk kasus
`completed-exclude-credentials` ketika pengguna sudah memiliki kredensial.

**Lapisan funnel dan inventaris.** Di atas proses, terdapat dua agregat lapisan yang
penting. **Lapisan funnel** mengelompokkan proses dari waktu ke waktu berdasarkan hasil,
inisiasi, status penyelesaian, OS, dan aplikasi, baik untuk login maupun penambahan.
**Lapisan inventaris kredensial** mengelompokkan kunci sandi yang ada berdasarkan status
sinkronisasi (disinkronkan vs. tidak disinkronkan), transportasi (`internal`, `hybrid`,
`usb`, `nfc`, `ble`, `smart-card`), autentikator (Apple,
[Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager),
[iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain), [Windows Hello](https://www.corbado.com/glossary/windows-hello),
[1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis),
[Bitwarden](https://www.corbado.com/blog/passkey-analysis-bitwarden-developer-survey-2024),
[Dashlane](https://www.corbado.com/blog/dashlane-passkeys), [YubiKey](https://www.corbado.com/glossary/yubikey)), OS, dan browser. Tanpa
lapisan inventaris, mustahil untuk menanyakan apakah varian penyimpangan tertentu
terkonsentrasi pada manajer kredensial atau kondisi sinkronisasi tertentu.

Inilah bentuk minimum yang membuat penambangan proses dapat ditangani. Setiap kejadian
membawa cukup metadata untuk dikelompokkan, difilter, dan diperingkat. Setiap proses dapat
dilacak satu per satu, yang memungkinkan contoh pengerjaan di bawah ini.

### 4.2 Jalur Bahagia vs. Analisis Penyimpangan

Setelah kejadian disimpan sebagai grafik terarah per sesi, Anda dapat mengajukan
pertanyaan penambangan proses: berapa persentase sesi yang mengikuti jalur bahagia (happy
path), dan untuk yang tidak, apa lima varian penyimpangan teratas berdasarkan frekuensi?
Dalam data analitik kami, lima varian teratas biasanya menyumbang 85% dari semua
penyimpangan. Memperbaiki dua di antaranya biasanya mengubah angka lebih banyak daripada
pengujian A/B apa pun pada jalur bahagia.

### 4.3 Deteksi Pergeseran Kohort

Varian menyimpang. Pembaruan browser, peluncuran OS, perubahan manajer kredensial dapat
membuat varian yang sebelumnya kecil tiba-tiba menjadi dominan. Deteksi pergeseran kohort
(cohort drift detection) adalah disiplin mengamati distribusi varian per kohort
perangkat/OS/browser dari waktu ke waktu, alih-alih hanya melihat tingkat keberhasilan
agregat. Inilah cara tim menangkap regresi diam-diam dalam hitungan jam, bukan kuartal.

## 5. Dari Penambangan Proses hingga Step-up Terperinci

### 5.1 Mengapa Step-up Kurang Dimanfaatkan

Autentikasi step-up telah ada selama lebih dari satu dekade. Hal ini kurang dimanfaatkan
karena sebagian besar tim menerapkan step-up dengan cara yang sama terlepas dari
risikonya: memaksa OTP pada setiap transaksi di atas ambang batas. Itu adalah aturan yang
kaku, bukan keputusan yang diberi skor risiko (risk-scored). Ini menciptakan hambatan pada
95% transaksi bernilai tinggi yang sah untuk menghentikan 5% yang mencurigakan.

### 5.2 Perjalanan Berskor Risiko

Dengan data penambangan proses, Anda dapat menilai suatu sesi secara terus-menerus.
Reputasi perangkat, tingkat keberhasilan dasar kohort, anomali waktu, penyimpangan dari
jalur historis pengguna itu sendiri, identitas manajer kredensial, reputasi IP. Skor
risiko tersebut kemudian mendorong keputusan step-up yang terperinci: memerlukan faktor
kedua hanya ketika skor risiko sesi melebihi ambang batas nilai transaksi. Sesi berisiko
rendah untuk transaksi bernilai tinggi akan lolos. Sesi berisiko tinggi untuk transaksi
bernilai rendah akan diminta step-up.

## 6. Apa Artinya ini bagi Lanskap Vendor CIAM

### 6.1 Desain Perjalanan sebagai Disiplin Spesialis

Industri identitas secara historis telah menggabungkan desain perjalanan di dalam IDP.
Mesin orkestrasi di dalam Okta, Ping, ForgeRock, [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis),
dan lainnya memungkinkan Anda mengonfigurasi alur. Apa yang tidak mereka lakukan dengan
baik adalah mengamatinya. Ketidakcocokan itulah yang membuka ruang bagi lapisan analitik
spesialis.

### 6.2 Mengapa Tidak Ada IDP yang Menyediakan ini secara Bawaan

Vendor IDP mengoptimalkan control plane: siapa yang dapat masuk, dengan kredensial apa, di
bawah kebijakan apa. Penambangan proses adalah disiplin data-plane: setiap kejadian, pada
skala besar, dinormalisasi di berbagai kombinasi OS/browser/manajer kredensial. Volume
kejadian, kardinalitas, dan garis dasar lintas pelanggan semuanya bertentangan dengan
pembuatan IDP bawaan. Lihat catatan lapangan dalam panduan beli-vs-bangun untuk kunci
sandi kami untuk pola yang sama yang diterapkan pada lapisan SDK.

### 6.3 Lapisan Analitik sebagai Kategori Baru

Apa yang muncul adalah lapisan analitik dan adopsi tipis yang berada di atas IDP, menelan
kejadian dari front-end, menormalisasinya terhadap garis dasar lintas penerapan, dan
memberikan umpan balik ke dalam keputusan orkestrasi. Ini tidak menggantikan IDP. Ini
membuat IDP dapat diukur.

## 7. Bagaimana Corbado Membantu dengan Penambangan Proses Autentikasi

[Corbado](https://www.corbado.com/) menyediakan lapisan pengukuran dan adopsi yang berada
di atas IDP yang ada. Ini terintegrasi dengan Okta,
[Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis), Ory, ForgeRock, dan tumpukan kustom tanpa
menggantikannya. Apa yang ditambahkan secara khusus adalah kemampuan penambangan proses:

- **Taksonomi Kejadian End-to-end.** SDK sisi klien menangkap seremonial penuh dari muatan
  halaman hingga asersi, termasuk kejadian pra-pengidentifikasi, pemanggilan
  [Conditional UI](https://www.corbado.com/glossary/conditional-ui), dan pemilihan manajer kredensial.
- **Analisis Varian Siap Pakai.** Platform ini merekonstruksi grafik perjalanan per kohort
  dan memeringkat varian penyimpangan berdasarkan frekuensi, peluang pemulihan, dan biaya.
- **Peringatan Pergeseran Kohort.** Ketika distribusi varian bergeser untuk OS, browser,
  atau manajer kredensial tertentu, platform menandainya sebelum menjadi masalah hari
  ke-2.
- **Garis Dasar Lintas Penerapan.** Karena Corbado mengagregasi data anonim di seluruh
  lingkungan pelanggan, kesalahan atau regresi baru yang muncul di satu penerapan
  diklasifikasikan dan didokumentasikan sebelum mencapai penerapan Anda. Lihat mengapa
  Corbado untuk pendekatan lengkapnya.
- **Umpan Balik ke Orkestrasi.** Keputusan step-up berskor risiko dan aturan penekanan
  dapat didorong kembali ke IDP atau ditangani di lapisan adopsi, termasuk sakelar pemutus
  dinamis (kill-switches) dan dorongan (nudging) khusus kohort.

## 8. Kesimpulan

Kunci sandi (passkeys) bukanlah tujuan akhirnya. Mereka adalah pendorong instrumentasi
yang memaksa gelombang pertama tim CIAM untuk mencatat kejadian sisi klien sama sekali.
Setelah lapisan observabilitas itu ada, disiplin baru duduk di atasnya: penambangan proses
autentikasi. Inilah cara tim identitas beralih dari "apakah login berhasil" menjadi
"varian perjalanan mana yang diambil pengguna ini, berapa biayanya, dan bagaimana sesi
berikutnya harus diarahkan secara berbeda." Tim yang membangun lapisan observabilitas
terlebih dahulu, dan lapisan penambangan proses segera setelahnya, akan menetapkan tolok
ukur untuk kategori tersebut. Tim yang tetap berada pada tingkat keberhasilan agregat akan
terus melewatkan varian sistemik di bawahnya.

## FAQ

### Apa itu Penambangan Proses Autentikasi?

Penambangan proses autentikasi (authentication process mining) adalah penerapan teknik
penambangan proses bisnis pada log kejadian login. Ini merekonstruksi grafik kejadian
terarah per sesi, membandingkan perjalanan autentikasi yang dialami dengan perjalanan yang
dirancang, dan memeringkat varian penyimpangan berdasarkan frekuensi dan biaya. Ini berada
di atas observabilitas autentikasi dan di bawah orkestrasi.

### Apa Bedanya dengan Analitik Autentikasi?

Analitik autentikasi melaporkan metrik seperti tingkat keberhasilan login, tingkat putus
(drop-off), dan tingkat penggunaan kunci sandi. Penambangan proses melangkah lebih jauh
dengan merekonstruksi urutan kejadian penuh per sesi dan menanyakan varian perjalanan mana
yang ada, seberapa sering masing-masing terjadi, dan di mana masing-masing menyimpang dari
jalur bahagia yang dirancang. Analitik melaporkan hasil. Penambangan proses menjelaskan
jalur.

### Mengapa Adopsi Kunci Sandi Membuat Disiplin ini Diperlukan?

Peluncuran kunci sandi (passkeys) adalah alasan pertama mengapa tim CIAM sama sekali
menginstrumentasi kejadian sisi klien. Setelah kejadian tersebut ada, metrik agregat
menyembunyikan terlalu banyak: tingkat keberhasilan 92% dapat menutupi tingkat pengabaian
40% di jalur kunci sandi. Penambangan proses menolak rata-rata tersebut dan memaksa tim
untuk melihat varian secara terpisah.

### Bagaimana Penambangan Proses Terhubung ke Autentikasi Step-up?

Autentikasi step-up bekerja paling baik ketika dinilai berdasarkan risiko (risk-scored)
daripada berbasis aturan. Penambangan proses memberikan bukti tingkat sesi (garis dasar
kohort, penyimpangan dari jalur historis pengguna, reputasi perangkat) yang memungkinkan
mesin step-up membuat keputusan terperinci alih-alih keputusan ambang batas yang kaku.

### Apakah IDP Saya akan Menyediakan ini secara Bawaan?

Tidak mungkin dalam waktu dekat. IDP mengoptimalkan control plane. Penambangan proses
adalah disiplin data-plane dengan volume kejadian tinggi dan kardinalitas tinggi di
seluruh kombinasi OS, browser, dan manajer kredensial. Polanya cocok dengan apa yang kita
lihat di lapisan SDK saat ini, seperti yang dibahas dalam panduan beli-vs-bangun kami.

### Apa Hal Pertama yang Harus Diukur oleh Tim CIAM?

Mulailah dengan frekuensi varian pada jalur kunci sandi: berapa persentase sesi yang
mengikuti jalur bahagia, dan apa lima varian penyimpangan teratas yang diperingkat
berdasarkan frekuensi? Satu bagan tersebut biasanya cukup untuk mengungkapkan dua atau
tiga perbaikan yang paling mendorong adopsi kunci sandi secara keseluruhan.