Cara berhenti khawatir dan mulai percaya pada tes A / B

Saat Anda mengembangkan suatu produk, setiap iterasi baru berisiko menjatuhkan metrik dan kehilangan pengguna. Namun demikian, kadang-kadang, terutama pada tahap awal, perusahaan tanpa sadar mengambil risiko ini - ganti produk, hanya mengandalkan naluri dan hipotesis mereka.

Kami di Badoo tidak mempercayai perasaan, tetapi kami percaya pada angka. Secara total, layanan kami memiliki lebih dari 500 juta pengguna, dan kami menulis kerangka pengujian kami untuk waktu yang lama. Dalam enam tahun, 2962 tes melewatinya, dan pengujian A / B membuktikan pentingnya, keandalan, dan efektivitasnya.



Tetapi dalam artikel ini saya tidak akan berbicara tentang cara kerja sistem kami. Satu artikel saja tidak cukup. Selain itu, banyak hal khusus untuk perusahaan kami dan tidak sesuai dengan yang lain. Hari ini saya akan berbicara tentang evolusi ide-ide kami tentang tes A / B: penggaruk seperti apa yang kami selesaikan dalam proses dan bagaimana kami memeriksa kebenaran tes. Artikel ini ditujukan bagi mereka yang belum memulai pengujian, tetapi pikirkan tentang hal itu, serta bagi mereka yang tidak yakin tentang sistem pengujian mereka.

Apa itu tes A / B?


Bayangkan sebuah situasi: fitur baru akan diluncurkan, dan manajer produk kami tidak siap mengambil risiko kecil tapi pendapatan stabil untuk produk. Setelah beberapa pertimbangan, ia menyarankan untuk meluncurkan fitur melalui uji A / B dan melihat apakah itu akan lepas landas dan pengguna tidak akan pergi ke pesaing. 

Kami tidak melakukan tes A / B sebelumnya, jadi hal pertama yang kami pelajari adalah apa adanya. Wikipedia mengatakan: "Pengujian A / B adalah metode riset pemasaran , intinya adalah bahwa kelompok kontrol elemen dibandingkan dengan satu set kelompok uji di mana satu atau lebih indikator diubah untuk mengetahui yang mana dari Ubah Tingkatkan Target". Ternyata kita perlu melakukan penelitian di mana harus ada kelompok kontrol, setidaknya satu kelompok uji dan indikator target.

Untuk grup uji, kami akan menunjukkan versi alternatif dari halaman pembayaran. Di atasnya, kami ingin mengubah teks, menyorot diskon, mengganti gambar - dan semua ini untuk pengguna dari Eurasia, sehingga mereka membeli lebih banyak. Dan untuk pengguna dari Amerika, kami tidak ingin mengubah apa pun. 

Kami akan memiliki target. Mari kita ambil yang dasar:

  • ARPU (pendapatan rata-rata per pengguna) - keuntungan yang akan kami terima rata-rata dari pengguna; 
  • jumlah klik pada elemen CTA (ajakan bertindak) - tombol dan tautan di halaman pembayaran. 

Tugas teknis


Direncanakan untuk mengubah tiga elemen pada halaman secara bersamaan: teks, tombol dan gambar dengan informasi diskon.



Akan sangat sulit untuk memahami perubahan mana yang mempengaruhi hasil jika diuji secara bersamaan. Mungkin teks baru akan mengusir pengguna dan menyebabkan penurunan jumlah pembelian, tetapi menyoroti diskon akan meningkatkannya: sebagai hasilnya, kami mendapat nol. Sumber daya pengembangan akan terbuang sia-sia dan hipotesis kerja akan ditolak. 

Karena itu, kami tidak akan melakukan ini. Kami hanya akan menyisakan satu perubahan untuk pengujian - alokasi diskon. 


Tes pertama


