Bagaimana Cara Mendiagnosis Sample Ratio Mismatch dalam Uji A/B?

Konteks Pertanyaan dan Penerapan

Sebuah eksperimen produk menggunakan penetapan acak yang stabil berdasarkan pengguna dengan pembagian 50/50 yang dikonfigurasi. Setelah 100.000 pengguna yang memenuhi syarat, analisis mencakup 51.000 pengguna kontrol dan 49.000 pengguna perlakuan. Konversi perlakuan 1,8% lebih tinggi, dan uji efek biasa melaporkan p di bawah 0,01. Putuskan apakah hasilnya dapat dipercaya dan rancang proses untuk mendeteksi, mendiagnosis, memperbaiki, dan mencegah Sample Ratio Mismatch, atau SRM.

Pertanyaan ini berlaku untuk peran data science, analitik produk, business intelligence, dan platform eksperimen. Panduan wawancara peran data Amazon saat ini secara eksplisit meminta pemahaman statistik, kemampuan menangani data yang ambigu, dan mengubah analisis menjadi keputusan yang dapat ditindaklanjuti. Riset eksperimen Microsoft memperlakukan SRM sebagai sinyal keandalan (trustworthiness) inti. Kategori utamanya adalah data: tugas utamanya adalah pengujian statistik dan diagnosis data-lineage, bukan merancang keseluruhan platform eksperimen.

Nilai 100.000, 51.000, 49.000, dan 1,8% adalah asumsi wawancara, bukan tolok ukur industri. Solusi ini mengasumsikan pengguna sebagai unit pengacakan dan setiap pengguna harus muncul tepat di satu varian. Eksperimen nyata yang diacak berdasarkan perangkat, akun, workspace, rumah tangga, atau wilayah harus menguji unit yang sesuai.

Apa yang Dievaluasi Pewawancara

Sinyal pertama adalah apakah kandidat memeriksa integritas eksperimen sebelum membaca dampak bisnis. Jawaban yang lemah melihat “kenaikan 1,8% dengan p di bawah 0,01” dan langsung merekomendasikan peluncuran. Jawaban yang kuat terlebih dahulu memverifikasi bahwa populasi yang diamati cocok dengan alokasi yang dikonfigurasi. Uji efek dapat menyatakan bahwa dua hasil yang diamati berbeda; uji tersebut tidak dapat membuktikan bahwa pengguna yang tersisa dalam kelompok-kelompok tersebut masih membentuk sampel acak yang dapat diperbandingkan.

Sinyal kedua adalah apakah perbedaan rasio yang terlihat diubah menjadi uji statistik. Pembagian 51/49 yang sama memiliki arti yang sangat berbeda dengan 1.000 pengguna dibandingkan dengan 100.000 pengguna. Uji SRM membandingkan jumlah varian yang diamati dengan jumlah yang tersirat dari alokasi yang dikonfigurasi. Lebih banyak data membuat penyimpangan sistematis kecil lebih mudah dibedakan dari kebetulan semata.

Sinyal ketiga adalah cakupan diagnostik. SRM dapat masuk melalui konfigurasi alokasi, identitas yang tidak stabil, eksekusi varian, telemetri yang hilang, pemfilteran bot, penggabungan data (joins), atau kondisi analisis yang didefinisikan setelah perlakuan. Menyebut setiap SRM sebagai “pengacakan yang buruk” mengabaikan banyak kegagalan eksekusi dan pemrosesan data yang umum terjadi.

Terakhir, pewawancara mencari kedisiplinan pengambilan keputusan. SRM adalah gejala, bukan sekadar noise tidak berbahaya yang dapat dihilangkan secara otomatis dengan pembobotan (weighting). Dalam kasus yang dipublikasikan, perlakuan mengubah interaksi pengguna hingga filter bot menghapus lebih banyak pengguna yang sangat aktif; kesimpulan bisnis berbalik setelah cacat tersebut diperbaiki. Tahan keputusan peluncuran sampai akar penyebabnya dipahami, alih-alih mencari metrik lain yang kebetulan tetap signifikan.

Pertanyaan untuk Diklarifikasi Sebelum Menjawab

