Ada ratusan artikel di Internet tentang manfaat menganalisis perilaku pelanggan. Paling sering ini menyangkut sektor ritel. Dari analisis keranjang makanan, analisis ABC dan XYZ hingga pemasaran retensi dan penawaran pribadi. Berbagai teknik telah digunakan selama beberapa dekade, algoritma telah dipikirkan, kode telah ditulis dan di-debug - ambil dan gunakan. Dalam kasus kami, satu masalah mendasar muncul - kami di ISPsystem terlibat dalam pengembangan perangkat lunak, bukan ritel.
Nama saya Denis dan saat ini saya bertanggung jawab atas backend sistem analitik di ISPsystem. Dan ini adalah kisah tentang bagaimana saya dan rekan saya — mereka yang bertanggung jawab atas visualisasi data — mencoba melihat produk perangkat lunak kami melalui prisma pengetahuan ini. Mari kita mulai, seperti biasa, dengan sejarah.
Pada awalnya ada sebuah kata, dan kata itu adalah “Bagaimana kalau kita mencoba?”
Saat itu saya bekerja sebagai pengembang di departemen R&D. Semuanya bermula ketika Danil membaca di sini di Habré — alat untuk menganalisis transisi pengguna dalam aplikasi. Saya agak skeptis dengan gagasan menggunakannya di sini. Sebagai contoh, pengembang perpustakaan mengutip analisis aplikasi yang target tindakannya didefinisikan dengan jelas - melakukan pemesanan atau variasi lain tentang cara membayar perusahaan pemilik. Produk kami dipasok di tempat. Artinya, pengguna terlebih dahulu membeli lisensi, dan baru kemudian memulai perjalanannya dalam aplikasi. Ya, kami memiliki versi demo. Anda dapat mencoba produknya di sana sehingga Anda tidak akan mendapat masalah.
Namun sebagian besar produk kami ditujukan untuk pasar hosting. Ini adalah klien besar, dan departemen pengembangan bisnis memberi saran kepada mereka mengenai kemampuan produk. Oleh karena itu, pada saat pembelian, pelanggan kami sudah mengetahui masalah apa yang dapat dipecahkan oleh perangkat lunak kami. Rute mereka dalam aplikasi harus sesuai dengan CJM yang tertanam dalam produk, dan solusi UX akan membantu mereka tetap berada di jalur yang benar. Spoiler: ini tidak selalu terjadi. Pengenalan perpustakaan ditunda... tapi tidak lama.
Semuanya berubah dengan dirilisnya startup kami - — platform untuk membuat toko online dari akun Instagram. Dalam aplikasi ini, pengguna diberi waktu dua minggu untuk menggunakan semua fungsi secara gratis. Kemudian Anda harus memutuskan apakah akan berlangganan. Dan ini sangat cocok dengan konsep “tindakan sasaran rute”. Diputuskan: ayo coba!
Hasil pertama atau dari mana mendapatkan ide
Saya dan tim pengembangan menghubungkan produk ke sistem pengumpulan acara hanya dalam sehari. Saya akan segera mengatakan bahwa sistem ISP menggunakan sistemnya sendiri untuk mengumpulkan peristiwa tentang kunjungan halaman, tetapi tidak ada yang menghalangi Anda menggunakan Yandex.Metrica untuk tujuan yang sama, yang memungkinkan Anda mengunduh data mentah secara gratis. Contoh penggunaan perpustakaan telah dipelajari, dan setelah seminggu pengumpulan data, kami menerima grafik transisi.
Grafik transisi. Fungsionalitas dasar, transisi lain dihapus untuk kejelasan
Ternyata persis seperti di contoh: datar, jernih, indah. Dari grafik ini, kami dapat mengidentifikasi rute dan penyeberangan yang paling sering dilalui orang-orang yang menghabiskan waktu paling lama. Hal ini memungkinkan kami untuk memahami hal-hal berikut:
- Alih-alih CJM besar, yang mencakup selusin entitas, hanya dua yang digunakan secara aktif. Penting juga untuk mengarahkan pengguna ke tempat-tempat yang kita perlukan menggunakan solusi UX.
- Beberapa halaman, yang dirancang oleh desainer UX secara end-to-end, berakhir dengan orang-orang menghabiskan banyak waktu pada halaman tersebut. Anda perlu mencari tahu elemen penghentian pada halaman tertentu dan menyesuaikannya.
- Setelah 10 transisi, 20% orang mulai lelah dan keluar dari sesi aplikasi. Dan ini memperhitungkan fakta bahwa kami memiliki sebanyak 5 halaman orientasi dalam aplikasi! Anda perlu mengidentifikasi halaman tempat pengguna secara teratur meninggalkan sesi dan memperpendek jalur ke sesi tersebut. Lebih baik lagi: identifikasi rute reguler dan izinkan transisi cepat dari halaman sumber ke halaman tujuan. Ada kesamaan dengan analisis ABC dan analisis keranjang yang ditinggalkan, bukan?
Dan di sini kami mempertimbangkan kembali sikap kami terhadap penerapan alat ini untuk produk lokal. Diputuskan untuk menganalisis produk yang dijual dan digunakan secara aktif - . Ini jauh lebih kompleks, ada urutan besarnya lebih banyak entitas. Kami sangat menantikan untuk melihat seperti apa grafik transisinya.
Tentang kekecewaan dan inspirasi
Kekecewaan #1
Saat itu adalah akhir hari kerja, akhir bulan dan akhir tahun pada waktu yang sama - 27 Desember. Data telah terakumulasi, pertanyaan telah ditulis. Tinggal beberapa detik lagi sebelum semuanya diproses dan kami bisa melihat hasil jerih payah kami untuk mengetahui di mana tahun kerja berikutnya akan dimulai. Departemen R&D, manajer produk, desainer UX, pemimpin tim, pengembang berkumpul di depan monitor untuk melihat seperti apa jalur pengguna di produk mereka, tapi... kami melihat ini:
Grafik transisi dibuat oleh perpustakaan Retentioneering
Inspirasi #1
Sangat terhubung, lusinan entitas, skenario yang tidak jelas. Jelas bahwa tahun kerja baru tidak akan dimulai dengan analisis, tetapi dengan penemuan cara untuk menyederhanakan pekerjaan dengan grafik seperti itu. Namun saya tidak dapat menghilangkan perasaan bahwa segala sesuatunya jauh lebih sederhana dari yang terlihat. Dan setelah lima belas menit mempelajari kode sumber Retentioneering, kami dapat mengekspor grafik yang dibuat ke format titik. Hal ini memungkinkan untuk mengunggah grafik ke alat lain - Gephi. Dan sudah ada ruang untuk menganalisis grafik: tata letak, filter, statistik - yang perlu Anda lakukan hanyalah mengonfigurasi parameter yang diperlukan di antarmuka. Dengan pemikiran ini, kami berangkat untuk akhir pekan Tahun Baru.
Kekecewaan #2
Setelah kembali bekerja, ternyata saat semua orang sedang istirahat, klien kami sedang mempelajari produk tersebut. Ya, saking kerasnya hingga muncul kejadian di penyimpanan yang sebelumnya tidak ada. Ini berarti bahwa pertanyaan perlu diperbarui.
Sedikit latar belakang untuk memahami kesedihan dari fakta ini. Kami mengirimkan peristiwa yang telah kami tandai (misalnya, klik pada beberapa tombol) dan URL halaman yang dikunjungi pengguna. Dalam kasus Cartbee, model “satu tindakan - satu halaman” berhasil. Tetapi dengan VMmanager situasinya benar-benar berbeda: beberapa jendela modal dapat dibuka pada satu halaman. Di dalamnya pengguna dapat memecahkan berbagai masalah. Misalnya, URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
artinya pada halaman “Alamat IP” pengguna menambahkan alamat IP. Dan di sini dua masalah terlihat sekaligus:
- URL berisi beberapa jenis parameter jalur - ID mesin virtual. Hal ini perlu dikecualikan.
- URL berisi ID jendela modal. Anda perlu “membongkar” URL tersebut.
Masalah lainnya adalah peristiwa yang kami tandai memiliki parameter. Misalnya, ada lima cara berbeda untuk membuka halaman berisi informasi tentang mesin virtual dari daftar. Oleh karena itu, satu peristiwa dikirim, tetapi dengan parameter yang menunjukkan metode mana yang digunakan pengguna untuk melakukan transisi. Ada banyak peristiwa seperti itu, dan semua parameternya berbeda. Dan kami memiliki semua logika pengambilan data dalam dialek SQL untuk Clickhouse. Kueri untuk 150-200 baris mulai terasa familier. Masalah mengelilingi kita.
Inspirasi #2
Suatu pagi, Danil, dengan sedih menelusuri permintaan untuk menit kedua, menyarankan kepada saya: “Mari kita menulis jalur pemrosesan data?” Kami memikirkannya dan memutuskan bahwa jika kami akan melakukannya, itu akan menjadi seperti ETL. Sehingga segera memfilter dan mengambil data yang diperlukan dari sumber lain. Ini adalah bagaimana layanan analitis pertama kami dengan backend lengkap lahir. Ini menerapkan lima tahap utama pemrosesan data:
- Membongkar peristiwa dari penyimpanan data mentah dan mempersiapkannya untuk diproses.
- Klarifikasi adalah "membongkar" pengidentifikasi jendela modal, parameter peristiwa, dan detail lain yang memperjelas peristiwa tersebut.
- Pengayaan (dari kata “menjadi kaya”) adalah penambahan peristiwa dengan data dari sumber pihak ketiga. Pada saat itu, ini hanya mencakup BILLmanager sistem penagihan kami.
- Penyaringan adalah proses menyaring peristiwa-peristiwa yang mendistorsi hasil analisis (peristiwa dari stand internal, outlier, dll).
- Mengunggah peristiwa yang diterima ke dalam penyimpanan, yang kami sebut data bersih.
Sekarang dimungkinkan untuk mempertahankan relevansi dengan menambahkan aturan untuk memproses suatu peristiwa atau bahkan kelompok peristiwa serupa. Misalnya, sejak itu kami tidak pernah memperbarui URL unpacking. Meskipun demikian, selama ini beberapa variasi URL baru telah ditambahkan. Mereka mematuhi aturan yang telah ditetapkan dalam layanan dan diproses dengan benar.
Kekecewaan #3
Setelah kami mulai menganalisis, kami menyadari mengapa grafiknya sangat koheren. Faktanya adalah hampir setiap N-gram berisi transisi yang tidak dapat dilakukan melalui antarmuka.
Investigasi kecil dimulai. Saya bingung karena tidak ada transisi yang mustahil dalam satu entitas. Artinya ini bukan bug pada sistem pengumpulan event atau layanan ETL kami. Ada perasaan bahwa pengguna secara bersamaan bekerja di beberapa entitas, tanpa berpindah dari satu entitas ke entitas lainnya. Bagaimana cara mencapainya? Menggunakan tab berbeda di browser.
Saat menganalisis Cartbee, kami terselamatkan oleh kekhususannya. Aplikasi ini digunakan dari perangkat seluler, di mana bekerja dari beberapa tab tidak nyaman. Di sini kita memiliki desktop dan saat tugas sedang dilakukan di satu entitas, masuk akal jika kita ingin menghabiskan waktu ini untuk menyiapkan atau memantau status di entitas lain. Dan agar tidak kehilangan progres, buka saja tab lain.
Inspirasi #3
Rekan-rekan dari pengembangan front-end mengajarkan sistem pengumpulan acara untuk membedakan tab. Analisisnya bisa dimulai. Dan kami mulai. Seperti yang diharapkan, CJM tidak cocok dengan jalur sebenarnya: pengguna menghabiskan banyak waktu di halaman direktori, meninggalkan sesi dan tab di tempat yang paling tidak terduga. Dengan menggunakan analisis transisi, kami dapat menemukan masalah di beberapa versi Mozilla. Di dalamnya, karena fitur implementasi, elemen navigasi menghilang atau halaman setengah kosong ditampilkan, yang seharusnya hanya dapat diakses oleh administrator. Halaman terbuka, tetapi tidak ada konten yang keluar dari backend. Penghitungan transisi memungkinkan untuk mengevaluasi fitur mana yang sebenarnya digunakan. Rantai memungkinkan untuk memahami bagaimana pengguna menerima kesalahan tertentu. Data diizinkan untuk pengujian berdasarkan perilaku pengguna. Sukses, idenya tidak sia-sia.
Otomatisasi analitik
Dalam salah satu demonstrasi hasil, kami menunjukkan bagaimana Gephi digunakan untuk analisis grafik. Pada alat ini, data konversi dapat ditampilkan dalam bentuk tabel. Dan kepala departemen UX mengatakan satu pemikiran yang sangat penting yang memengaruhi pengembangan seluruh arah analisis perilaku di perusahaan: “Mari kita lakukan hal yang sama, tetapi di Tableau dan dengan filter - akan lebih nyaman.”
Lalu saya berpikir: kenapa tidak, Retentioneering menyimpan semua data dalam struktur pandas.DataFrame. Dan ini, pada umumnya, adalah sebuah meja. Beginilah tampilan layanan lain: Penyedia Data. Dia tidak hanya membuat tabel dari grafik, tetapi juga menghitung seberapa populer halaman tersebut dan fungsionalitas yang terkait dengannya, bagaimana pengaruhnya terhadap retensi pengguna, berapa lama pengguna bertahan di halaman tersebut, dan halaman mana yang paling sering ditinggalkan pengguna. Dan penggunaan visualisasi di Tableau mengurangi biaya mempelajari grafik sehingga waktu iterasi untuk analisis perilaku dalam produk berkurang hampir setengahnya.
Danil akan berbicara tentang bagaimana visualisasi ini digunakan dan kesimpulan apa yang dapat diambil.
Lebih banyak meja untuk dewa meja!
Dalam bentuk yang disederhanakan, tugas dirumuskan sebagai berikut: menampilkan grafik transisi di Tableau, menyediakan kemampuan untuk memfilter, dan membuatnya sejelas dan senyaman mungkin.
Saya sebenarnya tidak ingin menggambar grafik berarah di Tableau. Dan meskipun berhasil, keuntungannya, dibandingkan dengan Gephi, tampaknya tidak terlihat jelas. Kami membutuhkan sesuatu yang lebih sederhana dan lebih mudah diakses. Meja! Bagaimanapun, grafik dapat dengan mudah direpresentasikan dalam bentuk baris tabel, di mana setiap baris merupakan sisi dari tipe “sumber-tujuan”. Selain itu, kami telah menyiapkan tabel seperti itu dengan cermat menggunakan alat Retensi dan Penyedia Data. Yang perlu dilakukan hanyalah menampilkan tabel di Tableau dan mengobrak-abrik laporan.
Berbicara tentang betapa semua orang menyukai meja.
Namun, di sini kita dihadapkan pada masalah lain. Apa yang harus dilakukan dengan sumber data? Tidak mungkin menghubungkan pandas.DataFrame; Tableau tidak memiliki konektor seperti itu. Meningkatkan basis terpisah untuk menyimpan grafik tampaknya merupakan solusi yang terlalu radikal dengan prospek yang tidak jelas. Dan opsi pembongkaran lokal tidak sesuai karena kebutuhan akan operasi manual yang konstan. Kami memeriksa daftar konektor yang tersedia, dan pandangan kami tertuju pada item tersebut , yang meringkuk dengan sedih di bagian paling bawah.
Tableau memiliki banyak pilihan konektor. Kami menemukan satu yang memecahkan masalah kami
Hewan apa? Beberapa tab baru yang terbuka di browser - dan menjadi jelas bahwa konektor ini memungkinkan Anda menerima data saat mengakses URL. Backend untuk penghitungan datanya sendiri hampir siap, yang tersisa hanyalah berteman dengan WDC. Selama beberapa hari Denis mempelajari dokumentasi dan bertarung dengan mekanisme Tableau, lalu mengirimi saya tautan yang saya tempelkan ke jendela koneksi.
Formulir koneksi ke WDC kami. Denis tampil di depan dan menjaga keselamatan
Setelah beberapa menit menunggu (data dihitung secara dinamis saat diminta), muncul tabel:
Ini adalah tampilan array data mentah di antarmuka Tableau
Seperti yang dijanjikan, setiap baris tabel tersebut mewakili tepi grafik, yaitu transisi terarah dari pengguna. Itu juga berisi beberapa karakteristik tambahan. Misalnya jumlah pengguna unik, jumlah total transisi, dan lain-lain.
Tabel ini dapat ditampilkan dalam laporan apa adanya, taburkan filter dengan murah hati, dan biarkan alat tersebut berlayar. Kedengarannya logis. Apa yang dapat Anda lakukan dengan meja tersebut? Tapi ini bukan cara kami, karena kami tidak hanya membuat tabel, tapi alat untuk menganalisis dan mengambil keputusan produk.
Biasanya, ketika menganalisis data, seseorang ingin mendapatkan jawaban atas pertanyaan. Besar. Mari kita mulai dengan mereka.
- Transisi apa yang paling sering terjadi?
- Ke mana mereka pergi dari halaman tertentu?
- Berapa lama rata-rata Anda menghabiskan waktu di halaman ini sebelum keluar?
- Seberapa sering Anda melakukan transisi dari A ke B?
- Di halaman manakah sesi berakhir?
Masing-masing laporan atau kombinasinya harus memungkinkan pengguna menemukan jawaban atas pertanyaan-pertanyaan ini secara mandiri. Strategi kuncinya di sini adalah memberi Anda alat untuk melakukannya sendiri. Ini berguna baik untuk mengurangi beban di departemen analitik dan untuk mengurangi waktu pengambilan keputusan - lagipula, Anda tidak perlu lagi membuka Youtrack dan membuat tugas untuk analis, Anda hanya perlu membuka laporan.
Apa yang kami dapatkan?
Di manakah orang paling sering menyimpang dari dasbor?
Fragmen laporan kami. Setelah dasbor, semua orang membuka daftar VM atau daftar node
Mari kita ambil tabel umum dengan transisi dan filter berdasarkan halaman sumber. Paling sering, mereka berpindah dari dasbor ke daftar mesin virtual. Terlebih lagi, kolom Keteraturan menunjukkan bahwa ini adalah tindakan yang berulang.
Dari mana asal mereka dalam daftar klaster?
Filter dalam laporan berfungsi dua arah: Anda dapat mengetahui ke mana Anda pergi, atau ke mana Anda pergi
Dari contoh jelas bahwa bahkan kehadiran dua filter sederhana dan peringkat baris berdasarkan nilai memungkinkan Anda memperoleh informasi dengan cepat.
Mari kita bertanya sesuatu yang lebih sulit.
Di mana pengguna paling sering meninggalkan sesi mereka?
Pengguna VMmanager sering kali bekerja di tab terpisah
Untuk melakukan ini, kami memerlukan laporan yang datanya dikumpulkan berdasarkan sumber rujukan. Dan apa yang disebut breakepoint diambil sebagai tugas - peristiwa yang menjadi akhir dari rantai transisi.
Penting untuk diperhatikan di sini bahwa ini bisa berupa akhir sesi atau pembukaan tab baru. Contoh tersebut menunjukkan bahwa rantai paling sering berakhir pada tabel dengan daftar mesin virtual. Dalam hal ini, perilaku karakteristiknya adalah beralih ke tab lain, yang konsisten dengan pola yang diharapkan.
Kami pertama-tama menguji kegunaan laporan-laporan ini pada diri kami sendiri ketika kami melakukan analisis dengan cara yang sama , produk kami lainnya. Dengan munculnya tabel dan filter, hipotesis diuji lebih cepat, dan mata tidak terlalu lelah.
Saat mengembangkan laporan, kami tidak melupakan desain visual. Saat bekerja dengan tabel sebesar ini, ini merupakan faktor penting. Misalnya, kami menggunakan rangkaian warna yang tenang dan mudah dilihat untuk angka, penyorotan warna garis sesuai dengan nilai numerik karakteristiknya. Detail seperti itu meningkatkan pengalaman pengguna dan meningkatkan kemungkinan alat tersebut berhasil diterapkan di dalam perusahaan.
Tabelnya ternyata cukup banyak, tapi kami berharap tabelnya tetap bisa dibaca
Perlu disebutkan secara terpisah tentang pelatihan klien internal kami: spesialis produk dan desainer UX. Manual dengan contoh analisis dan tip untuk bekerja dengan filter disiapkan khusus untuk mereka. Kami menyisipkan link ke manual langsung ke halaman laporan.
Kami membuat manual ini hanya sebagai presentasi di Google Docs. Alat Tableau memungkinkan Anda menampilkan halaman web langsung di dalam buku kerja laporan.
bukan sebuah epilog
Apa intinya? Kami bisa mendapatkan alat untuk sehari-hari dengan relatif cepat dan murah. Ya, ini jelas bukan pengganti grafik itu sendiri, peta panas klik, atau penampil web. Namun laporan semacam itu secara signifikan melengkapi alat-alat yang terdaftar dan memberikan bahan pemikiran serta hipotesis produk dan antarmuka baru.
Kisah ini hanya menjadi awal bagi pengembangan analitik dalam sistem ISP. Selama enam bulan terakhir, tujuh layanan baru telah muncul, termasuk potret digital pengguna dalam produk dan layanan untuk membuat database untuk penargetan Serupa, namun kita akan membicarakannya di episode berikutnya.
Sumber: www.habr.com