JupyterLab

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.

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.

https://github.com/ashamzah/JCDSAH-026_Alpha/tree/main

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.

Beberapa waktu terakhir saya mengerjakan project Revenue Leakage & Billing Control Tower Analysis.

Project ini menggunakan kasus fiktif dengan data dummy/simulasi untuk kebutuhan pembelajaran dan portfolio. Walaupun datanya bukan data riil perusahaan, struktur kasusnya dibuat menyerupai permasalahan yang cukup sering muncul dalam proses bisnis, yaitu bagaimana data dapat digunakan untuk membantu mendeteksi potensi revenue leakage, risiko tunggakan, kualitas data collection, anomali utilitas, hingga logical error pada sistem billing.

Dalam project ini, tujuan utamanya bukan hanya membuat dashboard yang menarik secara visual. Lebih dari itu, saya ingin membangun alur analisis yang utuh: mulai dari memahami masalah bisnis, menyiapkan data, melakukan proses ETL, menganalisis data, sampai menghasilkan dashboard yang bisa membantu proses monitoring dan pengambilan keputusan.

Bagi saya, project ini menjadi latihan yang cukup menarik karena proses analisis data ternyata tidak dimulai dari membuat grafik, tetapi dimulai dari memahami konteks masalah dan memastikan data yang digunakan memang layak untuk dianalisis.

1. Memahami Konteks Masalah

Tahap pertama dalam project ini adalah memahami masalah bisnis yang ingin dianalisis.

Dalam konteks estate atau township management, salah satu tantangan utama adalah pengelolaan billing secara berkala. Setiap unit memiliki tagihan yang perlu dibayar, seperti iuran pengelolaan lingkungan atau tagihan utilitas. Jika proses billing dan collection tidak berjalan dengan baik, maka perusahaan dapat mengalami keterlambatan penerimaan kas atau bahkan potensi kebocoran pendapatan.

Beberapa masalah utama yang ingin dianalisis dalam project ini antara lain:

• Invoice yang masih berstatus unpaid atau overdue
• Tunggakan yang sudah berumur lama
• Unit vacant yang tetap membebani biaya kawasan
• Nomor kontak pemilik yang tidak lengkap
• Metode pembayaran yang tidak konsisten
• Pemakaian air yang terlihat tidak wajar
• Anomali sistem seperti invoice paid sebelum tanggal handover

Dari sini, saya menyusun pertanyaan analisis utama:

1. Township mana yang memiliki risiko tunggakan tertinggi?
2. Berapa nilai outstanding berdasarkan umur tunggakan?
3. Apakah unit vacant lebih berisiko menunggak dibanding occupied?
4. Apakah missing contact menghambat proses collection?
5. Apakah terdapat data payment method yang tidak konsisten?
6. Apakah terdapat outlier pada pemakaian air?
7. Apakah terdapat logical error pada sistem billing?

Pertanyaan-pertanyaan ini kemudian menjadi dasar dalam menentukan proses pengolahan data, analisis, dan visualisasi dashboard.

2. Persiapan Data

Setelah memahami masalah, tahap berikutnya adalah memahami data yang tersedia.

Data yang digunakan dalam project ini terdiri dari beberapa tabel utama:

1. Data Cluster

Data ini berisi informasi terkait township dan cluster. Di dalamnya terdapat informasi seperti nama township, kategori cluster, dan identitas cluster.

Tabel ini penting karena digunakan untuk melihat perbandingan risiko antar area atau township.

2. Data Unit

Data unit berisi informasi properti individual, seperti unit ID, owner, contact number, vacant status, dan handover date.

Data ini penting untuk analisis vacant property risk, missing contact, dan validasi paid before handover.

3. Data Billing

Data billing berisi informasi invoice, billing date, water usage, total amount, payment status, payment method, dan payment date.

Tabel ini menjadi sumber utama untuk menganalisis tunggakan, aging schedule, payment method, water usage outlier, dan ERP logical error.

Secara sederhana, ketiga tabel tersebut belum bisa langsung memberikan insight jika berdiri sendiri. Karena itu, data perlu digabungkan terlebih dahulu agar membentuk satu dataset analitik yang utuh.

3. Proses ETL

Tahap paling penting sebelum analisis adalah ETL, yaitu Extract, Transform, dan Load.

