Desain Eksperimen Pertumbuhan: Hipotesis hingga MDE hingga Readout

Pertama kali saya mengirimkan "pemenang" yang membuat kami kehilangan 3% trial adalah pengujian CTA di halaman harga. Tiga hari, 240 pengunjung, varian B naik 6,2%. PM langsung memposting emoji trofi di Slack. Dua minggu kemudian volume trial mingguan kami terlihat tidak beres, saya mengulang matematikanya, dan "pemenang" asli sebenarnya berada dalam batas kebisingan sepanjang waktu. Kami tidak mengirimkan apa pun, kecuali seperempat roadmap yang dibangun di atas firasat.

Itulah pekerjaannya, sejujurnya. Bukan pengujian itu sendiri. Bagian yang tidak terjebak itulah yang penting.

Panduan ini adalah panduan yang ingin saya miliki sejak hari pertama: cara menulis hipotesis yang benar-benar bisa dibuktikan salah, cara melakukan matematika ukuran sampel di serbet makan, cara memilih antara ICE dan RICE tanpa berbohong pada diri sendiri, dan cara menulis readout yang benar-benar akan dibuka oleh CFO Anda. Jika Anda mengambil satu hal darinya, ambil ini: pengujian bukan hasil akhir yang diserahkan. Readout-lah yang diserahkan. Sebagian besar kuartal, itu adalah 4 readout, bukan 40.

Mengapa sebagian besar eksperimen B2B gagal

Saya telah mengaudit mungkin 60 eksperimen pertumbuhan di berbagai perusahaan SaaS dan PLG dalam beberapa tahun terakhir. Mode kegagalannya terkumpul menjadi lima hal, dan empat di antaranya sudah diputuskan sebelum pengujian berjalan.

1. Kekurangan daya sejak hari pertama. Tim menjalankan pengujian 5 hari pada 800 pengguna dengan tingkat konversi dasar 8%, melihat kenaikan 0,4 poin persentase, dan menyebutnya pemenang. MDE sebenarnya pada ukuran sampel tersebut adalah sekitar 3 poin persentase relatif terhadap dasar. Apa pun yang lebih kecil dari itu secara statistis tidak dapat dibedakan dari pelemparan koin. Mereka tidak menjalankan eksperimen yang buruk. Mereka menjalankan pengujian yang tidak mampu mendeteksi efek yang mereka harapkan.

2. Hipotesis ditulis sebagai daftar tugas. "Kami akan menguji headline baru di halaman harga." Itu bukan hipotesis. Hipotesis memprediksi apa yang berubah, seberapa banyak, untuk siapa, dan mengapa. Jika hipotesis Anda tidak dapat disangkal oleh data, pengujian akan menghasilkan cerita apa pun yang terjadi.

3. Tidak ada rencana rollback. Varian dikirimkan, konversi turun 4%, tidak ada yang memiliki keputusan rollback, varian berjalan selama 6 minggu lagi karena "kami ingin lebih banyak data." Anda tidak butuh lebih banyak data. Anda butuh aturan penghentian yang telah terdaftar sebelumnya.

4. Tidak ada metrik primer yang terdaftar sebelumnya. Tiga hari kemudian, konversi datar tetapi waktu di halaman naik 22%, sehingga tiba-tiba waktu di halaman menjadi metriknya. Ini memiliki nama: HARKing (Hypothesizing After Results are Known). Setiap tim melakukannya. Setiap tim yang melakukannya menghasilkan readout yang tidak dapat diandalkan.

5. PM mengamati grafik pada hari ke-3. Mengintip. Sequential testing ada persis untuk alasan ini, dan sebagian besar tim tidak menggunakannya. Pengujian fixed-horizon standar kehilangan jaminan statistiknya begitu Anda membuat keputusan berdasarkan hasil sementara.

Empat yang pertama diselesaikan dengan template hipotesis. Yang kelima diselesaikan dengan kalkulator ukuran sampel dan kedisiplinan untuk membiarkan dashboard sendirian.

Template hipotesis

Salin ini. Tempelkan ke pelacak eksperimen tim Anda. Jadikan sebagai satu-satunya template yang boleh digunakan siapa pun.

