TL;DR
Paradoks Simpson adalah keadaan waktu satu kelompok unggul di tiap segmen data, tapi kalah begitu semua segmen digabung jadi satu angka total. Penyebabnya bukan salah hitung, melainkan komposisi kelompok yang timpang plus ada variabel ketiga yang nyetir hasil. Cara ngecek paling cepat: hitung ulang metrikmu per segmen, lalu bandingin arahnya sama angka gabungan.
Paradoks Simpson adalah keadaan waktu satu kelompok unggul di tiap segmen data, tapi kalah begitu semua segmen digabung jadi satu angka total.
Kedengarannya mustahil. Tapi ini muncul rutin di data penjualan, dan sering bikin orang ngambil keputusan yang kebalik dari yang seharusnya.
Aku bakal tunjukin lewat angka promo toko_berkah, terus kasih cara ngecek datamu sendiri sebelum laporannya kamu kirim ke atasan.
Paradoks Simpson adalah pola statistik waktu arah kesimpulan berbalik antara data yang dipecah per segmen dan data yang digabung. Promo A bisa unggul di segmen pelanggan baru, unggul lagi di segmen pelanggan lama, tapi kalah di angka total. Penyebabnya bukan salah hitung, melainkan komposisi datanya yang timpang.
Namanya nempel ke Edward Simpson yang nulis soal pola ini tahun 1951, walau contoh serupa udah dibahas statistikawan sebelumnya.
Kasus paling sering dikutip datang dari data penerimaan pascasarjana UC Berkeley tahun 1973. Kalau dilihat totalnya, pelamar pria diterima 44 persen dan pelamar perempuan 35 persen. Pas dipecah per departemen, mayoritas departemen justru sedikit lebih longgar ke pelamar perempuan. Yang bikin angka totalnya timpang: pelamar perempuan lebih banyak ngelamar ke departemen yang tingkat penerimaannya rendah.
Ada dua bahan yang harus ketemu. Pertama, jumlah data di tiap segmen nggak seimbang. Kedua, segmen itu sendiri punya pengaruh besar ke metrik yang kamu ukur. Begitu dua bahan ini ada, angka gabungan berubah jadi rata-rata berbobot yang lebih nyeritain komposisi, bukan performa.
Variabel segmen yang nyetir hasil ini sering disebut variabel perancu. Dia nempel ke dua sisi sekaligus: ke perlakuan yang kamu bandingin, dan ke hasil yang kamu ukur.
Kalau kamu pernah baca soal korelasi vs kausalitas, ini kerabat dekatnya. Angka yang keliatan jelas bisa nunjuk arah yang salah kalau ada faktor ketiga yang nggak kamu masukin hitungan.
Toko_berkah, UMKM sembako dengan 2 outlet, nguji dua promo selama Juli. Promo A ngasih diskon 10 persen, Promo B ngasih bundling paket hemat. Masing-masing dikirim ke 500 pelanggan lewat WhatsApp, dan yang diukur adalah berapa persen yang akhirnya belanja.
Ini hasil lengkapnya, dipecah antara pelanggan baru dan pelanggan lama:
| Segmen | Promo A | Promo B |
|---|---|---|
| Pelanggan baru | 80 dari 400 (20%) | 15 dari 100 (15%) |
| Pelanggan lama | 45 dari 100 (45%) | 168 dari 400 (42%) |
| Total | 125 dari 500 (25%) | 183 dari 500 (36,6%) |
Lihat baris pertama: Promo A menang, 20 persen lawan 15 persen. Baris kedua: Promo A menang lagi, 45 persen lawan 42 persen.
Tapi barisnya total bilang sebaliknya. Promo B unggul jauh, 36,6 persen lawan 25 persen. Selisihnya 11,6 poin persen, cukup besar buat bikin siapa pun langsung milih Promo B.
Penyebabnya ada di penyebut. Promo A kebanyakan dikirim ke pelanggan baru (400 dari 500 orang), padahal pelanggan baru memang jarang langsung belanja. Promo B kebalikannya, 400 dari 500 penerimanya pelanggan lama yang tingkat belanjanya udah tinggi dari sananya.
Jadi angka total tadi ngukur siapa yang dikirimin promo, bukan promo mana yang lebih ngena. Kalau tim toko_berkah cuma lihat baris total, mereka bakal buang promo yang sebenernya lebih bagus di kedua segmen.
Nggak ada tombol ajaib buat ini. Yang ada cuma kebiasaan ngecek. Lima langkah ini yang aku pakai tiap kali mau ngirim angka perbandingan:
Di pandas, pengecekannya cuma beberapa baris:
# angka gabungan
df.groupby('promo')['beli'].mean()
# angka per segmen
df.groupby(['promo', 'tipe_pelanggan'])['beli'].agg(['mean', 'count'])
Kolom count itu yang paling penting. Dia yang nunjukin komposisimu timpang atau nggak. Detail parameternya ada di dokumentasi pandas groupby.
Kalau datamu masih di spreadsheet, hasil yang sama bisa kamu dapat pakai fungsi COUNTIFS buat ngitung jumlah per kombinasi, dan fungsi AVERAGEIFS buat rata-rata per segmen.
Jawaban singkatnya: tergantung segmen itu muncul sebelum atau sesudah perlakuan. Kalau segmennya udah ada sebelum promo dikirim, kayak status pelanggan baru atau lama, pakai angka per segmen. Kalau segmennya justru akibat dari perlakuan, angka per segmen malah nyesatin.
Contoh yang kedua: kamu mecah hasil promo berdasarkan pelanggan yang buka pesan atau nggak. Buka pesan itu akibat dari promonya, jadi mecah pakai kolom itu bikin perbandinganmu rusak.
Aturan praktisnya, pembagi yang aman adalah kolom yang nilainya udah kekunci sebelum perlakuan jalan. Prinsip yang sama kepakai pas kamu nyusun A/B testing yang bener.
1. Langsung percaya angka gabungan. Satu baris ringkasan di dashboard itu paling gampang dibaca dan paling gampang nipu.
2. Mecah data sampai segmennya kekecilan. Kalau tiap segmen cuma isi 7 orang, angkanya goyang gara-gara kebetulan. Berhenti mecah pas jumlah datanya udah terlalu tipis.
3. Nyari-nyari segmen sampai ketemu yang bikin hasilnya sesuai keinginan. Ini yang bikin laporan jadi alat pembenaran. Tentuin pembagi sebelum lihat hasilnya.
4. Nganggap ini bug data. Angkanya bener semua. Yang salah cara ngeringkasnya.
5. Nggak ngerapiin desain pengujian. Kalau tiap promo dikirim ke campuran segmen yang mirip, paradoks ini nggak bakal nongol dari awal. Pengacakan penerima ngerjain itu buat kamu.
Kesalahan nomor tiga masuk keluarga bias dalam analisis data yang paling susah ketahuan, soalnya kelihatan kayak kerja teliti.
Paradoks Simpson adalah keadaan waktu kesimpulanmu kebalik gara-gara data dipisah atau digabung. Satu promo bisa menang di segmen pelanggan baru dan menang lagi di segmen pelanggan lama, tapi kalah di angka total. Yang bikin kebalik biasanya jumlah orang di tiap segmen nggak seimbang. Jadi angka totalnya lebih nyeritain siapa yang diuji, bukan promo mana yang lebih ampuh.
Karena angka total itu rata-rata berbobot. Segmen yang jumlah datanya paling banyak paling nyetir hasil akhirnya. Kalau satu promo kebanyakan diuji ke segmen yang memang gampang beli, angka totalnya keangkat walau performanya di tiap segmen kalah. Bobot inilah yang sering kelewat pas kamu cuma lihat satu baris ringkasan di dashboard.
Biasakan ngecek metrik utamamu pecah per segmen sebelum dikirim, minimal pakai dua pembagi yang masuk akal kayak tipe pelanggan dan cabang. Kalau arahnya beda dari angka gabungan, tulis dua-duanya di laporan lengkap sama jumlah datanya. Nulis penyebut, bukan cuma persentase, bikin pembaca laporanmu bisa nangkep timpangnya komposisi sendiri.
Bias sampling bikin data yang kamu kumpulin nggak mewakili populasi aslinya. Paradoks Simpson bisa muncul walau datamu lengkap dan bener semua, karena masalahnya di cara ngeringkas, bukan di cara ngambil data. Dua-duanya bikin kesimpulan meleset, tapi obatnya beda. Bias sampling dibenerin di tahap pengumpulan, paradoks Simpson dibenerin di tahap analisis.
Nggak otomatis. Nambah baris data cuma bantu kalau bikin komposisi tiap segmen jadi lebih seimbang. Kalau kamu nambah 10.000 baris tapi tetap 80 persen dari segmen yang sama, polanya bakal tetap kebalik. Yang beneran nyelesaiin masalah adalah desain pengujian yang bikin tiap perlakuan dapat campuran segmen yang mirip, misalnya lewat pengacakan.
Dua hal yang perlu nempel: angka gabungan itu rata-rata berbobot, dan bobotnya sering ditentuin sama hal yang nggak kamu perhatiin.
Ambil satu laporan perbandingan yang lagi kamu kerjain sekarang, pecah metriknya pakai tipe pelanggan dan cabang, lalu lihat arahnya masih sama atau nggak. Lima menit, dan kamu bisa nyelametin satu keputusan.
Lanjut baca uji hipotesis buat mastiin selisih yang kamu lihat bukan kebetulan, atau glossary segmentation buat milih pembagi yang masuk akal.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Kolom datetime nyimpen tanggal, jam, hari, semuanya nempel jadi satu. Accessor .dt di pandas ngeluarin tiap bagian jadi kolom sendiri buat dianalisa.
Nama toko ketik campur huruf besar-kecil, spasi nyasar di ujung, atau kode produk nempel jadi satu. Accessor .str di pandas ngerapiin semua itu tanpa loop.
Model machine learning cuma ngerti angka, bukan teks kayak merah atau biru. get_dummies ngubah kolom kategori jadi kolom 0/1 dalam satu baris kode.