Rencananya adalah ini: kami membagi pengguna menjadi dua kelompok yang sama dan menunggu hasilnya. Ketika kami menerimanya, kami akan membandingkan indikator dalam kelompok kontrol dan tes. 

Semuanya terlihat sangat sederhana: kami membagi pengguna menjadi genap dan ganjil dan kemudian melihat statistik. 

Kami menulis kode:

if (userId % 2 == 1) {
    showNewAwesomeFeature();
}

Kami menantikan beberapa minggu: hasilnya luar biasa! ARPU meningkat 100%! Orang-orang mengklik, membayar, manajer produk meminta untuk segera meluncurkan perubahan sama sekali. 



Kami menyalakannya, beberapa minggu lagi berlalu, tetapi tidak ada hasil. Total laba belum bertambah. 

Apa yang kita lakukan salah?

Kami memilih grup uji


Kami hanya membagi pengguna menjadi dua kelompok yang sama dan menjalankan tes, tetapi Anda tidak dapat melakukan ini. Bagaimanapun, sesuatu telah berubah hanya untuk pengguna dari Eurasia. Dan jumlah kami jauh lebih sedikit daripada pengguna dari Amerika. Oleh karena itu, ternyata lonjakan aktivitas pengguna yang tiba-tiba dari Amerika memengaruhi hasil pengujian kami, meskipun dalam kenyataannya mereka bukan yang terbaik.

Kesimpulan: selalu pilih dalam kelompok uji hanya pengguna yang untuknya perubahan tersebut diterapkan.

Mari kita perbaiki kode kita:

if (user.continent === β€˜eurasia’ && userId % 2 == 1) {
    showNewAwesomeFeature();
}

Sekarang semuanya harus bekerja sebagaimana mestinya! Jalankan tes. Kami menunggu beberapa minggu.



Terjadi! ARPU naik 80%! Gulirkan perubahan ke semua pengguna. 

Dan ... setelah periode waktu yang sama, grafik sekali lagi tidak terlihat seperti yang kita rencanakan.

Hitung Signifikansi Statistik


Tes tidak dapat dihentikan hanya "setelah beberapa minggu": hasil yang diperoleh mungkin tidak akurat. Semakin sedikit metrik yang kami ikuti telah berubah, dan semakin sedikit orang yang berpartisipasi dalam pengujian, semakin besar kemungkinannya untuk menjadi acak.  

Probabilitas ini dapat dihitung. Nilai yang menunjukkan itu disebut nilai p. Saya akan memberi tahu Anda cara kerjanya.

Saat melakukan pengujian apa pun, ada peluang untuk mendapatkan hasil acak. Misalnya, pengguna yang mengunjungi situs mungkin tidak terdistribusi secara merata - dan seluruh audiens yang membayar akan termasuk dalam salah satu grup. Dalam tes nyata, perbedaan dalam metrik biasanya tidak begitu besar: sulit atau bahkan tidak mungkin untuk melihat masalah pada grafik, dan uji statistik tidak dapat dihilangkan. Secara khusus, kita perlu memperbaiki probabilitaskesalahan jenis pertama dan kedua - dengan kata lain, probabilitas menemukan perubahan di mana mereka tidak ada, dan, sebaliknya, tidak menemukan mereka jika ada. Bergantung pada nilai metrik dan probabilitas yang ditetapkan, kami akan membutuhkan jumlah pengguna yang berbeda.

Anda dapat menghitungnya menggunakan kalkulator online : tentukan nilai saat ini dan target metrik yang dipantau - Anda mendapatkan jumlah pengguna yang diperlukan untuk pengujian, dan sebaliknya.


Perhitungan untuk konversi 10% dan perubahan 0,2% relatif terhadap nilai saat ini.

Sekarang kami telah menerima semua data yang diperlukan dan kami memahami kapan harus menghentikan tes. Tidak ada lagi hambatan.

Mari kita jalankan tes A / B kami dan lihat hasilnya.



