Dari Data Menjadi Solusi Bisnis: Perjalanan Membangun Aplikasi Prediksi Seller Churn
Setelah mengikuti tiga rangkaian modul pembelajaran beserta evaluasinya, perjalanan belajar kami berlanjut ke tahap final project. Pada tahap ini, kami diseleksi dan dibagi menjadi tiga tim, yaitu Alpha, Beta, dan Gamma.
Saya bergabung dalam Tim Alpha bersama Rifdah Octavi Azzahra dan Dzakwan Taufiq Nur Muhammad. Kami mengerjakan proyek analisis data Olist dengan fokus pada prediksi seller churn, yaitu mengidentifikasi seller yang berpotensi berhenti bertransaksi agar dapat diprioritaskan dalam program retensi.
Final project ini menjadi kesempatan untuk menghubungkan materi yang telah dipelajari dengan satu proses kerja yang lengkap: memahami masalah bisnis, mengolah data, membangun model, membuat dashboard dan aplikasi, hingga mempertanggungjawabkan hasil analisis di hadapan penguji.
Membangun ritme kerja bersama tim
Selama penyusunan proyek, kami melakukan koordinasi dua kali dalam seminggu. Pertemuan ini menjadi ruang untuk membahas perkembangan pekerjaan, menyelaraskan analisis, dan menyelesaikan kendala yang muncul.
Kami juga menjalani empat sesi konsultasi rutin bersama mentor, dengan frekuensi satu kali setiap minggu. Konsultasi membantu kami meninjau pendekatan yang digunakan dan mengarahkan pekerjaan menuju tujuan proyek.
Koordinasi menjadi penting karena hasil pekerjaan kami saling terhubung. Definisi churn yang digunakan dalam notebook harus konsisten dengan dashboard. Fitur yang digunakan saat melatih model juga harus sama dengan masukan pada aplikasi prediksi. Seluruh hasil tersebut kemudian perlu dijelaskan dengan runtut dalam presentasi.
 |
| Alur Proses Final Project |
Mengapa memilih seller churn?
Olist merupakan platform marketplace yang menghubungkan seller dan pelanggan di Brasil. Keberlanjutan aktivitas seller penting karena seller yang berhenti bertransaksi dapat mengurangi pilihan produk, volume transaksi, dan potensi pendapatan platform.
Dari konteks tersebut, kami mengangkat pertanyaan: bagaimana data historis dapat membantu mengidentifikasi seller berisiko churn dan mendukung prioritas campaign retensi?
Dalam proyek ini, churn ditetapkan menggunakan aturan aktivitas transaksi dan periode observasi. Seller yang belum memiliki histori memadai dipisahkan sebagai not eligible. Penetapan aturan ini penting agar seller baru tidak langsung dianggap churn hanya karena belum banyak bertransaksi.
Kami juga memperhatikan pemisahan antara data historis sebelum tanggal cutoff dan periode yang digunakan untuk menentukan label. Informasi yang digunakan untuk memprediksi harus sudah tersedia pada saat prediksi dilakukan.
Memulai analisis melalui Google Colab
Kami menggunakan notebook Google Colab untuk mengolah dan menganalisis data. Data sumber mencakup informasi pesanan, item, seller, customer, pembayaran, produk, dan geolocation.
Tantangan awalnya adalah perbedaan tingkat rincian antartabel. Satu pesanan dapat memiliki beberapa item dan beberapa record pembayaran. Apabila seluruh tabel langsung digabungkan, jumlah baris dapat berlipat dan menyebabkan nilai transaksi terhitung berulang.
Karena itu, kami melakukan agregasi sebelum penggabungan. Informasi transaksi diringkas sesuai kebutuhan hingga terbentuk dataset dengan satu baris untuk satu seller.
Proses pengolahan juga mencakup penyesuaian tipe tanggal, pemeriksaan missing value, penanganan duplikasi lokasi, penyeragaman kategori, serta validasi koordinat geografis.
Tahap ini membutuhkan perhatian karena kesalahan pada penggabungan atau perhitungan fitur akan terbawa ke analisis berikutnya, meskipun model berhasil dijalankan.
Mengubah transaksi menjadi karakteristik seller
Catatan transaksi kemudian kami olah menjadi fitur yang menggambarkan aktivitas dan karakteristik seller. Beberapa contohnya adalah:
Jumlah order historis.
Hari sejak order terakhir.
Rata-rata jeda antarorder.
Jumlah hari aktif bertransaksi.
Jumlah produk dan kategori produk yang terjual.
Total harga produk.
Jarak geografis antara seller dan customer.
Fitur tersebut membantu model mengenali perbedaan pola aktivitas seller. Misalnya, jumlah order menunjukkan volume aktivitas, sedangkan rata-rata jeda antarorder membantu menggambarkan keteraturan transaksi.
Melalui exploratory data analysis atau EDA, kami memeriksa distribusi fitur, nilai ekstrem, hubungan antarfitur, serta perbedaan pola antara seller churn dan tidak churn. Hasil eksplorasi digunakan untuk memahami data dan mendukung pemilihan fitur, dengan tetap membedakan hubungan statistik dari hubungan sebab akibat.
Dataset pemodelan yang dilaporkan dalam proyek mencakup 2.692 seller eligible dengan 14 fitur numerik terpilih.
Menyiapkan data sebelum pemodelan
Sebelum melatih model, data dibagi menjadi data latih dan data uji dengan proporsi 80:20. Data latih digunakan untuk pembelajaran dan pemilihan konfigurasi model, sedangkan data uji digunakan untuk evaluasi akhir.
Preprocessing dilakukan melalui pipeline yang mencakup pengisian nilai kosong menggunakan median dan scaling menggunakan RobustScaler.
Pengisian median membantu menyediakan masukan numerik ketika sebagian fitur tidak tersedia. Sementara itu, RobustScaler menyetarakan skala fitur berdasarkan median dan rentang antarkuartil. Pendekatan ini relevan untuk data transaksi yang dapat memiliki rentang lebar dan nilai ekstrem.
Statistik preprocessing dipelajari dari data latih, kemudian diterapkan pada data validasi, data uji, dan masukan aplikasi. Dengan cara ini, proses prediksi menggunakan transformasi yang konsisten.
Membandingkan model dan memilih Logistic Regression
Kami membandingkan 13 model, termasuk Logistic Regression, KNN, Decision Tree, Random Forest, beberapa algoritma boosting, serta metode ensemble seperti voting dan stacking.
Evaluasi menggunakan F2-score dengan perhatian pada recall kelas churn. Recall menunjukkan seberapa banyak seller churn yang berhasil terdeteksi. F2-score menggabungkan precision dan recall dengan penekanan lebih besar pada recall, sesuai tujuan mengurangi seller churn yang terlewat.
Pada perbandingan awal, Random Forest menghasilkan rata-rata skor validasi tertinggi. Namun, pemilihan model juga mempertimbangkan selisih skor pelatihan dan validasi serta kemudahan interpretasi.
Kami memilih Logistic Regression untuk dikembangkan lebih lanjut. Model ini menghitung probabilitas churn dari kombinasi fitur seller, lalu mengubahnya menjadi keputusan kelas berdasarkan threshold.
Koefisiennya membantu menjelaskan arah hubungan fitur terhadap prediksi. Dengan fitur lain tetap, koefisien positif meningkatkan log-odds churn, sedangkan koefisien negatif menurunkannya. Interpretasi ini tetap merupakan hubungan prediktif dan tidak langsung menunjukkan penyebab churn.
Selanjutnya, kami melakukan hyperparameter tuning menggunakan GridSearchCV lima fold dengan F2-score sebagai metrik pemilihan. Presentasi proyek mencatat nilai C terpilih sebesar 0,001. Parameter C mengatur kekuatan regularisasi: semakin kecil nilainya, semakin kuat pembatasan terhadap besar koefisien.
Membawa hasil analisis ke dashboard dan aplikasi
Kami menyusun dashboard menggunakan Looker Studio dengan dua halaman utama. Seller Performance digunakan untuk memantau performa seller dan penjualan, sedangkan Seller Churn digunakan untuk memantau status aktivitas dan tingkat churn.
 |
