Tes A / B di Android dari A hingga Z

Sebagian besar artikel tentang tes A / B ditujukan untuk pengembangan web, dan meskipun relevansi alat ini dengan platform lain, pengembangan ponsel secara tidak adil tetap menyendiri. Kami akan mencoba menghilangkan ketidakadilan ini dengan menjelaskan langkah-langkah utama dan mengungkapkan fitur-fitur dari implementasi dan pelaksanaan tes A / B pada platform mobile.

Konsep Pengujian A / B

Tes A / B diperlukan untuk menguji hipotesis yang ditujukan untuk meningkatkan metrik aplikasi utama. Dalam kasus yang paling sederhana, pengguna dibagi menjadi 2 kelompok kontrol (A) dan eksperimental (B). Fitur yang mengimplementasikan hipotesis diluncurkan hanya ke grup eksperimen. Selanjutnya, berdasarkan analisis komparatif dari indikator metrik untuk masing-masing kelompok, sebuah kesimpulan diambil berdasarkan relevansi fitur tersebut.

Implementasi

1. Bagi pengguna menjadi beberapa kelompok

Pertama-tama kita perlu memahami bagaimana kita akan membagi pengguna ke dalam kelompok dalam persentase yang tepat dengan kemampuan untuk mengubahnya secara dinamis. Peluang seperti itu akan sangat berguna jika tiba-tiba ternyata fitur baru meningkatkan konversi sebesar 146%, dan diluncurkan, misalnya, oleh hanya 5% pengguna! Tentunya kami ingin meluncurkannya ke semua pengguna dan saat ini - tanpa memperbarui aplikasi di toko dan biaya waktu terkait.

Tentu saja, Anda dapat mengatur gangguan pada server dan setiap kali Anda perlu mengubah sesuatu, tarik pengembang backend. Namun dalam kehidupan nyata, dukungan sering dikembangkan di sisi pelanggan atau oleh perusahaan ketiga, dan pengembang server memiliki cukup banyak hal yang harus dilakukan, sehingga tidak selalu mungkin untuk dengan cepat menyesuaikan kerusakan, bekerja dengan pihak ketiga, atau lebih tepatnya, hampir tidak pernah, sehingga opsi ini tidak cocok untuk kita. Dan kemudian Firebase Remote Config datang untuk menyelamatkan!

Di Firebase Console, di grup Grow ada tab Remote Config tempat Anda bisa membuat konfigurasi sendiri yang akan dikirimkan Firebase ke pengguna aplikasi Anda.


Konfigurasi adalah peta <kunci parameter, nilai parameter> dengan kemampuan untuk menetapkan nilai parameter sesuai dengan kondisi. Misalnya, untuk pengguna dengan versi spesifik aplikasi, nilainya adalah X, untuk semua yang lain - Y. Untuk informasi lebih lanjut tentang konfigurasi, lihat bagian yang sesuai dari dokumentasi .



Juga di grup Tumbuh ada Pengujian tab A / B. Di sini kita dapat menjalankan tes dengan semua roti di atas. Kunci dari Remote Config kami digunakan sebagai parameter. Secara teori, Anda dapat membuat parameter baru secara langsung dalam tes A / B, tetapi ini hanya akan menambah kebingungan yang tidak perlu, jadi Anda tidak harus melakukan ini, lebih mudah untuk menambahkan parameter yang sesuai ke konfigurasi. Nilai di dalamnya secara tradisional adalah nilai default dan sesuai dengan kelompok kontrol, dan nilai eksperimental parameter, selain standar, adalah eksperimental.



Catatan Grup kontrol biasanya disebut grup A, grup eksperimen disebut B. Seperti yang dapat Anda lihat di tangkapan layar, di Firebase, grup eksperimental default disebut "Varian A", yang menimbulkan beberapa kebingungan. Tapi tidak ada yang mencegah untuk mengubah namanya.

Selanjutnya, jalankan uji A / B, Firebase membagi pengguna menjadi beberapa kelompok yang sesuai dengan nilai parameter yang berbeda, setelah menerima konfigurasi pada klien, kami mendapatkan parameter yang diperlukan darinya dan menggunakan fitur baru berdasarkan nilai tersebut. Secara tradisional, parameter memiliki nama yang sesuai dengan nama fitur, dan 2 nilai: Benar - fitur diterapkan, Salah - tidak diterapkan. Baca lebih lanjut tentang pengaturan tes A / B di bagian yang sesuai dari dokumentasi .

2. Kode

Kami tidak akan berkutat pada integrasi dengan Firebase Remote Config - ini dijelaskan secara rinci di sini .

