Sample Ratio Mismatch (SRM): Panduan Lengkap dengan Solusi untuk Kasus Pelanggan

Apa yang lebih buruk dari tes yang gagal?

Masalah kualitas data pengujian yang membuat hasil pengujian tidak dapat diandalkan.

Tapi bagaimana Anda bisa menjauh dari data yang buruk?

Memeriksa Sample Ratio Mismatch (SRM) adalah cara sederhana untuk mengetahui potensi masalah lebih awal. Jika ada sesuatu yang mencurigakan, semakin cepat Anda mengetahuinya, semakin baik.

Baca terus untuk mempelajari lebih lanjut tentang Ketidakcocokan Rasio Sampel, cara menemukannya, pengaruhnya terhadap pengujian Anda, dan platform pengujian A/B mana yang dilengkapi dengan pemeriksaan SRM bawaan (sehingga Anda tidak perlu menyimpan spreadsheet di samping) .

Apa itu Sample Ratio Mismatch (SRM)?

Sample Ratio Mismatch, atau SRM, terjadi dalam pengujian A/B ketika jumlah sampel sebenarnya (atau pengunjung dalam kelompok perlakuan) tidak sesuai dengan yang diharapkan.

Mari kita ilustrasikan ini dengan sebuah contoh.

Katakanlah sebuah situs web mendapat sekitar 15k pengunjung per minggu. Kami memiliki 3 variasi, yang asli (yang merupakan halaman yang tidak diubah), dan 2 variasi. Berapa banyak lalu lintas yang Anda harapkan diterima masing-masing jika lalu lintas dialokasikan secara merata? Di dunia yang ideal, jawabannya adalah bahwa setiap variasi harus menerima 15.000 / 3 = 5.000 pengunjung.

Sekarang, sangat tidak mungkin bahwa setiap variasi benar-benar akan menerima 5000 pengunjung, tetapi jumlah yang sangat dekat dengan itu, seperti 4982, atau 5021. Sedikit variasi itu normal dan disebabkan oleh keacakan sederhana! Tetapi jika salah satu variasi menerima 3500 pengunjung dan yang lainnya sekitar 5000, mungkin ada yang salah dengan itu!

Daripada mengandalkan intuisi kita sendiri untuk menemukan masalah ini, kita bisa melakukan tes SRM. Ini menggunakan uji kecocokan Chi-kuadrat untuk memberi tahu kami, misalnya, jika 4850 atau 4750 pengunjung, dibandingkan dengan jumlah pengunjung lain yang diterima, adalah "normal" atau tidak!

Dalam istilah statistik, uji kecocokan Chi-kuadrat membandingkan jumlah sampel yang diamati dengan yang diharapkan. Dan jika ada perbedaan nyata, nilai p akan lebih rendah dari tingkat signifikansi yang ditetapkan 0,01, yang sesuai dengan kepercayaan 99%.

Apakah Tes A/B Anda Memiliki SRM? Bagaimana Menghitung Sample Ratio Mismatch?

Dalam pengujian A/B, SRM dapat menjadi boogeyman nyata, menyebabkan hasil yang tidak akurat dan kesimpulan yang salah arah. Kabar baiknya adalah ada alat di luar sana yang dapat membantu Anda menghindari sakit kepala.

Menggunakan Spreadsheet

Spreadsheet adalah metode paling sederhana untuk menghitung SRM karena ketersediaan luas Microsoft Excel dan/atau Produk Google.

Mari kita tunjukkan contoh lain.

Kami akan menghitung SRM untuk pengujian A/B dengan pembagian lalu lintas 50/50 dan jumlah pengunjung yang diamati masing-masing 214.598 dan 241.156 untuk Asli dan Variasi.

Kami akan menggunakan uji Chi-kuadrat untuk melihat apakah pemisahan lalu lintas yang diamati cocok dengan pembagian lalu lintas yang diharapkan. Jika tidak, Anda akan ingin tahu apakah nilai yang diamati cukup berbeda dari nilai yang diharapkan untuk menimbulkan kekhawatiran dan menjamin membuang hasilnya.

Anda harus menggunakan fungsi CHISQ.TEST di spreadsheet Anda untuk menghitung nilai-p, seperti yang diilustrasikan dalam spreadsheet di bawah ini.

Dalam contoh kami, nilai p adalah 0. Dengan nilai p di bawah 0,05, Anda memiliki SRM di tangan Anda dan cukup bukti untuk mengabaikan temuan tes dalam banyak kasus.

