Bahasa Indonesia

Desain Eksperimen yang Lolos Tinjauan Pemangku Kepentingan

Tim yang pernah saya ajak bekerja sama menjalankan uji warna banner kuartal lalu. Tiga hari. Sekitar 200 pengguna per kelompok. PM melihat dashboard, melihat p = 0,07 untuk click-through, lalu menulis di Slack: "secara arah positif, mari kita rilis." Enam minggu kemudian metrik utama tetap datar, model personalisasi ML downstream secara diam-diam melakukan pelatihan ulang pada traffic yang diacak di tingkat sesi untuk tujuan tingkat pengguna, dan ketika VP bertanya apa hipotesis awalnya, tidak ada yang bisa menemukannya.

Eksperimen itu memiliki empat masalah yang bertumpuk: ukuran sampel yang kurang memadai, tidak ada perhitungan MDE, unit acak yang salah, dan pengintipan pada hari kedua yang mendorong keputusan. Masing-masing saja sudah dapat menggagalkan hasilnya. Bersama-sama, keempatnya menghasilkan keputusan yang percaya diri yang dibangun di atas ketiadaan.

Panduan ini adalah penangkalnya. Ini adalah Playbook desain yang membuat cerita semacam itu tidak mungkin terulang. Yang memungkinkan PM, pimpinan teknik, dan VP yang skeptis untuk membaca dokumen readout dan mencapai kesimpulan yang sama dengan Anda.

Template Hipotesis

Sebagian besar eksperimen gagal sebelum data apa pun dikumpulkan karena hipotesisnya tidak dapat difalsifikasi. "Tingkatkan UX." "Buat checkout lebih baik." "Tingkatkan keterlibatan." Tidak satu pun dari ini yang bisa salah, yang berarti tidak satu pun dari ini yang bisa benar.

Hipotesis yang dapat Anda pertahankan memiliki empat bagian:

  • Masalah: angka spesifik yang tidak Anda sukai, hari ini, dengan baseline.
  • Perubahan yang diprediksi: hal yang akan Anda lakukan, dalam satu kalimat.
  • Metrik keberhasilan: satu angka utama yang akan Anda gunakan untuk menilainya.
  • MDE: ukuran efek terkecil yang akan mengubah keputusan bisnis Anda.

Jika diisi, tampilannya seperti ini:

Tingkat penyelesaian checkout adalah 38% (baseline 90 hari, n kira-kira 1,2 juta sesi). Menambahkan progress bar 4 langkah pada alur checkout akan mengurangi drop-off setelah langkah alamat. Metrik utama: tingkat konversi, diukur per pengguna, jendela 14 hari. MDE: 1,5 poin persentase peningkatan absolut (4% relatif). Apa pun yang lebih kecil tidak membenarkan biaya rekayasa.

Perhatikan apa yang dipaksakan template ini. Anda berkomitmen pada angka baseline sehingga Anda tidak bisa berargumen secara pasca hoc bahwa metriknya berbeda. Anda berkomitmen pada satu metrik utama sehingga Anda tidak bisa beralih ke metrik sekunder saat metrik utama mengecewakan. Anda berkomitmen pada MDE sehingga Anda tidak bisa mengklaim pergeseran 0,3 pp "bermakna." Dan MDE didasarkan pada keputusan bisnis (peningkatan terkecil yang benar-benar akan mengubah apa yang Anda lakukan selanjutnya), bukan kemudahan statistik.

Tolak hipotesis yang tidak jelas sejak awal. Jika pemangku kepentingan berkata "kami ingin menguji tata letak baru untuk melihat apa yang terjadi," tugas Anda adalah mendorong kembali: angka apa yang berubah, berapa banyak, dan mengapa angka itu penting? "Mari lihat apa yang terjadi" adalah pertanyaan penelitian, bukan eksperimen.

Matematika MDE dan Ukuran Sampel

Bagian ini, lebih dari yang lain, akan menyelamatkan Anda dari merilis hal yang tidak bermutu. Matematika ini tidak opsional.

Untuk uji dua sampel proporsi dengan α = 0,05 (dua sisi) dan kekuatan statistik = 0,80, ukuran sampel per kelompok adalah kira-kira:

n ≈ 16 × σ² / δ²