• Apakah 50/50 mendeskripsikan penetapan, paparan (exposure), pemicuan (triggering), atau populasi analisis akhir? Penetapan bisa saja bersih

sementara paparan, kelayakan, atau analisis downstream mengalami SRM. Uji setiap tahapan.

• Apa unit pengacakannya? Jika penetapan berdasarkan workspace, jumlah anggota dapat berbeda secara alami. Uji jumlah

workspace terlebih dahulu dan analisis hasil dengan metode yang sesuai untuk penetapan terklaster (clustered assignment).

• Apakah identitasnya stabil dan saling eksklusif? Login lintas perangkat, penghapusan cookie, penggabungan anonim-ke-akun,

dan migrasi ID dapat menetapkan ulang atau menduplikasi seseorang.

• Apakah alokasi berubah selama eksperimen berjalan? Ramp-up dari 10/90 ke 50/50 memerlukan jumlah yang diharapkan dari setiap interval,

bukan pembagian akhir yang diterapkan ke seluruh eksperimen.

• Bagaimana “pengguna yang memenuhi syarat” didefinisikan? Kondisi yang dipengaruhi oleh perlakuan, seperti mengklik tombol baru khusus perlakuan,

merupakan seleksi pasca-perlakuan (post-treatment selection) dan dapat merusak keterbandingan.

• Bisakah satu varian mengalihkan (redirect), gagal, atau mencatat log secara berbeda? Waktu muat yang lebih lambat, crash, dan telemetri khusus versi dapat menghilangkan

pengguna selama eksekusi dan pengumpulan data.

• Pipeline mana yang menghasilkan hitungan akhir? Pisahkan penetapan, paparan, pengumpulan event, deduplikasi,

pemfilteran bot, join dimensi, dan jendela metrik.

• Bisakah eksperimen dijalankan ulang? Jika rekonstruksi yang tidak bias dari log mentah tidak memungkinkan, memperbaiki cacat dan menjalankan ulang

lebih dapat dipertanggungjawabkan daripada memaksakan kesimpulan dari sampel saat ini.

Kerangka Jawaban 30 Detik

“Saya tidak akan merilisnya. Dengan alokasi 50/50, jumlah yang diharapkan adalah 50.000 per grup. Statistik chi-square adalah (51,000 - 50,000)² / 50,000 + (49,000 - 50,000)² / 50,000 = 40; dengan satu derajat kebebasan (degree of freedom), nilai p sekitar 2.54 × 10^-10. Oleh karena itu, populasi akhir memiliki sample ratio mismatch yang parah, sehingga nilai p efek bisnis bukanlah bukti untuk peluncuran. Saya akan membandingkan jumlah pada tahap penetapan, paparan, pemicu, pemrosesan log, dan analisis akhir, kemudian melakukan segmentasi berdasarkan waktu, platform, versi, dan jenis identitas untuk menemukan titik divergensi pertama. Setelah memperbaiki penyebabnya, saya akan menjalankan ulang SRM, telemetri, dan pemeriksaan A/A; jika sampel tidak dapat direkonstruksi tanpa bias, saya akan menjalankan ulang eksperimen.”

Jawaban Mendalam Langkah demi Langkah

Mulailah dengan gerbang keputusan (decision gate) yang eksplisit: eksperimen harus lulus pemeriksaan pengacakan, integritas data, dan efek bisnis. Jalankan SRM sebelum analisis efek dan tampilkan secara jelas di platform eksperimen. Praktik yang dipublikasikan Microsoft menggunakan p < 0.0005 sebagai ambang batas peringatan konservatif untuk mengurangi positif palsu pada skala platform. Itu adalah contoh yang terdokumentasi, bukan konstanta universal. Tim harus memilih ambang batas kualitasnya terlebih dahulu daripada setelah melihat hasil.

Langkah 1: Hitung SRM dengan benar.

Untuk dua varian yang dikonfigurasi pada 50/50 dengan total 100.000 pengguna, setiap jumlah yang diharapkan adalah 50.000. Statistik goodness-of-fit chi-square adalah:

χ² = Σ (observed - expected)² / expected = 40