Mari kita cari tahu bagaimana mengatur kode untuk pengujian A / B. Jika kita hanya mengubah warna tombol, maka berbicara tentang organisasi tidak masuk akal, karena tidak ada yang istimewa untuk diatur. Kami akan mempertimbangkan varian di mana, tergantung pada parameter dari Remote Config, layar saat ini (untuk grup kontrol) atau baru (untuk percobaan) ditampilkan.

Anda perlu memahami bahwa setelah tes A / B berakhir, salah satu opsi layar perlu dihapus, dalam hal ini, kode harus diatur sedemikian rupa untuk meminimalkan perubahan dalam implementasi saat ini. Semua file yang terkait dengan layar baru harus dipanggil dengan awalan AB dan ditempatkan di folder dengan awalan yang sama.

Jika kita berbicara tentang MVP di lapisan Presentasi, itu akan terlihat seperti ini:



Hirarki kelas yang paling fleksibel dan transparan adalah:



BaseOrderStatusFragment akan berisi semua fungsionalitas implementasi saat ini, kecuali untuk metode yang tidak dapat ditempatkan dalam kelas abstrak karena keterbatasan arsitektur. Mereka akan berlokasi di OrderStatusFragment.

AbOrderStatusFragment akan mengganti metode yang berbeda dalam implementasi dan memiliki yang tambahan yang diperlukan. Dengan demikian, dalam implementasi saat ini, hanya penguraian satu kelas menjadi dua yang akan berubah dan beberapa metode di kelas dasar akan menjadi terbuka terbuka dan bukan privat.

Catatan: jika arsitektur dan kasus spesifik memungkinkan, Anda dapat melakukannya tanpa membuat kelas dasar dan langsung mewarisi AbOrderStatusFragment dari OrderStatusFragment.

Dalam kerangka organisasi seperti itu, kemungkinan besar perlu untuk menyimpang dari CodeStyle yang diterima, yang diizinkan dalam kasus ini, karena kode yang sesuai akan dihapus atau di refactored setelah menyelesaikan tes A / B (tetapi, tentu saja, di tempat-tempat CodeStyle dilanggar, ada baiknya memberikan komentar)

Organisasi semacam itu akan memungkinkan kami menghapus fitur baru dengan cepat dan tanpa rasa sakit jika ternyata tidak relevan, karena semua file yang terkait dengannya mudah ditemukan dengan awalan dan implementasinya tidak memengaruhi fungsionalitas saat ini. Jika fitur meningkatkan metrik kunci dan diputuskan untuk meninggalkannya, kami masih harus bekerja memotong fungsi saat ini, yang akan memengaruhi kode fitur baru.

Untuk mendapatkan konfigurasi, ada baiknya membuat repositori terpisah dan menyuntikkannya pada tingkat aplikasi sehingga dapat diakses di mana saja, karena kami tidak tahu bagian mana dari aplikasi yang akan memengaruhi tes A / B di masa depan. Untuk alasan yang sama, ada baiknya memintanya sesegera mungkin, misalnya, bersama dengan informasi dasar yang diperlukan agar aplikasi dapat berfungsi (biasanya permintaan seperti itu terjadi selama splash, meskipun ini adalah topik holistik, tetapi penting bahwa mereka ada di suatu tempat).

Nah, dan, tentu saja, penting untuk tidak lupa membuang nilai parameter dari konfigurasi ke parameter acara analitik, sehingga Anda dapat membandingkan metrik

Analisis Hasil

Ada banyak artikel yang merinci cara menganalisis hasil tes A / B, misalnya . Agar tidak mengulangi diri kita sendiri, kita cukup menunjukkan esensi. Anda perlu memahami bahwa perbedaan dalam metrik pada kelompok kontrol dan eksperimental adalah variabel acak, dan kami tidak dapat menyimpulkan bahwa fitur tersebut hanya relevan berdasarkan pada bahwa metrik pada kelompok eksperimen lebih baik. Diperlukan untuk membangun interval kepercayaan (pilihan tingkat keandalan harus dipercayakan kepada analis) untuk variabel acak yang dijelaskan di atas dan melakukan percobaan sampai interval benar-benar berada di setengah-bidang positif atau negatif - maka kesimpulan yang valid secara statistik dapat dibuat.

Perangkap

1. Kesalahan mendapatkan Remote Config