Menggunakan Kalkulator Ketidakcocokan Rasio Sampel Online

1. Kalkulator Convert dapat membantu mendiagnosis ketidakcocokan rasio sampel dan juga memberi tahu Anda berapa banyak waktu yang Anda perlukan untuk menunggu eksperimen Anda selesai!
   

   

2. Kalkulator online khusus SRM lainnya adalah yang dirancang oleh Lukas Vermeer. Metode ini menghitung SRM dengan cara yang sama seperti teknik sebelumnya, jadi jika Anda mengikuti dan memahami prosesnya, Anda harus dapat menggunakan kalkulator SRM online ini. Cukup isi angka untuk sampel Anda dan hasilnya akan terlihat seperti ini
   

   

Bagaimana SRM Mempengaruhi Pengujian A/B?

Sepertinya Anda telah melihat pemisahan lalu lintas di antara varian selama eksperimen dan mempertanyakan seberapa akuratnya.

Mungkin salah satunya terlihat seperti laporan di bawah ini. Anda mungkin melihatnya dan bertanya-tanya apakah itu normal bahwa Asli memiliki 1330 pengunjung tetapi Variasi 1713.

Perhitungan statistik singkat dari rasio SRM (menggunakan salah satu dari dua metode di atas) akan memberi tahu Anda apakah rasio variasi dapat diterima atau tidak.

Apakah pemisahan aktual antara dua variasi (Asli dan Variasi 1) sesuai dengan nilai yang diharapkan? Jika bukan itu masalahnya, Anda harus menolak data dan meluncurkan kembali pengujian setelah Anda memecahkan masalah.

Apakah SRM Mempengaruhi Model Statistik Frequentist dan Bayesian?

Ya.

Penyebab SRM memiliki dampak yang sama pada validitas hasil eksperimen, baik data dianalisis dengan pendekatan Bayesian (Google Optimize, Optimizely, VWO, A/B Tasty) atau Frequentist (Convert Experiences, Dynamic Yield).

Jadi kalkulator SRM di atas juga dapat digunakan untuk memeriksa SRM pada platform yang menggunakan statistik Bayesian.

Kapan Anda Harus Memperhitungkan SRM?

Menemukan Ketidakcocokan Rasio Sampel dalam pengujian Anda tidak berarti Anda harus membuang hasilnya.

Jadi, kapan perhitungan SRM benar-benar perlu dilakukan dengan serius?

Mari kita cari tahu dengan beberapa contoh.

Contoh 1

Anda menjalankan eksperimen di mana yang Asli dan Variasi masing-masing ditetapkan oleh 50% pengguna. Oleh karena itu, Anda berharap untuk melihat jumlah pengguna yang sama di masing-masing.

Hasilnya kembali sebagai

• Kontrol: 21.588 pengguna
• Perawatan: 15.482 pengguna

Mari kita menempatkan mereka melalui Pemeriksa SRM:

Apakah ini alasan untuk khawatir?

Nilai p untuk rasio sampel di atas adalah <0,0001, jadi kemungkinan melihat rasio ini atau yang lebih ekstrim, di bawah desain yang menyerukan proporsi yang sama, adalah <0,0001!

Anda benar-benar harus khawatir bahwa ada sesuatu yang salah , karena Anda baru saja mengamati peristiwa yang sangat tidak mungkin. Oleh karena itu, kemungkinan besar ada beberapa bug dalam penerapan eksperimen dan Anda tidak boleh mempercayai hasil apa pun.

Contoh #2

Anda menjalankan eksperimen lain, di mana Orisinal dan Variasi diberi persentase pengguna yang sama. Anda menghitung nilai-p, dan itu <0,002, jadi peristiwa yang sangat tidak mungkin.

Seberapa jauh metriknya? Apakah Anda benar-benar harus membuang hasilnya?

Dengan menggunakan platform eksperimen seperti Convert Experiences, Anda dapat menerapkan beberapa segmentasi pasca pengujian ke hasil dan mengetahui bahwa jika Anda mengecualikan pengguna Internet Explorer, SRM hilang.

Dalam hal ini, pengguna yang dikecualikan kemungkinan besar menggunakan browser IE lama, yang merupakan penyebab SRM; bot tidak diklasifikasikan dengan benar karena beberapa perubahan dalam Variasi, yang menyebabkan ketidakcocokan rasio.