Dengan dua kelompok dan tanpa parameter estimasi tambahan, terdapat satu derajat kebebasan, menghasilkan p sekitar 2.54 × 10^-10. Ini jauh di bawah ambang integritas konservatif dan sangat tidak masuk akal jika hanya merupakan noise alokasi biasa. Aproksimasi chi-square memerlukan jumlah yang diharapkan yang memadai; aturan umum NIST adalah sekitar lima observasi yang diharapkan per kelompok. Sampel yang sangat kecil, alokasi langka, atau banyak varian yang jarang (sparse) memerlukan uji binomial atau multinomial eksak.

Rasio harus diinterpretasikan bersama dengan ukuran sampelnya. Jika totalnya 1.000 dan hitungannya 510/490, jumlah yang diharapkan adalah 500/500, χ² = 0.4, dan p sekitar 0,527. Rasio 51/49 yang terlihat identik, tetapi buktinya tidak sama.

Langkah 2: Temukan tahap pertama di mana jumlahnya menyimpang.

Bangun funnel tahapan yang mempertahankan hitungan unit pengacakan unik berdasarkan varian:

Jika penetapan sudah tidak seimbang, periksa konfigurasi eksperimen, kode bucketing, dan ID pengacakan. Jika penetapan bersih tetapi paparan menyimpang, periksa kegagalan pemuatan khusus varian, crash, dan pengalihan. Jika populasi yang belum terpicu bersih tetapi “pengguna yang mengunjungi checkout” tidak bersih, tentukan apakah pemicu dipengaruhi oleh perlakuan atau hilang di kontrol. Jika hanya fact table akhir yang menyimpang, fokuslah pada pemfilteran, deduplikasi, dan join.

Langkah 3: Lokalisasi penyebabnya dengan waktu dan segmen.

Plot jumlah kumulatif yang diamati dan diharapkan per jam dan cari tahu kapan perbedaan mulai terjadi. Diskontinuitas yang tiba-tiba mengarah pada perubahan konfigurasi, deployment, atau pipeline. Penyimpangan bertahap sejak awal eksperimen lebih konsisten dengan cacat bucketing atau pemicu. Segmentasikan berdasarkan platform, browser, versi aplikasi, geografi, status login, jenis identitas, dan sumber traffic, sambil menampilkan ukuran segmen, arah penyimpangan, dan waktu anomali pertama.

Segmentasi adalah alat diagnostik, bukan pencarian subkelompok yang kebetulan lolos SRM. Banyak irisan data secara alami menghasilkan beberapa nilai p kecil. Irisan yang berguna harus mendukung suatu mekanisme logis. Jika SRM terkonsentrasi pada versi iOS lama dan log paparan perlakuan hilang pada versi tersebut, periksa pengiriman klien dan telemetri; jangan hanya mengecualikan iOS lalu menyatakan sisa eksperimen dapat dipercaya.

Langkah 4: Verifikasi semantik pengacakan dan identitas.

Bucketing harus merupakan fungsi deterministik dari ID pengacakan yang stabil, ID eksperimen, dan salt tetap. Unit yang sama harus tetap berada dalam satu varian sepanjang eksperimen. Periksa:

1. Apakah satu unit pengacakan muncul di beberapa varian.
2. Apakah ID anonim ditetapkan ulang saat digabungkan ke dalam ID akun.
3. Apakah pembersihan cookie atau penggunaan lintas perangkat menciptakan "pengguna baru" berulang.
4. Apakah aturan karyawan, bot, dan eksklusi diterapkan secara konsisten di sekitar penetapan.
5. Apakah setiap konfigurasi ramp memiliki stempel waktu efektif yang dapat diaudit.

Untuk pengacakan workspace atau rumah tangga, uji jumlah klaster terlebih dahulu. Varian perlakuan dapat secara acak menerima beberapa workspace besar dan menunjukkan rasio baris-anggota 51/49 tanpa adanya cacat bucketing. Memperlakukan baris anggota sebagai sampel acak independen akan menimbulkan alarm palsu (false alarm).

Langkah 5: Audit seleksi pasca-perlakuan dan data yang hilang.