ETL adalah proses mengambil data dari sumber, membersihkan dan membentuk data, lalu menyimpannya kembali dalam format yang siap digunakan untuk analisis maupun dashboard.

Proses ETL

Extract: Mengambil Data dari Sumber

Pada tahap Extract, data diambil dari beberapa tabel utama yang sudah disebutkan sebelumnya, yaitu data cluster, data unit, dan data billing.

Tujuan dari tahap ini adalah memastikan semua data yang dibutuhkan untuk menjawab pertanyaan bisnis sudah tersedia.

Contohnya, jika ingin menganalisis tunggakan berdasarkan township, maka data billing harus bisa terhubung dengan data unit dan data cluster. Jika ingin menganalisis paid before handover, maka payment date dari data billing harus bisa dibandingkan dengan handover date dari data unit.

Dengan kata lain, tahap Extract memastikan bahwa semua potongan puzzle data sudah tersedia.

Transform: Membersihkan dan Membentuk Data

Setelah data berhasil diambil, tahap berikutnya adalah Transform.

Menurut saya, tahap ini adalah bagian paling penting dalam project analisis data. Karena data mentah biasanya belum siap langsung digunakan. Ada banyak hal yang perlu dicek, dibersihkan, dan dibentuk ulang.

Beberapa proses transformasi yang saya lakukan antara lain:

1. Join Data

Data cluster, unit, dan billing digabungkan menjadi satu dataset utama.

Penggabungan ini dilakukan menggunakan key seperti cluster_id dan unit_id.

Dengan hasil join ini, setiap invoice tidak hanya memiliki informasi billing, tetapi juga informasi unit, township, status vacant, dan informasi pemilik.

2. Formatting Tanggal

Kolom tanggal seperti handover_date, billing_date, dan payment_date perlu dipastikan memiliki format date/datetime yang benar.

Ini penting karena beberapa analisis sangat bergantung pada tanggal, seperti aging schedule dan paid before handover anomaly.

Jika format tanggal tidak benar, maka hasil analisis bisa salah.

3. Handling Missing Value

Missing value dicek terutama pada kolom penting seperti contact number dan payment method.

Missing contact penting untuk analisis collection data quality, sedangkan payment method penting untuk proses rekonsiliasi channel pembayaran.

4. Payment Method Cleansing

Salah satu temuan data quality adalah metode pembayaran yang ditulis dengan beberapa variasi.

Contohnya:

• bca va
• VA BCA
• BCA Virtual Account

Ketiganya sebenarnya merujuk pada channel pembayaran yang sama, yaitu BCA Virtual Account. Jika tidak dibersihkan, maka analisis payment channel akan terpecah dan kurang akurat.

Karena itu, kategori payment method distandarisasi menjadi label yang lebih konsisten.

Hasilnya, kategori payment method yang sebelumnya lebih banyak dapat diringkas menjadi kategori standar yang lebih mudah dianalisis.

5. Membuat Status Tunggakan

Dalam project ini, invoice yang dianggap sebagai tunggakan adalah invoice dengan status:

• Unpaid
• Overdue

Dari kolom payment status, saya membuat flag atau status baru untuk membedakan invoice yang termasuk tunggakan dan tidak tunggakan.

Kolom ini kemudian digunakan untuk menghitung rasio tunggakan, outstanding amount, dan analisis collection risk.

6. Membuat Aging Bucket

Aging bucket digunakan untuk mengelompokkan tunggakan berdasarkan umur tagihan.

Contoh bucket yang digunakan:

• 0–1 bulan
• 2–3 bulan
• 4–6 bulan
• Lebih dari 6 bulan

Aging bucket ini sangat penting karena semakin lama tagihan tertunda, semakin tinggi risiko recovery-nya.

Dalam project ini, bucket lebih dari 6 bulan menjadi salah satu fokus utama karena memiliki outstanding amount terbesar.

7. Flagging Missing Contact

Untuk mendukung analisis collection data quality, saya membuat flag untuk membedakan unit dengan contact available dan missing contact.

Missing contact bukan berarti selalu menjadi penyebab tunggakan, tetapi tetap penting secara operasional karena tim collection akan lebih sulit melakukan follow-up kepada pemilik unit.

8. Deteksi Water Usage Outlier

