На собеседованиях почти всегда звучит один вопрос: «А какие были метрики?» И почти всегда в этот момент кандидат начинает натягивать цифры. Опытный продакт или лид это сразу слышит. Я и сама так делала 🙈 — пока не разобралась, как вообще связаны метрики разных уровней и где в этой цепочке моя работа.

Недавно мне попалась хорошая схема — пирамида метрик от канала No Data No Growth. Она показывает, как связаны бизнесовые, продуктовые и сервисные метрики. Разберу её и расскажу, как сама выбираю метрики, на двух своих кейсах.

Три уровня пирамиды

Бизнесовые — что получает бизнес

Выручка, рост, прибыльность, юнит-экономика, деньги. Revenue и MRR, Gross Margin, LTV и CAC, Burn Rate и Runway. Это язык CEO и инвесторов. Дизайнер напрямую почти никогда не двигает эти цифры, но должен понимать, на какую из них в итоге работает его задача.

Продуктовые — что делает пользователь

Это путь пользователя по воронке AAARRR: Awareness, Acquisition, Activation, Revenue, Retention, Referral. Охват и узнаваемость, трафик и конверсия в регистрацию, онбординг и время до «ага-момента», конверсия в оплату и средний чек, удержание и отток, NPS и рекомендации. Тут живёт основная работа продуктового дизайнера и продакта.

Сервисные — как работает система

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

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

Как я выбираю метрики

Покажу на кейсе Choco Business — кабинета мерчанта в Chocofamily. Подробно он описан у меня в портфолио, здесь только про метрики.

1. Начинаю с поведения, которое нужно изменить

Мерчанты почти не создавали акции сами и перекладывали это на отдел сервиса. А те, кто создавал, часто не возвращались: их акции плохо покупали. Метрика появляется из этого поведения. Список «стандартных» метрик тут не помощник.

2. Ищу, кто видит проблему каждый день

Данные — это не только аналитика. Самым полезным источником в этом кейсе стал отдел сервиса, который каждый день общается с мерчантами. Плюс коммерческие данные в Power BI и разговоры с продажами. Из этого стало понятно, почему акции не покупают: плохие фотографии и слабый текст, мало доверия к заведению, у мерчантов нет экспертности, чтобы сделать хороший контент.

3. Выбираю одну метрику, которую моя задача может сдвинуть

На платформе мерчанта было много метрик: просмотры, покупки, повторные покупки, оценки, активация купонов, выплаты. Но мой флоу создания акции напрямую влиял только на одно — насколько легко и быстро мерчант соберёт карточку сам. Поэтому главной метрикой стала скорость заполнения карточки акции. Мы добавили шаблонные фото и тексты, понятный порядок шагов и FAQ, и скорость выросла примерно на 30%.

4. Связываю её с уровнем выше и честно говорю, что не измерила

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

Одна метрика, которую вы реально сдвинули, и честное «вот на что это должно влиять дальше, но этого я не мерила» убеждают сильнее, чем пять цифр, которые не выдерживают двух уточняющих вопросов.

5. Если продукта ещё нет, беру точку отсчёта из исследования

В кейсе Damu я проводила discovery для CRM детских и образовательных центров. Продукта ещё не было, значит, и метрик после запуска тоже. Зато в интервью появилась цифра, от которой можно оттолкнуться: администратор тратит до 2 часов в день на таблицы, чаты и напоминания. Это и есть база, с которой потом сравнивать.

Исследование дало и приоритеты. Чаще всего говорили про расписание и переносы, тяжелее всего — про оплаты и задолженности. Отсюда MVP: заявки, клиенты, расписание, напоминания, оплаты. Отчёты и аналитику отложили.

Не всё измеряется цифрами

Главное открытие в Damu было качественным: CRM люди не ищут. Они устали вести записи, оплаты и расписание вручную. Поэтому продукт стоит продавать как «администратора на автопилоте». Это изменило позиционирование и приоритеты ещё до разработки. В кейсе такой результат так же важен, как цифра, главное — назвать его честно и не выдавать за число.

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

Что делать, если метрик нет совсем

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

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

Простое правило: найдите на пирамиде уровень, на котором работала ваша задача, назовите одну метрику, которую вы сдвинули или собирались сдвинуть, и одной фразой объясните, как она связана с уровнем выше.

Где дизайнер, а где продакт

Продакт-менеджер обычно отвечает за всю продуктовую воронку и должен понимать, как она поднимается до бизнесовых метрик: почему рост Retention меняет LTV, а LTV — юнит-экономику. Продуктовому дизайнеру считать юнит-экономику не обязательно, но важно уверенно говорить про Activation, Retention и конверсии в своём сценарии и понимать, на какую бизнесовую цель работает задача. Сервисные метрики полезно знать обоим хотя бы на уровне «что может сломать мой сценарий».

Как я применяю пирамиду в CaseSociety

Свой продукт раскладываю так же. Главная метрика CaseSociety сейчас — сколько людей в неделю собрали в CaseLab готовый кейс. На пирамиде это продуктовый уровень, Activation: человек получил ценность. Статьи и посты работают ниже по воронке — на Awareness и Acquisition. А платные разборы и консультации — это Revenue, который появляется уже после того, как человек получил результат бесплатно.

Метрики разных уровней в кейсе можно разложить в CaseLab: там пирамида встроена в шаги, и можно проверить, на каком уровне работала ваша задача и что про неё сказать на собеседовании.

А вы на каком уровне пирамиды обычно работаете? И какую метрику сложнее всего защищать на собеседовании?