EKSPERIMEN: [nama singkat, misalnya "Blok social proof halaman harga"]

MASALAH (apa yang kami amati dalam data):
  Kami melihat perilaku X dalam segmen Y. Secara spesifik:
  - Titik data 1: [dari analitik, tiket dukungan, panggilan penjualan, kualitatif]
  - Titik data 2: [konfirmasi atau triangulasi]

PERUBAHAN YANG DIPREDIKSI (apa yang kami lakukan, untuk siapa):
  Untuk [segmen], kami akan [perubahan], karena [mekanisme yang kami yakini sedang bekerja].

METRIK KEBERHASILAN:
  Primer:       [satu metrik, dengan angka dasar saat ini]
  Penjaga 1: [tidak boleh bergerak lebih buruk dari X]
  Penjaga 2: [tidak boleh bergerak lebih buruk dari Y]

MDE (efek terkecil yang akan kami tindaklanjuti):
  Kami perlu mendeteksi kenaikan relatif [N%] pada metrik primer.
  Di bawah itu, perubahan tidak sebanding dengan biaya engineering / risiko brand / fokus.

UKURAN SAMPEL DAN DURASI:
  Per kelompok: [N] pengguna
  Estimasi durasi pada traffic saat ini: [N minggu]

KRITERIA ROLLBACK:
  Kami menghentikan varian segera jika:
  - Metrik primer bergerak lebih buruk lebih dari [X]
  - Salah satu metrik penjaga melampaui ambangnya selama lebih dari 48 jam
  - Engineering menemukan bug P0/P1

TANGGAL KEPUTUSAN: [tanggal nyata, bukan "ketika kami memiliki cukup data"]
PEMILIK: [satu orang]

Dua catatan. Pertama, baris MDE bukan keinginan. Ini adalah ambang di bawahnya di mana Anda tidak akan mengirimkan perubahan bagaimanapun juga, bahkan jika itu "nyata." Jika kenaikan 1,5% pada aktivasi tidak sebanding dengan biaya pemeliharaan membawa varian dalam kode selamanya, maka kenaikan 1,5% bukan MDE Anda. MDE Anda adalah angka apa pun yang benar-benar melampaui biayanya. Jujurlah di sana.

Kedua, tanggal keputusan membunuh lebih banyak zombie daripada hal lain dalam template ini. Tanpanya, setiap pengujian berjalan selamanya.

Matematika MDE yang bisa Anda lakukan di serbet makan

Berikut formula yang saya gunakan untuk perencanaan, yang oleh ahli statistik sungguhan akan sedikit diprotes tetapi yang membawa Anda dalam 10% dari kebenaran dan cukup cepat sehingga Anda akan benar-benar menggunakannya:

n per kelompok  ≈  16 × p × (1 - p) / MDE²

Di mana:

• p adalah tingkat konversi dasar Anda (sebagai desimal, misalnya 0,08 untuk 8%)
• MDE adalah kenaikan absolut yang ingin Anda deteksi (sebagai desimal, misalnya 0,008 untuk pergerakan dari 8,0% ke 8,8%, yang merupakan kenaikan relatif 10%)
• 16 sudah mencakup daya 80% dan kepercayaan 95% (dua sisi)

Itu saja. Tidak perlu perangkat lunak. Mari kita jalankan satu contoh nyata.

Contoh: konversi trial ke berbayar sebesar 8%

B2B SaaS Anda memiliki 600 signup mingguan. Trial ke berbayar adalah 8% (sehingga p = 0,08). Anda ingin mendeteksi kenaikan relatif 10%, artinya dari 8,0% ke 8,8% absolut (sehingga MDE = 0,008).

n per kelompok  =  16 × 0,08 × 0,92 / (0,008)²
               =  16 × 0,0736 / 0,000064
               =  1,1776 / 0,000064
               ≈  18.400 pengguna per kelompok

Dua kelompok = 36.800 pengguna. Pada 600 signup/minggu yang dibagi 50/50 antara pengujian, itu kira-kira 6 hingga 8 minggu traffic untuk satu eksperimen. Bukan 5 hari.

Sekarang, jika Anda ingin mendeteksi kenaikan relatif 25% (8,0% ke 10,0%), matematikanya lebih bersahabat:

n per kelompok  =  16 × 0,08 × 0,92 / (0,02)²
               =  1,1776 / 0,0004
               ≈  2.944 per kelompok

Sekitar 6.000 pengguna total. Pada 600/minggu, sekitar 2 minggu. Masalahnya: kenaikan relatif 25% pada trial ke berbayar pada dasarnya adalah unicorn dalam corong B2B yang matang. Anda akan mendapatkan satu atau dua per tahun jika Anda mahir. Sebagian besar kemenangan nyata adalah 3 hingga 8% relatif, yang berarti sebagian besar pengujian Anda membutuhkan traffic berbulan-bulan, bukan berhari-hari.

Inilah bagian yang tidak ingin didengar siapa pun: corong Anda tidak bergerak 25%, jadi eksperimen Anda perlu diberi daya untuk kenaikan yang benar-benar ada. Abaikan ini dan setiap pengujian menjadi Rorschach.

Kapan "kami hanya akan menjalankannya lebih lama" itu salah

Jika sebuah pengujian kekurangan daya sejak hari pertama, menjalankannya lebih lama pada pengaturan fixed-horizon tidak memperbaikinya. Itu malah meningkatkan tingkat positif palsu, karena Anda secara efektif mengintip. Jika Anda benar-benar membutuhkan fleksibilitas pada durasi, beralih ke:

• Sequential testing (msPRT, p-value yang selalu valid): memungkinkan Anda berhenti lebih awal atau diperpanjang tanpa merusak matematikanya. Statsig, GrowthBook, dan Eppo semuanya mendukungnya secara native.
• CUPED (pengurangan varians menggunakan data pra-eksperimen): dapat memangkas ukuran sampel yang diperlukan sebesar 30 hingga 50% pada metrik dengan sinyal pra-periode yang kuat. Layak diaktifkan untuk pengujian besar apa pun.

Jangan coba menjalankan ini secara manual. Gunakan platformnya.

Diagnosis umum yang perlu diketahui namanya

Jika Anda bisa memberi nama mode kegagalan, Anda bisa berargumen menentangnya dalam review readout. Lima yang paling sering saya lihat:

• HARKing: memilih metrik setelah melihat hasil. Diselesaikan dengan mendaftarkan primer dan metrik penjaga sebelum peluncuran.
• Peeking: membuat keputusan berdasarkan hasil sementara pada pengujian fixed-horizon. Diselesaikan dengan sequential testing atau dengan benar-benar tidak melihat sampai tanggal keputusan.
• Efek kebaruan: varian menang selama dua minggu karena baru, kemudian mundur. Diselesaikan dengan memperpanjang pengujian pada perubahan UI dan mengamati perilaku minggu ke-3 ke atas.
• Paradoks Simpson: varian menang secara keseluruhan tetapi kalah di setiap segmen, karena komposisi bergeser. Diselesaikan dengan selalu pra-segmentasi readout Anda (baru vs kembali, berdasarkan paket, berdasarkan sumber).
• Survivorship bias dalam metrik kohort: mengukur "retensi di minggu ke-4" hanya pada pengguna yang bertahan hingga minggu ke-4 menggelembungkan angkanya. Diselesaikan dengan mengaitkan kohort pada event masuk.

Prioritisasi: ICE vs RICE vs PIE

Tiga framework, bahan yang sedikit berbeda, semuanya berbohong kepada Anda dengan cara yang berbeda.

Pendapat jujur saya: ICE baik untuk tim 2 orang dan berbohong untuk tim 20 orang. Ketika tim Anda cukup kecil sehingga semua orang telah membaca setiap dokumen, ICE hanyalah cara menuliskan percakapan yang akan Anda lakukan bagaimanapun juga. Begitu tim cukup besar sehingga skor ICE adalah satu-satunya artefak yang dibaca pemangku kepentingan, setiap PM akan memanipulasinya.

Jebakan dengan ketiganya: Anda menilai eksperimen Anda sendiri. Pemilik memberi bobot berlebihan pada Kepercayaan untuk ide mereka sendiri. Engineer memberi bobot kurang pada Kemudahan untuk ide orang lain. Skor menjadi proxy untuk politik kantor.

