Kesalahan desain pengujian A / B yang saya pikir tidak akan pernah saya lakukan

Saat meluncurkan eksperimen pertama saya, saya berpikir bahwa semua "tiga / lima / tujuh kesalahan paling populer" ini, yang saya baca di artikel dan didengarkan di konferensi - tentu saja bukan tentang saya. Selain itu, desain tes dibantu oleh templat penelitian besar yang indah yang diadopsi oleh perusahaan.







Namun dalam praktiknya, jebakan menunggu. Mari kita bicara tentang apa yang bisa terjadi jika Anda mengubah desain sedikit atau mengisi sedikit template Anda. Dan bagaimana memperbaiki semuanya.



Saya ingin memberi manfaat bagi pengguna baru, tetapi secara alami mereka tidak berperilaku sebagaimana mestinya



Alat penjualan utama Skyeng adalah tutorial video pengantar gratis dengan fasilitator. Kami melakukan pelajaran di platform kami, dan kebetulan seorang siswa mencoba untuk terhubung ke panggilan, tetapi mikrofon atau kameranya tidak tertangkap.





Hal ini dapat terjadi karena lusinan alasan - dari kesalahan klik yang dangkal pada notifikasi di browser (seperti dalam gambar ini) hingga kasus yang benar-benar eksotis: misalnya, setelah seseorang mencoba bekerja dari Tesla, dan ada perangkat lunaknya sendiri yang tidak kami dukung.



Jika Anda tidak dapat dengan cepat memperbaiki masalah, gangguan teknis dari pelajaran pengantar terjadi:



  • siswa tetap negatif,
  • pelajaran guru terputus,
  • sekolah kehilangan konversi ke pembayaran di sini dan sekarang (ini adalah metrik utama departemen kami), mengkompensasi partisipasi guru dalam pelajaran dan memulai proses mentransfer pelajaran.


Setiap orang menderita. Oleh karena itu, tahun lalu kami memulai banyak proyek untuk mengurangi gangguan teknis. Setiap ide diuji: bisnis ingin memahami apakah fitur tersebut berfungsi dan apakah biaya untuk mendukungnya dapat ditutup.





Salah satu solusi yang harus diuji adalah pencarian peralatan. Awalnya ini adalah widget, berikut adalah layar utamanya.



Idenya sederhana: jangan menunggu saat untuk memasuki pelajaran, tetapi undang siswa untuk memeriksa kamera dan mikrofon terlebih dahulu - ketika dia meninggalkan permintaan untuk pelatihan. Jika ada yang tidak beres, kami akan mengeluarkan tiket ke dukungan teknis, dan orang-orang akan memiliki beberapa jam untuk menyelesaikan masalah tersebut.



Saat saya membagi pengguna menjadi pengujian dan kontrol, saya berharap orang-orang di grup pengujian akan mengklik widget dan menyelesaikan pencarian. Apa yang salah?



Dalam grup kontrol ("A") semuanya berjalan seperti biasa - orang meninggalkan aplikasi dan menjalankan bisnisnya. Tetapi setelah pengujian, kami melihat bahwa persentase kegagalan teknis di grup "A" dan "B" serupa dengan seperseratus persen. Hmm, mereka semua dalam kelompok uji menjalani quest, tapi itu tidak membantu, atau tidak ada yang masuk? Kami tidak tahu - tidak ada penebangan.



Kedua tahap itu digabung menjadi satu, dan ternyata kita tidak bisa memisahkannya. Saya harus memulai kembali tes dan mencatat tahap kunci "memasuki pencarian". Kami menemukan bahwa sekitar 10% pengguna telah masuk ke dalamnya. Tidak ada pertumbuhan yang signifikan dalam metrik: misi telah terlupakan, pemeriksaan peralatan pada akhirnya dibangun ke dalam orientasi selama desain ulang global. Dan sekarang saya memeriksa di awal apakah saya memiliki data tentang semua tahapan utama corong.



ยซ - ?ยป. ,



Selain masalah teknis, terkadang siswa tidak muncul pada pelajaran pengantar yang sangat gratis itu - karena dia ketiduran, terbang keluar dari kepalanya, ada sesuatu yang dipindahkan, dan seterusnya.



Oleh karena itu, sebelum setiap pelajaran, ahli metodologi perlu menemukan siswa yang siap menelepon: untuk ini, sistem memberinya beberapa kontak, dan guru memanggil mereka. Ini "menggerogoti" 12-15% dari waktu yang dapat dihabiskan seseorang untuk sesuatu yang lebih berguna atau menyenangkan.



Sepertinya peluang bagus untuk otomatisasi - biarkan robot memanggil. Tapi kita perlu tes A / B: bagaimanapun, beberapa orang, setelah mendengar robot, bisa menutup telepon. Kemungkinan kehilangan sesuatu sudah jelas. Kami menjalankan tes dan pada awalnya semuanya berjalan dengan sangat baik, tapi ... Kami dikecewakan oleh perfeksionisme.



