Dalam artikel ini, saya akan berbicara tentang analitik produk di studio kami, IT Territory. Artikel ini terdiri dari tiga bagian. Pada bagian pertama saya akan memberi tahu Anda bagaimana departemen analisis produk diatur, siapa karyawannya, apa yang mereka lakukan dan mengapa semuanya hanya itu dan bukan sebaliknya. Pada bagian kedua, saya akan menjelaskan contoh teknik yang telah kami kembangkan dan terapkan pada semua proyek. Pada bagian ketiga saya akan memberikan beberapa tips yang secara serius dapat membuat hidup lebih mudah dan membantu bekerja lebih efisien.

Sekarang studio kami mengoperasikan 11 proyek game seluler, dua lagi sedang dalam pengembangan. Kami fokus pada pasar ponsel dan membuat game midcore shareware, terutama dengan ekonomi tertutup. Studio ini menangani seluruh spektrum pekerjaan - mulai dari pengembangan hingga promosi dan operasi. Staf 240 orang, kantor di Moskow dan Voronezh.

Untuk memahami tempat departemen analitik produk dalam struktur studio, saya mengusulkan untuk melihat diagram yang disederhanakan ini:

Departemen analisis produk adalah departemen satelit untuk tim proyek, bersama dengan departemen pengujian, operasi, dan pemasaran. Kami bekerja sangat erat dengan semua proyek, memberikan mereka hasil pekerjaan kami dan menerima informasi dari tim tentang situasi saat ini, rencana dan prioritas. Tetapi pada saat yang sama kami melapor kepada manajemen studio.

1. Siapa yang merupakan analis produk?

Ini adalah bagian dari departemen yang terpisah, dengan masing-masing analis ditugaskan untuk proyek atau waralaba tertentu. Dia bekerja dengan tim proyek, melakukan tugas-tugas dan membantu pengambilan keputusan di tim dan dalam manajemen. Analis secara aktif menggunakan produk, jika tidak, ia tidak akan memiliki pengalaman pengguna - komponen yang sangat penting yang diperlukan untuk bekerja. Pada saat yang sama, analis menyadari semua proses, yaitu, memahami masalah dan tugas apa yang dihadapi proyek sekarang, dan mengarahkan upayanya untuk menyelesaikannya.

1.1. Pendekatan analisis

Kami percaya bahwa kami memiliki pendekatan sistematis untuk analitik di studio kami.

Dalam desain klasik, analitik adalah bagian dari tim proyek. Orang seperti itu sangat tenggelam dalam proyek ini, dia mengenalnya dengan seksama. Biasanya, analis dari tim yang berbeda praktis tidak saling berkomunikasi.

Dalam sistem kami, ada peran kepala departemen, yang menerjemahkan persyaratan, metode, dan alat. Artinya, semua analis di semua proyek menggunakan pendekatan universal yang terdokumentasi dan terbukti, tetapi tidak terbatas pada mereka saja. Bagi kami, ini adalah minimum tertentu, atas dasar itu kami bisa mendapatkan pemeriksaan yang lebih pribadi dan mendalam. Karyawan dapat menggunakan alat dan pendekatan yang tidak disebutkan dalam metode standar. Pada gilirannya, kepala departemen mengendalikan hasil pekerjaan analis, dan karena ia sendiri adalah spesialis yang paling kompeten, ia menambah pengalaman dan pengetahuan timnya.

Keuntungan penting dari pendekatan ini adalah bahwa analis sepadan. Sering terjadi bahwa seseorang telah bekerja di proyek yang sama selama bertahun-tahun dan akhirnya terbakar, tatapannya "kabur". Dalam situasi seperti itu, mentransfernya ke proyek lain biasanya sangat sulit, karena analis memiliki pengetahuan khusus tentang proyek dan infrastrukturnya, yang tidak dimiliki orang lain. Tetapi ketika metode dan persyaratannya sama, setelah sedikit pelatihan, orang bisa dipindahkan antar proyek, memberi mereka pengalaman dan tantangan baru.

1.2. Tugas utama

Tugas utama analis di departemen kami:

Analisis perubahan KPI sebagai produk berkembang .
Deteksi dan studi anomali .
Cari kemacetan dan poin pertumbuhan . Ini adalah tugas yang sangat penting yang memungkinkan seseorang untuk berkembang secara profesional. Dia sendiri menetapkan hipotesis, memeriksanya, menemukan informasi baru yang tidak dilihat orang lain, dan dengan demikian memperoleh pengalaman yang tidak akan diberikan oleh pemimpin.
Dukungan keputusan . Kami membantu anggota tim menjawab pertanyaan mereka.
Dukungan dan pengembangan infrastruktur analitik .

Saya akan bercerita lebih banyak tentang poin terakhir. Infrastruktur terdiri dari tingkatan-tingkatan berikut:

Pada level pertama adalah database proyek, di mana kami merekam semua data, dan kami sendiri menggunakan replika untuk menghilangkan risiko bagi proyek.

Pada tingkat kedua, kami memiliki penyimpanan berdasarkan Hadoop, tempat kami mentransfer informasi dari basis data proyek untuk analisis historis volume yang sangat besar.

Level selanjutnya adalah add-on di atas repositori untuk mengeksekusi kode. Di sini Anda dapat menerapkan transformasi data kompleks apa pun yang tidak dapat kami terapkan dengan menggunakan alat dari level sebelumnya.

Pada level terakhir, kami memiliki visualisasi. Secara historis, perangkat lunak berpemilik, QlikView, bertanggung jawab atasnya. Dan Excel adalah klasik, untuk tugas cepat kami selalu menggunakannya.

1.3. Kompetensi Analis Produk

Kami menyoroti daftar berikut:

SQL dan bahasa serupa;
arsitektur basis data;
bahasa pemrograman (Python, R, Scala);
matematika dan statistik matematika;
logika dan pemikiran produk;
kemampuan untuk mempertahankan posisi seseorang;
keterampilan komunikasi.

Saya ingin menekankan dua poin terakhir. Secara umum diterima bahwa analis adalah seorang introvert dengan IQ di atas 130, yang menyiapkan laporan setebal 50 halaman tentang apa yang terjadi dalam bidang tanggung jawabnya. Tetapi pada kenyataannya, dalam paradigma kita, analis adalah orang yang menjadi pendorong masalah dan titik pertumbuhan yang dia temukan. Sulit dalam tim untuk meyakinkan orang bahwa Anda telah menemukan sesuatu yang penting, karena semua orang terlibat dalam tugas prioritas mereka sendiri. Tetapi hanya menyampaikan informasi ini dan melupakannya - posisi seperti itu tidak cocok untuk kita. Oleh karena itu, sangat penting bagi analis untuk dapat membangun hubungan dalam tim, menemukan cara untuk mempertahankan posisinya dan kesimpulannya, dan "mendorong" pelaksanaan rekomendasinya.

2. Metode

Sekarang saya akan berbicara sedikit tentang contoh teknik yang kami siarkan kepada karyawan departemen analitik. Menurut pendapat kami, tiga pilar produk free-to-play yang sukses adalah ekonomi, retensi, dan monetisasi. Untuk masing-masing entitas ini, di departemen analitik, metode dikembangkan untuk mengevaluasi dan membandingkan dengan proyek lain. Mereka dapat dibagi menjadi tiga kelompok besar:

Metode evaluasi produk awal . Pendekatan yang relevan pada tahap awal kehidupan suatu produk, ketika belum ada inti, dan hanya ada permainan baru di mana audiens baru saja mulai muncul.
Metode untuk menilai perubahan dalam proyek dengan kernel . Mereka digunakan untuk mengevaluasi perubahan dalam versi baru gim, efek penambahan fitur dan suntingan, baik pada KPI dan pada kinerja produk secara keseluruhan.
Metode mempelajari anomali . Kami mengembangkannya untuk reaksi khas terhadap situasi abnormal umum dengan indikator produk. Ada beberapa pendekatan tertentu, apa dan dalam urutan apa Anda perlu menganalisis untuk dengan cepat menemukan penyebab yang paling mungkin dan mulai untuk menyelesaikan masalah.

