Halo semuanya, kami baru-baru ini
menulis tentang bagaimana kami belajar menjadi Data Driven dengan GoPractice Simulator! Dalam edisi ini kami akan melanjutkan topik analisis data dan berbicara tentang membangun proses bekerja dengan analitik dalam tim Plesk.
Plesk adalah produk kompleks dengan latar belakang 20 tahun dan kami tidak selalu dapat secara efektif mengumpulkan statistik yang diperlukan. Untuk waktu yang lama, kami melihat data hanya dalam retrospeksi, dan keputusan dibuat berdasarkan sensasi subyektif "sebagaimana mestinya". Di masa lalu, kami sudah memiliki konsekuensi yang menyedihkan dari pendekatan ini - pada tahun 2012, kami mengubah desain, ingin melakukan yang terbaik, tetapi menerima gelombang umpan balik negatif, penolakan untuk memperbarui ke versi terbaru dari produk dan arus keluar pelanggan.
Setelah memahami pengalaman menyedihkan ini, kami membuat kesimpulan dan memutuskan untuk bergerak ke arah pendirian perusahaan Data Driven. Dalam perjalanan ini, berbagai kesulitan dari sifat yang berbeda menunggu kita. Dalam skala besar, mereka dapat dibagi menjadi dua kelompok utama - sistem dan proses, dan dalam artikel ini saya akan fokus pada tugas membangun proses bekerja dengan analitik.
Masalah sistemik yang terkait dengan spesifikasi produk kotak layak mendapatkan artikel terpisah, jadi saya tidak akan membahasnya secara terperinci, saya hanya akan mencantumkan yang paling signifikan.
- Banyak acara, volume penggunaan yang tinggi. Jika kami hanya berbicara tentang melacak tindakan pengguna di panel, menurut perhitungan kami, ini adalah 60 juta acara per bulan, dan sangat disayangkan untuk memberikan $ 150k untuk Advanced Google Analytics. Kesulitan lain adalah bahwa agar dapat bekerja dengan GA, Anda perlu memproses setiap tindakan khusus secara eksplisit, tetapi kami ingin mendapatkan mekanisme terpadu yang tidak memerlukan penandaan acara atau tindakan untuk setiap fitur baru secara manual.
- Karena volume dan format kotak (menjalankan perubahan apa pun membutuhkan waktu), analytics tidak dapat melakukan waktu nyata. Pengguna duduk di 8 versi produk yang berbeda, dengan 4 di antaranya sudah DIMULAI. Bahkan pada versi terbaru, hanya 60% pengguna yang melakukan perubahan baru dalam dua minggu pertama setelah rilis.
- Produk yang kompleks. Plesk mendukung 14 sistem operasi keluarga Linux, 4 OC Windows, 150 komponen pihak ketiga, beberapa server web, server mail, klien webmail, visualisator statistik, solusi antivirus, dll. Sejumlah besar kemungkinan konfigurasi terutama memengaruhi kerumitan dan volume pengujian dan membuatnya hampir mustahil untuk menggunakan uji A / B.
- Spesifikasi B2B2C. Pembuat keputusan tidak selalu sama dengan "pengguna sebenarnya dari panel".
- GDPR - kebutuhan untuk mematuhi surat hukum memerlukan upaya tambahan untuk menganonimkan data dan mempersulit tugas segmentasi pengguna, dan juga menghalangi kita untuk dengan mudah dan cepat menghubungi pelanggan menggunakan informasi kontak mereka.
Kami akan berbicara tentang nyeri proses secara lebih rinci. Sampai baru-baru ini, proses pengumpulan analitik bersama kami benar-benar terpisah dari proses pengembangan - kami ingat pelacakan dan metrik pada akhirnya, mengacaukan solusi satu kali, dan seterusnya hingga fitur berikutnya. Selain itu, selama bertahun-tahun, Plesk telah mengakumulasikan banyak sumber data - yang memerlukan biaya untuk mempertahankan konsistensi, relevansi data, kebutuhan untuk mengingat dari mana asalnya, dalam kondisi apa yang didapat ke database dan mengapa metrik yang sama di tempat yang berbeda berbeda (misalnya, jumlah kunci lisensi dan instalasi fisik). Banyak informasi ditulis ke sumber-sumber ini (potongan bulanan dari basis data 270 ribu kunci dan laporan datang dua kali lebih sering dari 300 ribu server), tetapi hanya beberapa orang yang dapat bekerja dengan data ini dan menemukan waktu. Saya datang ke Plesk pada 2015, dan tugas pertama saya hanyalah mendapatkan statistik yang heterogen dari kubus OLAP dan database MongoDB. 'How To' ke database ini adalah halaman dengan nama pengguna dan kata sandi dari host dan file teks dengan skrip js dari permintaan populer terakhir.
Banyak sumber berarti banyak alat dan layanan, yang masing-masing dapat digunakan oleh Manajer Program. Perasaan di hari-hari awal kerja adalah sesuatu seperti ini:
Apa yang telah kita lakukan
Solusinya adalah sebagai berikut: sekitar satu setengah tahun yang lalu, kami mulai merombak total proses pengumpulan data - sekarang kami mengembangkan analitik dengan cara yang sama seperti fitur itu sendiri, pada setiap tahap seluruh tim (awak fitur) terlibat, mulai dari PM dan pengembangan hingga insinyur QA.
Hipotesis
Semuanya dimulai pada tahap perencanaan fitur: PM merumuskan hipotesis berdasarkan metrik yang akan dipilih pada langkah berikutnya. Misalnya: Plesk memiliki sistem rekomendasi Penasihat yang membantu pengguna meningkatkan keadaan server dengan mengikuti langkah-langkah yang diusulkan (tambahkan sertifikat ssl, aktifkan pembaruan, perbarui versi PHP, dll.). Dengan melepaskan Penasihat, kami menganggap bahwa pengguna akan mengikuti rekomendasi, peringkat "kesehatan" server akan meningkat, dan berkat "pencapaian" tervirtualisasi, pengguna akan terlibat dalam interaksi dengan Penasihat secara berkelanjutan.
Metrik
Pada langkah berikutnya, metrik dipilih untuk setiap hipotesis: untuk Penasihat, ini adalah jumlah klik-tayang dalam rekomendasi, persentase situs yang dilindungi oleh sertifikat, skor penilaian, dll. Semua informasi ini (hipotesis + metrik) dimasukkan dalam dokumen Visi dengan persyaratan fitur. Pada titik ini, analis data terlibat dalam proses - tugas mereka adalah membantu membuat metrik terukur, mudah dikumpulkan dan tidak ambigu. Bahkan detail seperti struktur bidang masa depan dalam database atau laporan penting - karena PM yang bertanggung jawab atas fitur ini akan paling sering mengakses informasi ini, adalah kepentingannya untuk menentukan bagaimana lebih mudah untuk melakukan ini, hingga ke struktur permintaan database yang diinginkan. Berkat pendekatan ini, omong-omong, menjadi lebih mudah bagi semua orang dalam arti bahwa kebutuhan untuk naik ke 100.500 sumber telah berkurang secara signifikan - sekarang Anda memutuskan dalam format mana data akan dikumpulkan dan bagaimana Anda memilih untuk mendapatkannya. Dengan memperbaiki logika penghitungan dalam tampilan, PM juga mendapat kesempatan kapan saja untuk kembali ke dokumen dan mengingat dengan kriteria apa database masuk / meningkatkan penghitung / fakta pengiriman, dll. Ini memecahkan masalah memahami logika laporan.
Implementasi
Ketika hipotesis dirumuskan dan metrik dipilih, itu adalah giliran implementasi. Pengembang mengimplementasikan sekaligus fitur itu sendiri dan mekanisme untuk mengumpulkan statistiknya. Seperti yang telah disebutkan, penggunaan solusi siap pakai seperti GA sulit bagi kami karena berbagai alasan, oleh karena itu, 2 tahun yang lalu, teknisi kami menerapkan mekanisme mereka sendiri untuk melacak tindakan pengguna di panel. Selain tindakan pengguna, berbagai detail teknis, pengaturan konfigurasi, dll. Juga dapat menarik. - semua ini dikirim ke database MongoDB yang telah disebutkan.
Pengujian dan pratinjau
Seperti produk apa pun, mekanisme pengumpulan data harus diuji - dalam kasus kami, insinyur QA memeriksa apakah rekomendasi ditampilkan dan dibuka, peringkatnya dipantau, dan informasi tentang semua peristiwa ini dikumpulkan dalam database. Seringkali, kasus penggunaan yang dipilih untuk pelacakan dan analisis menjadi kasus uji baru untuk menguji fungsionalitas fitur itu sendiri.
Setelah insinyur QA memeriksa semua skenario, PM bersama-sama dengan pengembang melihat data pertama dan memastikan bahwa fitur 1) tidak merusak apa pun dan 2) berfungsi seperti yang diharapkan, dan statistik mengumpulkan minatnya - semuanya siap untuk dirilis di lepaskan.
Kehidupan fitur
Ketika sebuah fitur diluncurkan dalam rilis, bagian yang paling menarik dimulai - "nyawanya" dalam produk. Tidak perlu lagi melempar: “apakah Anda tahu bidang mana dalam basis data kami yang menyimpan informasi tentang menunjukkan rekomendasi? tidak blin ... ". Analis data tidak menerima pesan dalam slack: "dapatkah Anda menghitung lagi berapa banyak tayangan pada versi terbaru?" - untuk ini ada grafik di dasbor dengan peringatan yang dikonfigurasi yang mengirim surat jika nilai yang dipantau turun tajam / meningkat / diubah / tidak ada catatan ditemukan dalam database. Tapi itu belum semuanya. Memahami bahwa penghitung telah meningkat atau turun n% tidak selalu cukup untuk mengatakan dengan keyakinan bahwa ini adalah perubahan yang signifikan, dan bukan lompatan musiman atau fluktuasi dalam margin of error. Salah satu anggota tim kami sedang mengembangkan kerangka kerja untuk mengukur signifikansi statistik dari perubahan metrik. Dengan menggunakan alat statistik matematika, ia menghitung sampel minimum (jumlah pengguna / instalasi / peristiwa) yang diperlukan untuk menilai signifikansi perubahan, memilih segmen di mana Anda dapat membandingkan dan menentukan interval kepercayaan yang kemungkinan besar berisi nilai nyata dari metrik minat kepada kami. Kerangka kerja ini sudah diuji dan memberikan hasil yang menarik minggu lalu: kami mengetahui bahwa setelah kami mulai menunjukkan harga dalam katalog ekstensi di dalam panel Plesk, orang-orang mulai membeli kunci lisensi yang lebih sedikit tahunan dan lebih sering bulanan untuk produk-produk ini. Saat ini, kolega kami menghitung perkiraan LTV, setelah itu akan menjadi jelas bahwa perubahan ini bagi kami dalam jangka panjang dan opsi apa yang harus kami promosikan dalam logika menunjukkan harga.
Pengakhiran dukungan
Hasil dari kehidupan setiap produk atau fitur adalah penghentian dukungannya dalam hal itu karena kurangnya permintaan atau alasan lain (misalnya, pertimbangan keamanan dalam hal penghentian dukungan untuk sistem operasi yang ketinggalan jaman atau versi PHP). Di sini, analytics juga membantu kami: misalnya, ketika kami memutuskan untuk mendorong pengguna untuk beralih ke versi baru PHP, hal pertama yang kami lakukan adalah mengumpulkan statistik penggunaan versi di antara pengguna Plesk. Kami mengetahui bahwa persentase menggunakan PHP 7 hanya mencapai 20% pengguna dan menyadari bahwa potensi biaya pengalihan paksa dalam bentuk jutaan situs yang rusak lebih besar daripada risiko kemungkinan kerentanan versi lama. Akibatnya, kami memutuskan untuk mengukur pengaruh yang lebih ringan dan mulai dengan pemberitahuan tentang keinginan peningkatan di panel. Contoh lain dapat berupa banyak cerita dengan penghentian dukungan untuk sistem operasi - dalam kasus ketika kami menemukan bahwa salah satu klien terbesar dengan puluhan ribu instalasi Plesk menggunakan OS tertentu, kami menargetkan berkomunikasi dengan mitra ini dan, dalam kasus ketidakmungkinan transisi cepat, menawarinya yang disebut lazy drop - penghentian dukungan untuk instalasi baru dan kemampuan untuk terus bekerja pada yang sudah ada setelah memutakhirkan ke versi terbaru Plesk.
Kesimpulan
Untuk meringkas, saya ingin sekali lagi menyuarakan apa yang kami anggap paling penting - sekarang bekerja dengan analitik untuk kami adalah bagian integral dari bekerja pada setiap fitur. Tetapi proses yang dibangun bukanlah akhir. Dari pengalaman kami sendiri, kami yakin bahwa kontrol kualitas data tidak kalah pentingnya dengan proses itu sendiri. Semuanya tidak masuk akal jika pada setiap tahap pengumpulan data hilang atau terdistorsi. Untuk mencegah hal ini terjadi, pada setiap tahap kami berusaha menambahkan pemeriksaan untuk kelengkapan dan kebenaran data, serta mencatat setiap langkah pemrosesan.
Dan yang terakhir. Jangan menimbang diri Anda dengan metrik hanya karena Anda :) dapat dengan jelas menyatakan apa informasi ini untuk Anda, dan ketika diterima, tanyakan pada diri Anda apakah itu membawa kesimpulan yang mengarah pada tindakan. Bagaimanapun, memahami apa yang harus dilakukan adalah persis seperti apa semua itu dimulai :)