Pemicu yang valid harus ditentukan dari informasi yang tersedia sebelum perlakuan kapan pun memungkinkan. “Mencapai checkout” dapat didefinisikan melalui paparan halaman yang dicatat di kedua varian. “Mengklik tombol kupon perlakuan baru” tidak memiliki observasi yang setara di kontrol dan secara alami memilih lebih banyak pengguna perlakuan. Kinerja perlakuan juga dapat mengubah kelengkapan telemetri; filter bot, timeout, dan error dapat menghapus pengguna yang paling terpengaruh oleh perubahan tersebut.

Jangan berasumsi bahwa pengguna yang hilang terjadi secara acak. Bandingkan log penetapan yang tidak dapat diubah (immutable) dengan setiap tabel downstream, ambil sampel ID yang hilang, dan periksa platform, waktu, versi, dan perilaku mereka. Jika perlakuan memengaruhi probabilitas pengguna untuk masuk ke dalam tabel analisis, perbedaan konversi yang diamati mengandung bias seleksi.

Langkah 6: Pilih perbaikan, rekonstruksi, atau jalankan ulang.

• Alokasi salah atau pengguna berada di multi-varian: hentikan, perbaiki penetapan, acak ulang, dan jalankan kembali eksperimen.
• Penetapan dan paparan lengkap dengan drop ETL yang dapat dipulihkan: perbaiki job, bangun ulang dari event mentah yang tidak bias, dan jalankan ulang SRM.
• Pemicu bergantung pada perlakuan: gunakan kondisi pra-perlakuan atau kembali ke populasi intent-to-treat yang belum terpicu.
• Telemetri wajib hilang pada versi klien tanpa backfill: perbaiki instrumentasi dan jalankan ulang untuk populasi target tersebut.
• Ramp alokasi terencana: jumlahkan hitungan yang diharapkan dari setiap interval konfigurasi dan pertahankan riwayat konfigurasi.

Pembobotan hanya dapat dibenarkan jika mekanisme seleksi diketahui, dapat diestimasi, dan divalidasi secara independen. Sebagian besar SRM menandakan bahwa mekanisme hilangnya data tidak diketahui. Mengalikan 49.000 pengguna perlakuan dengan bobot tertentu hingga totalnya terlihat seperti 50.000 tidak memulihkan perilaku pengguna yang hilang atau mengembalikan keacakan.

Langkah 7: Bangun pencegahan ke dalam platform eksperimen.

Simpan catatan penetapan yang tidak dapat diubah, rasio yang dikonfigurasi, dan stempel waktu efektif. Hitung SRM secara terpisah untuk populasi penetapan, paparan, pemicu, dan analisis. Hasil bisnis tidak boleh mendorong keputusan rilis sampai pemeriksaan integritas lolos. Jalankan uji A/A secara teratur untuk memverifikasi bahwa bucketing, telemetri, dan analisis tetap bersih saat tidak ada perbedaan produk.

Peringatan harus mencakup ukuran total, jumlah yang diamati dan diharapkan, nilai p, arah, waktu anomali pertama, dan segmen-segmen utama. Tingkatkan pengawasan setelah perubahan pada deployment, identitas, deteksi bot, atau ETL. Pertahankan lineage yang cukup setelah eksperimen berakhir untuk mereproduksi jumlah yang diharapkan dari konfigurasi historis daripada hanya menyimpan gambar dasbor.

Contoh Jawaban Berkualitas Tinggi

“Saya tidak akan merilisnya karena kenaikan 1,8% yang dilaporkan mengasumsikan sampel acak yang dapat diperbandingkan. Di bawah pembagian 50/50 yang dikonfigurasi, 51.000 pengguna kontrol dan 49.000 pengguna perlakuan memiliki jumlah yang diharapkan masing-masing 50.000. Statistik chi-square adalah 40 dengan satu derajat kebebasan, sehingga nilai p sekitar 2.54 × 10^-10. Eksperimen mengalami SRM, dan saya akan membekukan kesimpulan bisnis.

