Вы читаете вторую статью из серии «Дизайнер и метрики». В первой статье я пытался ответить на вопрос, нужны ли дизайнеру метрики. Ее можно найти тут. В новой статье я хочу рассмотреть, какие бывают метрики, как можно их использовать и на какие метрики опираться при оценке своей работы. Предлагаю не вдаваться в теорию, а сразу взять конкретную метрику и посмотреть, что это такое и как она работает. Начнем с retention — метрика, которая показывает возвращаемость пользователей. То есть, если сегодня наше приложение скачало 100 новых пользователей, то retention ответит на вопрос, сколько из них к нам вернется завтра, через месяц и так далее. Допустим, что retention второго дня равен 60% — это значит, что на второй день приложение запустят 60 пользователей из 100 скачавших.  Эту метрику можно посчитать на любой день жизни пользователя. Допустим, retention 7 дня равен 30% — это означает, что на 7 день с момента скачивания в нашем приложении останется 30 человек из 100 скачавших. Тут важно отметить, что в один и тот же день в сервис заходят как пользователи, которые только сегодня скачали приложение, так и те, кто пользуется им уже давно. А значит, у каждого пользователя свой второй день пользования приложением. Допустим, у меня это было две недели назад, а у кого-то — сегодня. В итоге мы берем каждого пользователя, смотрим на его «второй день», и считаем, зашел он в сервис или нет. Затем смотрим, какой процент все-таки зашел — это и будет показатель retention второго дня. Допустим, наше приложение скачали 1000 раз за неделю. Во второй день из этой тысячи зашли 600 пользователей, а в седьмой — 300. Используя эти данные, мы можем посчитать retention второго дня — 600/1000 = 60%, и retention седьмого дня — 300/1000 = 30% Она быстро даёт понять, удалось ли нам сделать продукт, который был полезен пользователю, или он пощёлкал, посмотрел и удалил. Если retention какого-то дня составляет 0%, значит, из всех, кто когда-то скачивал приложение, никто в нем не остался, и приложение никому не нужно. Может, стоит его закрыть? Хочу сразу отметить, что в некоторых приложениях retention нужно трактовать иначе — допустим, дейтинг. Пользователь нашел пару — больше условный «Тиндер» ему не нужен. Но чаще всего цель разработки приложения — найти пользователей, которые будут пользоваться им в течение длительного времени. То есть, с какого-то дня retention должен перестать убывать — retention 90 дня должен быть равен retention 180 дня и так далее. В таком случае аналитики говорят, что retention вышел на плато. Если у продукта большая и постоянно растущая аудитория, это свидетель того, что продукт вышел на плато retention — как Facebook, Telegram, Google Maps и так далее. Отойдем на шаг назад и посмотрим, какие вообще бывают метрики. Выделяют 2 типа: метрики роста и метрики продукта Допустим, у нас есть некое мобильное приложение. В него попадают пользователи, как-то с ним взаимодействуют, и по итогам этого взаимодействия приложение зарабатывает деньги. То, как это приложение «перерабатывает» пользователей — метрики продукта. Допустим, сколько денег компания получает с каждого нового пользователя. А метрика роста — это то, что получается после этой «переработки», например выручка компании за год. Как думаете, retention — это метрика роста или метрика продукта? Определить это поможет очень простое правило: увеличьте в разы количество пользователей, скачавших приложение. Если показатели метрики при этом не изменятся, значит, это метрика продукта. Допустим, мысленно сравняйте количество пользователей своего приложения с количеством пользователей Facebook. Retention приложения при этом останется неизменным. Как был 30% на седьмой день, так и останется. А значит, Retention — это метрика продукта. А что произойдет с выручкой? Выручка при увеличении аудитории заметно взлетит. Если один пользователь приносил нам 10₽, то 100 пользователей принесут нам 1 000 ₽, а 1 000 000 пользователей — 10 000 000 ₽. Получается, что выручка (или revenue) — это метрика роста. Итак, метрики роста отвечают на вопросы: — Растет или падает дневная аудитория нашего приложения? — Сколько зарабатывает наш продукт? А метрика продукта: — Сколько денег нам приносит один средний пользователь? — Какая часть пользователей остается с нами спустя месяц после установки приложения? Все дизайнерские решения каким-то образом влияют на метрики. Поэтому если в них разбираться, можно лучше понять — удалось ли вам улучшить продукт или ваш новый дизайн сделал все только хуже? Конечно, проще всего было бы ответить на эти вопросы, посмотрев на метрики роста. Мол, если мы стали больше зарабатывать — значит, все не зря, а если начали зарабатывать меньше, то что-то идет не так. Но в этом подходе кроется ошибка, которая может стоить продукта. Чтобы лучше разобраться, почему при оценке дизайна или редизайна не стоит опираться на метрики роста, давайте разберем следующий кейс: Допустим, в команду разработки пришел плохой менеджер и выбрал для развития фичу Х. Под новую фичу компания нанимает команду маркетинга, которая начинает активно привлекать трафик. Команда выкатывает эту фичу — и она оказывается неудачной. Метрики продукта — то есть, retention, возвращаемость пользователей — летят вниз. Продукт начинает хуже удерживать пользователей, доход на нового пользователя уменьшается. Но из-за того, что в продукт было привлечено намного больше трафика, новые пользователи маскируют ухудшение в метриках продукта и компания начинает зарабатывать больше. Потому что на метрики роста влияет 2 составляющих — сам продукт и его продвижение.  Получается, что по метрикам продукта все очень плохо, но по метрикам роста — просто отлично. И руководство, посмотрев на метрики роста, радуется и повышает плохого менеджера, который только испортил продукт. Такой случай — не редкость в компаниях. Изучая метрики, вы сможете помочь своей компании этого избежать и более убедительно аргументировать свои выводы и дизайнерские решения. Это была 2 статья из серии «Дизайнер и метрики». В следующей статье я планирую рассказать как сравнивать изменение метрик что было до релиза и что стало после, как понять улучшили мы продукт или нет. Подписывайтесь, чтобы не пропустить. Product designer