Saya akan berbicara tentang anomali di lain waktu, dan hari ini kita akan berbicara tentang penilaian awal dan analisis perubahan menggunakan proyek F2P klasik dengan ekonomi tertutup.

2.1. Teknik Penilaian Awal

Contoh teknik penilaian awal:

Retensi
CARPU (LTV) untuk pasar utama;
FPE (konversi dalam pembayaran);
konversi mulai tetap (tutorial);
poin kemajuan yang menyebabkan penarikan;
poin kemajuan yang merangsang pembayaran;
arus masuk dan keluar sumber daya dalam konteks kemajuan dan / atau masa hidup;
Upaya WinRate pertama + jumlah upaya sebelum berhasil diselesaikan.

Saya akan memberi tahu Anda sedikit tentang beberapa di antaranya.

2.1.1. Ekonomi hari-hari pertama kehidupan

Kami baru saja meluncurkan produk baru dalam rilis dan ingin mengevaluasi keadaan ekonomi mata uang saat ini. Ada cara yang cukup sederhana untuk penilaian tingkat atas dari keseimbangan permintaan untuk sumber daya semacam itu. Biarkan pengeluaran kumulatif dalam game di hari-hari pertama kehidupan terlihat seperti ini:

Sumbu X mewakili siklus hidup. Penghasilan kumulatif adalah gratis, yaitu total pengeluaran kami melebihi pendapatan spesifik per pengguna. Jadi kami memiliki kekurangan sumber daya ini, yang ditutup oleh pembelian. Ini adalah potongan pertama yang paling umum. Kemudian kami membaginya menjadi sumber dan mencari dari mana penghasilan gratis yang meningkat berasal. Aturan umum adalah: jika pengeluaran melebihi pendapatan gratis, Anda akan memiliki permintaan. Anda dapat menyesuaikan volumenya menggunakan rasio pengeluaran dan pendapatan gratis. Jika penghasilan gratis Anda mencakup biaya unit per pengguna, maka kemungkinan besar hanya mereka yang biayanya sangat tinggi akan membayar. Artinya, pengguna yang sangat loyal, tetapi tidak total massa.

2.1.2 Konversi kemajuan

Salah satu aspek terpenting dari sebuah game adalah retensi primer. Pada menit pertama setelah instalasi, orang berkenalan dengan game dan memutuskan apakah mereka akan memainkannya atau tidak. Sebagian besar proyek kehilangan setengah audiens dalam 30 menit pertama. Bagaimana saya dapat dengan cepat menemukan masalah dalam mempertahankan pemirsa saya? Sehubungan dengan kemajuan, kami melakukan ini menggunakan corong klasik:

Kami membuat grafik jumlah pengguna yang mencapai titik kunci tertentu. Grafik menunjukkan penurunan yang nyata pada titik 4, 10, dan 20. Jika Anda menghitung konversi relatif dari titik ke titik, Anda akan segera melihat penurunan di mana konversi turun tajam relatif terhadap titik-titik tetangga. Alasannya berbeda: masalah di UX, masalah memilih antara mode yang berbeda, ketika pengguna tidak sesuai dengan strategi Anda, tetapi pergi ke PvP atau mode lain, kompleksitas, kegagalan teknis, dll. Namun secara umum, ini adalah poin yang harus segera Anda perhatikan, karena mereka memprovokasi pengguna untuk pergi atau tidak bertindak pada kurva progres pilihan Anda.

2.1.3 Poin perawatan dan pembayaran

Berikut adalah contoh proyek di mana poin-poin ini sangat jelas:

Pada titik-titik tertentu dalam kemajuan pemain, ledakan pembayaran dan penarikan pengguna terjadi. Alasannya adalah bahwa pada saat-saat ini orang dihadapkan dengan kenyataan bahwa tidak mungkin untuk bergerak lebih jauh dalam permainan sampai Anda mengumpulkan sejumlah poin. Akibatnya, cuti yang lemah, dan mereka yang ingin mengalahkan permainan dengan buruk dan menghemat waktu menggunakan fitur berbayar.

