Halo semuanya. Nama saya Danila, saya bekerja di sebuah tim yang mengembangkan infrastruktur analitik di Avito. Pusat dari infrastruktur ini adalah pengujian A / B.
Eksperimen A / B adalah alat pengambilan keputusan utama di Avito. Dalam siklus pengembangan produk kami, tes A / B adalah suatu keharusan. Kami menguji setiap hipotesis dan hanya meluncurkan perubahan positif.
Kami mengumpulkan ratusan metrik dan dapat menelusurinya ke bagian bisnis: vertikal, wilayah, pengguna yang berwenang, dll. Kami melakukan ini secara otomatis menggunakan platform tunggal untuk percobaan. Dalam artikel ini, saya akan memberi tahu Anda dengan cukup detail bagaimana platform diatur dan kami akan membahas beberapa detail teknis yang menarik.
Fungsi utama platform A / B dirumuskan sebagai berikut.
- Membantu Anda menjalankan eksperimen dengan cepat
- Mengontrol persimpangan eksperimen yang tidak diinginkan
- Metrik hitungan, stat. tes, memvisualisasikan hasil
Dengan kata lain, platform membantu membuat keputusan bebas kesalahan paling cepat.
Jika kami mengabaikan proses pengembangan fitur yang dikirim untuk pengujian, siklus penuh percobaan akan terlihat seperti ini:
- Pelanggan (analis atau manajer produk) mengonfigurasi parameter percobaan melalui panel admin.
- Layanan split, sesuai dengan parameter ini, mendistribusikan grup A / B yang diperlukan ke perangkat klien.
- Tindakan pengguna dikumpulkan dalam log mentah yang melewati agregasi dan berubah menjadi metrik.
- Metrik dijalankan melalui uji statistik.
- Hasilnya divisualisasikan di portal internal sehari setelah peluncuran.
Semua transportasi data dalam satu siklus membutuhkan waktu satu hari. Sebagai aturan, eksperimen berlangsung seminggu, tetapi pelanggan menerima peningkatan hasil setiap hari.
Sekarang mari selami rinciannya.
Manajemen eksperimen
Panel admin menggunakan format YAML untuk mengkonfigurasi percobaan.
Ini adalah solusi yang nyaman untuk tim kecil: menyelesaikan kapabilitas konfigurasi tanpa front. Menggunakan konfigurasi teks menyederhanakan pekerjaan untuk pengguna: Anda perlu membuat lebih sedikit klik dengan mouse. Solusi serupa digunakan oleh kerangka kerja A / B Airbnb .
Untuk membagi lalu lintas ke dalam kelompok, kami menggunakan teknik hashing garam biasa.
Untuk menghilangkan efek "memori" pengguna, saat memulai percobaan baru, kami melakukan pencampuran tambahan dengan garam kedua:
Prinsip yang sama dijelaskan dalam presentasi Yandex .
Untuk mencegah persimpangan percobaan yang berpotensi berbahaya, kami menggunakan logika yang mirip dengan "lapisan" di Google .
Koleksi metrik
Kami menempatkan log mentah di Vertica dan menggabungkannya ke dalam tabel persiapan dengan struktur:
Pengamatan biasanya penghitung acara sederhana. Pengamatan digunakan sebagai komponen dalam rumus perhitungan metrik.
Rumus untuk menghitung metrik apa pun adalah sebagian kecil, dalam pembilang dan penyebutnya adalah jumlah pengamatan:
Dalam salah satu laporan Yandex, metrik dibagi menjadi dua jenis: oleh pengguna dan Rasio. Ini masuk akal secara bisnis, tetapi dalam infrastruktur lebih mudah untuk mempertimbangkan semua metrik dengan cara yang sama seperti Rasio. Generalisasi ini valid, karena metrik "posyuzerny" jelas direpresentasikan sebagai fraksi:
Kami merangkum pengamatan dalam pembilang dan penyebut metrik dalam dua cara.
Sederhana:
Ini adalah jumlah biasa dari setiap pengamatan: jumlah pencarian, klik pada iklan, dll.
Dan yang lebih rumit:
Sejumlah kunci unik, dalam pengelompokan dimana total pengamatan lebih besar dari ambang yang diberikan.
Rumus seperti itu mudah diatur menggunakan konfigurasi YAML:
Parameter groupby dan threshold adalah opsional. Hanya mereka yang menentukan metode penjumlahan kedua.
Standar yang diuraikan memungkinkan Anda mengonfigurasi hampir semua metrik online yang dapat Anda pikirkan. Pada saat yang sama, logika sederhana dipertahankan yang tidak membebani infrastruktur secara berlebihan.
Kriteria Statistik
Kami mengukur signifikansi penyimpangan dengan metrik menggunakan metode klasik: T-test , Mann-Whitney U-test . Syarat utama yang diperlukan untuk menerapkan kriteria ini adalah bahwa pengamatan dalam sampel tidak boleh saling bergantung. Di hampir semua percobaan kami, kami percaya bahwa pengguna (Uid) memenuhi kondisi ini.
Sekarang muncul pertanyaan: bagaimana melakukan T-test dan MW-test untuk metrik Rasio? Untuk uji-T, Anda harus dapat membaca varians sampel, dan untuk MW, sampel harus “ditentukan pengguna”.
Jawaban: Anda perlu memperluas Rasio dalam seri Taylor ke urutan pertama pada suatu titik :
Rumus ini mengubah dua sampel (pembilang dan penyebut) menjadi satu, mempertahankan mean dan varians (asimtotik), yang memungkinkan penggunaan statistik klasik. tes.
Gagasan serupa disebut oleh rekan kerja Yandex, metode linierisasi Rasio (penampilan satu kali dan dua kali ).
Kinerja penskalaan
Menggunakan cepat untuk stat CPU. kriteria memungkinkan untuk melakukan jutaan iterasi (perbandingan pengobatan vs kontrol) dalam hitungan menit pada server yang sepenuhnya biasa dengan 56 core. Tetapi dalam kasus volume data yang besar, kinerja terletak, pertama-tama, dalam penyimpanan dan waktu baca dari disk.
Perhitungan metrik Uid setiap hari menghasilkan sampel dengan ukuran total ratusan miliar nilai (karena banyaknya eksperimen simultan, ratusan metrik, dan akumulasi kumulatif). Terlalu bermasalah untuk mengeluarkan volume seperti itu dari disk setiap hari (meskipun ada banyak basis kolom Vertica). Karena itu, kami terpaksa mengurangi kardinalitas data. Tapi kami melakukan ini hampir tanpa kehilangan informasi tentang varians menggunakan teknik yang disebut "Bucket".
Idenya sederhana: kita memiliki Uid dan, menurut sisa divisi, “hamburkan” mereka ke dalam sejumlah ember (kami menyatakan nomornya dengan B):
Sekarang kita beralih ke unit eksperimental baru - ember. Kami merangkum pengamatan dalam ember (pembilang dan penyebutnya independen):
Dengan transformasi ini, kondisi independensi pengamatan terpenuhi, nilai metrik tidak berubah, dan mudah untuk memverifikasi bahwa varians metrik (rata-rata di atas sampel pengamatan) dipertahankan:
Semakin banyak ember, semakin sedikit informasi yang hilang, dan semakin kecil kesalahan dalam kesetaraan. Di Avito, kita ambil B = 200.
Kepadatan distribusi metrik setelah konversi bucket selalu menjadi serupa dengan normal.
Sebanyak sampel besar yang Anda inginkan dapat dikurangi menjadi ukuran tetap. Pertumbuhan jumlah data yang disimpan dalam kasus ini hanya secara linear tergantung pada jumlah percobaan dan metrik.
Visualisasi Hasil
Sebagai alat visualisasi, kami menggunakan Tableau dan tampilan web di Tableau Server. Setiap karyawan Avito memiliki akses di sana. Perlu dicatat bahwa Tableau melakukan pekerjaan dengan baik. Untuk mengimplementasikan solusi yang serupa menggunakan pengembangan full back / front akan menjadi tugas yang jauh lebih banyak sumber daya.
Hasil setiap percobaan adalah selembar angka beberapa ribu. Visualisasi harus sedemikian rupa untuk meminimalkan kesimpulan yang salah dalam hal implementasi kesalahan jenis pertama dan kedua , dan pada saat yang sama tidak untuk "kehilangan" perubahan dalam metrik dan bagian penting.
Pertama, kami memantau metrik "kesehatan" percobaan. Yaitu, kami menjawab pertanyaan: "Apakah benar para peserta" dituangkan "ke dalam masing-masing kelompok?", "Apakah itu sama dengan pengguna yang berwenang atau yang baru?"
Dalam kasus penyimpangan yang signifikan secara statistik, sel-sel yang sesuai disorot. Saat Anda mengarahkan kursor ke nomor apa pun, dinamika kumulatif hari itu ditampilkan.
Dasbor utama dengan metrik terlihat seperti ini:
Setiap baris adalah perbandingan grup dengan metrik tertentu di bagian tertentu. Di sebelah kanan adalah panel dengan filter untuk eksperimen dan metrik. Panel filter bagian bawah.
Setiap perbandingan metrik terdiri dari beberapa metrik. Mari menganalisis nilai-nilai mereka dari kiri ke kanan:
1. MDE. Efek Deteksi Minimum
⍺ dan β adalah probabilitas kesalahan yang dipilih sebelumnya dari jenis pertama dan kedua. MDE sangat penting jika perubahannya tidak signifikan secara statistik. Ketika membuat keputusan, pelanggan harus ingat bahwa kurangnya stat. Signifikansi sama saja tidak berpengaruh. Cukup dapat diandalkan, kita hanya bisa mengatakan bahwa efek yang mungkin tidak lebih dari MDE.
2. MW | T. Mann-Whitney Hasil U-dan T-test
Panel menampilkan nilai statistik z dan t (masing-masing untuk MW dan T). Dalam tooltip - dinamika nilai-p. Jika perubahannya signifikan, maka sel disorot dalam warna merah atau hijau, tergantung pada tanda perbedaan antara kelompok. Dalam hal ini, kami katakan bahwa metriknya “berwarna”.
3. Angkat. Persentase perbedaan antar kelompok
4. Berarti | Bil | Den Nilai metrik, serta pembilang dan penyebut secara terpisah
Kami menerapkan uji-T lain untuk pembilang dan penyebut, yang membantu untuk memahami kontribusi siapa yang menentukan.
5. Std. Standar Deviasi Selektif
6. Hist. Shapiro-Wilk menguji normalitas distribusi "bucket".
Jika indikatornya merah, maka mungkin sampel tersebut memiliki outlier atau ekor panjang yang tidak normal. Dalam hal ini, Anda harus mengambil hasilnya sesuai dengan metrik ini dengan cermat, atau tidak sama sekali. Mengklik pada indikator membuka histogram metrik oleh grup. Histogram dengan jelas menunjukkan anomali - lebih mudah untuk menarik kesimpulan.
Kesimpulan
Munculnya platform A / B di Avito adalah titik awal ketika produk kami mulai tumbuh lebih cepat. Setiap hari, kami melakukan percobaan hijau yang membebani tim; dan "merah," yang menyediakan makanan sehat untuk dipikirkan.
Kami berhasil membangun sistem pengujian dan metrik A / B yang efektif. Seringkali kita memecahkan masalah kompleks dengan metode sederhana. Karena kesederhanaan ini, infrastruktur memiliki margin keselamatan yang baik.
Saya yakin mereka yang akan membangun platform A / B di perusahaan mereka menemukan beberapa wawasan menarik dalam artikel tersebut. Saya senang berbagi pengalaman kami dengan Anda.
Tulis pertanyaan dan komentar - kami akan mencoba menjawabnya.