Diagnosis Ketidaksesuaian Rasio Sampel di Lima Cabang Sebelum Anda Membuang Tes Tersebut

Sekitar 6% eksperimen di Microsoft menunjukkan ketidaksesuaian rasio sampel, yang pada produk yang menjalankan 10,000 eksperimen per tahun berarti kira-kira satu deteksi per hari.Fabijan dkk., KDD 2019Tim yang menjalankan jauh lebih sedikit pengujian jarang melihat angka tersebut, karena pemeriksaan yang dijalankan platform mereka tidak dapat mencapai signifikansi pada volume lalu lintas mereka. Pengujian terlihat bersih, melaporkan peningkatan 4%, dan tetap saja salah.

Panduan ini ditujukan untuk orang yang membaca hasil eksperimen dan harus memutuskan apakah akan mengirimkan sampel atau tidak. Pada akhirnya, Anda akan dapat menentukan apakah pengujian Anda cukup besar sehingga pemeriksaan ketidaksesuaian menjadi berarti, menjalankan lima cabang diagnosis dalam urutan yang menemukan penyebabnya paling cepat, dan memisahkan ketidakseimbangan yang membatalkan hasil dari ketidakseimbangan yang dapat Anda abaikan dan pertahankan.

Apa yang sebenarnya diberitahukan oleh alarm SRM kepada Anda?

Ketidaksesuaian rasio sampel adalah kesenjangan antara pembagian yang Anda konfigurasi dan pembagian yang Anda amati: Anda menetapkan 50/50 dan mendapatkan 50.8/49.2. Pemeriksaan standar adalah uji kecocokan chi-kuadrat Pearson pada jumlah paparan, satu derajat kebebasan untuk uji dua kelompok.

Hal ini penting karena mekanisme yang menyebabkan hilangnya pengguna hampir tidak pernah netral terhadap metrik Anda. Jika pengalihan (redirect) menyebabkan koneksi lambat terputus dari varian tersebut, maka pengguna yang bertahan adalah mereka yang menggunakan koneksi lebih baik, dan mereka memiliki tingkat konversi yang lebih tinggi. Peningkatan tersebut tampak nyata dalam data, tetapi tidak ada dalam kenyataan.

Inilah kesalahan pertama yang sering dilakukan sebagian besar tim: tidak ada ambang batas standar industri. Platform-platform tersebut memiliki perbedaan yang lebih dari satu orde besaran.

Ada dua konsekuensi. Tes yang ditandai pada satu platform akan lolos pada platform lain dengan data yang identik, jadi "alat kami tidak memperingatkan kami" bukanlah bukti pemisahan yang bersih. Dan ambang batas 0.01 menandai satu dari seratus tes yang sehat. Jika Anda mengamati nilai p setiap hari selama tes tiga minggu, batas pengamatan independen yang naif pada alarm palsu adalah 19%; angka sebenarnya lebih rendah karena hari-hari berturut-turut sangat berkorelasi, tetapi bukan 1%. Itulah mengapa AB Tasty menjalankan prosedur berurutan. Jika platform Anda menjalankan chi-square horizon tetap, lihat sekali, di akhir, pada jumlah kumulatif.

Periksa apakah tes Anda dapat mendeteksi ketidakseimbangan sama sekali.

Untuk pembagian 50/50, statistik chi-kuadrat disederhanakan menjadi 4n(p̂−0.5)², di mana n adalah total eksposur. Balikkan persamaannya dan Anda akan mendapatkan ketidakseimbangan terkecil yang dapat ditandai oleh pemeriksaan Anda:

Bacalah ini sebagai batasan, bukan izin. Pada 10,000 eksposur, ketidakseimbangan yang lebih kecil dari 1.3 poin tidak terlihat oleh pemeriksaan, dan efek seleksi 1.3 poin lebih dari cukup untuk menghasilkan peningkatan konversi kecil. Itulah masalah struktural di sebagian besar wilayah tersebut. Turki mencatat sekitar 6 miliar transaksi e-commerce di sekitar 634,000 bisnis pada tahun 2025 (Kementerian Perdagangan, 12 Mei 2026), rata-rata hampir 9,500 per tahun untuk masing-masing, dan rata-rata tersebut sangat dipengaruhi oleh segelintir marketplace. Toko online menengah yang menguji langkah pembayaran berurusan dengan puluhan ribu eksposur, bukan jutaan, sehingga pemeriksaan SRM-nya hanya menangkap kerugian besar dan tidak ada yang lebih halus.

