0. Intro

Приятно видеть, как люди запускают множество сервисов и приложений. Кому-то везет и  успех к продукту приходит сам. Большинство же должно адекватно оценивать ситуацию на своем проекте и принимать правильные решения, ведущие к своему лунапарку с нардами и секретаршами.
Сейчас я предложу вам один из вариантов того, как правильно оценивать ситуацию с продуктом, принимать решения и не попасться на ошибку «средней температуры по больнице». Под капотом — немного датайманинга, больничных метафор и «стартаперских метрик».


Это птичка века и она поможет нам с сегодняшней статьей.

1. Вечный вопрос: «Что делать?»

Итак, мы запустили новый веб-сервис массового пользования. Нам повезло: мы не загнулись в процессе разработки, создали работоспособный проект, успешно его презентовали и даже начали привлекать первых пользователей. Это вполне себе успех — кучи проектов не доживают до публичного релиза. По этому случаю мы закатываем пирушку с котами, тортом в виде огромного Дарта Вейдера и шоколадными фонтанами.
После вечеринки становится очевидно, что проблемы только начинаются. Нужно как-то расти, работать с пользователями, добавлять новые фичи и улучшать старые. В общем, надо что-то делать. Но, даже если этот проект у вас не первый, пути дальнейшего движения далеко не всегда очевидны.
Каждый решает проблему по-своему. Кто-то бездумно нанимает первого попавшегося маркетолога и следует его советам («а тут мы начнем продавать подписку на красные ведра по $2.99 за ведро в месяц»). Кто-то говорит, что он, блин, визионер, поэтому делать будем потому что «я так вижу» (и таки это иногда работает).
Хороший способ для большинства — адекватно оценить свою ситуацию в цифрах, а потом заниматься маркетоидством и визионерством для улучшения показателей, а в конце — в цифрах оценить результаты своих действий. По этому пути мы и пойдем.

2. Внести пациента!

Тут я уже хотел было перейти к рассмотрению конкретного примера из своей работы, там как раз есть много пользователей и проблема «что же делать» встает чуть ли не каждый день. Но, как только я раскрою цифры и детали — мой босс устроит мне смерть через сну-сну за разглашение рабочей информации.

Поэтому все методы мы рассмотрим на примере моего хобби — bamb.ninja, бесплатного проекта для тех, кто учит английский язык (на Гиктаймс была статья про эту штуку). Если кратко — сервис позволяет анализировать книги на английском языке и предсказывать трудные слова в тексте. После этого сервис собирает для вас новую книгу, вставляя переводы сложных слов прямо в текст. На выходе получается ваша персональная адаптированная версия текста.
Это и есть пациент на сегодня. У пациента есть несколько тысяч пользователей и абсолютно не ясно, что с делать с сервисом дальше. А еще это просто хобби — можно не стесняясь засветить данные и обсуждать их как угодно.

3. Жизненные показатели

Когда кто-то попадает в больницу, то любые действия медиков начинаются с определения жизненных показателей. В случае с людьми все известно — нужно померять пульс, давление, вес, взять общие анализы и провести осмотр.
С технологичными проектами не все очевидно. Все проекты разные и показатели у них тоже будут разными. Часто люди пытаются рассматривать в качестве наиболее важных значений количество регистраций в сутки, конверсию, скорость роста. Но на эти параметры легко влиять извне — закупил кучу рекламы, попер народ, куча метрик подскочило. Радость? Не совсем. Новые пользователи могут прийти, зарегистрироваться и больше никогда не вернуться. Еще эти метрики ничего не скажут про качество сервиса и реальную вовлеченность аудитории.

Здоровый проект — это полезный и нужный сервис, который способен решать проблемы, вовлекать пользователей и заставлять людей пользоваться услугой снова и снова.
Значит, хорошо бы найти у себя параметры, говорящие об осмысленной активности человека на сервисе. Не абстрактный ретеншен (сколько людей от общего числа зарегистрированных вернулось на сервис), а именно количество осмысленных действий, сделанных человеком. А еще — время между этими осмысленными действиями.
Поковыряв в базе данных, я пришел к выводу, что для моего проекта такими параметрами являются:

• Количество текстов, переведенных каждым пользователем (чем больше — тем лучше)
• Среднее время в часах между обращениями пользователя к функции загрузки текста и перевода. Чем больше, тем лучше. Хорошо, если человек будет периодически загружать новые книги и почитывать их, улучшая свой английский и набивая в голову в знания. Плохо, если человек сразу перевел 30 книг и забыл про них навсегда.
• Количество ошибок в работе сервиса для каждого пользователя. Чем меньше — тем лучше.
• Количество операций со списком сложных слов у каждого пользователя. Чем больше — тем лучше. Работа по списком слов после чтения книги говорит о том, что человек увлекся и учил новые слова из прочтенной книги.

Все эти параметры довольно точно говорят о том, пользуются ли люди сервисом, мешают ли им технические проблемы и решат ли они свои задачи. В вашем проекте тоже должны быть такие параметры — например, количество единиц созданного или потребленного контента, время между созданием/потреблением, популярность этого контента, ошибки в системе при работе человека с сервисом.

И, само собой, нужно следить за ростом, конверсией и ретеншеном — эти цифры тоже нужно знать.

4. Что с этим делать?

Теперь мы знаем ключевые жизненные показатели сервиса, которые говорят о том, насколько людям у нас хорошо. Что с этим делать дальше?
Я уже слышу, как несколько человек кричат «посчитать средние и пытаться оптимизировать их для всех пользователей». Среднее — это, конечно, тоже метрика, но она мало говорит о реальном положении дел.
Если в больнице померять температуру у всех, кто там есть (включая трупы в морге), то можно прийти к неправильным выводам. Например, можно сказать, что если в больницу отправить 100 человек с острыми инфекциями и жаром, то средняя температура станет как раз 36.6 и тогда можно всех сразу выписать по домам (включая мертвых) — по всем средним значениям у нас все стало хорошо.
Если в случае с больницей мы все понимаем, что стратегия оптимизации средних значений абсурдна, то в случае с программными продуктами это понятно не всем. В стартапах любят выводить потрясающие средние значения, получать под это дело пару миллионов долларов, а потом умирать через 3–4 года, к великому удивлению инвесторов.
Если не средние, то что?

5. Кластеры

Нужно сгруппировать пользователей так, чтобы средние свойства группы хорошо отражали свойства всех пользователей, попавших в эту группу. Это называется «кластеры пользователей». Вместо нескольких тысяч человек мне нужно будет рассматривать всего несколько кластеров, статистические значения для которых отражают особенности поведения внутри каждого кластера.

Я строю кластеры.

• Выкачиваю из базы таблицу в CSV тех самых критических параметров — количество переведенных книг, количество ошибок при обработке запроса, интервалы между использованиями сервиса и количество операций со списком слов.
• Беру Weka — бесплатную программу для майнинга данных. Кластеризация значений — это один из способов майнить данные. Weka названа в честь новозеландской птички веки.
• Путем пары нехитрых операций кормим в Weka данные о своих пользователях и с помощью кластеризатора находим кластеры среди своих пользователей. Для нашй задачи вполне можно использовать кластеризатор с параметрами EM -I 100 -N -1 -M 1.0E-6 -S 100 (рекомендую ознакомиться с документацией к Weka и немного вникнуть о том, что делают разные анализаторы, кластеризаторы и классификаторы).

Вместо нескольких тысяч пользователей и получил всего 3 кластера с разными свойствами, в которые удивительно хорошо вписались все мои пользователи с различными поведениями. Но за последние несколько месяцев я пару раз менял свой проект коренным образом, поэтому для большей надежности я возьму данные только за последний месяц — они более точно покажут текущее состояние дел.

6. Анализируй это