Di mana σ² adalah varians metrik dan δ adalah ukuran efek absolut yang ingin Anda deteksi (MDE Anda). Untuk metrik biner seperti tingkat konversi, σ² ≈ p(1 − p) di mana p adalah tingkat baseline.

Mari lakukan contoh checkout dari awal hingga akhir.

  • Tingkat penyelesaian baseline: p = 0,38
  • Varians: σ² = 0,38 × 0,62 ≈ 0,2356
  • MDE: δ = 0,015 (1,5 poin persentase absolut)
  • δ² = 0,000225
n ≈ 16 × 0,2356 / 0,000225
n ≈ 16.755 per kelompok

Jadi kira-kira n = 17.000 pengguna per kelompok, n = 34.000 total, untuk mendeteksi peningkatan 1,5 pp secara andal pada baseline 38% dengan kekuatan statistik 80%. Jika volume pengguna yang memenuhi syarat harian adalah 5.000, itu berarti uji minimum 7 hari. Jika Anda menginginkan MDE 1 pp, penyebutnya turun sekitar 2,25 kali dan Anda memerlukan n kira-kira 38.000 per kelompok, mendekati uji 16 hari.

Sekarang lihat uji banner dari pembukaan: 200 pengguna per kelompok, click-through baseline sekitar 8%. Varians kira-kira 0,074. Untuk mendeteksi peningkatan 1 pp dengan kekuatan statistik 80%, n ≈ 16 × 0,074 / 0,0001 = 11.840 per kelompok. Mereka memiliki 200. Uji tersebut secara matematis tidak mampu mendeteksi efek yang mereka harapkan. p = 0,07 yang mereka kutip bukan sinyal hampir-signifikan, melainkan gangguan acak pada sampel yang tidak bisa menyampaikan sinyal apa pun.

Beberapa catatan praktis:

  • Angka 16 dalam rumus berasal dari (z_α/2 + z_β)² × 2 untuk α = 0,05, kekuatan statistik = 0,80. Untuk kekuatan statistik 90%, gunakan sekitar 21. Untuk α = 0,01 (koreksi Bonferroni untuk 5 metrik, misalnya), konstantanya meningkat lebih jauh.
  • Untuk metrik kontinu (pendapatan per pengguna, durasi sesi), gunakan varians sampel aktual, dan waspadai ekor distribusi yang berat. Melakukan pembatasan atau transformasi logaritmik pada metrik sering kali merupakan langkah yang tepat; lakukan sebelum menjalankan uji, bukan setelahnya.
  • Ukuran sampel skala dengan 1/δ². Mengecilkan MDE setengahnya melipatempat ukuran sampel yang diperlukan. Inilah mengapa "mari jalankan lebih lama jika tidak muncul" adalah khayalan belaka.

Jika kalkulator ukuran sampel Anda mengatakan Anda memerlukan 38.000 pengguna per kelompok dan tim hanya memiliki 5.000 per minggu, pilihan Anda adalah: jalankan selama 8 minggu, terima MDE yang lebih besar (dan akui Anda tidak dapat mendeteksi kemenangan yang lebih kecil), atau pilih eksperimen yang berbeda. Tidak ada pilihan keempat di mana matematika bisa dibengkokkan.

Unit Acak: Pengguna vs Sesi vs Kluster

Memilih unit acak yang salah adalah pembunuh senyap A/B test. Anda akan mendapatkan nilai p yang bersih untuk pertanyaan yang salah.

Randomisasi tingkat pengguna adalah standar untuk sebagian besar eksperimen produk. Pengguna ditugaskan ke varian pertama kali mereka masuk ke eksperimen, dan mereka tetap dalam varian tersebut selamanya (atau setidaknya selama jendela uji). Ini benar ketika metrik dihitung per pengguna: retensi, LTV, frekuensi pembelian, tingkat kembali 7 hari.

Randomisasi tingkat sesi menugaskan setiap sesi secara independen. Ini berfungsi untuk metrik tanpa status, satu sesi seperti waktu muat halaman atau tingkat konversi satu sesi di halaman arahan di mana pengguna tidak kembali. Ini rusak parah ketika metrik terakumulasi lintas sesi. Jika Anda mengacak algoritma rekomendasi di tingkat sesi dan mengukur retensi 30 hari, Anda baru saja menampilkan tiga pengalaman rekomendasi berbeda kepada pengguna selama 30 hari; Anda mengukur rata-rata A dan B, bukan A vs B.

