Средняя температура по больнице, кластеры данных и принятие решений в проекте02.11.2015 13:21

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 и пройдите цикл снова.

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

8. Outro

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

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

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