Pada volume tersebut, jangan mengandalkan alarm. Ambil sendiri data mentah jumlah paparan per hari dan per segmen, dan anggap pergeseran ke arah yang sama secara terus-menerus sebagai hal yang mencurigakan meskipun nilai p-nya tidak signifikan. Jika Anda tidak yakin di mana platform Anda memaparkan jumlah tersebut, Dokumentasi Pemeriksa SRM memetakannya per alat.

Kelima cabang tersebut, dalam urutan yang paling cepat menemukan penyebabnya.

Taksonomi KDD mengklasifikasikan penyebab SRM berdasarkan tahap siklus hidup: penugasan, eksekusi, pemrosesan log, analisis, dan intervensi. Diagnosa penyebab tersebut dalam urutan yang berbeda, dimulai dari yang termurah dan paling umum.

1. Analisis dan pemicuan. Gejala: pemisahan terlihat jelas dalam log paparan mentah tetapi terputus dalam kartu skor. Periksa: hitung ulang rasio tanpa kondisi pemicu, filter tanggal, dan penggabungan tingkat metrik Anda. Konfirmasikan jika rasio kembali ke yang diharapkan. Perbaiki: evaluasi pemicu secara identik di kedua kelompok, sebelum perilaku spesifik varian apa pun dapat mengubah kelayakan. Alarm palsu yang paling umum, sepuluh menit untuk menyingkirkannya.
2. Pemrosesan log. Gejala: jumlah paparan berbeda antara dua pipeline, atau kesenjangan muncul setelah langkah ETL. Periksa: bandingkan jumlah di sisi SDK, jumlah di gudang data, dan jumlah pelaporan untuk jendela yang sama, lalu bandingkan tingkat pengecualian filter bot per cabang. Konfirmasikan jika cabang-cabang tersebut sama di hulu dan tidak sama di hilir. Perbaiki: filter secara deterministik dan identik. Lalu lintas otomatis mencapai 53% dari lalu lintas web pada tahun 2026, naik dari 51% pada tahun 2024 (Laporan Bot Jahat Imperva, 29 April 2026), jadi filter heuristik yang dikunci pada waktu pemuatan atau perilaku agen pengguna dapat mengecualikan pada tingkat yang berbeda per varian. Kerugian yang didorong oleh persetujuan juga termasuk di sini: ketika ad_storage Jika permintaan ditolak, platform tag Google berhenti memasang cookie iklan.Dokumen persetujuan platform tag Google), jadi jika tingkat penolakan berbeda di berbagai wilayah geografis dalam satu pengujian, penugasan apa pun yang bergantung pada pengidentifikasi tersebut akan kehilangan pengguna secara tidak merata.
3. Eksekusi. Gejala: ketidakseimbangan meningkat seiring dengan ukuran halaman, lebih buruk di perangkat seluler, atau dimulai saat penerapan. Periksa: pisahkan rasio berdasarkan perangkat, peramban, jenis koneksi, dan hari; bandingkan waktu paparan antara kedua varian. Konfirmasikan jika defisit terkonsentrasi pada segmen yang lambat atau di satu peramban. Perbaiki: di sinilah pengujian pengalihan gagal. Pengalihan menambahkan navigasi penuh hanya ke satu varian, dan setiap orang yang meninggalkan halaman selama pengalihan tersebut merupakan kerugian selektif. Render kedua varian di sisi server pada satu URL, atau terima bahwa kedua varian tidak dapat dibandingkan.
4. Tugas. Gejala: rasio tidak seimbang sejak jam pertama dan tetap tidak seimbang dengan faktor konstan. Periksa: jalankan A/A pada alokasi yang sama dan verifikasi bahwa hash salt tidak digunakan kembali dari eksperimen sebelumnya pada populasi ini. Konfirmasikan jika A/A juga menunjukkan ketidakseimbangan. Perbaiki: tetapkan ulang dengan salt baru dan mulai ulang. Carryover dari pengujian sebelumnya adalah versi tersembunyi dari masalah ini, dan hanya A/A yang mengungkapkannya.
5. Gangguan. Gejala: ketidakseimbangan terkonsentrasi pada sejumlah kecil pengidentifikasi dengan aktivitas tinggi, atau pada rentang IP internal. Periksa: distribusi jumlah paparan per pengguna, dan 1% pengidentifikasi teratas berdasarkan volume kejadian. Konfirmasikan jika penghapusan pengidentifikasi tersebut mengembalikan rasio. Perbaikan: kecualikan lalu lintas internal dan yang dihasilkan skrip berdasarkan aturan yang terdokumentasi, bukan secara manual, sehingga pengecualiannya identik di lain waktu.

