Продуктовые метрики: какие они бывают и как ими пользоваться?

Я работаю CPO в компании с десятками тысяч заказов в день. Недавно стал плотно вовлекать коллег в продуктовые процессы. Оказалось, что не все знают, что такое GMV или конверсия, не говоря уже о более узких метриках, например, session duration или page depth. Расскажу поподробнее в этой статье про метрики и комплексы метрик.

GMV. Основная метрика для большинства сервисов. Расшифровывается как Gross merchandise volume или общий объём оборота товаров/услуг. Измеряется в рублях или любой другой валюте. Проще говоря - весь доход компании до вычета расходов. Как по шагам "очистить" эту метрику от налогов, зарплат, амортизации, комиссий и прочего, чтобы получить показатели чистого дохода, можно почитать тут.

GMV = LTV*PU

LTV. Lifetime value. Доход/прибыль, который приносит в среднем один пользователь за срок своей "жизни" в сервисе. Обычно компании считают LTV360, то есть доход с одного пользователя за год. А все, что получено больше, чем за этот срок, можно потом добавить нарастающим итогом на следующий. Во-первых, потому, что это удобно для расчета годовых планов. Во-вторых, это проще считать. В третьих, мало в каких сервисах люди живут больше года.

Обратите внимание: вам нужно четко понимать, что именно вы хотите измерять - доход или прибыль. Если вы маркетплейс, который живет на инвестициях и которому важен оборот как показатель роста, то измерять стоит доход на пользователя. Если вы сервис, который вышел на самоокупаемость, то в LTV стоит считать прибыль на клиента.

LTV = AOV*Retention

PU. Paying users. Количество пользователей, которые принесли доход.

PU = Traffic*C1.

AOV. Average order value, оно же средний чек. Если у вас есть большие выбросы в числовых рядах (например, 99% пользователей имеет средний чек 1 тыс ₽ и 1% имеет средний чек 20 тыс ₽), то значение среднего чека будет немного не информативным. В таком случае лучше пользоваться медианой чека.

Retention. Возвращаемость пользователей. Day N Retention показывает, какой процент пользователей вернулись к указанному дню. Допустим, если 1го Января в сервис пришло 100 пользователей и 50 из них вернулось на следующий день, а 3го Января из них вернулось 25, то Retention 2го дня будет равен 50%, а Retention 3го дня будет равен 25%. Эта метрика всегда считается по когортам. Все те пользователи, для которых вы замеряете Retention (или любую другую метрику) - это когорты. Например, Retention когорты 25го Января, или Retention когорты мобильных пользователей Ноября 2021 года.

Traffic - это количество пользователей, которые пришли на сервис: ввели ссылку в адресную строку браузера, из поисковика, из рекламы.

С1 - это conversion rate (конверсия) первой покупки. Например, если из 100 пришедших новых пользователей пятеро совершили покупку, то С1 = 5%.

C1 в расчете платящих пользователей нужно только для того, чтобы посчитать, сколько из тех, кто пришел, совершил первую покупку (то есть, стал платящим пользователем). В дальнейшем в продукте разумнее смотреть общую конверсию для всех покупок пользователя - и первых, и последующих. Давайте поговорим об этом поподробнее.

Конверсия - это переход из одного этапа в другой (в целевое действие).

Обычно самая главная конверсия - из сессии в покупку или подписку.

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

На графике часто можно увидеть то, что глазами в таблице воспринять сложно. В данном примере огромная просадка конверсии происходит на переходе из поиска в карточку товара. Значит, пользователь не может найти то, что ему нужно. Причин может быть много: неудобный поиск, плохой контент, неактуальный ассортимент, неверные ожидания пользователя от сервиса и тд. Найти и устранить их должен продакт.

Кроме того, мои продакты отдельно смотрят конверсии из всех страниц в покупку. Допустим, кто-то мог найти товар в дереве каталога, кто-то мог найти товар на главной в подборке акций, а кто-то мог найти его через поиск. У всех этих пользователей разная конверсия.

Воронок мы смотрим тоже несколько. Не все пользователи попадают на главную. Кто-то приходит из Гугла или Яндекса сразу на карточку, после чего переходит в корзину. А кто-то заходит на главную и пользуется поиском. А кто-то пользуется поиском, но добавляет товары из автоподсказок или поисковой выдачи и вообще не попадает на карточку товара потому, что потом сразу идет в корзину и оформляет.

Если у вас B2B2С сервис (например, маркетплейс), нужно отдельно смотреть воронку конверсий селлера. Сколько селлеров подали заявку, сколько из них вы рассмотрели, сколько из них вы одобрили, сколько из них выставили хотя бы 1 товар, сколько из них хотя бы 1 товар продали.

Там же можно посмотреть воронку товаров. Сколько товаров отправили на модерацию, сколько из них было одобрено, сколько из них посмотрели пользователи, сколько из них добавили в корзину, сколько из них купили.