Randomisasi kluster digunakan untuk efek marketplace, jaringan, dan sosial. Jika varian mengubah cara penawaran bertemu permintaan (algoritma peringkat baru di marketplace, perubahan feed yang memengaruhi apa yang dilihat pengguna lain), Anda tidak bisa mengacak pengguna individual. Mereka saling memengaruhi pengalaman satu sama lain. Acak di tingkat geo, tingkat marketplace, atau kluster sosial. Biayanya adalah n efektif Anda turun menjadi jumlah kluster, bukan jumlah pengguna, dan perhitungan ukuran sampel perlu menggunakan varians tingkat kluster (yang biasanya jauh lebih tinggi dari varians tingkat pengguna).

Pertanyaan diagnostiknya adalah: "Jika saya menugaskan pengguna A ke kontrol dan pengguna B ke perlakuan, dapatkah hasil pengguna A dipengaruhi oleh pengalaman pengguna B?" Jika ya, Anda memiliki interferensi, dan Anda perlu randomisasi kluster atau desain switchback.

Kesalahan tingkat sesi dari uji pembuka persis seperti ini. Click-through secara teknis adalah metrik sesi, sehingga randomisasi tingkat sesi lolos pemeriksaan awal. Tetapi model downstream yang melakukan pelatihan ulang pada data memerlukan sinyal tingkat pengguna. Unit acak harus sesuai dengan unit analisis, dan keduanya harus sesuai dengan unit keputusan.

Metrik Pengaman

Metrik utama memberi tahu Anda apakah perubahan berhasil. Metrik pengaman memberi tahu Anda apakah perubahan merusak sesuatu yang lain.

Daftarkan dua hingga empat metrik pengaman yang tidak boleh mengalami regresi melebihi ambang batas, bahkan jika metrik utama menang. Metrik pengaman standar:

  • Latensi (waktu muat halaman p95, waktu respons API): banyak "kemenangan" adalah kemenangan karena varian baru dimuat lebih cepat, bukan karena perubahannya baik.
  • Tingkat kesalahan (5xx, kesalahan JS sisi klien): perlakuan yang menggandakan tingkat kesalahan sedang merilis bug, terlepas dari apa yang dilakukan tingkat konversi.
  • Pendapatan per pengguna: jika Anda mengoptimalkan click-through dan pendapatan per pengguna turun, Anda menemukan cara membuat orang mengklik hal-hal yang bernilai lebih rendah. Jangan dirilis.
  • Tingkat tiket dukungan: perubahan UX yang membingungkan pengguna muncul di sini, bukan pada metrik tingkat konversi.

Ambang batasnya penting. Pola yang umum: "metrik pengaman tidak boleh mengalami regresi lebih dari 1% relatif, atau eksperimen gagal terlepas dari hasil utama." Daftarkan ambang batasnya terlebih dahulu. Jika tidak, ketika latensi masuk 2% lebih lambat, percakapannya menjadi "apakah 2% benar-benar bermakna," dan Anda bernegosiasi dengan diri sendiri.

Tujuan metrik pengaman adalah untuk menangkap eksperimen yang memenangkan metrik utama tetapi merugikan bisnis. Ini adalah alat yang paling jarang digunakan dalam pekerjaan DS, dan asuransi termurah yang bisa Anda beli.

Dokumen Readout

Bentuk yang sama, setiap saat. Dokumen readout yang lolos tinjauan adalah satu halaman, dapat dipindai dalam 90 detik, tanpa kejutan di lampiran. Berikut templatenya:

  • Hipotesis: satu paragraf, template empat bagian di atas, ditulis sebelum eksperimen dimulai.
  • Desain: unit acak, target ukuran sampel, MDE, metrik utama, metrik pengaman, alokasi traffic.
  • Tanggal dan sampel: tanggal mulai, tanggal selesai, ukuran sampel aktual yang dicapai per kelompok.
  • Hasil utama: estimasi titik, interval kepercayaan 95%, nilai p. Satu baris.
  • Metrik pengaman: tabel metrik pengaman dengan delta, interval kepercayaan, dan lulus/gagal vs ambang batas yang telah didaftarkan.
  • Potongan segmen yang telah didaftarkan: metrik yang sama, dipecah berdasarkan segmen yang Anda komitkan sebelumnya.
  • Keputusan: rilis / tidak rilis / iterasi, dengan alasan yang terhubung langsung ke hasilnya.
  • Rencana pengembalian: jika dirilis, bagaimana kami memantau di produksi, dan apa yang memicu pengembalian?