Pada bagian utility billing, saya mendeteksi outlier pada pemakaian air.

Outlier ini dihitung menggunakan pendekatan IQR atau Interquartile Range. Nilai yang berada jauh di luar batas normal akan ditandai sebagai extreme outlier.

Tujuan dari analisis ini adalah untuk mendeteksi potensi salah input meteran, error pencatatan, atau potensi salah tagih utilitas.

9. Flagging Paid Before Handover

Salah satu analisis yang cukup penting adalah mendeteksi invoice yang berstatus Paid, tetapi payment date-nya lebih awal dari handover date.

Secara alur bisnis, kondisi ini terlihat tidak wajar. Karena itu, transaksi seperti ini ditandai sebagai anomali paid before handover.

Anomali ini bisa mengindikasikan beberapa kemungkinan, seperti bug sistem, salah mapping tanggal, backdated transaction, atau masalah migrasi data.

Load: Menyimpan Data Bersih

Setelah proses cleaning dan transformasi selesai, data final disimpan sebagai clean table.

Clean table ini kemudian digunakan sebagai sumber utama untuk dashboard.

Bagi saya, tahap Load ini penting karena dashboard sebaiknya tidak langsung membaca data mentah yang masih belum rapi. Dengan adanya clean table, dashboard menjadi lebih stabil, lebih cepat dibaca, dan lebih mudah dikembangkan.

Secara sederhana, output dari proses ETL ini adalah satu dataset analitik yang sudah siap digunakan untuk menjawab pertanyaan bisnis.

4. Analisis Data

Setelah data bersih tersedia, tahap berikutnya adalah analisis data.

Proses & Hasil Analisis Data

Dalam project ini, saya membagi analisis ke beberapa area utama.

Revenue Leakage Analysis

Analisis pertama adalah revenue leakage.

Revenue leakage dalam project ini didefinisikan sebagai potensi pendapatan yang belum tertagih karena invoice masih berstatus unpaid atau overdue.

Dari analisis ini, saya melihat rasio tunggakan antar township. Menariknya, rasio tunggakan antar township terlihat relatif mirip, yaitu berada di kisaran 28,5% sampai 29,9%.

Hal ini menunjukkan bahwa masalah collection tidak hanya terjadi di satu township tertentu, tetapi cenderung bersifat sistemik.

Artinya, strategi collection tidak cukup hanya difokuskan berdasarkan township dengan rasio tertinggi. Perlu dilihat juga dari sisi aging dan nilai outstanding.

Aging Schedule Analysis

Setelah melihat revenue leakage secara umum, analisis dilanjutkan ke aging schedule.

Aging schedule digunakan untuk melihat umur tunggakan.

Dari hasil analisis, outstanding terbesar berada pada kategori tunggakan lebih dari 6 bulan, dengan nilai sekitar Rp82,51 miliar.

Temuan ini penting karena tagihan yang sudah lama tertunda biasanya memiliki risiko recovery yang lebih tinggi.

Dari sisi prioritas, collection sebaiknya difokuskan pada aging lebih dari 6 bulan, terutama pada township yang menyumbang porsi terbesar dari total revenue tertunda.

Dalam project ini, tiga township utama menyumbang sekitar 82,7% dari total revenue tertunda lebih dari 6 bulan.

Vacant Property Risk Analysis

Analisis berikutnya adalah vacant property risk.

Unit vacant adalah unit yang kosong atau tidak dihuni. Walaupun unit tersebut tidak dihuni, kawasan tetap membutuhkan biaya operasional seperti keamanan, kebersihan, fasilitas umum, dan maintenance.

Dari hasil analisis, unit vacant memiliki rasio tunggakan yang jauh lebih tinggi dibanding occupied.

Rasio tunggakan unit vacant mencapai 59,7%, hampir tiga kali lebih tinggi dibanding occupied.

Untuk memperkuat insight ini, saya menggunakan Chi-Square Test. Hasilnya menunjukkan bahwa terdapat hubungan signifikan antara occupancy status dan status tunggakan.

Artinya, vacant status dapat digunakan sebagai salah satu indikator risiko dalam strategi collection.

Collection Data Quality Analysis

Setelah menganalisis vacant risk, saya masuk ke collection data quality.

Fokusnya adalah melihat apakah missing contact berhubungan dengan status tunggakan.