Конверсию нужно смотреть по дням, неделям или месяцам. Чтобы видеть динамику роста или падения. Если есть просадка - нужно бежать проверять трафик, работоспособность микросервисов, последние релизы и тд.

Я и многие другие стейкхолдеры регулярно смотрим продуктовые показатели всей компании на общем дашборде (попозже будет целый раздел о дашбордах). Расскажу о таких общих показателях поподробнее.

Но сначала давайте остановимся на линиях тренда. Это линия, которая в сложном, волатильном графике покажет вам динамику роста.

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

DAU/MAU. Daily active users и Monthly active users. Количество активных пользователей сервиса в день и в месяц. Очень важный показатель, который позволяет видеть динамику и просадки/пики.

Orders. Кол-во заказов. Или подписок, если у вас подписочные сервисы.

Old vs New. Соотношение новых и старых пользователей (обычно смотрят внутри графиков GMV и DAU/MAU). Еще можно на одном графике смотреть разные показатели новых и старых пользователей (именно показатели, а не их соотношение) - например, выводить средний чек старых и новых.

Session duration. Длительность сессии. Казалось бы, если сервис хорош, то для принятия решения пользователю не нужно много времени. И чем сессия короче, тем лучше: значит, человек смог быстро что-то выбрать и оплатить. Но обычно чем сессия длиннее, тем выше вероятность, что пользователь сконвертируется в целевое действие.

Page depth. Глубина просмотра страниц. То есть, количество страниц, которые пользователь просмотрел за сессию. Аналогично метрике выше: обычно, чем показатель больше, тем лучше.

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

ARPU. Average revenue per user. Применяется для подписочных сервисов. Средняя сумма оплаты на пользователя. К вам пришло 100 пользователей. Из них 5 купило подписку за 100 ₽, а 5 за 200 ₽. ARPU будет (5*100 + 5*200)/100 = 15 ₽.

ARPPU. Average revenue per paying user. Применяется для подписочных сервисов. Средняя сумма оплаты на платящего пользователя. Если брать те же условия, что и выше, то получится 150 рублей. Потому, что делим не на 100 (то есть не на всех пользователей), а на 10 (то есть, заплативших).

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

Обычно на дашборде очень хорошо смотреть одну тематику по разным срезам. Все то, что я описал (трафик, конверсия, кол-во заказов, DAU, GMV и тд) в разрезе городов, платформ, источников, способов доставки и тд.

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

Давайте рассмотрим примеры пары продуктовых команд, которые работают внутри выдуманной мной компании.

Команда А. Компания занимается продажей замороженной выпечки: пирогов, пирожков, пиццы. Компания решает расширить свой ассортимент, например, авторскими свежими тортами. Для этого собирают новую команду, которая себе заведет отдельный дашборд, на котором могут быть:

Команда Б. Компания понимает, что покупатели хотят свежие торты как можно раньше, а их курьерская доставка через 2 дня не подходит. Приходит понимание, что нужны новые способы доставки: самовывоз из магазина и экспресс-доставка на велосипедах. Новая продуктовая команда начинает работу и заводит себе дашборд, на котором смотрит графики, на каждом из которых показатели для разных типов доставки:

Скорее всего, по каждому из направлений доставки перед стартом работ была защита и есть плановые метрики. Поэтому команде нужно будет отслеживать еще для каждого способа план и факт. Как минимум, по количеству заказов или GMV.

Итак, мы можем сделать первый вывод: Есть отдельные продуктовые и бизнесовые метрики по компании, которые очень важны. Но у каждой команды есть еще отдельные дашборды с общими метриками по их направлению.

Но у каждой команды в работе может быть одна или даже несколько страниц сервиса. Про метрики этих страниц мы уже в целом поговорили. Но страницы состоят из разных элементов и кнопок. Поэтому мы делаем второй вывод: для разных элементов страниц нужно отслеживать свои метрики.

В идеальном процессе после формулирования и расчета гипотезы, а затем проработки дизайн-макетов и проведения UX тестов макет попадает к продуктовому аналитику. Который дополняет карту ивентов. Пишет, какой ивент на каком элементе располагается. Ивент - это такое событие, которое передается в базу данных, когда пользователь выполняет действие. Чтобы знать, что пользователь, зашедший на страницу нажимал те или иные кнопки, переходил к тем или иным разделам, вводил данные, получал ошибки и тд. Эта карта ивентов попадает в разработку вместе с продуктовой постановкой, а потом по ивентам продуктовый аналитик может сделать различные выводы о пользовательском опыте.

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

Пример 1. Карточка товара (страница конкретного тортика, на котором его фото, описание и тд, а так же возможность добавить его в корзину) во многих сервисах содержит раздел "Пользователи так же интересовались". Для простоты дадим разделу рабочее название "Аналоги".

Продакт, который отвечает за эту страницу и этот раздел, отдельно смотрит различные метрики, например:

Пример 2. Поиск на сайте или в приложении:

Пример 3. Так как тортики в нашем сервисе появились недавно, большинство пользователей до сих пор приходит только за заморозкой. И надо им сообщить о тортиках. Для этого маркетологи делают баннер, в котором пишут "У нас на сайте есть прекрасные тортики. Купи тортик сегодня и получи скидку 300 рублей". И кнопку - перейти в раздел тортиков. Команда под эту гипотезу создает небольшой дашборд:

Продакт команды уже предварительно посчитал, когда прорабатывал гипотезу: сколько человек перейдет, сколько из них купит. Насколько изменится средний чек, насколько вырастет прибыль. И, разумеется, Unit-экономику: потенциальный доход не должен превысить расходы на скидку. По крайней мере, если это заранее не заложил продакт или маркетолог. Осталось только проверить, что экономика по факту сходится. Или изменить условия.

Frequency. Частотность покупок. Точнее, частотность выполнения целевых действий.

CTR. Click through rate. Конверсия из показа в клик (переход). 100 человек увидели баннер, 15 перешло. CTR = 15%

CSI, NPS и CES. Три метрики, которые показывают, насколько пользователь доволен.

CSI - это Custorer Satisfaction Indicator или индикатор пользовательской удовлетворенности. Знакомое многим "оцените наш сервис от 1 до 10".

NPS - Net Promotion Score. Готовность рекомендовать сервис. Все еще знакомое, но реже встречающееся "Насколько вы готовы рекомендовать наш сервис друзьям и близким от 1 до 10"

CES - Customer Effort Score. Одна из важнейших метрик, которую в России почему-то почти не используют. Коэффициент того, насколько сложно пользователю выполнить какой-то шаг в своем CJM (карте пользовательского пути). Например, при оформлении тортика первый раз может быть высокая конверсия, но при этом высокий коэффициент сложности. Почему так бывает? Потому, что у пользователя есть скидка на первый заказ и большая мотивация завершить заказ. Но завершить его трудно - неудобные элементы оформления, сложный выбор адреса и тд. Это - плохой продукт. В хорошем конверсия должна быть высокой, а CES - низким. Если вы знаете, почему его обычно не трекают, пишите в комменты.

CAC - Customer acquisition cost. Стоимость привлечения пользователя. Обычно стараются, чтобы CAC был ниже, чем LTV.

ROI. Return on investment. Показатель возврата инвестиций. Вкладываете деньги, например, в рекламу. Покупок становится больше. Смотрите, сколько заработали, вычитаете сумму вложений за рекламу.

Acquisition rate, Churn rate. Приток и отток пользователей. Churn rate (отток) обратно пропорционален показателю Retention. Приток должен быть выше оттока. Приток новых пользователей зависит, в основном, от маркетинга. Показатель оттока зависит, в основном, от качества и условий сервиса.

Reactivation Rate. Показатель реактивации. Пользователей, которые перестали пользоваться сервисом, можно вернуть. Как правило, маркетинговыми коммуникациями. Количество вернувшихся клиентов к количеству рассылок - это и есть Reactivation Rate.

Referal. Показатель реферальных клиентов. То есть, пользователей, которые пришли к вам по рекомендации других пользователей. Отслеживаются они по персональным промо-кодам, которые им дали друзья. Обычно и реферал, и референт получают бонусы. Как правило, компания в рамках реферальной программы тратит денег меньше, чем на CAC, а показатели таких пользователей часто выше: покупают чаще, дольше и на большие суммы.

Доля лояльных пользователей и метрики лояльных пользователей.

Есть множество специфичных метрик, которые употребляются редко и которые приводить в статье нет смысла, иначе она превратится в учебник. Например, AHT - Average handling time. Среднее время обработки вызова оператором в контакт-центре.

Итак, мы поговорили о следующих штуках:

Пришло время двигаться к еще более крупному представлению - комплексам метрик. Это несколько показателей, которые с одного взгляда показывают состояние продукта в компании.

Таких комплексных метрик тоже бывает много. Наиболее часто встречающиеся - HEART (придумали в Google) и воронка AARRR (придумал основатель проекта 500 Startups Дэйв Макклюр).

HEART

AARRR

Я рассказал вам об основных метриках. Не все из моей статьи может на 100% подходить вашей компании. Как только делаешь шаг влево или шаг вправо, то сразу появляется своя специфика. Уже надо считать не средний чек, а медиану чека. Уже надо считать не Classic Day N Retention, а Rolling Retention. Кому-то подходит LTV360, а кому-то нет. Кто-то считает "старым" клиентом того, который не первый раз на сайте, а кто-то того, кто уже раньше платил. А кому-то приходится маржу делить на NPS и умножать на реферальность, чтобы получить свою узкоспециализированную метрику.

Если вы только знакомитесь с метриками, то прочитав статью или пройдя Go Practice, не сможете полноценно построить и управлять системой метрик. Для этого должно пройти много времени, вы должны решить много кейсов и найти много ответов на совершенно разные вопросы. Но раз вы тут - значит, двигаетесь в верном направлении. Дерзайте и у вас все получится!

Спасибо за критику/дополнения Ростиславу Оголенко, главе продуктовой аналитики Здравсити.