Yang tidak ada dalam readout: potongan segmen pasca hoc yang disajikan sebagai temuan, pembingkaian ulang narasi hipotesis, atau keputusan "secara arah." Jika potongan segmen bersifat eksplorasi, beri label eksplorasi di bagian yang ditandai dengan jelas. Peninjau seharusnya bisa langsung melihat angka mana yang direncanakan dan mana yang dicari-cari.

Disiplinnya adalah templatenya. Ketika setiap eksperimen dalam organisasi menggunakan dokumen satu halaman yang sama, peninjau tidak perlu mempelajari gaya pribadi setiap DS dan bisa benar-benar mengevaluasi pekerjaannya.

Mengapa Sebagian Besar Eksperimen Gagal

Setelah cukup banyak readout, modus kegagalan mengelompok menjadi daftar pendek:

  • Kurang bertenaga. Matematika MDE tidak dilakukan, atau dilakukan lalu diabaikan. Uji tersebut tidak bisa mendeteksi efek yang diklaim.
  • Hipotesis tidak jelas. Tidak ada prediksi yang dapat difalsifikasi, tidak ada komitmen pada metrik utama, tidak ada MDE. Eksperimen "berhasil" tidak peduli apa yang dikatakan data.
  • Unit acak yang salah. Tingkat sesi untuk pertanyaan tingkat pengguna, atau tingkat pengguna untuk pertanyaan marketplace dengan interferensi.
  • Tidak ada metrik pengaman. Metrik utama menang, tim merilis, latensi mengalami regresi 8%, dan tiga minggu kemudian seseorang menyadari pendapatan turun.
  • Tidak ada rencana pengembalian. Kode dirilis, eksperimen dinyatakan selesai, dan tidak ada yang memantau produksi. Perubahan menyimpang dan tidak ada yang bisa mengaitkan penyimpangan tersebut kembali ke rilis.
  • Terkontaminasi oleh rilis lain. Eksperimen berjalan selama kampanye pemasaran atau pembaruan UI yang mengenai kedua kelompok. Efek yang diperkirakan adalah eksperimen ditambah kontaminan, dan Anda tidak bisa memisahkannya.

Setiap satu dari ini dapat dicegah pada fase desain. Tidak satu pun yang bisa diperbaiki setelah pengumpulan data.

Menghindari HARKing

HARKing (Hypothesizing After Results are Known, yaitu membuat hipotesis setelah hasil diketahui) adalah bentuk pengelabuan diri yang paling umum dalam eksperimentasi. Polanya: Anda menjalankan uji pada seluruh basis pengguna, metrik utama null, tetapi variannya terlihat bagus untuk "pengguna iOS di AS yang datang melalui pencarian berbayar." Jadi itu menjadi berita utama.

Masalahnya murni statistik. Jika Anda memotong data menjadi 20 segmen, Anda dapat mengharapkan salah satunya mencapai p < 0,05 secara kebetulan. Memilih pemenang setelah melihat semua 20 dan menyajikannya sebagai hasil yang dikonfirmasi adalah, secara matematis, penipuan. Anda akan menemukan "efek" yang sama pada lemparan koin jika Anda memotong cukup halus.

Solusinya adalah praregistrasi. Sebelum eksperimen dimulai, tuliskan:

  1. Metrik utama.
  2. Potongan segmen yang tepat yang akan Anda laporkan (misalnya, pengguna baru vs lama, mobile vs desktop, 3 pasar teratas), dan hanya itu.
  3. Subkelompok apa pun yang Anda komit sebagai analisis konfirmatori.