Dari hasil analisis, missing contact tidak terbukti signifikan secara statistik sebagai penyebab tunggakan. Proporsi tunggakan antara unit dengan contact available dan missing contact relatif mirip, sekitar 30%.

Namun, secara operasional, missing contact tetap menjadi masalah.

Mengapa?

Karena jika nomor kontak pemilik tidak tersedia, maka tim collection akan lebih sulit melakukan follow-up. Jadi, missing contact mungkin bukan penyebab utama tunggakan, tetapi tetap dapat menghambat proses collection.

Ini menjadi contoh bahwa hasil statistik dan konteks bisnis perlu dibaca bersama-sama.

Payment Method Cleansing

Bagian berikutnya adalah payment method cleansing.

Sebelum cleaning, beberapa metode pembayaran tercatat dalam format yang berbeda-beda, padahal merujuk ke channel yang sama.

Contohnya variasi BCA Virtual Account, Cash, Tokopedia, dan Credit Card.

Setelah proses cleaning, kategori payment method menjadi lebih ringkas dan konsisten.

Hal ini penting karena payment method yang tidak standar dapat mengganggu analisis channel pembayaran dan proses rekonsiliasi finance.

Namun, masih terdapat payment method yang kosong atau None. Ini perlu menjadi perhatian karena dapat mengindikasikan masih adanya gap dalam pencatatan channel pembayaran.

Water Usage Outlier Analysis

Selanjutnya adalah analisis water usage outlier.

Tujuannya adalah mendeteksi pemakaian air yang tidak wajar.

Outlier pemakaian air perlu divalidasi karena bisa menimbulkan salah tagih utilitas. Meskipun secara persentase jumlah extreme outlier relatif rendah, yaitu kurang dari 1%, tetap perlu dilakukan validasi.

Dalam project ini, outlier tertinggi ditemukan pada kategori tertentu dengan nilai sekitar 0,65%.

Insight penting dari analisis ini adalah bahwa water usage outlier lebih tepat diperlakukan sebagai risiko akurasi billing, bukan sebagai penyebab utama tunggakan.

ERP Logical Error Analysis

Salah satu bagian paling menarik dalam project ini adalah analisis ERP logical error.

Saya mendeteksi invoice dengan status Paid, tetapi payment date lebih awal daripada handover date.

Secara alur bisnis, kondisi ini tidak normal. Pembayaran seharusnya terjadi setelah unit aktif atau setelah invoice terbentuk sesuai alur billing.

Dari hasil analisis, ditemukan 6.291 invoice anomali paid before handover dengan nilai sekitar Rp8,35 miliar.

Selain itu, sekitar 82,9% invoice anomali terkonsentrasi pada tiga township utama.

Temuan ini menunjukkan bahwa audit sistem bisa dilakukan lebih terarah, tidak harus langsung menyisir semua area secara merata.

Rekomendasi utamanya adalah menambahkan validation rule pada sistem agar payment date tidak boleh lebih awal dari handover date.

5. Dashboard Looker Studio

Setelah semua analisis dilakukan, hasilnya divisualisasikan ke dalam dashboard Looker Studio.

Dashboard ini dibuat sebagai bentuk billing control tower, yaitu tampilan monitoring yang membantu melihat kondisi billing dan collection secara lebih terpusat.

Tampilan Dashboard

Beberapa halaman dashboard yang dibuat antara lain:

1. Executive Overview

Halaman ini berisi ringkasan KPI utama, seperti total billing, outstanding amount, paid, unpaid, overdue, dan indikator risiko utama lainnya.

2. Collection & Aging

Halaman ini digunakan untuk memantau aging tunggakan dan menentukan prioritas collection berdasarkan umur tagihan serta nilai outstanding.

3. Vacant Property Risk

Halaman ini digunakan untuk memantau risiko tunggakan pada unit vacant dan membandingkannya dengan unit occupied.

4. Water & Utility

Halaman ini digunakan untuk memantau pemakaian air dan mendeteksi outlier yang berpotensi menyebabkan salah tagih utilitas.

5. Data Quality Monitoring

Halaman ini digunakan untuk memantau missing contact, payment method cleansing, dan ERP logical error.

Dengan dashboard ini, insight yang sebelumnya hanya ada di notebook dapat digunakan secara lebih praktis untuk monitoring.

