Продуктовая аналитика: Матрица Интенсивности

Сегодня мы продолжим тему продуктовой аналитики и обсудим вопрос интенсивности использования продуктом. 

В прошлом посте я сказал, что степень вовлеченности можно измерять интенсивностью использования. И привел пример с отправкой сообщений:

• Клиент за месяц сгенерировал 293 события message_send_text.
• Клиент пользовался этой фичей 14 дней в месяц - avg_days_cnt.
• В среднем, он отправлял 21 сообщение в день - avg_hits_per_day.

Очевидно, что общее количество событий является производной от количества дней пользования фичей и количеством совершенных действий в день. Поэтому дальше мы будем рассматривать только эти два базовых измерения.

Эти 2 измерения говорят нам об абсолютно разных паттернах поведения: каких-то действий нам нужно сделать много в день, а какие-то действия нам нужно повторять много дней. 

Рассматривать их отдельно не рекомендуется. Более того, только вместе они позволяют нам приоткрыть занавес и посмотреть как именно клиенты пользуются нашим продуктом. 

Для этого давайте снова построим матрицу - в этот раз Матрицу интенсивности:

• ось Х: показывает ежедневную повторяемость фичи, за нее отвечает метрика avg_days_cnt 
• ось Y: показывает дневную интенсивность, за нее отвечает метрика avg_hits_per_day

LOG(avg_days_cnt) x LOG(avg_hits_per_day) 
(кликните, чтобы увеличить картинку)

Матрица интенсивности ничего не говорит нам о том, сколько клиентов воспользовались той или иной фичей. Для этого есть Матрица Вовлеченности, о которой мы говорили в предыдущем посте.

В тоже время, мы могли бы добавить % MAU в качестве размера точки события. И хотя это добавляет контекста нашему графику, работать с 3-мя измерениями одновременно будет определенно сложнее. Здесь все зависит от вашего опыта.

 

LOG(avg_days_cnt) x LOG(avg_hits_per_day) + %MAU 
(кликните, чтобы увеличить картинку)

Итак, Матрица интенсивности показывает нам какие есть паттерны использования у разных фич. 

Давайте рассмотрим несколько примеров.

Фича tasks_view используется и интенсивно и регулярно. Это одна из core-фич.

Она закрывает важную потребность как в течение дня, так и на уровне месяца. Фактически эта фича максимально формирует привычку пользоваться инструментом task. Если ее логика сломается и/или изменится, то это будет иметь огромное влияние на вовлеченность. 

Такую фичу стоило было бы вынести в прокси-метрику: взять % клиентов, которые используют ее в течение месяца (возможно добавив какой-то порог: X раз в месяц или Y дней). Если этот % начинает снижаться - это очень серьезная проблема на которую стоит бросить все силы продуктовой команды.  

Фичи tasks_copy и tasks_subtask_add используются не так регулярно. Но при этом у них достаточно высокая интенсивность использования в течение дня.

Это говорит нам о том, что такие фичи используются клиентами в пакетном режиме: у клиента периодически возникает потребность сделать сразу N таких действий, и вероятно стоит для таких фич делать доп. функционал, который поможет делать такую работу быстрее и/или умнее. 

Например, если есть какой-то текст (например, в посте) и из него потребуется создать несколько подзадач, то клиента можно сразу спросить сколько подзадач он хочет сделать и, собственно, сделать их. 

Указав один раз настройки для первой такой подзадачи, все остальные (автоматически созданные) подзадачи будут сразу преднастроены, а текст скопирован в каждую из них. И клиенту останется лишь подредактировать текст для каждой из таких подзадач. Если таких подзадач 3+, то это существенно сократит время и повысит удовлетворенность. 

Внимательный читатель возможно отметил, что я только что предложил доработать фичу так, чтобы ее интенсивность после доработки снизилась! 

А это подводит нас к такому интересному вопросу - всегда ли нужно, чтобы клиент проводил в продукте максимальное количество времени? Нет ли здесь противоречия?

Короткий ответ - это зависит. 

• если ваш продукт дает клиенту fun и использует рекламную модель монетизации, то уменьшение времени в продукте, очевидно, ударит по заработку компании. 
• если же ваш продукт приносит ценность другого характера, например повышает эффективность, то картинка м.б. обратная. Чем быстрее клиент справляется с задачей, тем больше он доволен продуктом. 

Поэтому интенсивность стоит интерпретировать в контексте. И контекст этот - монетизация и/или ретеншн. 

В следующем посте мы разберем какие инсайты по фичам можно сделать используя кластеризацию интенсивности использования продукта.