Apa pun yang Anda temukan kemudian masuk ke bagian "Eksplorasi" yang berlabel jelas, dengan catatan bahwa nilai p tidak dikoreksi untuk pengujian berganda dan temuan tersebut memerlukan eksperimen tindak lanjut untuk dikonfirmasi. Jangan pernah menyebut hasil subkelompok pasca hoc sebagai "signifikan." Sebut itu sebagai hipotesis untuk uji berikutnya.

Solusi budaya lebih sulit dari solusi teknis. Ketika pemangku kepentingan sangat menginginkan kemenangan dan potongan pasca hoc memberikannya, tekanan untuk melegitimasi hasilnya sebagai temuan yang dikonfirmasi memang nyata. Disiplin praregistrasi (menuliskannya sebelumnya) adalah yang memberi Anda dasar untuk mendorong kembali.

Disiplin Pengintipan

Ini adalah angka yang mengejutkan banyak orang: jika Anda memeriksa A/B test untuk signifikansi setiap hari selama dua minggu, tingkat positif palsu efektif Anda bukan 5%. Itu mendekati 14%. Bahkan mungkin lebih tinggi, tergantung seberapa agresif Anda dalam menghentikan lebih awal.

Alasannya adalah masalah pengujian sekuensial. Uji t atau uji z standar dikalibrasi untuk satu pandangan pada data, setelah ukuran sampel yang telah dikomit dikumpulkan. Setiap pandangan tambahan adalah kesempatan lain bagi gangguan acak untuk melampaui ambang batas. Jika Anda mengintip dan berhenti, Anda memilih momen paling ekstrem dalam perjalanan acak dan melaporkannya sebagai hasil yang tetap.

Anda memiliki dua pilihan yang bersih:

  1. Komit pada ukuran sampel. Hitung n, jalankan uji hingga mencapai n, lalu lihat hasilnya sekali. Tidak ada dashboard harian yang mendorong keputusan berhenti/rilis. Memantau metrik pengaman untuk keamanan tidak apa-apa; menggunakan metrik utama untuk menghentikan eksperimen lebih awal tidak diperbolehkan.
  2. Gunakan metode pengujian sekuensial. mSPRT (mixture sequential probability ratio test), desain grup sekuensial dengan fungsi alpha-spending, atau metode Bayesian yang diimplementasikan dengan benar dengan prior informatif. Ini memungkinkan Anda mengintip sesering yang Anda inginkan dengan inferensi yang valid, dengan biaya ukuran sampel yang sedikit lebih tinggi sebagai kompensasi.

Yang tidak bisa Anda lakukan adalah menjalankan uji cakrawala tetap, mengintip setiap hari, dan berhenti saat p melampaui 0,05. Itu adalah generator positif palsu paling umum dalam eksperimentasi industri, dan itu adalah alasan "kemenangan rilis" secara rutin gagal direplikasi saat diukur dengan benar kemudian.

Solusinya bersifat prosedural. Tuliskan aturan berhenti ke dalam dokumen desain. "Kami akan berjalan selama n = 17.000 per kelompok, diperkirakan 8 hari, dan membaca hasilnya sekali." Jika tim tidak tahan dengan dashboard, sembunyikan metrik utama dari tampilan langsung dan hanya tampilkan metrik pengaman. Disiplinnya adalah desainnya.

Penutup

Dokumen readout yang lolos tinjauan adalah yang keputusan desainnya dibuat sebelum pengumpulan data dimulai. Hipotesisnya spesifik. Ukuran sampel dihitung. Unit acak dibenarkan. Metrik pengaman telah didaftarkan. Potongan segmen dikomit terlebih dahulu. Aturan berhenti dituliskan.

Selebihnya adalah bercerita. Dan bercerita baik-baik saja untuk bagian narasi readout, tetapi tidak bisa menjadi dasar keputusan rilis.

Pertarungan yang Anda menangkan adalah yang dilakukan sebelum pengumpulan data. Habiskan satu jam untuk dokumen desain. Itu adalah jam termurah yang akan Anda habiskan sepanjang kuartal, dan itu yang menentukan apakah eksperimen Anda lolos tinjauan atau diam-diam bergabung dengan tumpukan uji "secara arah positif" yang tidak dapat direkonstruksi siapa pun enam bulan kemudian.

Pelajari Lebih Lanjut