Prediksi Nasabah Potensial Deposito dengan Machine Learning | XGBoost & Streamlit

Beberapa waktu terakhir saya kembali mencoba mengembangkan project machine learning, kali ini menggunakan studi kasus Bank Marketing Campaign.

Permasalahan yang ingin diselesaikan cukup sederhana: bagaimana cara membantu tim telemarketing menentukan nasabah yang lebih berpotensi membuka deposito?

Dalam campaign konvensional, bank dapat menghubungi banyak nasabah tanpa mengetahui siapa yang memiliki peluang konversi lebih tinggi. Strategi tersebut memang dapat menjangkau lebih banyak nasabah, tetapi juga membutuhkan biaya, waktu, dan kapasitas tim yang cukup besar.

Karena itu, saya mencoba membangun model klasifikasi yang dapat mempelajari data campaign sebelumnya dan memberikan prediksi terhadap potensi nasabah dalam membuka deposito.

Model ini tidak dibuat untuk menggantikan keputusan bisnis, tetapi digunakan sebagai alat bantu dalam menyusun prioritas target campaign.

Data tidak menggantikan keputusan; data membantu kita membuat keputusan yang lebih tepat.

📌 Business Understanding

Sebelum membangun model, hal pertama yang perlu dipahami adalah dampak dari setiap kesalahan prediksi.

Dalam project ini, target True berarti nasabah membuka deposito, sedangkan False berarti nasabah tidak membuka deposito.

Terdapat dua kesalahan prediksi yang perlu diperhatikan:

1. False Positive
   Model memprediksi nasabah akan membuka deposito, tetapi aktualnya tidak. Dampaknya adalah biaya dan sumber daya campaign digunakan untuk nasabah yang tidak melakukan konversi.
2. False Negative
   Model memprediksi nasabah tidak akan membuka deposito, tetapi aktualnya nasabah tersebut membuka deposito. Dampaknya adalah nasabah potensial tidak menjadi target campaign sehingga peluang bisnis dapat terlewat.

Berdasarkan kebutuhan tersebut, saya memilih Recall sebagai metrik utama.

Recall menunjukkan seberapa banyak nasabah yang aktualnya membuka deposito berhasil ditemukan oleh model. Semakin tinggi Recall, semakin sedikit nasabah potensial yang terlewat.

Namun, Recall yang tinggi juga dapat meningkatkan False Positive. Oleh karena itu, hasil model tetap perlu diterjemahkan ke dalam konteks biaya dan kapasitas campaign.

📊 Data Understanding dan EDA

Dataset yang digunakan memiliki informasi karakteristik nasabah dan riwayat campaign, seperti:

• usia;
• pekerjaan;
• saldo;
• kepemilikan housing loan;
• kepemilikan personal loan;
• metode kontak;
• bulan campaign;
• jumlah kontak selama campaign;
• jarak waktu dari campaign sebelumnya; dan
• hasil campaign sebelumnya.

Setelah menghapus data duplikat, terdapat 7.805 observasi yang digunakan dalam proses analisis.

Pada tahap Exploratory Data Analysis, saya memeriksa distribusi setiap variabel, komposisi target, missing value, data duplikat, outlier, serta hubungan awal antara karakteristik nasabah dan keputusan membuka deposito.

Tahap ini penting karena model yang baik tidak hanya bergantung pada algoritma, tetapi juga pada pemahaman terhadap kualitas dan karakteristik data.

[Sisipkan gambar distribusi target]

🧹 Data Preprocessing

Setiap fitur memiliki karakteristik yang berbeda sehingga metode preprocessing tidak bisa disamaratakan.

Beberapa metode yang digunakan dalam project ini antara lain:

SimpleImputer

SimpleImputer digunakan untuk menangani missing value.

• Mean digunakan pada fitur yang relatif stabil.
• Median digunakan pada fitur dengan distribusi miring atau memiliki outlier.
• Most frequent digunakan pada fitur kategorikal atau diskrit.

Tujuannya agar missing value dapat ditangani tanpa menghapus terlalu banyak data.

Scaling

Beberapa metode scaling digunakan sesuai karakteristik fitur:

• MinMaxScaler mengubah data ke rentang yang lebih terkontrol.
• StandardScaler menyetarakan skala berdasarkan mean dan standard deviation.
• RobustScaler menggunakan median dan IQR sehingga lebih tahan terhadap outlier.

Scaling membantu memastikan perbedaan satuan antarfitur tidak memberikan pengaruh yang tidak proporsional selama proses modeling.

Encoding

Data kategorikal perlu diubah menjadi format numerik agar dapat diproses oleh model.

Metode yang digunakan meliputi:

• OneHotEncoder untuk kategori nominal;
• BinaryEncoder untuk fitur dengan kategori yang relatif banyak; dan
• OrdinalEncoder untuk kategori yang memiliki urutan tertentu.

Seluruh proses preprocessing ditempatkan di dalam pipeline.

Pipeline memastikan preprocessing dan model dijalankan sebagai satu rangkaian proses. Struktur ini juga membantu mencegah data leakage karena transformer hanya mempelajari informasi dari data training pada setiap proses validasi.

🔄 Pembagian Data dan Validasi

Data dibagi menjadi training set dan test set dengan proporsi 80:20.

Pembagian dilakukan menggunakan metode stratified agar proporsi kelas deposito dan tidak deposito tetap relatif sama pada kedua kelompok data.

Saya juga menggunakan random_state=42 agar proses pengacakan dapat direproduksi. Angka 42 bukan berarti mengambil 42 data, tetapi hanya berfungsi sebagai seed dalam proses pengacakan.

Pada data training, evaluasi dilakukan menggunakan 5-fold Stratified Cross-Validation.

Data training dibagi menjadi lima bagian. Empat bagian digunakan untuk melatih model dan satu bagian digunakan untuk validasi. Proses tersebut diulang hingga setiap bagian pernah menjadi data validasi.

Pendekatan ini memberikan evaluasi yang lebih stabil dibandingkan hanya menggunakan satu kali pembagian data.

🤖 Model Benchmarking

Beberapa algoritma klasifikasi dibandingkan terlebih dahulu, yaitu:

• K-Nearest Neighbors;
• Logistic Regression;
• Decision Tree;
• XGBoost;
• AdaBoost; dan
• CatBoost.

Perbandingan dilakukan menggunakan Recall cross-validation.

Dari proses benchmarking, XGBoost memberikan performa yang paling sesuai untuk tujuan project. XGBoost mampu menangkap hubungan non-linear, interaksi antarfitur, serta memiliki mekanisme regularisasi untuk membantu mengurangi overfitting.

[Sisipkan gambar model benchmarking]

⚙️ Hyperparameter Tuning dengan GridSearchCV

Setelah algoritma dipilih, saya melakukan hyperparameter tuning menggunakan GridSearchCV.

GridSearchCV mencoba seluruh kombinasi parameter yang telah ditentukan, kemudian mengevaluasi setiap kombinasi menggunakan cross-validation.

Parameter yang diuji meliputi:

• n_estimators;
• max_depth;
• learning_rate; dan
• scale_pos_weight.

Kombinasi parameter terbaik yang diperoleh adalah:

• n_estimators = 100;
• max_depth = 3;
• learning_rate = 0.01; dan
• scale_pos_weight = 1.5.

Nilai scale_pos_weight membantu meningkatkan perhatian model terhadap kelas positif. Hal ini sesuai dengan tujuan project yang berfokus pada kemampuan menemukan nasabah potensial.

📈 Hasil Evaluasi Model

Model final menghasilkan performa sebagai berikut:

• Recall cross-validation: 91,09%;
• Recall test: 91,42%;
• ROC-AUC test: 75,05%;
• True Negative: 258;
• False Positive: 557;
• False Negative: 64; dan
• True Positive: 682.

Recall test sebesar 91,42% berarti model berhasil menemukan sekitar 91 dari setiap 100 nasabah yang aktualnya membuka deposito.

Nilai Recall cross-validation dan test juga relatif berdekatan. Hal ini menunjukkan performa model cukup konsisten dan tidak memperlihatkan indikasi overfitting yang berarti.