Yang saya jalankan di skala besar: matriks 2x2 Kepercayaan x Jangkauan tanpa matematika. Kanan atas (kepercayaan tinggi, jangkauan tinggi) dikirimkan sekarang. Kiri atas (kepercayaan tinggi, jangkauan sempit) dikirimkan jika murah. Kanan bawah (kepercayaan rendah, jangkauan luas) menjadi investasi riset berbayar. Kami akan mendanai pengujian berdasarkan nilai pembelajaran, bukan kenaikan yang diharapkan. Kiri bawah mati. Ditinjau mingguan, dalam rapat 30 menit, dengan head of growth yang memegang spidol.

Itu bukan angka. Itu adalah mekanisme pemaksaan untuk percakapan yang jujur.

Batas WIP: maksimal 3 hingga 5 pengujian aktif

Untuk sebagian besar tim B2B dengan kurang dari 500 karyawan, jumlah eksperimen bersamaan yang tepat adalah 3 hingga 5. Di atas itu, Anda memakan traffic sendiri, efek interaksi Anda menjadi tidak dapat dilacak, dan tim Anda tidak bisa benar-benar memperhatikan readout. Kendala bukan kecepatan engineering. Itu adalah traffic dan perhatian.

Dokumen readout (ini adalah hasil akhir yang sesungguhnya)

Setiap pengujian yang dikirimkan, dihentikan, atau tidak meyakinkan mendapatkan satu halaman readout. Bukan dashboard. Sebuah dokumen. Disimpan di folder yang sama selamanya.

READOUT: [nama eksperimen]
TANGGAL: [mulai] ke [selesai]
PEMILIK: [nama]
STATUS: Dikirimkan / Dihentikan / Tidak Meyakinkan

APA YANG DIKIRIMKAN
  Varian B mengganti [X] dengan [Y] pada [halaman/alur], untuk [segmen], dari [tanggal] ke [tanggal].

APA YANG KAMI UKUR
  Primer:      [metrik], kontrol [N], varian [N], delta [+X% / -Y%], p = [N], CI [N, N]
  Penjaga 1:   [metrik], datar / terlampaui
  Penjaga 2:   [metrik], datar / terlampaui
  Sampel:      [N per kelompok], diberi daya untuk kenaikan relatif [MDE]%

APA YANG KAMI PELAJARI
  - Interpretasi hasil dalam 2 hingga 3 kalimat. Tanpa "kami berhasil besar." Ya "trial ke berbayar bergerak
    +4,2% (CI 1,1 hingga 7,3%), dalam MDE yang telah terdaftar sebesar 4%, jadi kami kirimkan."
  - Segmentasi: [di mana efeknya paling kuat / paling lemah]
  - Hal aneh: [sinyal kebaruan? kebisingan penjaga? kualitas data?]

APA YANG KAMI LAKUKAN SELANJUTNYA
  - Rencana pengiriman / holdout untuk varian
  - Pengujian lanjutan (maksimal 2)
  - Hal apa pun yang membutuhkan perhatian eng, produk, atau desain

KAMI SALAH TENTANG ___
  Satu kalimat. Hal yang kami yakini sebelum masuk yang disangkal (atau tidak dikonfirmasi) oleh data.

Baris "kami salah tentang" adalah senjata rahasia. Ini melakukan tiga hal:

1. Membangun kepercayaan tim. Pemimpin melihat bahwa Anda tidak mengemas kerugian sebagai kemenangan.
2. Berlipat ganda pembelajaran. Selama satu tahun Anda memiliki 30 baris "kami salah tentang" ke atas, dan pola muncul ("kami terus melebih-lebihkan dampak perubahan halaman harga").
3. Mengkalibrasi skor Kepercayaan di masa depan. Prior Anda menjadi lebih tajam.

Jika readout Anda tidak memiliki baris "kami salah" untuk setidaknya 60% pengujian yang selesai, Anda baik sedang menguji hanya hal-hal yang aman atau Anda sedang menulis ulang sejarah. Keduanya buruk.

Dari mana backlog hipotesis berasal

Pipeline pengujian kehabisan jika tim tidak memiliki cara terstruktur untuk mendapatkan ide. Lima sumber yang saya percaya, dalam urutan sinyal menurun:

1. Perbedaan corong: segmen X berkonversi pada setengah tingkat segmen Y pada langkah yang sama. Cari tahu mengapa. Di sinilah kemenangan terbesar dan paling dapat dipertahankan berada.
2. Wawancara kualitatif: 5 pelanggan yang berhenti, direkam, ditranskrip. Anda akan mendengar gesekan yang sama pada 3 di antaranya. Gesekan itu adalah hipotesis berikutnya Anda.
3. Rekaman panggilan penjualan: Gong/Chorus adalah tambang emas. Cari "Saya berharap bisa" atau "hal yang membingungkan saya." Masing-masing adalah hipotesis dengan kepercayaan yang sudah bawaan.
4. Tiket dukungan: ide yang sama, lebih jauh ke bawah corong. Kelompokkan berdasarkan topik. Kelompok terbesar seringkali adalah perbaikan engineering 2 minggu yang meningkatkan aktivasi lebih dari 6 pengujian terakhir Anda digabungkan.
5. Analisis kompetitor: berguna tetapi berbahaya. Anda akan memberi bobot berlebihan pada kebaruan. Tandai ini sebagai Kepercayaan rendah secara default.

Nilai setiap ide terhadap template hipotesis sebelum memasuki antrian prioritisasi. Jika Anda tidak dapat mengisi bagian Masalah dengan dua titik data nyata, ide itu belum siap. Itu adalah tebakan. Kembalikan untuk riset.

Menghilangkan eksperimen zombie

Setiap tim pertumbuhan yang saya lihat memilikinya: pengujian yang masih menyajikan traffic ke varian yang tidak dimiliki siapa pun, di balik flag yang tidak diingat siapa pun, di halaman yang tidak diaudit siapa pun. Tiga aturan:

• Aturan 90 hari. Jika sebuah pengujian telah berjalan lebih dari 90 hari tanpa readout, pengujian itu dihentikan secara default pada review kuartalan berikutnya. Tidak ada pengecualian untuk "kami sedang menunggu lebih banyak data." Jika sebuah pengujian membutuhkan 4 bulan untuk mencapai signifikansi, itu kekurangan daya saat diluncurkan dan jawaban yang tepat adalah berhenti dan desain ulang.
• Review kuburan kuartalan. Sekali per kuartal, audit setiap flag aktif di platform eksperimen Anda. Cocokkan masing-masing dengan pemilik dan dokumen readout. Apa pun yang yatim piatu dikembalikan ke kontrol dan flag dihapus dari kodebase.
• Audit "masih menyajikan traffic". Tarik daftar semua URL yang memenuhi syarat eksperimen dan periksa silang dengan pengujian aktif di platform. Setiap celah adalah bug konfigurasi atau zombie. Perbaiki keduanya.

Tim yang menjalankan audit ini dengan jujur akan menemukan bahwa 30 hingga 40% pengujian "aktif" mereka adalah bobot mati. Menghilangkannya membebaskan traffic dan perhatian untuk pengujian yang benar-benar dapat belajar.

Pekerjaan sebenarnya growth IC

Saya akan menutup dari mana saya membuka. Pekerjaan IC bukan mengirimkan lebih banyak pengujian. Ini adalah mengirimkan lebih banyak pembelajaran. Sebagian besar kuartal, itu adalah 4 pengujian yang dirancang dengan baik, diberi daya dengan benar, dengan readout yang jujur, bukan 40 hasil yang meragukan.

Praktik eksperimen yang baik terlihat lambat dari luar. Tim menjalankan 3 pengujian, bukan 30. Setengah readout mengatakan "kami salah." PM yang mempertahankan mengintip mendapat penolakan. CFO benar-benar membuka dokumen readout dan mengajukan pertanyaan tentang metrik penjaga.

Itulah pekerjaan yang berjalan. Trofi di Slack datang belakangan, dan mereka nyata karena matematikanya nyata.

Pelajari Lebih Lanjut

• Deskripsi Pekerjaan Growth Marketing Manager
• Diagnostik Corong PLG untuk Growth IC
• Pemilihan Metrik Aktivasi: Memilih Satu Angka
• Membaca Kurva Retensi Kohort Tanpa Berbohong pada Diri Sendiri