Dalam sejumlah skenario, robot perlu mentransfer panggilan ke operator manusia: misalnya, jika siswa ingin membatalkan pelajaran, operator harus melakukan perubahan pada CRM. Dan kadang-kadang robot hanya menemukan lawan bicara yang banyak bicara - sistem tidak dirancang untuk pengenalan ucapan dan dukungan dialog yang serius, di sini juga perlu untuk menghubungkan seseorang.



Kami ingin membuat pengalaman pengguna berjalan semulus mungkin.



Oleh karena itu, kami memutuskan untuk segera mengalihkan panggilan tersebut ke saluran telepon masuk. Bahkan jika pertanyaannya tidak mendesak. Para ahli metodologi dalam kasus yang sama berkata: "Anda akan dipanggil kembali dalam 3-5 menit untuk menugaskan kembali pelajaran." Dan operator punya waktu untuk mendistribusikan beban kerja dan membantu semua orang.



Operator tidak setuju dengan robot, dan itu menciptakan lonjakan dengan beberapa panggilan mendesak per menit. Sirkuit tersebut ternyata tidak dapat diskalakan.





Pada saat-saat puncak, situasinya menyerupai permainan klasik) Untuk foto, terima kasih kepada Wikipedia dan kontributornya perepelin30 .



Kami kembali ke skema yang digunakan oleh Metodis - jika seseorang dengan jelas menyuarakan permintaan transfer, robot akan menjawab "Kami akan menelepon Anda kembali". Hanya masalah yang berpotensi mendesak segera dialihkan ke operator. Setelah perubahan ini, pengujian harus dijalankan lagi, karena perubahan tersebut dapat memengaruhi metrik utama. Dan sekarang, sebelum setiap percobaan, kami mengajukan pertanyaan: "Oke, jika semuanya berjalan dengan baik, dapatkah kami meluncurkannya?"





Meluncurkan tes, memeriksa bahwa semuanya berjalan dengan baik, mengumpulkan banyak tugas saat ini



Skyeng memiliki penonton yang sangat keren dan terus bertambah - anak-anak yang mengajar matematika dan bahasa Inggris bersama kami. Tetapi kita tidak dapat melakukan pelajaran pengantar untuk seorang anak jika orang tuanya tidak ada. Kami tidak bisa secara hukum. Oleh karena itu, jika anak terhubung sendiri, pelajarannya akan terganggu. Maka Anda tahu: negatif, rekaman ulang, dan sebagainya.



Orang tua selalu diperingatkan secara lisan, ketika mereka menelepon, pada waktu pelajaran disepakati. Tetapi waktu berlalu dari panggilan ke pelajaran dan, tentu saja, tidak semua orang mengingat kesepakatan ini.





Kemudian solusinya datang: mari kita kirim SMS pengingat. Kira-kira teks seperti itu sampai ke orang tua mendekati waktu pelajaran pengantar.



Peningkatan jumlah pelajaran pengantar tanpa gangguan tidak berarti peningkatan konversi untuk membayar. Anda perlu memperkirakan ROI. Untuk melakukan ini, mari lakukan percobaan:



  • kami akan membagi secara acak semua aplikasi untuk referensi anak-anak menjadi dua kelompok,
  • kami tidak akan mengirimkan apa pun kepada orang tua di kelompok pertama - mereka memiliki aliran yang teratur,
  • Orang tua di kelompok lain akan dikirimi dua SMS pengingat: 24 dan 1-2 jam sebelum pelajaran dimulai.


Kami memulai tes, melakukan pemeriksaan pada hari pertama - dan membersihkan omzet.



Beberapa minggu kemudian, saya melihat ke dasbor - dan di sana, selain grup pengujian dan kontrol, ada beberapa pengguna lain.





Jika kita ingin membagi 50 dengan 50, grafik merah dengan jelas menunjukkan ada yang tidak beres.



Ternyata kesalahan dangkal yang harus disalahkan: ada yang salah dengan acara tersebut, tidak semua orang mengirim SMS pada pemicu. Bug telah diperbaiki, tetapi pengujian harus dimulai ulang: pada akhirnya, meskipun Anda memiliki desain pengujian yang benar, dengan semua templat yang terisi, dan seterusnya, ini tidak berarti bahwa pengujian akan berjalan lancar. Dan Anda harus memeriksanya sesering mungkin.



ps Saya sangat berharap teks ini akan membantu seseorang membuat lebih sedikit kesalahan dalam tes mereka. Kemungkinan besar Anda akan memiliki atau sudah memiliki kasing lucu Anda sendiri: asyik jika Anda membagikannya juga suatu hari nanti!



pps Posting ini didasarkan pada laporan di komunitas TI Rostov RnDTech - jika Anda tinggal di suatu tempat di bagian selatan negara, bergabunglah, orang-orang melakukan gerakan hebat.



All Articles