Setelah menerima informasi ini, tim harus mengerjakan saldo agar kehilangan sesedikit mungkin orang, tetapi pada saat yang sama, memaksimalkan atau menghemat pembayaran.

2.1.4. Masalah Monetisasi Penting

Masalah monetisasi sangat luas. Kami mendekati setiap proyek secara individual dan percaya bahwa monetisasi berasal dari desain, dan bukan pendekatan universal yang dapat diterapkan di mana-mana. Ringkasnya, metode kita dapat diekspresikan dalam pertanyaan yang kita ajukan, dan poin penerapan upaya akan tergantung pada jawaban atas pertanyaan ini.

Produk mana yang paling baik mengubah pengguna menjadi yang membayar? Kami memiliki proyek yang "menembak" dengan sangat baik pada awalnya. Tetapi hanya beberapa bulan setelah menerima fitur'ov, setelah mencerna volume audiens yang cukup besar, proyek pendapatan mulai turun, dan cukup serius. Dia memiliki pegangan yang bagus untuk proyek midcore, dan gameplaynya cukup sulit. Kami tidak memiliki cukup massa pembayaran untuk mendapatkan proyek di dataran tinggi keuangan karena pembayaran dari audiens inti.

Kami memutuskan bahwa kami perlu memutus batasan pembayaran pertama untuk sebagian besar pengguna. Kami memilih konten eksklusif yang belum dijual baik untuk mata uang game atau uang, dan memberikan harga serendah mungkin. Secara alami, konten ini bukan ultimatum dan tidak mencakup semua kebutuhan pemain. Mulai menawarkannya pada permulaan monetisasi yang terjangkau dalam permainan, dalam satu gerakan kami meningkatkan porsi pembayaran sebesar sepertiga, sambil mempertahankan tagihan rata-rata.

Semakin cepat pengguna masuk ke kategori pembayaran, semakin besar akan menjadi bagian integral dari pendapatannya dalam permainan. Harap dicatat bahwa setiap game akan memiliki kontennya sendiri yang paling baik memecahkan masalah ini. Jika di game lain melakukan hal yang sama di dahi, maka Anda tidak bisa menebak. Sangat penting untuk memahami bahwa seseorang benar-benar menghargai dalam permainan konten apa yang akan diminati pada tahap ini, serta bagaimana menghindari pukulan terhadap ekonomi dan keseimbangan secara keseluruhan.

Berapa proporsi pengguna yang dikonversi menjadi membayar di tahap akhir permainan? Jika Anda memiliki banyak pembayar baru setelah hari ke-30 dalam hidup Anda, kemungkinan besar Anda akan menerima lebih sedikit uang. Orang-orang ini telah bermain selama sebulan, mereka telah memenuhi tujuan jangka pendek dan menengah. Tetapi pada saat yang sama, mereka tidak memiliki motivasi yang cukup untuk mulai membayar. Dan pada tahap selanjutnya, dia tiba-tiba muncul. Biarkan saya mengingatkan Anda bahwa jika seorang pengguna mengkonversi terlambat, maka pendapatan spesifiknya akan berkurang dibandingkan dengan situasi jika ia dikonversi pada hari-hari pertama proyek. Oleh karena itu, perlu untuk menemukan motivasi bagi pemain untuk mengonversi pembayaran menjadi pada tahap awal.

Berapa banyak pengguna yang dikonversi menjadi dua pembelian, tiga, dll.? Jika kami membuat produk yang dengan sempurna mengubah pengguna pada tahap awal dan kami mendapatkan banyak pembayar baru, maka muncul penghalang berikutnya. Antara produk semacam itu dan sisa penawaran Anda mungkin ada selisih harga yang besar, dan bagi pengguna yang membeli produk bagus seharga satu dolar, semua penawaran lain tampaknya tidak menguntungkan. Dalam situasi seperti itu, perlu untuk memikirkan rantai: apa yang akan menjadi langkah selanjutnya dari pemain yang harus menjadi pembayar penuh? Jika dia membeli produk yang sangat menguntungkan dengan harga murah, perlu untuk menawarkan beragam tawaran untuknya yang secara bertahap akan meningkatkan ukuran cek, tetapi pada saat yang sama setiap kali memberi pengguna kualitas baru.