Pertama, saya akan memverifikasi bahwa pengguna adalah unit pengacakan sebenarnya dan rasio 50/50 berlaku untuk seluruh durasi pengujian. Kemudian saya akan membandingkan hitungan melalui penetapan, paparan aktual, kelayakan pemicu, inklusi fact-table event, dan analisis akhir. Tahap divergensi pertama menentukan arah investigasi. SRM penetapan mengarah pada konfigurasi, ID stabil, salt, atau keanggotaan lintas varian. Penetapan bersih tetapi paparan tidak seimbang mengarah pada deployment, performa, crash, atau pengalihan. SRM khusus pemicu mengarah pada kondisi yang bergantung pada perlakuan. SRM tabel akhir mengarah pada telemetri, pemfilteran bot, deduplikasi, atau join.

Saya akan melakukan segmentasi berdasarkan waktu, platform, versi aplikasi, geografi, status login, dan jenis ID untuk menemukan bukti bagi suatu mekanisme, bukan untuk memilih-milih (cherry-pick) subkelompok yang bersih. Jika event mentah yang tidak bias dapat merekonstruksi populasi, saya akan memperbaiki pipeline dan menjalankan ulang setiap pemeriksaan integritas. Jika pengguna melintasi varian, pemicu bergantung pada perlakuan, atau telemetri yang diperlukan tidak dapat dipulihkan, saya akan memperbaiki sistem dan menjalankan ulang eksperimen.

Untuk pencegahan, platform harus menjalankan SRM sebelum menampilkan hasil bisnis, mempertahankan penetapan dan riwayat alokasi yang tidak dapat diubah, serta memantau hitungan penetapan, paparan, pemicu, dan analisis secara terpisah. Uji A/A, bucketing yang stabil, dan pemicu pra-perlakuan akan memverifikasi alur tersebut. Hanya setelah akar penyebab dijelaskan dan populasi yang diperbaiki lolos SRM, saya akan mempertimbangkan kembali kenaikan 1,8% beserta batas pengamannya (guardrails).”

Kesalahan Umum

• Merilis karena nilai p hasil kecil → Inferensi efek mengasumsikan sampel yang sebanding → Loloskan pemeriksaan SRM dan integritas data terlebih dahulu.
• Hanya melihat persentase 51/49 → Rasio yang sama memiliki bukti berbeda pada ukuran sampel yang berbeda → Gunakan jumlah yang diharapkan dan uji statistik.
• Memperlakukan SRM hanya sebagai masalah angka acak → Eksekusi, log, dan filter juga dapat menghapus pengguna → Lacak divergensi pertama di seluruh alur.
• Menunggu hingga jumlah terlihat lebih dekat → Lebih banyak data yang bias tidak memulihkan pengacakan → Bekukan keputusan dan segera diagnosis.
• Melakukan reweighting langsung ke 50/50 → Bobot tidak memulihkan perilaku yang hilang secara sistematis → Koreksi hanya di bawah model missingness yang tervalidasi.
• Hanya memeriksa tabel analisis akhir → Ini menyembunyikan apakah penetapan atau pemrosesan downstream yang gagal → Pertahankan jumlah di setiap tahap.
• Memicu berdasarkan perilaku khusus perlakuan → Kontrol tidak memiliki kesempatan yang sama untuk masuk ke dalam sampel → Gunakan kondisi pra-perlakuan yang simetris.
• Menguji baris anggota dalam eksperimen klaster → Variasi ukuran klaster menciptakan SRM palsu → Uji unit pengacakan sebenarnya terlebih dahulu.
• Menghapus platform yang bermasalah setelah melihat hasil → Seleksi populasi post-hoc menambah bias → Gunakan irisan untuk diagnosis dan jalankan ulang populasi target yang direncanakan.
• Menggunakan kembali laporan efek lama setelah perbaikan → Laporan tersebut dihitung dari sampel yang cacat → Buat ulang analisis integritas, efek, dan guardrail.

Pertanyaan Lanjutan dan Tanggapan

Pertanyaan Lanjutan 1: Bagaimana jika pembagiannya masih 51/49 tetapi total sampelnya hanya 1.000?