Kali ini, hasilnya lebih seperti kebenaran, tetapi masih bagus: pertumbuhan ARPU sebesar 55%. 

Kami menghentikan tes, menerapkan kelompok tes sama sekali. Dan ... metrik jatuh lagi. Mengapa? 

Periksa jumlah pengguna


Mari kita cari tahu berapa banyak pengguna yang benar-benar mengunjungi situs kami saat pengujian sedang berlangsung. Dilihat oleh log, hanya 10% dari kelompok uji kami, tetapi kami tidak memperhitungkannya. 

Jika DAU Anda (jumlah pengguna unik per hari) adalah 1000 orang, ini tidak berarti bahwa dalam sepuluh hari Anda akan memiliki 10.000 pengguna dalam ujian. Selalu login hit nyata ke tes (test hit) dan hitung hanya mereka.

Kami menerapkan logika sederhana. Untuk setiap pengguna yang mengunjungi situs, kami mengirim permintaan ke server dengan nama-nama kelompok uji dan kontrol A / B. Berkat ini, kami akan tahu persis berapa banyak pengguna yang mengunjungi kami, dan kami tidak akan salah lagi.

Kami meluncurkan tes A / B.

Hasilnya sangat bagus. Kami mendapatkan lebih banyak uang lagi! Kami mengaktifkan pengujian kami untuk semua orang - dan terjadi kesalahan lagi: setelah beberapa minggu, metriknya kembali lebih rendah dari yang diperkirakan. 

Ingat, kami mulai mengirim klik untuk semua pengguna yang mengunjungi situs ini? Tidak pernah melakukannya. Hit harus dikirim hanya kepada pengguna yang berinteraksi dengan bagian sumber daya yang diuji. Dan semakin akurat Anda mendefinisikannya, semakin baik. 

Untungnya, ini mudah diverifikasi. Untuk melakukan ini, Anda dapat melakukan tes A / A / B. Sepertinya tes A / B, tetapi dalam kasus ini Anda memiliki dua kelompok kontrol dan satu kelompok uji. Mengapa ini dibutuhkan? Jika momen untuk mengirim klik dipilih secara tidak benar, maka pengguna yang tidak berinteraksi dengan bagian situs yang diuji akan masuk dalam pengujian. Dalam hal ini, akan ada perbedaan besar dalam metrik dalam grup A dan A, dan Anda dapat segera memahami bahwa ada sesuatu yang salah. 

Kami meluncurkan tes A / A / B. 

Di grup B, tinggalkan 50% pengguna, dan bagi 50% sisanya secara merata antara grup A dan A (kami menyebutnya kontrol dan kontrol_check). Ya, hasilnya harus menunggu lebih lama, tetapi dengan apakah hasil grup A dan A menyatu, Anda akan memahami apakah hit dikirim dengan benar.



Hasilnya sederhana (pertumbuhan hanya 20%), tetapi realistis. Mari kita lakukan perubahan sama sekali. 

Semuanya bekerja dengan sempurna! 

Tapi setelah sebulan, metrik jatuh lagi.

Menguji apa yang bisa kita kontrol


Ternyata penagihan pihak ketiga kami juga melakukan uji A / B, yang secara langsung memengaruhi hasil kami. Karena itu, selalu ikuti hasil pada produksi dan cobalah untuk menguji apa yang Anda kontrol secara penuh.

Total


Tes A / B dapat membantu pertumbuhan produk. Tetapi untuk mempercayai tes, penting untuk melakukannya dengan benar dan selalu memeriksa hasilnya. Pendekatan ini akan memungkinkan Anda untuk menguji produk Anda secara kualitatif dan menguji hipotesis sebelum mereka menjatuhkan semua metrik.

  • Selalu periksa grup target.
  • Kirim hit.
  • Kirim hit yang tepat.
  • Uji apa yang Anda kendalikan sepenuhnya.
  • /-!

All Articles