Apakah ada strategi yang jelas untuk meningkatkan ukuran cek? Tidak cukup hanya mengonversi pengguna, karena jelas bahwa orang-orang seperti itu membeli sendiri dengan penawaran yang cukup murah. Penting untuk membangun strategi dengan benar sehingga setiap produk berikutnya yang diminta dalam kategori harga yang berbeda. Saya tidak segera berbicara tentang jumlah besar, tetapi Anda memiliki metrik sebagai rata-rata cek untuk pembayar. Seseorang yang telah dikonversi dari penawaran murah harus dibawa ke sini. Ini mungkin, dan paling sering orang menolak membayar karena alasan psikologis.

Apakah ada proses penolakan pembayaran sambil mempertahankan aktivitas? Dalam banyak permainan, di tahap akhir kehidupan proyek, pemain beradaptasi dengan ekonomi, menyesuaikan kebutuhan mereka dengan kemampuan mereka dan pindah ke tahap tidak membayar atau membeli minimum. Di sini Anda perlu bekerja dalam hal desain game. Ini mungkin berarti bahwa gameplaynya terlalu monoton dan jangka panjang, terlalu sedikit tantangan yang memotivasi. Namun, karena inti dari pengguna, permainan dapat tumbuh dengan sangat baik dan berkembang sebagai proyek bisnis.

Tentu saja, ini bukan semua aspek penting dari pendekatan untuk monetisasi, namun, pekerjaan lebih lanjut akan sangat tergantung pada nuansa produk.

2.2. Penilaian Perubahan Produk

Sekarang mari kita bicara tentang metode untuk menilai perubahan pada produk. Ini adalah:

[Semua metode penilaian awal] +
metrik monetisasi aliran: DPU, ARPPU, ARPDAU;
retensi bergulir menit;
arus masuk dan keluar sumber daya dalam dinamika;
Tingkat churn;
rata-rata lama menginap dalam aplikasi;
dinamika kegiatan utama;
keseimbangan sumber daya yang ada.

Saya akan membahas beberapa teknik.

2.2.1. Retensi Bergulir Menit

Retensi Bergulir per menit adalah cara yang baik untuk dengan cepat memahami jika ada masalah teknis atau desain di awal, pada menit pertama pertandingan.
Mari kita lihat jadwal proyek pertama:

Kurva logaritmik, semuanya jelas: semakin lama seorang pemain dalam permainan, semakin kecil kemungkinannya untuk pergi. Proyek kedua juga sehat, tetapi hasilnya sedikit lebih baik. Setelah satu jam bermain, kami memiliki lebih banyak pengguna. Dan kemudian kami membuat perubahan pada proyek kedua yang memecahkan sesuatu - jadwalnya berubah.

Penting di sini bahwa kita memiliki bagian di mana ketergantungan dari probabilitas meninggalkan waktu yang dihabiskan dalam permainan berubah secara dramatis. Gambaran seperti itu menunjukkan bahwa kita telah merusak sesuatu. Mungkin gim mulai bekerja dengan tidak stabil, atau kami merusak pengalaman pengguna. Dalam kasus apa pun, Anda perlu mencari tahu apa yang dilakukan para pemain di saat-saat kehidupan permainan ini, dan menemukan sumber kemunduran dalam retensi.

2.2.2. Tingkat churn, atau tingkat aliran keluar

Kami menyebut Churn Rate sedikit berbeda dari apa yang dimaksud industri dengan istilah ini. Ketika tugas muncul untuk menilai arus audiens aktif secara tepat, yaitu, perlu untuk melanjutkan bukan dari registrasi, tetapi dari aktivitas inti pengguna saat ini, kami “datang” dengan Churn Rate kami. Kami menghitungnya seperti ini: untuk setiap tanggal kami menghitung para pemain yang aktif, dan kemudian melihat berapa banyak dari mereka yang tidak lagi masuk selama waktu tertentu, yaitu, meninggalkan permainan. Jadi kami mendapatkan probabilitas statistik dari pemain yang keluar dengan parameter yang diberikan pada hari tertentu.