• Кластер #0 — люди, которые неплохо залипли на сервисе. Они перевели в среднем по 8 книг, средний интвервал между обращениями к функции перевода — 36 часов. Средняя влипаемость довольно низкая — 25.5 операций со списком трудных слов из текста. Большинство сбоев в работе сервиса пришлось на этих людей — они переводили много разных текстов и породили много сбойных ситуаций. 9% от общего числа моих пользователей.
• Кластер #1 — люди, которые залипли на короткий срок. Они перевели в среднем по 3.2 книги на сервисе, но у них лучше параметр вовлеченности в работу с новыми английскими словами — 27.2. У этих пользователей вообще нет проблем с сервисом — 0. И 65 часов между обращениями к основной функции с большим стандартным отклонением — 164. 19% людей от общего числа.
• Кластер #2 — люди, которые только пробовали, но дальше дело не пошло. С новыми словами они не работают, книг переводят мало. При этом среднее значение между обращениями к сервису — 34 часа. Явная аномалия — откуда возьмется среднее время между обращениями, если люди обращаются в среднем 1 раз? 72% от общего числа.

Глядя на эти 3 кластера понимаешь, что есть кое-какие вопросы.

• Даже самые верные пользователи не работают над изучением слов. Может, это слишком сложно? Плохо реализовано? Или это вообще ненужная фича? Да, «я так вижу», но, может люди считают иначе?
• Не все могут начать использовать сервис после регистрации. Слишком сложно? Непонятен принцип работы? Лень?
• Пользователи, прочитавшие по 3 книги, более склонны учить новые слова, чем те, кто прочила 7–8 книг. Это тренд или просто флуктуация? Есть ли тут закономерность? А не становиться ли людям тяжелей учить слова при большом количестве книг? Не вываливаю ли я на них слишком много информации?
  
• Для удержания самых верных пользователей нужно решать технические проблемы. Какие проблемы возникают у этих людей? Нет ли у них общих причин?
  

Распределение людей по кластерам показывает, что у меня есть проблемы. А немного пораскинув мозгами и посмотрев дополнительную статистику в базе данных, я могу понять природу этих проблем и методы их решения. Если бы я взял средние значения — картинка была бы достаточно приятной. И я бы сфокусировался на росте аудитории и увеличении метрики «количество книг на пользователя» А в этом случае — это прямая дорога к тому, чтобы загнуться.

7. Что с этим делать?

Теперь поговорим о вашем проекте.

1. Выявите ключевые жизненные показатели для вашего проекта.
2. Выгрузите по ним статистику и попробуйте найти кластеры.
3. Осмотрите полученные результаты. Что в них вам нравится, что не нравится и что вызывает подозрения?
4. Если вы хотите что-то поменять в вашей статистике — составьте гипотезы, которые, как вам кажется, объясняют влияние каких-то факторов на значение в ваших кластерах. Попробуйте повлиять на эти факторы. Вернитесь к шагу 1 и пройдите цикл снова.

Добавьте к этому типичную статистику: рост юзеров, MAU/DAU, ретеншен, ваши заработки и конверсии — вы получите довольно удобный рабочий компас для принятия решений. С помощью этих чисел можно выстроить правильный маркетинг и проверить свои визионерские решения, при этом не потеряв контакта с реальностью.

8. Outro

Если бы в больнице строили кластеры — довольно быстро бы поняли, что есть разные категории пациентов в здании. Некоторые из них — трупы (это бывает), некоторые из них — со сломанными руками и ногами (им нужен гипс и рентген), а некоторые — уже поправились и могут идти домой.
Конечно, это не решит всех проблем, но на масштабах сотен тысяч больных поможет понять, что на этом этаже у нас инфекционное отделение и там надо применять антибиотики. Мы точно не знаем, кто там и чем болеет, но даже накачка этой области антибиотиками поможет получить более адекватный результат.

Ищите и пробуйте разные подходы к анализу статистики. Анализируйте когорты, пробуйте майнить данные и выделять группы. Ищите отклонения от средних значений, пики и провалы в активности. В общем — попробуйте смотреть на статистику под самыми разными углами. Главное — выйти за пределы стандартных метрик для стартапов и взглянуть на вещи шире.

Да пребудет Сила с вами и вашими делами!