Tanpa segmen, persentase pengguna yang tersisa akan seimbang dengan benar dan metrik tampak normal.

Seandainya SRM tidak ditemukan, seluruh eksperimen akan dianggap sebagai kegagalan besar.

Tapi begitu SRM terlihat, segmen kecil bisa dihapus, dan eksperimen digunakan untuk analisis yang tepat.

Dalam skenario serupa, Anda dapat dengan aman mengabaikan pengguna yang dikecualikan dan eksperimen dapat digunakan .

Contoh #3

Anda menjalankan eksperimen dan menemukan bahwa ada tag SRM pada pengujian Anda.

Namun, jika Anda memperhatikan grafik Anda, Anda akan melihat bahwa kurva tingkat konversi tetap paralel dan kepercayaan yang dihitung adalah 99,99%. Pola itu seharusnya memberi Anda kepastian yang cukup bahwa tes itu valid.

Dalam hal ini, Anda dapat dengan aman mengabaikan SRM dan terus mempercayai data Anda .

Di Mana Anda Harus Memeriksa Apakah SRM Ada?

Ada beberapa area di mana SRM dapat terjadi. Mari kita lihat taksonomi penyebab Lukas Vermeer:

1. Penugasan Eksperimen – Mungkin ada kasus pengelompokan yang salah (pengguna ditempatkan di kluster yang salah), fungsi pengacakan yang salah, atau ID pengguna yang rusak.
2. Eksekusi Eksperimen – Variasi mungkin telah dimulai pada waktu yang berbeda (menyebabkan perbedaan), atau mungkin ada penundaan eksekusi filter (menentukan grup mana yang menjadi sasaran eksperimen).
3. Pemrosesan Log Eksperimen – Bot otomatis menghapus pengguna nyata, penundaan informasi yang masuk ke log.
4. Analisis Eksperimen – Pemicu variasi yang salah atau salah memulainya.
5. Gangguan Eksperimen – Eksperimen dapat terkena serangan dan peretasan, atau dampak eksperimen lain yang sedang berlangsung dapat mengganggu eksperimen saat ini.

Jika Anda memiliki SRM dan tidak yakin ke mana harus mencari jawaban, taksonomi di atas adalah tempat yang berharga untuk memulai.

Dan untuk memperjelasnya, kami sekarang akan memberi Anda contoh nyata untuk setiap kasus ini.

Tugas Percobaan

Di sinilah salah satu hal yang paling menarik untuk diperhatikan adalah fungsi pengacakan yang digunakan platform pengujian A/B Anda.

Pada contoh di bawah, ilmuwan data di Wish menemukan masalah SRM pada tes A/A dan, setelah penyelidikan panjang, menyimpulkan bahwa SRM muncul karena pengacakannya tidak sepenuhnya acak.

Untuk mencapai temuan eksperimen yang valid, prosedur pengacakan sangat penting.

Asumsi penting dari uji statistik yang digunakan dalam pengujian A/B adalah penggunaan sampel acak. Di antara keranjang percobaan, pengacakan menyeimbangkan atribut pengguna yang diamati dan tidak diamati, membangun hubungan sebab akibat antara fitur produk yang diuji dan perbedaan hasil apa pun dalam temuan uji coba.

Eksekusi Eksperimen

Dalam hal eksekusi eksperimen, ada dua alasan utama yang dapat menyebabkan SRM dalam pengalaman Anda.

1. Script tidak terpasang dengan benar di salah satu Variasi

Selalu periksa apakah skrip platform pengujian A/B Anda diinstal dengan benar pada Versi Asli dan Variasi.

Tim dukungan pelanggan kami baru-baru ini memecahkan kasus di mana skrip Konversi tidak ditambahkan pada salah satu variasi, menyebabkan SRM dalam pengujian.

Pastikan Anda menambahkan skrip di semua halaman tempat Anda ingin menjalankan pengalaman, seperti yang ditunjukkan di bawah ini:

2. Penargetan halaman tidak dikonfigurasi dengan benar

Dalam hal ini, ketidakcocokan SRM adalah karena penargetan pengujian tidak diatur dengan benar.

Dengan penyiapan yang salah, beberapa pengunjung dipilih untuk diteruskan ke variasi, tetapi pengalihan gagal, kemungkinan besar karena ekspresi URL asli tidak cocok dengan setiap URL dari semua pengunjung yang dimasukkan dalam pengujian dan dialihkan.