6. Kesimpulan

Dari project ini, ada beberapa insight utama yang saya dapatkan.

Key Visual

Pertama, risiko revenue terbesar tidak hanya berasal dari rasio tunggakan, tetapi terutama dari aging tunggakan yang sudah lebih dari 6 bulan.

Kedua, unit vacant memiliki risiko tunggakan yang jauh lebih tinggi dibanding occupied, sehingga perlu menjadi segment khusus dalam strategi collection.

Ketiga, missing contact tidak terbukti signifikan sebagai penyebab tunggakan, tetapi tetap menjadi hambatan operasional dalam proses follow-up.

Keempat, outlier pemakaian air relatif rendah, tetapi tetap perlu divalidasi untuk mencegah salah tagih utilitas.

Kelima, ERP logical error berupa paid before handover perlu menjadi prioritas audit karena melibatkan nilai transaksi yang cukup besar.

7. Rekomendasi

Berdasarkan hasil analisis, beberapa rekomendasi yang dapat dilakukan antara lain:

1. Menerapkan risk-based collection berdasarkan aging, nilai outstanding, vacant status, dan contact availability.
2. Memprioritaskan collection pada aging lebih dari 6 bulan.
3. Membuat segment khusus untuk unit vacant yang memiliki status unpaid atau overdue.
4. Melakukan cleansing contact number secara berkala.
5. Menstandarisasi payment method untuk mendukung rekonsiliasi finance.
6. Memvalidasi water usage outlier sebelum invoice diterbitkan.
7. Menambahkan validation rule pada ERP agar payment date tidak lebih awal dari handover date.
8. Menggunakan dashboard sebagai alat monitoring billing control secara berkala.

Penutup

Dari project ini saya belajar bahwa proses analisis data tidak hanya berhenti di membuat grafik atau dashboard.

Bagian paling penting justru ada pada bagaimana kita memahami konteks bisnis, membersihkan data, membuat fitur yang relevan, menganalisis pola, dan menerjemahkan hasilnya menjadi rekomendasi yang bisa ditindaklanjuti.

Dashboard yang bagus bukan hanya yang terlihat menarik, tetapi yang mampu membantu menjawab pertanyaan bisnis dengan lebih jelas.

Karena pada akhirnya, data analysis bukan hanya tentang angka, tetapi tentang bagaimana angka tersebut bisa membantu proses pengambilan keputusan.

Link Terkait

• Github : File Analisis
• Dashboard : Looker Studio

Catatan

Project ini menggunakan kasus fiktif dan data dummy/simulasi untuk kebutuhan pembelajaran dan portfolio.

Machine Learning menjadi salah satu topik yang paling banyak dibahas saat ini. Perkembangannya didorong oleh kemajuan teknologi dan arus digitalisasi yang sangat masif, terutama dalam bidang Artificial Intelligence (AI).

Dalam ekosistem AI, Machine Learning berperan penting sebagai komponen yang memungkinkan sistem untuk belajar dari data. Secara umum, proses pembelajaran ini terbagi menjadi tiga kategori utama: supervised learning, unsupervised learning, dan reinforcement learning.

Penerapan Machine Learning kini telah merambah berbagai sektor untuk meningkatkan efisiensi dan produktivitas. Industri besar, misalnya, banyak memanfaatkan supervised learning untuk menganalisis segmentasi pasar, memprediksi penjualan, mengoptimalkan rantai pasok, dan berbagai kebutuhan strategis lainnya.

Machine Learning dalam Akuakultur

Dalam dunia akuakultur, penerapan Machine Learning berkembang sangat cepat. Beragam studi dan industri mulai memanfaatkannya untuk meningkatkan performa budidaya, antara lain:

• Analisis dan deteksi pola kualitas air
• Prediksi pertumbuhan udang
• Estimasi panjang dan bobot benur melalui foto
• Estimasi ukuran hepatopankreas udang berbasis citra
• Deteksi penyakit sejak dini
• Optimasi pakan dan manajemen kolam berbasis data

Semua aplikasi tersebut memiliki satu fondasi utama yaitu data.

Data yang digunakan dalam Machine Learning harus valid, lengkap, dan sesuai format. Kualitas data menentukan kualitas model yang dihasilkan. Prinsip dasarnya sederhana:

• Data yang benar → kesimpulan yang benar

• Data yang salah → kesimpulan yang keliru

Karena itu, proses pengumpulan, pembersihan, dan verifikasi data menjadi tahapan yang tidak bisa diabaikan dalam setiap analisis Machine Learning—terlebih dalam akuakultur yang sangat dipengaruhi dinamika lingkungan.

Data Imputasi

Dalam proses data collection akuakultur, keberadaan data NaN (Not a Number) atau data kosong merupakan masalah yang sangat sering dijumpai. 

Ketidakhadiran data ini dapat mengganggu proses analisis statistik maupun model Machine Learning yang membutuhkan data lengkap dan konsisten. Karena itu, langkah penting yang harus dilakukan sebelum analisis lanjut adalah data imputasi.

Data imputasi adalah proses mengisi nilai yang hilang (missing values) menggunakan estimasi yang didasarkan pada pola atau tren dari data lain yang tersedia. 

Tujuannya adalah menjaga integritas dataset sehingga analisis dapat berjalan tanpa bias yang disebabkan oleh kekosongan data.

Ada beberapa metode imputasi yang sering digunakan, di antaranya:

• Mean Imputation – mengisi nilai kosong dengan nilai rata-rata kolom
• Median Imputation – mengisi dengan nilai median
• Mode Imputation – mengisi dengan nilai yang paling sering muncul
• Iterative Imputer – metode yang lebih kompleks, mengestimasi nilai hilang dengan memodelkan hubungan antar variabel

Metode yang dipilih biasanya bergantung pada karakteristik data dan tujuan analisis.

Data Imputasi

Dalam kasus ini, saya menggunakan JupyterLab (Python) untuk melakukan proses imputasi dengan metode SimpleImputer strategy="mean".

Nilai-nilai yang hilang kemudian diestimasi sehingga menjadi bernilai 0, namun tetap mempertahankan distribusi dan pola umum dataset. 

Dengan demikian, hasil akhir dataset menjadi lebih realistis, bersih, dan siap dipakai tanpa mengganggu pola atau tren sebelumnya.

Proses ini penting untuk memastikan bahwa model Machine Learning yang digunakan nantinya mendapatkan input yang valid dan representatif, sehingga hasil prediksi lebih akurat dan dapat diandalkan.

Feature Importance

Akuakultur adalah sistem yang kompleks dan dipengaruhi oleh berbagai faktor, mulai dari kualitas air, kondisi mikrobiologi (termasuk bakteri dan virus), hingga faktor genetik. 

Keragaman faktor ini seringkali membuat kita kesulitan menentukan variabel mana yang paling berpengaruh terhadap performa budidaya.

Untuk menjawab tantangan tersebut, konsep Feature Importance menjadi sangat penting. Feature Importance merupakan salah satu output dari algoritma Machine Learning yang membantu mengukur tingkat pengaruh setiap variabel terhadap hasil prediksi model.

Feature Importance dalam Random Forest

Pada algoritma Random Forest, Feature Importance umumnya dihitung menggunakan dua pendekatan utama:

Gini Importance (Mean Decrease in Impurity – MDI)

Metode ini mengukur seberapa besar penurunan impurity (ketidakmurnian) saat sebuah fitur digunakan untuk melakukan split pada decision tree.

Semakin sering dan semakin besar pengurangan impurity yang dihasilkan oleh suatu fitur, semakin tinggi nilai importance-nya. 

Sederhananya: Fitur yang banyak membantu model membuat keputusan dengan “lebih bersih” dianggap lebih penting.

Permutation Importance

Pada metode ini, nilai suatu fitur diacak (shuffled) tanpa mengubah fitur lainnya. Model kemudian dijalankan ulang untuk melihat penurunan performa (misalnya akurasi atau R²).

Jika performa model turun drastis, maka fitur tersebut sangat penting. Jika performa tetap stabil, fitur tersebut kurang berpengaruh.

Metode ini dianggap lebih intuitif karena mengevaluasi pentingnya fitur berdasarkan dampaknya terhadap prediksi akhir.

Feature Importance (Aplikasi Random Forest)

Dalam analisis ini, saya menggunakan JupyterLab (Python) untuk menghitung Feature Importance menggunakan algoritma Random Forest. 

