- PVSM.RU - https://www.pvsm.ru -
Приятно видеть, как люди запускают множество сервисов и приложений. Кому-то везет и успех к продукту приходит сам. Большинство же должно адекватно оценивать ситуацию на своем проекте и принимать правильные решения, ведущие к своему лунапарку с нардами и секретаршами.
Сейчас я предложу вам один из вариантов того, как правильно оценивать ситуацию с продуктом, принимать решения и не попасться на ошибку «средней температуры по больнице». Под капотом — немного датайманинга, больничных метафор и «стартаперских метрик».
Это птичка века и она поможет нам с сегодняшней статьей.
Итак, мы запустили новый веб-сервис массового пользования. Нам повезло: мы не загнулись в процессе разработки, создали работоспособный проект, успешно его презентовали и даже начали привлекать первых пользователей. Это вполне себе успех — кучи проектов не доживают до публичного релиза. По этому случаю мы закатываем пирушку с котами, тортом в виде огромного Дарта Вейдера и шоколадными фонтанами.
После вечеринки становится очевидно, что проблемы только начинаются. Нужно как-то расти, работать с пользователями, добавлять новые фичи и улучшать старые. В общем, надо что-то делать. Но, даже если этот проект у вас не первый, пути дальнейшего движения далеко не всегда очевидны.
Каждый решает проблему по-своему. Кто-то бездумно нанимает первого попавшегося маркетолога и следует его советам («а тут мы начнем продавать подписку на красные ведра по $2.99 за ведро в месяц»). Кто-то говорит, что он, блин, визионер, поэтому делать будем потому что «я так вижу» (и таки это иногда работает).
Хороший способ для большинства — адекватно оценить свою ситуацию в цифрах, а потом заниматься маркетоидством и визионерством для улучшения показателей, а в конце — в цифрах оценить результаты своих действий. По этому пути мы и пойдем.
Тут я уже хотел было перейти к рассмотрению конкретного примера из своей работы, там как раз есть много пользователей и проблема «что же делать» встает чуть ли не каждый день. Но, как только я раскрою цифры и детали — мой босс устроит мне смерть через сну-сну за разглашение рабочей информации.
Поэтому все методы мы рассмотрим на примере моего хобби — bamb.ninja [1], бесплатного проекта для тех, кто учит английский язык (на Гиктаймс была статья про эту штуку [2]). Если кратко — сервис позволяет анализировать книги на английском языке и предсказывать трудные слова в тексте. После этого сервис собирает для вас новую книгу, вставляя переводы сложных слов прямо в текст. На выходе получается ваша персональная адаптированная версия текста.
Это и есть пациент на сегодня. У пациента есть несколько тысяч пользователей и абсолютно не ясно, что с делать с сервисом дальше. А еще это просто хобби — можно не стесняясь засветить данные и обсуждать их как угодно.
Когда кто-то попадает в больницу, то любые действия медиков начинаются с определения жизненных показателей. В случае с людьми все известно — нужно померять пульс, давление, вес, взять общие анализы и провести осмотр.
С технологичными проектами не все очевидно. Все проекты разные и показатели у них тоже будут разными. Часто люди пытаются рассматривать в качестве наиболее важных значений количество регистраций в сутки, конверсию, скорость роста. Но на эти параметры легко влиять извне — закупил кучу рекламы, попер народ, куча метрик подскочило. Радость? Не совсем. Новые пользователи могут прийти, зарегистрироваться и больше никогда не вернуться. Еще эти метрики ничего не скажут про качество сервиса и реальную вовлеченность аудитории.
Здоровый проект — это полезный и нужный сервис, который способен решать проблемы, вовлекать пользователей и заставлять людей пользоваться услугой снова и снова.
Значит, хорошо бы найти у себя параметры, говорящие об осмысленной активности человека на сервисе. Не абстрактный ретеншен (сколько людей от общего числа зарегистрированных вернулось на сервис), а именно количество осмысленных действий, сделанных человеком. А еще — время между этими осмысленными действиями.
Поковыряв в базе данных, я пришел к выводу, что для моего проекта такими параметрами являются:
Все эти параметры довольно точно говорят о том, пользуются ли люди сервисом, мешают ли им технические проблемы и решат ли они свои задачи. В вашем проекте тоже должны быть такие параметры — например, количество единиц созданного или потребленного контента, время между созданием/потреблением, популярность этого контента, ошибки в системе при работе человека с сервисом.
И, само собой, нужно следить за ростом, конверсией и ретеншеном — эти цифры тоже нужно знать.
Теперь мы знаем ключевые жизненные показатели сервиса, которые говорят о том, насколько людям у нас хорошо. Что с этим делать дальше?
Я уже слышу, как несколько человек кричат «посчитать средние и пытаться оптимизировать их для всех пользователей». Среднее — это, конечно, тоже метрика, но она мало говорит о реальном положении дел.
Если в больнице померять температуру у всех, кто там есть (включая трупы в морге), то можно прийти к неправильным выводам. Например, можно сказать, что если в больницу отправить 100 человек с острыми инфекциями и жаром, то средняя температура станет как раз 36.6 и тогда можно всех сразу выписать по домам (включая мертвых) — по всем средним значениям у нас все стало хорошо.
Если в случае с больницей мы все понимаем, что стратегия оптимизации средних значений абсурдна, то в случае с программными продуктами это понятно не всем. В стартапах любят выводить потрясающие средние значения, получать под это дело пару миллионов долларов, а потом умирать через 3–4 года, к великому удивлению инвесторов.
Если не средние, то что?
Нужно сгруппировать пользователей так, чтобы средние свойства группы хорошо отражали свойства всех пользователей, попавших в эту группу. Это называется «кластеры пользователей». Вместо нескольких тысяч человек мне нужно будет рассматривать всего несколько кластеров, статистические значения для которых отражают особенности поведения внутри каждого кластера.
Я строю кластеры.
Вместо нескольких тысяч пользователей и получил всего 3 кластера с разными свойствами, в которые удивительно хорошо вписались все мои пользователи с различными поведениями. Но за последние несколько месяцев я пару раз менял свой проект коренным образом, поэтому для большей надежности я возьму данные только за последний месяц — они более точно покажут текущее состояние дел.
Глядя на эти 3 кластера понимаешь, что есть кое-какие вопросы.
Распределение людей по кластерам показывает, что у меня есть проблемы. А немного пораскинув мозгами и посмотрев дополнительную статистику в базе данных, я могу понять природу этих проблем и методы их решения. Если бы я взял средние значения — картинка была бы достаточно приятной. И я бы сфокусировался на росте аудитории и увеличении метрики «количество книг на пользователя» А в этом случае — это прямая дорога к тому, чтобы загнуться.
Теперь поговорим о вашем проекте.
Добавьте к этому типичную статистику: рост юзеров, MAU/DAU, ретеншен, ваши заработки и конверсии — вы получите довольно удобный рабочий компас для принятия решений. С помощью этих чисел можно выстроить правильный маркетинг и проверить свои визионерские решения, при этом не потеряв контакта с реальностью.
Если бы в больнице строили кластеры — довольно быстро бы поняли, что есть разные категории пациентов в здании. Некоторые из них — трупы (это бывает), некоторые из них — со сломанными руками и ногами (им нужен гипс и рентген), а некоторые — уже поправились и могут идти домой.
Конечно, это не решит всех проблем, но на масштабах сотен тысяч больных поможет понять, что на этом этаже у нас инфекционное отделение и там надо применять антибиотики. Мы точно не знаем, кто там и чем болеет, но даже накачка этой области антибиотиками поможет получить более адекватный результат.
Ищите и пробуйте разные подходы к анализу статистики. Анализируйте когорты, пробуйте майнить данные и выделять группы. Ищите отклонения от средних значений, пики и провалы в активности. В общем — попробуйте смотреть на статистику под самыми разными углами. Главное — выйти за пределы стандартных метрик для стартапов и взглянуть на вещи шире.
Да пребудет Сила с вами и вашими делами!
Автор: 57uff3r
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/102347
Ссылки в тексте:
[1] bamb.ninja: http://bamb.ninja/
[2] статья про эту штуку: http://geektimes.ru/post/248294/
[3] Weka: http://www.cs.waikato.ac.nz/ml/weka/
[4] Источник: http://megamozg.ru/post/20814/
Нажмите здесь для печати.