Jumlah yang diharapkan masing-masing adalah 500 dan jumlah yang diamati adalah 510 dan 490. Statistik chi-square adalah (510 - 500)² / 500 + (490 - 500)² / 500 = 0.4, menghasilkan nilai p sekitar 0,527 dengan satu derajat kebebasan. Itu adalah bukti yang tidak cukup untuk SRM. Inilah mengapa aturan tetap “lebih dari satu poin persentase” tidak dapat menggantikan uji statistik, meskipun cacat teknis yang diketahui tetap harus diselidiki.

Pertanyaan Lanjutan 2: Penetapan keseluruhan lolos SRM, tetapi pengguna iOS gagal. Apakah eksperimen masih dapat digunakan?

Pertimbangkan jumlah irisan data, ukuran sampel iOS, dan apakah ada satu mekanisme yang menjelaskan anomali tersebut. Jika SRM terkonsentrasi pada versi iOS penting yang telah ditentukan sebelumnya dan kehilangan paparan menjelaskannya, hasil populasi tersebut tidak dapat dipercaya. Apakah populasi lain tetap dapat digunakan bergantung pada rencana analisis dan isolasi penyebab yang sebenarnya. Jangan membuang iOS hanya setelah melihat hasilnya; memperbaiki klien dan menjalankan ulang populasi target yang direncanakan jauh lebih aman.

Pertanyaan Lanjutan 3: Populasi yang tidak terpicu bersih, tetapi analisis yang terpicu memiliki SRM. Apa yang paling mungkin salah?

Periksa pemicunya terlebih dahulu. Pemicu mungkin hanya dicatat di satu varian atau bergantung pada perilaku yang disebabkan oleh perlakuan. Ganti dengan kondisi yang dapat dipenuhi oleh kedua kelompok sebelum perlakuan, seperti mencapai suatu halaman daripada mengklik komponen baru. Bandingkan juga cakupan telemetri pemicu. Jumlah populasi belum terpicu yang bersih menunjukkan penetapan dasar mungkin baik, tetapi tidak memvalidasi analisis efek yang terpicu.

Pertanyaan Lanjutan 4: Mengapa tidak melakukan reweighting pada kelompok berdasarkan ukuran yang diamati?

SRM tidak mengidentifikasi siapa yang hilang. Jika perlakuan kehilangan pengguna yang paling aktif, pengguna dengan konversi tertinggi, atau pengguna yang paling rentan crash, bobot hitungan hanya memulihkan totalnya, bukan distribusi perilakunya. Koreksi mungkin dimungkinkan jika probabilitas seleksi dijelaskan sepenuhnya oleh variabel pra-perlakuan dan modelnya tervalidasi, tetapi itu adalah asumsi tambahan, bukan solusi bawaan (default).

Pertanyaan Lanjutan 5: Workspace diacak 50/50, tetapi hitungan pengguna adalah 55/45. Apakah itu SRM?

Periksa jumlah workspace terlebih dahulu. Jika penetapan workspace adalah 50/50 tetapi perlakuan secara acak menerima beberapa workspace besar, ketidakseimbangan anggota dapat berupa variasi ukuran klaster biasa, bukan kegagalan bucketing. Analisis hasil juga harus memperhitungkan ketergantungan intra-workspace. Jika traffic anggota yang seimbang diperlukan, gunakan stratifikasi ukuran atau pengacakan berpasangan (matched randomization) dalam desain eksperimen daripada memperlakukan baris anggota sebagai penetapan independen setelahnya.

Pertanyaan Lanjutan 6: Eksperimen ditingkatkan (ramped) dari 10/90 ke 50/50. Bagaimana Anda menghitung jumlah yang diharapkan?

Hitung jumlah yang diharapkan dalam setiap interval alokasi dan jumlahkan. Jika 20.000 pengguna masuk di bawah 10/90 dan 80.000 di bawah 50/50, total jumlah yang diharapkan adalah 42.000 dan 58.000, bukan masing-masing 50.000. Gunakan konfigurasi dan waktu efektif yang aktif pada saat penetapan; jangan pernah menerapkan pembagian akhir secara retroaktif ke seluruh durasi eksperimen.