Hasilnya kemudian divisualisasikan dalam bentuk grafik sehingga lebih mudah dipahami.

Pada grafik tersebut, semakin tinggi nilai Importance (%), semakin besar pengaruh variabel tersebut terhadap performa akuakultur.

Visualisasi ini membantu menentukan variabel mana yang perlu diprioritaskan dalam manajemen budidaya.

Analisis Risk Zone

Analisis Risk Zone bertujuan untuk mengidentifikasi rentang nilai parameter yang meningkatkan probabilitas terjadinya Low Productivity dengan tingkat probabilitas ≥60% dan ≥80%.

Analisis ini dilakukan menggunakan pendekatan Machine Learning, yaitu Random Forest Classifier yang dikombinasikan dengan metode Accumulated Local Effects (ALE) untuk menjelaskan pengaruh masing-masing parameter terhadap probabilitas produktivitas tambak.

Random Forest digunakan untuk membangun model klasifikasi antara tambak dengan produktivitas rendah dan produktivitas tinggi, sedangkan ALE digunakan untuk mengidentifikasi rentang nilai parameter yang meningkatkan risiko terjadinya Low Productivity berdasarkan prediksi model.

Sebelum melakukan analisis zona berbahaya, kita perlu untuk menentukan productivity class sebagai grup faktor. Productivity class ditentukan berdasarkan distribus data yaitu : Low Productivity (< Q1 : < 25%) dan High Productivity (>Q3 : >75%).

Berdasarkan hasil klasifikasi, ditentukan nilai Quartil 1 (Q1) yaitu 5 kg/m², Quartil 2 (Median) yaitu 7 kg/m² dan Quartil 3 (Q3) yaitu 11 kg/m².

Data yang berada pada rentang Q1–Q3 tidak digunakan dalam model klasifikasi untuk meningkatkan kontras antara kelompok produktivitas rendah dan tinggi sehingga model machine learning dapat mengidentifikasi pola dengan lebih jelas.

Random Forest Classifier dan Accumulated Local Effects (ALE)

Model Random Forest Classifier digunakan untuk mempelajari hubungan antara parameter budidaya (seperti kepadatan tebar, kualitas air, dan faktor lingkungan) dengan kelas produktivitas tambak. Model ini menghasilkan probabilitas terjadinya Low Productivity pada berbagai kombinasi parameter.

Selanjutnya metode Accumulated Local Effects (ALE) digunakan untuk menganalisis pengaruh lokal setiap parameter terhadap probabilitas Low Productivity. ALE memungkinkan identifikasi rentang nilai parameter yang meningkatkan probabilitas risiko berdasarkan distribusi data aktual. Melalui kombinasi metode ini, dapat ditentukan:

• High Risk Zone (≥60%) → rentang parameter yang meningkatkan probabilitas Low Productivity ≥60%

• Critical Risk Zone (≥80%) → rentang parameter dengan probabilitas Low Productivity ≥80%

Zona ini kemudian digunakan sebagai indikator batas operasional parameter budidaya yang berpotensi menurunkan produktivitas tambak.

Model Prediksi & AI Advisor

Dalam praktik akuakultur modern, tantangan terbesar bukan hanya bagaimana membesarkan udang, tetapi bagaimana mengantisipasi risiko sebelum masalah benar-benar terjadi. Di sinilah peran machine learning mulai terasa relevansinya.

Melalui tools yang saya kembangkan, yaitu PL Performance Prediction, pendekatan berbasis data digunakan untuk membaca kondisi biologis dan lingkungan secara lebih komprehensif. Tools ini dirancang untuk membantu memperkirakan bagaimana performa post larvae (PL) akan berkembang, sekaligus mendeteksi potensi risiko dari bakteri seperti Vibrio.

Alih-alih hanya mengandalkan observasi manual, sistem ini memanfaatkan parameter yang sebenarnya sudah sangat familiar di lapangan, seperti tahap PL, tingkat kelangsungan hidup awal (SR), serta kepadatan bakteri dalam air (TVC dan GVC). Dari kombinasi data tersebut, model kemudian “belajar” mengenali pola—misalnya, bagaimana peningkatan beban bakteri dapat berdampak pada penurunan survival atau menghambat pertumbuhan.