Meskipun demikian, model menghasilkan False Positive yang cukup tinggi. Kondisi ini merupakan trade-off dari optimasi Recall karena model dibuat lebih sensitif dalam menangkap kelas deposito.

[Sisipkan gambar confusion matrix]

ROC-AUC sebesar 75,05% menunjukkan model memiliki kemampuan yang cukup baik dalam membedakan nasabah deposito dan tidak deposito pada berbagai threshold.

[Sisipkan gambar ROC curve]

💰 Business Loss Analysis

Evaluasi model tidak berhenti pada metrik statistik.

Saya membandingkan tiga skenario campaign menggunakan asumsi biaya:

• biaya False Negative sebesar $10; dan
• biaya False Positive sebesar $5.

Hasil perbandingannya adalah:

1. Tidak ada nasabah yang dihubungi
   Business Loss: $7.460
2. Seluruh nasabah dihubungi
   Business Loss: $4.075
3. Menggunakan model
   Business Loss: $3.425

Berdasarkan asumsi tersebut, penggunaan model menghasilkan Business Loss paling rendah.

Model dapat menghemat $650 dibandingkan strategi menghubungi seluruh nasabah. Namun, model masih merekomendasikan sekitar 79,37% nasabah test untuk dihubungi karena optimasi difokuskan pada Recall.

Hasil ini menunjukkan bahwa model membantu menyaring target campaign, tetapi threshold prediksi masih dapat disesuaikan kembali berdasarkan biaya, kapasitas telemarketing, dan tujuan bisnis.

🔍 Feature Importance

Feature importance digunakan untuk melihat kontribusi relatif setiap fitur terhadap keputusan model.

Namun, feature importance perlu diinterpretasikan dengan hati-hati. Nilai yang tinggi tidak menunjukkan arah pengaruh dan tidak membuktikan hubungan sebab-akibat.

Analisis lanjutan seperti SHAP dapat digunakan apabila dibutuhkan penjelasan yang lebih detail mengenai bagaimana nilai suatu fitur meningkatkan atau menurunkan probabilitas prediksi.

[Sisipkan gambar feature importance]

🖥️ Model Deployment dengan Streamlit

Model final disimpan sebagai full pipeline dalam file best_model.sav.

Full pipeline berarti file tersebut sudah memuat preprocessing dan model XGBoost. Dengan demikian, aplikasi tidak perlu melakukan preprocessing ulang secara manual.

Model kemudian diterapkan ke aplikasi Streamlit dengan dua menu utama:

🎯 Prediksi Customer

Menu ini digunakan untuk:

• memprediksi satu customer;
• melakukan prediksi data CSV;
• menampilkan hasil klasifikasi;
• menampilkan probabilitas deposito; dan
• menentukan tingkat prioritas campaign.

📊 Riwayat & Analisis

Menu ini digunakan untuk:

• menyimpan riwayat prediksi selama sesi aktif;
• menampilkan KPI historis;
• membandingkan probabilitas antarcustomer;
• menampilkan komposisi hasil prediksi;
• menyusun ranking prioritas campaign;
• menghapus data tertentu; dan
• mengunduh riwayat dalam format CSV.

[Sisipkan gambar aplikasi Streamlit]

Deployment menjadi tahap penting karena model yang hanya tersimpan di notebook akan sulit digunakan oleh pengguna nonteknis.

Melalui Streamlit, proses prediksi dapat dilakukan melalui antarmuka sederhana tanpa perlu menjalankan kode Python secara langsung.

💡 Catatan Pembelajaran

Dari project ini saya kembali belajar bahwa pemilihan model tidak cukup hanya berdasarkan skor tertinggi.

Metrik evaluasi harus disesuaikan dengan tujuan bisnis. Recall yang tinggi memang membantu menemukan lebih banyak nasabah potensial, tetapi juga dapat meningkatkan jumlah nasabah yang tetap harus dihubungi.

Karena itu, hasil model perlu dievaluasi bersama dengan Business Loss, kapasitas campaign, dan threshold yang digunakan.

Model sebaiknya diposisikan sebagai alat prioritas, bukan keputusan otomatis.

Setelah deployment, performa model juga tetap perlu dimonitor karena karakteristik nasabah dan pola campaign dapat berubah dari waktu ke waktu.