Analisis komparatif dilakukan pada pengguna baru, karena pengguna dengan pengalaman pengguna yang sama dan hanya mereka yang telah melihat satu-satunya opsi implementasi yang harus berpartisipasi dalam percobaan. Ingatlah bahwa menerima konfigurasi adalah permintaan jaringan dan mungkin gagal, dalam hal ini nilai default, secara tradisional sama dengan nilai untuk kelompok kontrol, akan diterapkan.

Pertimbangkan kasus berikut: kami memiliki pengguna yang ditugaskan Firebase ke grup eksperimental. Pengguna memulai aplikasi untuk pertama kalinya dan permintaan Remote Config mengembalikan kesalahan - pengguna melihat layar lama. Di awal berikutnya, permintaan Remote Config diproses dengan benar dan pengguna melihat layar baru. Penting untuk memahami bahwa pengguna seperti itu tidak relevan untuk percobaan, jadi Anda perlu mencari cara untuk menyaring pengguna seperti itu di sisi sistem analisis, atau untuk membuktikan bahwa jumlah pengguna tersebut dapat diabaikan.

Bahkan, kesalahan seperti itu jarang terjadi, dan kemungkinan besar opsi yang terakhir cocok untuk Anda, tetapi pada dasarnya ada masalah yang serupa, tetapi jauh lebih mendesak - waktu untuk mendapatkan konfigurasi. Seperti disebutkan di atas, lebih baik menempel permintaan Remote Config di awal sesi, tetapi jika permintaan terlalu lama, pengguna akan bosan menunggu dan dia akan keluar dari aplikasi. Oleh karena itu, Anda perlu menyelesaikan tugas yang tidak sepele - untuk memilih batas waktu saat permintaan Remote Config diatur ulang. Jika terlalu kecil, maka persentase besar pengguna mungkin ada dalam daftar yang tidak relevan untuk pengujian, jika terlalu besar - kami berisiko menimbulkan kemarahan pengguna. Kami telah mengumpulkan statistik pada saat menerima konfigurasi:



Catatan Data selama 30 hari terakhir. Total jumlah permintaan 673 529 . Kolom pertama, selain permintaan jaringan, berisi tanda terima konfigurasi dari cache, oleh karena itu dihapus dari formulir distribusi umum.


2. Knurling perbarui Remote Config

Anda harus memahami bahwa Firebase melakukan cache permintaan Remote Config. Masa pakai cache default adalah 12 jam. Waktu dapat disesuaikan, tetapi Firebase memiliki batasan pada frekuensi permintaan, dan jika terlampaui, Firebase akan mencekal kami dan akan mengembalikan kesalahan pada permintaan konfigurasi (Catatan untuk pengujian, Anda dapat mengatur pengaturan setDeveloperModeEnabled, dalam hal ini batas tidak akan diterapkan, tetapi melakukannya mungkin untuk sejumlah perangkat).

Karena itu, misalnya, jika kita ingin menyelesaikan tes A / B dan meluncurkan fitur baru sebesar 100%, kita perlu memahami bahwa transisi hanya akan berlangsung dalam waktu 12 jam, tetapi ini bukan masalah utama. Pertimbangkan kasus berikut: kami melakukan tes A / B, menyelesaikannya dan menyiapkan rilis baru, di mana ada tes A / B lain dengan konfigurasi yang sesuai. Kami telah merilis versi baru aplikasi, tetapi pengguna kami sudah memiliki cache yang di-cache dari tes A / B sebelumnya, dan jika cache belum kedaluwarsa, permintaan konfigurasi tidak akan mengambil parameter baru, dan kami akan mendapatkan lagi pengguna yang ditugaskan ke grup eksperimental, yang pada permintaan pertama akan menerima nilai default dari konfigurasi dan di masa depan merusak data percobaan baru.

Solusi untuk masalah ini sangat sederhana - Anda harus memaksa permintaan konfigurasi saat memperbarui versi aplikasi dengan mengatur ulang masa cache:

val cacheExpiration = if (isAppNewVersion) 0L else TWELVE_HOURS_IN_SECONDS FirebaseRemoteConfig.getInstance().fetch(cacheExpiration) 

Karena pembaruan tidak sering diterbitkan, kami tidak akan melebihi batas
Baca lebih lanjut tentang masalah ini di sini .

Kesimpulan

Firebase menyediakan alat pengujian A / B yang sangat nyaman dan sederhana yang harus digunakan, dengan memberi perhatian khusus pada kemacetan yang dijelaskan di atas. Organisasi yang diusulkan kode akan meminimalkan jumlah kesalahan ketika membuat perubahan yang terkait dengan siklus tes A / B.

Semoga sukses untuk semua orang, pengujian A / B yang berhasil dan peningkatan konversi 100,5%.