Hasilnya bukan sekadar angka. Tools ini mampu memberikan gambaran yang lebih utuh: mulai dari prediksi panjang akhir PL, estimasi bobot rata-rata (MBW), hingga kemungkinan survival rate di fase berikutnya. Visualisasi grafik yang ditampilkan membantu pengguna melihat tren pertumbuhan dan potensi penurunan performa secara lebih intuitif.

Salah satu fitur penting dalam tools ini adalah kemampuan untuk membaca tingkat stres biologis melalui indikator yang disebut Stress Index. Nilai ini memberikan sinyal sederhana namun powerful—semakin tinggi nilainya, semakin besar tekanan yang dialami oleh PL. Dalam banyak kasus, kondisi ini berkaitan erat dengan tingginya populasi bakteri, terutama Vibrio yang bersifat patogen.

Ketika kelimpahan bakteri meningkat, model secara otomatis menangkap potensi dampaknya terhadap survival dan pertumbuhan. Dengan kata lain, sistem tidak hanya melihat apa yang terjadi, tetapi juga mencoba memahami mengapa itu terjadi.

Untuk menjembatani hasil analisis dengan kebutuhan praktis di lapangan, tools ini dilengkapi dengan fitur AI Advisor. Fitur ini berperan sebagai “asisten digital” yang menerjemahkan hasil prediksi menjadi insight yang lebih mudah dipahami. Bukan hanya memberi tahu bahwa kondisi sedang tidak ideal, tetapi juga menjelaskan faktor penyebabnya—misalnya, tingginya GVC yang berkontribusi terhadap penurunan SR.

Lebih dari itu, AI Advisor juga memberikan rekomendasi tindakan yang bisa langsung diterapkan. Mulai dari saran pengelolaan kualitas air, pengurangan beban organik, hingga perlunya monitoring lebih intensif dalam 24–48 jam ke depan. Pendekatan ini membuat sistem tidak hanya bersifat analitis, tetapi juga solutif dan preventif.

Dengan integrasi antara model prediksi dan AI Advisor, tools ini pada dasarnya mengubah cara kita melihat data dalam akuakultur. Data tidak lagi hanya menjadi catatan, tetapi menjadi dasar pengambilan keputusan. Dari yang sebelumnya reaktif—menangani masalah setelah terjadi—menjadi lebih proaktif dengan mendeteksi risiko sejak dini.

Pada akhirnya, inilah arah perkembangan akuakultur ke depan: lebih presisi, berbasis data, dan didukung oleh kecerdasan buatan. Teknologi seperti ini bukan untuk menggantikan pengalaman di lapangan, tetapi untuk memperkuatnya—memberikan sudut pandang tambahan yang mungkin tidak selalu terlihat secara kasat mata.

Dan mungkin, dari sinilah kita mulai bergerak menuju sistem budidaya yang tidak hanya produktif, tetapi juga lebih stabil dan berkelanjutan.

One Way Anova & Uji Lanjut

Pada sebuah studi eksperimental dari data PlantGrowth, kita memiliki 3 kelompok percobaan dengan 10 ulangan, yaitu :

• Control (ctrl): Tidak diberikan perlakuan khusus.
• Treatment 1 (trt1): Diberikan perlakuan A.
• Treatment 2 (trt2): Diberikan perlakuan B.

Fokus analisis ini adalah untuk mengetahui apakah terdapat perbedaan yang signifikan dalam rata-rata berat antar kelompok perlakuan.

One Way Anova & Uji Lanjut (Tukey-HSD)   Uji Anova digunakan untuk mengetahui apakah terdapat perbedaan rata-rata antar kelompok perlakuan. Hasil analisis Anova menunjukkan bahwa kelompok perlakuan memberikan pengaruh yang signifikan (p-value < 0.05) terhadap pertumbuhan tanaman.  Anova tidak menunjukkan pasangan mana yang berbeda. Maka dari itu kita lanjutkan dengan uji post-hoc. Uji Tukey HSD (Honest Significant Difference) digunakan untuk mengidentifikasi pasangan kelompok mana yang berbeda secara signifikan. Trt2 memberikan hasil pertumbuhan tertinggi dengan menunjukkan nilai yang signifikan dengan Trt1, namun tidak signifikan dengan Ctrl. Kemudian Ctrl menunjukkan nilai yang tidak signifikan dengan Trt1. Download : Notebook & Data