Panduan langkah demi langkah yang terperinci.

Angka-angka di bawah ini bersifat ilustratif, bukan data klien. Tes checkout melaporkan 61,480 paparan kontrol dan 58,520 paparan varian: 51.2/48.8 pada 120,000 pengguna, chi-square p di bawah 0.001. Cabang 1: menghilangkan kondisi pemicu menghasilkan 60,020 / 59,980, jadi penugasan sudah benar dan kerugian terjadi setelah paparan. Cabang 2: jumlah pipeline sesuai, pengecualian bot 0.9% di kedua lengan. Cabang 3: desktop berada di 50.1/49.9, seluler di 52.4/47.6, dan waktu median varian hingga paparan 900 ms lebih tinggi pada seluler. Diagnosis: varian mengirimkan permintaan pemblokiran rendering tambahan, pengguna seluler meninggalkan aplikasi selama proses tersebut, pengguna yang bertahan memiliki koneksi yang lebih baik. Hasil pembacaan tidak valid. Perbaikannya adalah perbaikan kinerja, dan tes dijalankan ulang, bukan diinterpretasikan ulang.

Apa yang bisa Anda selamatkan dan apa yang tidak bisa Anda selamatkan

• Batalkan pembacaan ketika mekanisme kerugian secara masuk akal dapat berkorelasi dengan metrik tersebut. Setiap penyebab eksekusi dan penugasan memenuhi syarat secara default.
• Penyelamatan per segmen Hanya jika ketidakseimbangan terbatas pada segmen yang dapat Anda kecualikan dengan jelas, segmen tersebut telah didefinisikan sebelum Anda melihat metriknya, dan sisanya lolos pemeriksaan SRM-nya sendiri. Dua dari tiga tidaklah cukup.
• Simpan tesnya padahal penyebabnya murni terletak pada analisis dan kartu skor yang telah dikoreksi dinyatakan lulus. Anda membaca ulang data yang sama dengan filter tetap, bukan mencari-cari kesalahan.
• Catat saja, baik itu dengan cara apa pun. Catat kategori penyebab pada eksperimen. Taksonomi ini memberikan manfaat secara kumulatif: jika tiga dari sepuluh pengujian terakhir Anda gagal di cabang 3, masalah Anda bukanlah eksperimen, melainkan pengiriman front-end. [DATA INTERNAL DIPERLUKAN: persentase eksperimen yang dijalankan Switas dalam 24 bulan terakhir yang gagal dalam pemeriksaan SRM, dibagi berdasarkan cabang taksonomi, untuk menggantikan tolok ukur Microsoft 6% dengan angka dari pasar ini]

Di sinilah letak kesalahannya

Pohon keputusan ini mengasumsikan uji dua kelompok dengan alokasi tetap dan diketahui serta pengacakan tingkat pengguna. Ini tidak mencakup uji multi-kelompok, yang membutuhkan chi-square penuh di semua kelompok ditambah tindak lanjut tentang pasangan mana yang salah, atau alokasi bertahap, di mana rasio yang diharapkan berubah selama pengujian dan chi-square kumulatif adalah uji yang salah. Ini tidak berlaku untuk desain klaster atau geo-randomisasi, di mana unitnya bukan pengguna dan ketidakseimbangan yang penting adalah karakteristik klaster. Ini tidak mengatakan apa pun tentang apakah definisi metrik Anda benar. Dan ini tidak dapat membantu ketika paparan tidak dicatat dan Anda menyimpulkan penugasan dari peristiwa metrik, yang bukan merupakan pengecekan pemisahan tetapi tebakan.

