Penting bagi kita untuk memahami apa yang terjadi pada siswa kita selama pelatihan, dan bagaimana peristiwa ini mempengaruhi hasilnya, jadi kita membangun Peta Perjalanan Pelanggan - peta pengalaman pelanggan. Bagaimanapun, proses pembelajaran bukanlah sesuatu yang berkelanjutan dan integral, itu adalah rangkaian peristiwa yang saling terkait dan tindakan siswa, dan tindakan ini dapat sangat bervariasi di antara siswa yang berbeda. Jadi dia mengikuti pelajaran: apa yang akan dia lakukan selanjutnya? Pergi ke pekerjaan rumah? Luncurkan aplikasi seluler? Ganti kursus, minta ganti guru? Langsung ke pelajaran selanjutnya? Atau tinggalkan saja kecewa? Apakah mungkin, dengan menganalisis kartu ini, untuk mengidentifikasi pola-pola yang mengarah pada keberhasilan penyelesaian kursus, atau sebaliknya, "roll-off" siswa?
Biasanya, sumber khusus, sangat mahal, alat sumber tertutup digunakan untuk membangun CJM. Tetapi kami ingin membuat sesuatu yang sederhana, membutuhkan upaya minimal dan mungkin open source. Jadi muncul ide untuk menggunakan rantai Markov - dan kami berhasil. Kami membangun peta, menafsirkan data perilaku siswa sebagai grafik, melihat jawaban yang sama sekali tidak jelas untuk pertanyaan bisnis global, dan bahkan menemukan bug yang sangat tersembunyi. Kami melakukan semua ini dengan bantuan solusi skrip Python open source. Pada artikel ini saya akan berbicara tentang dua kasus dengan hasil yang sangat tidak jelas dan berbagi skrip dengan semua orang.
Jadi, rantai Markov menunjukkan probabilitas transisi antar peristiwa. Berikut ini adalah contoh Wikipedia primitif:
Di sini, "E" dan "A" adalah peristiwa, panah adalah transisi di antara mereka (termasuk transisi dari suatu peristiwa ke sana), dan bobot panah adalah probabilitas transisi ("grafik berorientasi tertimbang").
Apa yang digunakan
Rantai dilatih oleh fungsionalitas Python standar, yang diumpankan oleh log aktivitas siswa. Grafik pada matriks yang dihasilkan dibangun oleh perpustakaan NetworkX.
Log terlihat seperti ini:
Ini adalah file csv yang berisi tabel tiga kolom: id siswa, nama acara, waktu ketika itu terjadi. Tiga bidang ini cukup untuk melacak pergerakan klien, membangun peta dan akhirnya mendapatkan rantai Markov.
Perpustakaan mengembalikan grafik yang dibuat dalam format .dot atau .gexf. Untuk memvisualisasikan yang pertama, Anda dapat menggunakan paket Graphviz gratis (alat gvedit), kami bekerja dengan .gexf dan Gephi, juga gratis.
Selanjutnya, saya ingin memberikan dua contoh penggunaan rantai Markov, yang memungkinkan kami untuk melihat dengan segar tujuan kami, proses pendidikan dan ekosistem Skyeng itu sendiri. Nah, perbaiki bug.
Kasus Pertama: Aplikasi Seluler
Untuk memulainya, kami menjelajahi jalur siswa melalui produk kami yang paling populer, Jenderal. Pada saat itu, saya bekerja di Departemen Anak Skyeng dan kami ingin melihat seberapa efisien aplikasi seluler bekerja dengan audiens anak-anak kami.
Mengambil log dan menjalankannya melalui skrip, saya mendapatkan sesuatu seperti ini:
Simpul awal adalah Mulai Umum, dan di bawah ini adalah tiga simpul keluaran: siswa “tertidur”, mengubah arah, menyelesaikan kursus.
- Jatuh tertidur, "Jatuh tertidur" - itu berarti bahwa kelas tidak lagi terjadi, kemungkinan besar, dia jatuh. Kami optimis menyebut kondisi ini "tertidur", karena secara teori, ia masih memiliki kesempatan untuk melanjutkan studinya. Hasil terburuk bagi kami.
- Turun jenderal, Kursus berubah - beralih dari Jenderal ke yang lain dan tersesat untuk rantai Markov kami.
- Selesai kursus, saya lulus dari kursus - kondisi sempurna, orang tersebut telah menyelesaikan 80% dari pelajaran (tidak semua pelajaran diperlukan).
Masuk ke simpul kelas yang berhasil berarti berhasil menyelesaikan pelajaran di platform kami dengan guru. Ini menangkap kemajuan kursus dan perkiraan untuk hasil yang diinginkan - "Selesai kursus." Penting bagi kami agar siswa menghadirinya sebanyak mungkin.
Untuk mendapatkan kesimpulan kuantitatif yang lebih akurat untuk aplikasi seluler (simpul sesi aplikasi), kami membuat rantai terpisah untuk masing-masing simpul akhir dan kemudian membandingkan bobot tepi berpasangan:
- dari sesi aplikasi kembali ke sana;
- dari sesi aplikasi ke kelas yang sukses;
- dari kelas yang sukses ke sesi aplikasi.
Di sebelah kiri - siswa yang menyelesaikan kursus, di sebelah kanan - "tertidur"Tiga tulang rusuk ini menunjukkan hubungan antara keberhasilan siswa dan penggunaan aplikasi mobile mereka. Kami berharap melihat bahwa siswa yang menyelesaikan kursus akan memiliki koneksi yang lebih kuat dengan aplikasi daripada mereka yang “tertidur”. Namun, pada kenyataannya, mereka menerima hasil yang sebaliknya:
- kami memastikan bahwa berbagai kelompok pengguna berinteraksi secara berbeda dengan aplikasi seluler;
- siswa yang berhasil menggunakan aplikasi seluler kurang intensif;
- siswa yang tertidur lebih aktif menggunakan aplikasi mobile.
Ini berarti bahwa siswa "tertidur" mulai menghabiskan lebih banyak waktu dalam aplikasi mobile dan, pada akhirnya, tetap di dalamnya selamanya.
Awalnya kami terkejut, tetapi, setelah berpikir, kami menyadari bahwa ini adalah efek yang sepenuhnya alami. Pada suatu waktu, saya belajar bahasa Prancis secara mandiri menggunakan dua alat: aplikasi seluler dan kuliah tentang tata bahasa di YouTube. Pada awalnya, saya membagi waktu di antara mereka dalam proporsi 50 hingga 50. Tetapi aplikasinya lebih menyenangkan, ada gamifikasi, semuanya sederhana, cepat dan mudah dimengerti, tetapi Anda perlu mempelajari kuliah, menulis sesuatu, berlatih di buku catatan. Berangsur-angsur, saya mulai menghabiskan lebih banyak waktu pada smartphone sampai bagiannya tumbuh hingga 100%: jika hang selama tiga jam, itu menciptakan rasa kerja yang salah, karena tidak ada keinginan untuk pergi dan mendengarkan sesuatu.
Tapi bagaimana caranya? Lagipula, kami secara khusus membuat aplikasi seluler, yang
dibangun di kurva Ebbinghaus , membuatnya menjadi menarik, sehingga orang-orang menghabiskan waktu di dalamnya, tetapi ternyata itu hanya mengalihkan perhatian mereka? Faktanya, alasannya adalah bahwa tim aplikasi seluler melakukan tugasnya dengan sangat baik, sebagai akibatnya ia menjadi produk mandiri yang keren dan mulai rontok dari ekosistem kita.
Sebagai hasil dari penelitian ini, dapat dipahami bahwa aplikasi mobile perlu diubah sehingga kurang menarik dari program studi utama. Apalagi anak-anak dan orang dewasa. Sekarang pekerjaan ini sedang berlangsung.
Kasus Dua: Bug Onboarding
Onboarding adalah prosedur tambahan opsional saat mendaftarkan siswa baru, menghilangkan potensi masalah teknis di masa depan. Skenario dasar menyiratkan bahwa seseorang terdaftar di halaman arahan, mendapat akses ke akun pribadinya, mereka menghubunginya dan melakukan pelajaran pengantar. Pada saat yang sama, kami mencatat sejumlah besar kesulitan teknis selama pelajaran pengantar: versi browser yang salah, mikrofon atau suara tidak berfungsi, guru tidak dapat langsung menyarankan solusi, dan semua ini sangat sulit ketika menyangkut anak-anak. Karena itu, kami mengembangkan aplikasi tambahan di akun Anda, di mana Anda dapat melakukan empat langkah sederhana: periksa browser Anda, kamera, mikrofon dan konfirmasi bahwa orang tua akan ada di sana selama pelajaran pengantar (setelah semua, mereka membayar untuk pendidikan anak-anak).
Beberapa halaman orientasi ini menunjukkan corong ini:
1: mulai blokir dengan tiga bentuk entri login / kata sandi yang sedikit berbeda (tergantung pada klien).
2: Gagak menyetujui prosedur tambahan untuk orientasi penerbangan.
2.1-2.3: memeriksa keberadaan induk, versi Chrome dan suara.
3: blok terakhir.Itu terlihat sangat alami: pada dua langkah pertama, sebagian besar pengunjung bergabung, menyadari bahwa ada sesuatu untuk diisi, periksa, tetapi tidak ada waktu. Jika klien telah mencapai langkah ketiga, maka ia hampir pasti akan mencapai final. Tidak ada satu pun alasan yang terlihat di corong untuk mencurigai sesuatu.
Namun demikian, kami memutuskan untuk menganalisis orientasi kami bukan pada corong satu dimensi yang klasik, tetapi menggunakan rantai Markov. Kami menyalakan beberapa acara lagi, menjalankan skrip dan mendapatkan ini:
Hanya ada satu hal yang dapat dipahami dengan jelas dalam kekacauan ini: ada sesuatu yang salah. Proses orientasi adalah linier, melekat dalam desain, seharusnya tidak memiliki jaringan tautan seperti itu. Dan di sini Anda dapat segera melihat bahwa pengguna melakukan langkah-langkah, di antaranya tidak boleh ada transisi sama sekali.
Mungkin ada dua alasan untuk gambaran aneh seperti ini:
- tiang tembok merayap ke dasar log;
- Shoals hadir dalam produk itu sendiri - onboarding.
Alasan pertama, kemungkinan besar, memang terjadi, tetapi memeriksanya agak memakan waktu, dan memperbaiki log tidak akan membantu meningkatkan UX. Tetapi dengan yang kedua, jika ada, mendesak untuk melakukan sesuatu. Oleh karena itu, kami pergi untuk memeriksa node, mengidentifikasi ujung-ujungnya, yang seharusnya tidak, mencari penyebab terjadinya mereka. Kami melihat bahwa beberapa pengguna berputar-putar dan berjalan berputar-putar, yang lain terjatuh dari tengah ke awal, dan yang ketiga, pada prinsipnya, tidak bisa keluar dari dua langkah pertama. Data ditransfer ke QA - dan ya, ternyata ada cukup bug di dalam kapal: ini adalah produk sampingan, sedikit produk kruk, belum diuji cukup dalam, karena tidak mengharapkan masalah. Sekarang seluruh proses perekaman telah berubah.
Kisah ini menunjukkan kepada kita aplikasi tak terduga rantai Markov di bidang QA.
Coba sendiri!
Saya memposting
skrip Python untuk mempelajari rantai Markov di domain publik - gunakan untuk kesehatan. Dokumentasi tentang GitHub, pertanyaan dapat diajukan di sini, saya akan mencoba menjawab semuanya.
Tautan yang baik dan bermanfaat:
Pustaka NetworkX ,
Visualizer Graphviz . Dan di sini,
di Habré ada artikel tentang rantai Markov. Grafik dalam artikel dibuat menggunakan
Gephi .