Kami telah menyiapkan bagi pembaca Habra terjemahan sebuah artikel oleh Michael Kaminsky, mantan direktur analisis di Harry. Dia berbicara tentang apa yang salah dengan pengujian A / B. Komentar tentang materi oleh Gleb Sologub, direktur analitik di Skyeng.
Konsep pengujian A / B didasarkan pada asumsi yang secara fundamental salah bahwa ada solusi tunggal yang rata-rata lebih baik untuk semua pelanggan. Analis harus meninggalkan asumsi bahwa audiens mereka homogen dan mulai mengembangkan sistem yang memungkinkan penggunaan (dan mendorong) hasil tes selain yang biner.
Selama beberapa minggu terakhir, dua artikel yang sangat menarik telah diterbitkan pada interpretasi non-standar dari tes A / B. Salah satu artikel dari blog teknik Uber adalah tentang menghitung dampak dampak oleh quantile, dan yang lainnya ( dari blog StitchFix Data Science blog yang sangat baik ) adalah tentang menggunakan algoritma bandit kontekstual untuk mencapai personalisasi.
Kedua artikel ini menarik, tetapi bagi saya tampaknya mereka memiliki terlalu banyak teori tentang interpretasi dan implementasi tes dan kekurangan fakta. Saya merumuskan kembali tesis saya untuk kejelasan:
Pengujian A / B tradisional didasarkan pada asumsi yang secara fundamental salah. Dalam kebanyakan kasus, opsi A akan lebih baik untuk beberapa subkelompok, dan opsi B untuk yang lain. Memilih A atau B pada awalnya kehilangan kombinasi A dan B. yang dipilih dengan cermat
Sayangnya, menerapkan pendekatan ini untuk pengujian, pengoptimalan, dan pengembangan perangkat lunak tidak mudah. Ini membutuhkan alat statistik baru, alat baru untuk mengembangkan dan mendukung solusi perangkat lunak, serta melatih para pemangku kepentingan, jika Anda ingin mereka terlibat dalam proses tersebut. Dalam artikel ini saya akan memberikan contoh yang memotivasi, dan kemudian saya akan berbicara tentang beberapa masalah yang akan Anda hadapi ketika membuat sistem yang beradaptasi dengan kenyataan baru. Saya tidak akan membahas data statistik yang mendasari dan terkait dengan pembangunan jenis sistem ini (lebih baik baca artikel oleh StitchFix dan artikel ini dari Google ), tetapi saya akan berbicara tentang peluang yang saya lihat di tingkat strategis dan arsitektur.
Contoh yang memotivasi
Untuk meyakinkan Anda bahwa ini penting, mari kita lihat contoh kecil. Meskipun angka-angka ini fiktif, mereka dengan sempurna mewakili apa yang telah saya lihat berkali-kali dalam evaluasi tes A / B real-time.
Perusahaan Kasur Lain (EOMK) menjual kasur secara online (Anda dapat melihat iklan mereka di kereta bawah tanah). Mereka ingin menguji formulir pemesanan yang diperbarui yang dioptimalkan untuk ponsel. Desainer agak khawatir bahwa meskipun versi yang diperbarui kurang rumit, ia juga menyampaikan lebih sedikit informasi selama proses pemesanan dan ini dapat secara negatif mempengaruhi konversi oleh pengguna dengan komputer desktop.
Tim memulai tes dan mendapatkan hasil berikut:
Sial, tidak ada perbedaan! Secara intuitif, Anda memutuskan untuk membagikan lalu lintas di ponsel dan PC Anda.
Wow! Versi baru ... menunjukkan dengan tepat apa yang diharapkan oleh desainer! Situasi menjadi lebih baik bagi pengguna perangkat seluler dan lebih buruk bagi pengguna PC.
Sangat buruk bahwa tes A / B kami tidak menunjukkan efek. Mungkin kita harus mengirim desainer kita untuk memikirkan versi baru dari formulir pemesanan.
Tapi tunggu! Bagaimana jika kami mendukung versi seluler yang dioptimalkan untuk pengguna yang mengakses situs melalui telepon? Dan versi desktop yang dioptimalkan - untuk pengguna di komputer desktop? Bagaimana jika kami membuat halaman arahan yang akan berfungsi lebih baik pada akhir pekan ketika orang memiliki lebih banyak waktu untuk membaca? Bagaimana jika kami membuat iklan yang berfungsi lebih baik di California daripada di Massachusetts?
Bagaimana jika halaman web tidak cocok untuk semua orang sekaligus?
Tugasnya
Sulit untuk mengatakan apakah ide ini jelas atau revolusioner. Sangat jelas sehingga tampak hampir bodoh. Tetapi jika Anda melihat bagaimana sebagian besar perusahaan mengembangkan, menguji dan men-debug produk perangkat lunak, ternyata ini adalah perubahan yang cukup mendasar dalam pendekatan untuk masalah perangkat lunak.
Banyak perusahaan masih hanya memiliki satu versi situs web yang berfungsi. Tes dapat dilakukan, tetapi segera setelah salah satu tes menang, versi yang kalah dibuang dan satu-satunya versi yang benar muncul, "raja bukit".
Untuk mencakup semua keragaman pelanggan dan pengguna, perlu untuk mengembangkan solusi perangkat lunak dengan cara yang berbeda secara fundamental. Kami membutuhkan alat baru dan lebih canggih, dan kami juga perlu melatih pemangku kepentingan dalam cara berpikir yang baru.
Saat ini, mencoba mengelola skenario penggunaan dengan banyak variabel sangat sulit (jika memungkinkan). Karena mengelola begitu banyak opsi itu mahal, banyak perusahaan bahkan tidak mencoba untuk mempersonalisasi pengalaman pelanggan mereka. Selanjutnya, saya akan berbicara lebih banyak tentang masalah dan menguraikan cara untuk menyelesaikannya.
Alat pemrograman
Di dunia baru kami yang berani, di mana kami menyediakan beragam konten untuk berbagai kategori pengguna (dalam proporsi yang dapat berubah seiring waktu), kami akan memerlukan alat untuk pengembangan dan analisis perangkat lunak kami.
Tampaknya konsekuensi paling jelas dari penggunaan paradigma semacam itu adalah peningkatan signifikan dalam jumlah kode dalam proyek. Alih-alih menghapus cabang kode yang usang setelah pengujian, kami harus mendukungnya (mungkin selamanya). Ini mengerikan!
Bahkan, kita perlu membuat aplikasi lebih modular sehingga kita dapat terus mengembangkan, menguji, menyebarkan, dan memelihara cabang kode baru (misalnya, versi baru untuk pengujian).
Untuk dapat mengarahkan pengguna ke cabang berbeda dari kode berdasarkan karakteristik mereka (berpotensi jumlah cabang dari skrip pengguna bisa sangat besar), perlu untuk mengembangkan arsitektur yang akan mendukung percabangan tersebut. Kami membutuhkan mekanisme pengambilan keputusan terpusat yang dapat memilih rute untuk pengguna ini. Penting juga bahwa komponen jalur dapat cukup dipertukarkan untuk memandu pengguna secara bebas di sepanjang rute, bahkan jika mereka dikembangkan secara independen satu sama lain dan tanpa menggunakan satu kasus.
Akhirnya, tanpa penggunaan tunggal, holistik, kami membutuhkan alat sehingga manajer dan desainer produk dapat membayangkan jalur pelanggan di taman jalur yang berbeda. Bagaimana kami memperkenalkan dan mengevaluasi fitur-fitur baru? Bagaimana kita melacak langkah apa yang dilalui pengguna ini ketika dia menggunakan aplikasi kita? Bagaimana kita mencegah aplikasi berubah menjadi massa kode spaghetti yang tidak berbentuk?
Komunikasi dan pelatihan
Ini akan menjadi sangat sulit bagi orang-orang yang jauh dari proses menciptakan suatu produk untuk mengambil pandangan baru ini pada pengembangan perangkat lunak. Manajer terbiasa menangani rute satu pengguna, satu-satunya suara merek dan pengalaman berinteraksi yang sama dan universal dengan klien. Ketika kami mulai mempersonalisasikan pengalaman pengguna, kesempatan untuk berbicara tentang solusi perangkat lunak hanya dari satu sudut pandang menghilang.
Kita perlu mendidik pemangku kepentingan tentang nilai pendekatan baru ini dan membantu mereka berpikir tentang skrip kustom dan suara merek dalam konteks ini. Penting untuk mengembangkan metode untuk menentukan rute yang paling umum. Dan berikan manajer alat untuk mempelajari produk atas nama pengguna dari subkelompok tertentu, sehingga mereka dapat memperoleh pengalaman berinteraksi dengan produk yang dipersonalisasi untuk pengguna yang berbeda dari sudut pandang yang berbeda.
Alat Statistik
Kemungkinan besar, di dunia tanpa pengujian A / B, kita harus menyingkirkan banyak alat yang secara tradisional kita gunakan untuk mengoptimalkan aplikasi web. Semua upaya kami untuk melatih para manajer produk dan pemasar dalam meluncurkan dan menafsirkan tes A / B tidak akan menjadi masalah.
Di dunia baru ini, kita perlu mengembangkan metode penelitian dan visualisasi sampel dengan ukuran berbeda. Kita akan membutuhkan metode perbandingan yang baru dan lebih maju agar tidak jatuh ke dalam perangkap banyak perbandingan .
Kesimpulan
Dengan mempertimbangkan keragaman sejati dalam basis pengguna kami, kami dapat meningkatkan interaksi dengan sejumlah besar pengguna, yang sangat berharga. Sayangnya, seperti yang sering terjadi ketika mengubah pendekatan untuk pengembangan dan implementasi teknologi, keuntungan ini mahal. Kami memiliki jalan panjang untuk pergi dari titik di mana kami berada sekarang, ke masa depan yang menyenangkan dan lebih personal, dan saya yakin bahwa perjalanan ini akan menyenangkan.
Catatan penulis:
Saya mengecualikan semua diskusi interval kepercayaan dan signifikansi statistik untuk kesederhanaan. Maaf
Komentar dari Gleb Sologub, Direktur Analytics di Skyeng
Michael merangkum tren personalisasi saat ini dan berfantasi tentang apa yang seharusnya menjadi sarana dan metode pengembangan dan analitik, ketika semua produk TI akan sepenuhnya disesuaikan untuk pengguna tertentu.
Sejauh ini, kami telah mempelajari cara mempersonalisasi dalam dua cara: pertama, dengan membuat skenario terpisah untuk segmen pengguna yang berbeda, kedua, dengan mengembangkan solusi algoritmik untuk menampilkan konten yang dipersonalisasi pada langkah-langkah individual corong.
Jadi, Skyeng tentu saja telah mengoptimalkan versi seluler dari situs dan platform pelatihan, serta berbagai versi produk ini untuk pengguna dari berbagai usia. Selain itu, kami melakukan tes AB dan menyadari bahwa pengguna dari berbagai daerah memiliki kebutuhan yang berbeda, setelah itu kami memperkenalkan diferensiasi deskripsi pemasaran tergantung pada wilayah tersebut.
Pada contoh personalisasi algoritmik, selain yang dikutip oleh Michael, orang dapat menambahkan daftar panjang produk dan konten yang direkomendasikan, serta keberhasilan yang relatif baru dalam menghasilkan poster film individu.
Namun, semua ini dapat dilakukan sambil terus menggunakan metode dan analisis pembangunan yang lama.
Di masa depan yang sama seperti yang dijelaskan Michael, tes AB, seperti mereka, mungkin tidak bermanfaat, tetapi mereka akan membutuhkan modularitas perangkat lunak yang luar biasa dan beberapa metode analitik baru untuk membuat variasi tak berujung dari skenario pengguna yang sepenuhnya individual .
Kami di Skyeng sudah memiliki dan memperluas tim peneliti dan analis yang mempelajari tren ini dan mencoba menerapkannya untuk meningkatkan produk kami.