FAQ (Pertanyaan Umum)

Apakah pembagian 51/49 selalu menjadi masalah? Itu sepenuhnya bergantung pada n. Pada 5,000 eksposur, itu adalah noise biasa; pada 500,000, itu hampir pasti merupakan cacat. Nilailah rasio tersebut berdasarkan tabel deteksi, bukan berdasarkan aturan persentase tetap.

Bisakah saya hanya melakukan penyesuaian bobot statistik pada setiap kelompok tanpa perlu menjalankan ulang perhitungan? Tidak. Penyesuaian bobot mengoreksi jumlah dan membiarkan pilihan tetap utuh. Pengguna yang hilang sudah hilang, dan mereka bukanlah sampel acak dari kelompok tersebut.

Seberapa sering saya harus melihat nilai p SRM? Sekali saja, di akhir, berdasarkan jumlah kumulatif, kecuali jika platform Anda menjalankan prosedur berurutan. Mengintip setiap hari pada chi-square dengan horizon tetap akan meningkatkan alarm palsu secara substansial.

Apakah SRM juga membatalkan metrik pengaman? Ya, karena alasan yang sama. Jika lengan pembatas menahan populasi yang berbeda, pembatas datar tidak lebih dapat dipercaya daripada metrik utama yang bergerak.

Bagaimana jika tes A/A juga menunjukkan ketidakcocokan? Jadi, kesalahannya ada pada penugasan atau pada alur pencatatan (logging pipeline), bukan pada penanganan Anda. Perbaiki itu sebelum menjalankan hal lain, karena itu akan mencemari setiap pengujian pada platform tersebut.

Apakah pengujian pengalihan selalu menyebabkan SRM? Tidak selalu, tetapi desain ini membawa risiko struktural yang tidak dimiliki desain lain, karena navigasi tambahan hanya ada di satu lengan saja. Jika Anda harus menggunakannya, periksa rasio berdasarkan kecepatan koneksi dan perangkat sebelum membaca metrik apa pun.

Jumlah pengunjung situs saya terlalu rendah sehingga pengecekan tersebut tidak berarti apa-apa. Lalu bagaimana? Pantau jumlah paparan harian mentah untuk melihat adanya pergeseran yang terus-menerus, jalankan A/A secara berkala pada lapisan penugasan, dan daftarkan terlebih dahulu daftar pemeriksaan kewarasan yang lebih panjang. Anda menggantikan proses dengan kekuatan statistik.

Apakah penyaringan bot harus dilakukan sebelum atau setelah penugasan? Setelah pencatatan paparan, sebelum analisis, menggunakan aturan deterministik yang diterapkan secara identik pada kedua kelompok. Penyaringan heuristik di dalam SDK adalah bagaimana filter itu sendiri menjadi ketidaksesuaian.

Lakukan pengecekan pada program eksperimen Anda sendiri

Jika Anda menginginkan pendapat kedua mengenai kondisi pengujian yang sedang Anda jalankan, atau tinjauan terhadap lapisan penugasan dan pencatatan yang menjadi dasar semuanya, itulah tujuan dari layanan kami. Layanan CRO dan eksperimen tidak.

sumber

• Fabijan, Gupchup, Gupta, Omhover, Vermeer, Dmitriev, "Mendiagnosis Ketidaksesuaian Rasio Sampel dalam Eksperimen Terkontrol Online: Taksonomi dan Aturan Praktis untuk Praktisi", KDD 2019
• Dokumentasi AB Tasty, Ketidaksesuaian rasio sampel (S-SRM sekuensial, ambang batas 0.01)
• Statsig, "Panduan singkat tentang ketidaksesuaian rasio sampel", 31 Agustus 2023 (chi-square, ambang batas 0.01)
• Dokumentasi GrowthBook, Eksperimen (uji chi-square, peringatan di bawah 0.001)
• Imperva, "Laporan Bot Jahat 2026: Bot di Era Agen", 29 April 2026
• Kementerian Perdagangan Republik Turki, Angka perdagangan elektronik 2025, 12 Mei 2026
• Platform tag Google, Mode persetujuan, dan perilaku penyimpanan.
• Dokumentasi dan FAQ SRM Checker, Lukas Vermeer