Biasanya kami menganalisis arus berdasarkan level, usia, status pembayaran. Peningkatan tajam dalam metrik menunjukkan bahwa kemungkinan pemain meninggalkan segmen ini telah meningkat, dan Anda perlu mencari alasannya. Jika Tingkat Churn terus ditingkatkan setelah pembaruan yang terlihat, masuk akal untuk membunyikan alarm.

2.2.3. Arus masuk dan keluar sumber daya

Idenya hampir sama seperti dalam kasus metodologi untuk menilai ekonomi proyek baru, hanya sekarang kita memiliki inti yang memiliki siklus permainan untuk mendapatkan dan menghabiskan sumber daya.

Garis kuning adalah pengeluaran, garis hitam adalah penghasilan gratis. Ada perbedaan besar di antara mereka, pendapatan lebih rendah dari biaya. Delta adalah defisit yang menciptakan permintaan untuk sumber daya yang diperdagangkan kami. Saya bertemu beberapa proyek di mana situasinya benar-benar berlawanan: mereka hanya menghasilkan uang dengan mengorbankan pengguna yang membayar besar. Secara umum, jika biaya unit Anda untuk sumber daya yang dimonetisasi melebihi pendapatan gratis tertentu, maka ini adalah ekonomi yang langka dan sehat.

3. Tips

3.1. Tren smoothing jangka panjang

Misalkan kita mengikuti beberapa parameter penting. Misalnya, LTV (ARPU kumulatif) selama 30 hari untuk pemirsa baru. Sulit untuk bekerja dengannya. Dia sangat sensitif terhadap pembayar besar, memiliki dispersi yang tinggi, sehingga jadwalnya untuk kelompok yang berurutan dalam dinamika akan terlihat sama sekali tidak representatif. Kita dapat memecah parameter ini berdasarkan bulan atau grup, tetapi ini tidak cukup seperti yang ingin kita lihat dalam dinamika.

Ada saran sederhana tentang cara menganalisis indikator tersebut secara lebih efisien: kami menerapkan perataan geser. Untuk melakukan ini, pada setiap titik kami mempertimbangkan nilai total parameter bersama dengan beberapa yang sebelumnya. Jendela untuk menghaluskan dapat berbeda: 7 hari, 30 hari atau lebih. Semakin besar jendela, semakin halus dinamika dan semakin sedikit pengaruh fluktuasi, tetapi jangka panjang harus ada tren agar dapat melihatnya dengan jelas.

Kami memiliki indikator yang baik dan mudah dipahami yang mempertahankan makna fisik. Pada saat yang sama, mudah untuk melihat penurunan di akhir grafik.

3.2. Tes A / B

Kami benar-benar menyukai tes A / B. Kami memiliki proyek di mana kami melakukan 70 tes A / B lengkap hanya dalam 2 tahun. Jika kita merangkum pengalaman kita dalam suatu tekanan, kita dapat mengatakan yang berikut:

Tes A / B adalah cara paling jujur (realistis) untuk menguji hipotesis.
Yang terbaik adalah melakukannya di audiens baru. Jika Anda menguji fitur yang sudah dilihat pemirsa lama, lalu menunjukkannya opsi baru, maka persepsi dan reaksi tidak akan sama dengan orang yang tidak melihat fitur tersebut. Kemungkinan besar, reaksinya akan negatif dan bersifat publik, dan dapat memengaruhi hasil tes. Hanya dalam kasus individual, dengan perbedaan yang tidak jelas bagi para pemain atau dalam situasi tertentu, tes dapat dilakukan di seluruh audiens.
. , . , , . A/B-.
A/B-, , . , , .
A/B-. . A/B-. , .
A/B-, , . , . , . .

3.3.

, -. , , . , , .

, :

, , . , ? , , .

, , , . , , , .

, - :

-, . «ARPU ».
baseline. . « », , .
. .
. , . - , , , . .
. , , - , .
. , ? - .
. - . , , . , , , . , , , . , - . , -, . , , .

4.

— !
!
, !
A/B- !
!

Analitik produk di studio siklus penuh