| Dashboard Olist |
Kami juga mengembangkan aplikasi machine learning menggunakan Streamlit. Aplikasi menyediakan dua cara penggunaan: input manual untuk satu seller dan unggahan CSV untuk prediksi beberapa seller sekaligus.
Hasil prediksi menampilkan status beserta probabilitas churn. Probabilitas memberikan informasi tambahan mengenai tingkat risiko menurut model, sehingga pengguna dapat mempertimbangkannya ketika menyusun prioritas tindak lanjut.
Dashboard dan aplikasi memiliki fungsi yang saling melengkapi. Dashboard membantu membaca kondisi secara agregat, sedangkan aplikasi membantu menghasilkan prediksi pada data seller yang dimasukkan.
.png) |
| Proses Kerja Aplikasi Machine Learning Seller Churn |
Menyusun presentasi dan menghadapi sidang
Setelah analisis, dashboard, dan aplikasi disusun, kami merangkainya menjadi presentasi. Pada tahap ini, kami perlu menyampaikan hubungan antara masalah bisnis, keputusan pengolahan data, pemodelan, dan rekomendasi dalam waktu yang terbatas.
Puncak final project berlangsung pada 22 Oktober 2026, ketika Tim Alpha menjalani sidang di hadapan dua orang penguji.
Kami memperoleh waktu 20 menit untuk mempresentasikan proyek. Setelah itu, sesi tanya jawab dan pengujian berlangsung selama kurang lebih satu jam sepuluh menit.
Sidang menjadi tahap untuk mempertanggungjawabkan proses yang telah kami kerjakan. Hasil proyek perlu disertai penjelasan mengenai alasan pemilihan metode, cara membaca evaluasi, dan batas penggunaan model.
Pembelajaran dari final project
Melalui proyek ini, saya belajar melihat pekerjaan data sebagai rangkaian keputusan yang saling berkaitan. Definisi target memengaruhi penyusunan dataset. Penggabungan tabel memengaruhi ketepatan fitur. Evaluasi model memengaruhi bagaimana hasilnya layak digunakan.
Saya juga semakin memahami pentingnya membedakan skor prediksi dengan dampak bisnis. Model yang mampu mengenali seller churn belum otomatis membuktikan bahwa campaign akan berhasil mempertahankan seller. Efektivitas intervensi tetap perlu diuji dan diukur.
Perjalanan bersama Tim Alpha memberi pengalaman bekerja dari data sumber hingga hasil yang dapat dikomunikasikan dan digunakan. Terima kasih kepada kedua rekan tim, mentor, dan para penguji yang telah menjadi bagian dari proses pembelajaran ini.
🔗 GitHub Repository:
0 komentar:
Posting Komentar