Untuk menghindarinya, konfigurasikan ulang ekspresi URL variasi eksperimen dan jalankan kembali pengujian.

Berikut adalah dua skenario lagi yang menunjukkan cara menyiapkan penargetan halaman Anda dengan Pengalaman Konversi untuk menghindari SRM pada pengujian URL Terpisah.

Skenario 1: Hanya targetkan beranda (https://www.convert.com) dengan URL Terpisah dan berikan semua parameter kueri yang mungkin dimiliki pengunjung

Di sini, di Area Situs, URL Halaman harus sama persis dengan https://www.convert.com. Di bagian kecualikan, String Kueri harus berisi v1=true sehingga Anda menghindari pengalihan apa pun (karena kondisi eksperimen akan tetap cocok jika Anda berakhir di https://www.convert.com ?v1=true dan lalu lintas distribusi mungkin berakhir tidak merata).

Kemudian, ketika Anda menentukan variasi Anda, pertahankan seperti ini:

Skenario 2: Targetkan semua halaman, bukan hanya beranda (https://www.convert.com), dengan URL Terpisah dan teruskan parameter kueri

Di sini, Anda perlu menentukan Area Situs Anda dengan “URL Halaman” yang berisi https://www.convert.com . Di bagian pengecualian, kueri harus berisi v1=true.

Saat menentukan variasi, gunakan resep regex di bawah ini untuk menangkap semua halaman:

Pemrosesan Log Eksperimen

Di sini, sebagai alasan utama SRM, kami mengidentifikasi bot yang dapat menargetkan pengalaman Anda. Anda dapat menghubungi kami untuk memeriksa log tambahan yang kami simpan jika kami dapat menemukan pola yang tidak biasa pada agen pengguna.

Misalnya, tim dukungan kami membantu klien yang pengujiannya memiliki SRM.

Dalam kasus mereka, ketika kami memfilter laporan dengan Browser=Other , kami melihat pemisahan yang tidak merata dan SRM. Namun saat kami memfilter laporan yang sama dengan Browser=Chrome+Safari , tidak ada SRM yang terdeteksi, dan tidak ada distribusi yang tidak merata.

Jadi, kami memeriksa beberapa peristiwa yang mengatur Browser ke Lainnya, dan semuanya menunjukkan Agen Pengguna "site24x7". Kami segera tahu bahwa ini adalah semacam perangkat lunak pemantauan, yang beruntung karena beriklan dan menggunakan agen pengguna yang berbeda. Jika ini disembunyikan di balik Agen Pengguna biasa, tidak mungkin menemukannya.

Untuk mengatasi masalah ini, kami melanjutkan dan menambahkan Agen-Pengguna ini ke daftar bot yang kami kecualikan dari lalu lintas. Sayangnya, perubahan ini mungkin berdampak pada data di masa mendatang, setelah kami menambahkan bot ke daftar, tetapi setidaknya itu ditemukan dan diperbaiki.

Analisis Eksperimen

Kategori ini terutama memengaruhi pengalaman yang disetel dengan pemicu manual.

Ini terjadi misalnya pada Aplikasi Halaman Tunggal di mana Anda harus menangani pemicunya sendiri.

Jadi, setiap kali Anda harus melakukannya secara manual dengan menggunakan kode yang mirip dengan kode di bawah ini, perhatikan baik-baik potensi SRM pada pengujian Anda.

 jendela._conv_q = _conv_q || [];
window._conv_q.push(["run","true"]);

Interferensi Eksperimen

Ini mengacu pada intervensi pengguna di mana salah satu variasi dijeda selama pengalaman. Bayangkan Anda memiliki tes URL Terpisah yang berjalan selama beberapa minggu dan entah karena kesalahan atau dengan sengaja Anda menjeda Variasi dan hanya membiarkan yang Asli berjalan.

Segera setelah itu, dan tergantung pada lalu lintas situs web Anda, Anda akan melihat SRM dihitung untuk pengujian Anda.

Dalam hal ini, Anda dapat mengecualikan rentang tanggal saat variasi dijeda atau menyetel ulang data pengalaman.

Alasan Non Eksperimen

Jika tidak ada kategori di atas yang mengungkapkan akar penyebab SRM Anda, kami sarankan Anda menambahkan perangkat lunak pelacakan kesalahan di situs web Anda (seperti Sentry) untuk mengidentifikasi masalah yang lebih dalam dengan situs Anda.

Platform Pengujian A/B yang Mendukung Peringatan SRM

Anda mungkin bertanya-tanya platform pengujian A/B mana yang mendukung fungsi SRM ini dan memberi Anda peringatan tanpa harus menghitungnya sendiri.

Kami telah menyelesaikan penelitian dan menyusun daftar alat.

Konversi Pengalaman

Pada Desember 2021, kami telah memperkenalkan metode SRM kami sendiri.

Jika Anda pengguna, Anda dapat mengaktifkan pemeriksaan SRM dari Konfigurasi Proyek > Pengaturan Lainnya.

Kemudian Anda akan dapat melihat tag SRM di laporan:

Optimalkan

Mengoptimalkan solusi pengujian sekuensial open-source pada September 2021 yang dapat diterapkan siapa saja untuk mendeteksi SRM.

Optimizely telah mengubah ssrm-test menjadi layanan mikro backend siap produksi yang dapat berjalan pada semua eksperimen yang berjalan pada saat yang bersamaan.

Pada halaman hasil Optimizely, Anda dapat mengatur peringatan dan mendapatkan hasil real-time dari ssrm-test:

Michael Lindon, Ahli Statistik Staf Optimal, mengatakan bahwa SRM adalah masalah umum yang terjadi ketika pengujian dilakukan dengan buruk.

Untuk menjalankan eksperimen produk, diperlukan sejumlah besar infrastruktur, sehingga mungkin ada kesalahan. Misalnya, jika pengunjung situs web tidak secara konsisten dimasukkan ke dalam variasi eksperimen dan berkonversi di bawah kondisi asli dan variasi, data yang diperoleh untuk pengguna tersebut tidak valid untuk mengevaluasi dampak eksperimen.

Perhatian utama adalah ketika SRM menghasilkan data yang tidak akurat yang mungkin memengaruhi metrik Anda dan tidak terdeteksi.

Adobe Target melalui MiaProva

Pada April 2021, Adobe Target bermitra dengan MiaProva untuk memberikan peringatan SRM pada aktivitas A/B.

Peringatan ini memberi tahu pelanggan MiaProva yang menggunakan Adobe Target saat terdeteksi ketidakcocokan. Pendekatan ini secara otomatis menerapkan uji Chi-Squared untuk setiap pengujian A/B langsung.

Buku Pertumbuhan

GrowthBook adalah platform pengujian A/B open-source dengan mesin statistik Bayesian dan pemeriksaan SRM otomatis untuk setiap eksperimen.

Setiap eksperimen mencari SRM dan memperingatkan pengguna jika ada yang teridentifikasi.

Saat Anda memprediksi pembagian lalu lintas tertentu (mis. 50/50), tetapi melihat sesuatu yang sangat berbeda (mis. 40/60), Anda mendapat peringatan. Ini hanya ditampilkan jika nilai p kurang dari 0,001, menunjukkan bahwa hal itu sangat tidak mungkin terjadi secara kebetulan.

Hasil tes semacam itu tidak boleh dipercaya karena berpotensi menipu, oleh karena itu peringatannya. Sebagai gantinya, pengguna harus mencari dan memperbaiki sumber bug sebelum memulai ulang eksperimen.

Split.io

Split adalah platform pengiriman fitur yang mendukung manajemen flag fitur, eksperimen perangkat lunak, dan pengiriman berkelanjutan.

Dengan setiap pembaruan komputasi, platform Split memeriksa rasio sampel untuk melihat apakah ada perbedaan substansial antara rasio sampel yang ditargetkan dan saat ini. Pemeriksaan rasio sampel ini dapat ditemukan di bawah ringkasan metrik kunci dan organisasi, bersama dengan detail penting lainnya seperti durasi dan pembaruan terakhir.

Rasio Ukuran Sampel Ketidakcocokan Demystified

Anda mungkin bertanya, seberapa sering "normal" melihat SRM?

Lukas Vermeer mengatakan yang terbaik. Bahkan perusahaan teknologi besar mengamati frekuensi alami SRM dari 6% hingga 10% dalam eksperimen terkontrol online mereka.

Sekarang, jika SRM berulang lebih sering, itu memerlukan penyelidikan lebih dalam ke dalam desain eksperimen atau situs web.

Tim kami selalu siap membantu Anda jika Anda mengalami masalah seperti di atas! Klik di sini untuk menghubungi tim kami.