Твоя работа как продакт-менеджера заключается не в генерации гипотез, а в поиске решений для получения результата. Кажется, что разница небольшая, но с такой формулировкой фокус смещён на нужную область. Это уже озвучивалось ранее, но мне кажется важным повторить ещё раз: фичи сами по себе никому не нужны. Не нужно вводить функциональность ради функциональности. Внося любое изменение в продукт, ты должен понимать, какой эффект ты надеешься получить. То есть ещё до генерации гипотез должен быть сформирован ожидаемый результат.

1. Определи цель. Часто это влияние на какую-то продуктовую метрику;

2. Выдели сегмент аудитории, для которой хочешь изменить метрику;

3. Определи, какой именно эффект хочешь получить. Например, увеличить Retention D1 до 10%;

4. Сформулируй гипотезы.

Сначала результат, потом гипотезы. Не наоборот. Гипотеза — это инструмент решения задачи, а не сама задача. Представь, что тебе нужно забить гвоздь на 5 сантиметров. Твоё предположение, что это можно сделать молотком. Вот молоток и есть гипотеза.

Реальная практика, конечно же, суровее теории. Будут возникать ситуации, когда ты можешь определить метрику, на которую хочешь повлиять, но твоя цель — получить положительные статистически значимые изменения. Работа над зрелыми продуктами только так и складывается. Такой подход тоже работает, пусть и конкретики меньше. Но даже так сохраняется принцип «результат первичнее гипотез».

Шаблон ожидаемого результата

Для [сегмент/персона] в [сценарий/этап пути] мы добьёмся [изменения поведения], что приведёт к [бизнес-эффекту], измерим через [набор метрик], влияя на [ключевую метрику] через изменение [метрики влияния], при этом соблюдаем [ограничения].

Пример:

«Для новых пользователей на онбординге добьёмся роста активации с 38% до 45%. Измеряем: Ключевая метрика (Primary) — Activation, Метрики влияния (Input) — процент завершения онбординга, Time-to-Value; Ограничения — Retention D7 не ниже 24%, Отказы не ниже 10%.»

Корзина метрик

• Primary (North Star/целевая метрика): одна главная метрика результата;

• Input/метрики влияния: рычаги, на которые ты реально можешь повлиять;

• Guardrails/ограничения: что не должно ухудшиться (удержание, отказоустойчивость, маржинальность и т. д.).

Итого

Ожидаемый результат должен быть:

• Измерим и конкретен: (%, per user, per cohort), а не «сумма за всё время»;

• Основан на ключевой метрике эксперимента;

• Иметь цель, определённые показатели успеха;

• Привязан к сегменту и сценарию.

Пример плохого ожидаемого результата: «+20% MAU».

Как интерпретировать результаты?

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

Правдивая формулировка вопроса скорее «Какими данные должны быть, чтобы правильно интерпретировать результат». Именно на этот вопрос я и отвечаю ниже.

Пять вопросов к любому результату

Ниже перечислены важные вопросы к результату, а в скобках указано, что нужно проверить, чтобы убедиться, что всё в порядке.

1. Измерили ли мы то, что хотели? (валидность метрики, корректность ивентов);

2. Насколько велик эффект? (абсолютный прирост, относительный %, effect size);

3. Данные надёжны? (доверительные интервалы, статистическая мощность, риск ошибки; Sample Ratio Mismatch исключён?);

4. Нет ли предвзятости и противоречий в данных? (есть ли честный контроль; не перепутали сезонность/каналы/миграции?);

5. Учтены внешние эффекты? (не «съели» ли другие показатели: монетизация, стабильность, NPS; нет ли сезонности?).

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

Быстрый чеклист для проверки данных

• Проверь Sample Ratio Mismatch: доли трафика в группах соответствуют плану? Они распределены как задумано? Например, 50/50 для A/B-теста;

• Event-аудит: нет ли потерянных/дублированных событий? Уверен в источнике данных?

• Не навреди: метрики ограничений в норме?

• Переобучение/новизна: эффект не угас через 2–3 недели? Посмотри на ключевую метрику в динамике за период эксперимента и после его завершения.

Сегментация

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

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

Какие сегменты можно выделить дополнительно:

• по источникам трафика;

• платящие / неплатящие;

• по устройствам / операционным системам;

• по географии (страны, регионы, города).

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

Unit-экономика

Совсем хорошо посчитать unit-экономику для каждого сегмента. Unit-экономика может «зарубить» позитивное изменение ключевой метрики, потому что вдруг окажется, что доходы упали по важным или вообще по всем сегментам.

Итого

Чтобы сделать правильно интерпретировать результаты:

1. убедись в достоверности данных;

2. делай выводы по каждому сегменту отдельно;

3. определи влияние на финансовые метрики.

Что делать, если данные неочевидны?

Бывает так, что после эксперимента ключевая метрика стала хуже, и совсем непонятно, почему это произошло. Метрика могла даже вырасти, но найти причины этого с первого взгляда не получается. Данные нередко бывают неочевидны.

Посмотри с разных сторон

• Исследуй воронку и найди шаг, на котором больше «отваливаются» пользователи. Пройди путь пользователя сам или попроси друзей/коллег и понаблюдай;

• Исследуй сценарий пользователя с помощью вебвизора или тепловых карт кликов для разных устройств. Возможно, есть что-то, что мешает пользоваться продуктом;

• Интервью / опросы: поговорить с пользователями всегда полезно.

Сделай метрику чувствительнее

• Перейди от «в среднем» к метрикам «на пользователя / на сессию»;

• Смотри DAU/MAU вернувшихся юзеров и медиану вместо среднего, если распределение с длинным хвостом;

• Введи ранние индикаторы (leading): время до перехода в ключевой сценарий, реферальный эффект, успешные установки.

Управление шумом и мощностью

• Увеличь период наблюдения или размер выборки;

• Раздели пользователей на однородные сегменты (один тип устройства, схожий возраст, схожий доход и т. д.);

• Используй квази-эксперименты (до–после, синтетический контроль), если A/B невозможен;

• Сформулируй решение при неопределённости: «Если прирост > X — раскат; если в [Y; X] — доэксперимент / улучшение дизайна; если < Y — откат».

Не бойся менять вопрос

Иногда ответ «неочевиден» потому, что вопрос был неправильным. Возвращайся к самому началу: какую поведенческую переменную ты хочешь сдвинуть? Возможно, ключевая метрика (North) была выбрана неверно, и вместо того чтобы искать ответ, нужно просто начать эксперимент заново, выбрав другие метрики.

Как избежать ловушек (vanity metrics)?

Vanity-метрики, или метрики тщеславия, красиво растут, но мало что решают: «всего регистраций», «всего скачиваний», «просмотры» без контекста, «лайки». Они:

• кумулятивны (легко растут);

• не нормированы (ни к чему не привязаны);

• слабо связаны с ценностью и деньгами;

• легко манипулируемы.

Проще говоря, такие общие метрики вообще никак не отражают качество продукта и его удобство. В твоём продукте может быть бешеное MAU, но при этом все эти пользователи проводят в продукте меньше минуты и никогда не возвращаются. И какой смысл от большого MAU тогда?

Принципы анти-vanity

• Нормируй: per user / per session / per cohort / per exposure (на контакт);

• Привязывай к поведению: activation, retention, frequency (частота), depth (глубина), conversion (конверсия);

• Следи за качеством: ARPU или ARPPU, LTV или CAC, churn (отток), payback (окупаемость), margin (маржа);

• Ставь ограничения: retention, отказоустойчивость, количество жалоб, возвраты средств;

• Избегай усреднений в тяжёлых хвостах: медиана и P75 (75-й процентиль) часто информативнее среднего.

Что использовать вместо vanity-метрик?

❌ Зарегистрировано всего
✅ Activation D1/D7, Процент завершения онбординга, Time-to-Value

❌ Просмотры страниц
✅ Конверсия по воронке, CTR в ключевое действие, Количество страниц за сессию

❌ Установки
✅ Доля запусков приложения после установки, Retention D1/D7, CAC

❌ Лайки/реакции
✅ Количество активных авторов, количество популярных публикаций

❌ MAU в целом
✅ DAU/MAU активной аудитории, WAU на когорту, доля вернувшихся от общего MAU

Мини-чеклист

Перед стартом эксперимента

• Ожидаемый результат сформулирован по шаблону, понятен сегмент/сценарий;

• Корзина метрик: ключевая + влияния + ограничения, единицы измерения нормированы;

• Гипотезы и риски записаны, метод измерения согласован (A/B, квази и т. д.);

• Ты уверен в источнике данных, распределение групп эксперимента контролируется.

После получения результата

• Эффект: абсолютный и относительный, с доверительным интервалом;

• Валидация причинности и контроль фоновых факторов (сезонность, источники привлечения, релизы в продукте);

• Сегментация: где эффект концентрируется / исчезает;

• Метрики ограничений в норме, внешних издержек нет;

• Решение и следующий шаг: раскат / итерация / откат; обнови приоритеты и карту метрик;

• Зафиксируй результаты эксперимента: контекст → гипотеза → метод → результат → решение → что делать иначе в следующий раз.

Итог шестой главы

• North Star Metric — главная метрика продукта, отражающая ценность для пользователя и коррелирующая с бизнес-результатами;

• Фреймворк HEART (Happiness, Engagement, Adoption, Retention, Task Success) — удобная структура для выбора релевантных метрик;

• Leading и Lagging метрики — нужно балансировать между предсказывающими и фиксирующими результат показателями;

• Источники данных — количественные (аналитика, CRM, финансы, логи) и качественные (интервью, саппорт, продажи); важно интегрировать их в единый «источник правды»;

• Метрики для новых функций — сначала цель, затем ключевая метрика, связанные показатели, сроки и критерии успеха;

• Если аналитики нет — начать с 3–5 базовых метрик и коробочных систем (Яндекс.Метрика, AppMetrica), постепенно выстраивая культуру работы с данными;

• Главные ошибки — гонка за vanity-метриками, игнорирование целостной картины, отсутствие сегментов, подгонка целей под результат;

• Вовлечённость — измеряется частотой, глубиной и регулярностью использования продукта, а не просто «временем в приложении»;

• Retention — зеркало вовлечённости, отражает возвращаемость за ценностью и напрямую связано с монетизацией (LTV);

• Поведение = доход — выручка растёт через активацию, глубину использования, удержание и сегментацию пользователей;

• Интерпретация результатов — важна достоверность данных, проверка эффекта, сегментация и влияние на юнит-экономику;

• Неочевидные данные — нужно копать глубже: анализировать воронку, интервьюировать пользователей, смотреть медианы, увеличивать выборку;

• Vanity-метрики — опасны, так как не отражают реальную ценность. Их заменяют нормированные и поведенческие показатели (activation, retention, ARPU и др.).

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

Яндекс Метрика — на мой взгляд, на российском рынке это ключевой и обязательный инструмент для базовой аналитики вашего продукта в вебе. Достаточно добавить код счётчика — и у вас в руках вся ключевая аналитика продукта «из коробки»: источники трафика; поведенческие метрики; записи сессий; карта кликов; пол, возраст и география пользователей. И всё это без какой-либо дополнительной настройки. Если в команде нет аналитика, то это вообще must-have.

Google Analytics 4 — злобный брат-близнец Метрики. Инструмент мощный, но пользоваться им больно. За рубежом остаётся базовым инструментом для понимания поведения пользователей. Рекомендую подключить счётчик и использовать для «сверки часов», периодически поглядывая, что GA тебе показывает. В Google Аналитике удобно строить воронки и считать конверсии, так как все данные строятся от уников, а не визитов, как в Метрике.

BI и визуализация данных

Системы веб-аналитики хоть и настроены «из коробки», но они собирают не весь набор данных. Да и не всё хочется им передавать, так как данные о продукте будут храниться не на ваших серверах, а у Яндекса или Google. Тут на помощь придут BI-системы, позволяющие объединять в одной системе данные из разных источников, в том числе и из веб-аналитики. В таких инструментах в одном отчёте могут быть и метрики продукта, и данные из биллинга, и даже сведения о сотрудниках. Вообще всё, что только потребуется для аналитики бизнеса. Большой плюс — это полный доступ к данным и широкая кастомизация визуализации.

Tableau — для глубокой аналитики и красивых дашбордов. Если у тебя есть аналитик, это мощнейший инструмент для исследования и визуализации данных. Стандарт в иностранных компаниях.

Power BI — более доступная альтернатива от Microsoft. Хорошо интегрируется с экосистемой Office и Azure. На данный момент используется только настоящими олдами бизнес-аналитики.

Redash — селф-хост система визуализации данных с открытым исходным кодом. На мой взгляд, на этом плюсы закончены. Инструмент стал очень актуальным и популярным в последние годы, но сам по себе он очень тормозной и с рядом ограничений — и по количеству данных, и по возможностям их вывода. Например, воронки там визуализировать «из коробки» нельзя.

DataLens — BI-система от Яндекса. Очень простая, но довольно функциональная. Тут тоже хватает ограничений для визуализации, но их меньше, чем у Redash. Отчёты красивые, грузятся быстро.

Looker (теперь часть Google Cloud) — отличается своим подходом к моделированию данных. Технологичный, мощный и быстрый инструмент. Но, увы, официально в России недоступен.

Специализированные инструменты

Список того, что скорее всего тебе не понадобится, но будет полезно знать, что оно существует.

ClickHouse — тоже инструмент из стандартного набора для аналитики продукта на российском рынке. Пользуются ли за рубежом — не знаю. Но в наших краях встречается в каждой второй компании. Используется для сбора и хранения «сырых» данных по продукту. Туда за данными ходить только со знанием SQL, потому что хранение табличное, без визуализации.

AppMetrica — если коротко, это как Яндекс.Метрика, но для нативных приложений.

Grafana — визуализация технических данных о работе продукта: скорость загрузки и время ответа сервера, ошибки по работе микросервисов и т. д. Место обитания DevOps- и backend-инженеров.

OpenTelemetry — инструмент для записи и визуализации трейсов (путей запросов). Классная вещь для отслеживания взаимодействия микросервисов друг с другом. Обычно используется для отладки. Инструмент сугубо технический.

Как выбирать ключевые метрики для продукта?

Начни с North Star Metric

Каждому продукту нужна одна главная метрика — North Star (буквально — Полярная звезда, которая используется как ориентир для нахождения севера без компаса). Она должна отражать ценность, которую продукт приносит пользователям. Например, для Spotify это время прослушивания, для Slack — количество отправленных сообщений, а для Telegram — количество активных пользователей за период (например, MAU — активные пользователи за месяц).

Критерии хорошей North Star метрики:

• Отражает создаваемую пользователю ценность;

• Коррелирует с бизнес-результатами;

• Может быть улучшена всеми командами, работающими над продуктом;

• Измерима и понятна всем.

Используй пирамиду метрик

Представь набор метрик как пирамиду:

• Верхний уровень (North Star) — одна главная метрика, её обсудили выше;

• Средний уровень (Primary) — 3–5 ключевых метрик, влияющих на North Star;

• Базовый уровень (Secondary) — детализированные метрики для конкретных функций продукта.

Например, для маркетплейсов:

• North Star: выручка на пользователя (Average Revenue per User, она же ARPU);

• Primary: конверсия в покупку, количество заказов на пользователя, Retention (удержание);

• Secondary: процент «брошенных корзин», скорость загрузки страниц, время ответа поддержки.

Применяй фреймворк HEART от Google:

В скобках указаны примеры метрик.

• Happiness — удовлетворённость пользователей (NPS, уровень удовлетворённости);

• Engagement — вовлечённость (DAU/MAU, длительность сессии);

• Adoption — принятие новых функций (feature adoption rate — процент использования какой-либо фичи в продукте);

• Retention — удержание (retention, процент оттока);

• Task Success — успешность выполнения задач (Time to Market — скорость доставки до пользователей; количество багов в продукте).

Для каждой категории выбери 1-2 метрики, наиболее релевантные твоему продукту. Подробнее.

Баланс между leading и lagging индикаторами

Lagging (буквально — лагающие) метрики показывают результат (выручка, отток — churn rate). Они важны для понимания итогов, но картина по ним ясна не сразу, с задержкой.

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

Идеальный набор метрик включает оба типа. Например, если ты видишь падение вовлечения (engagement — leading-метрика), можешь предугадать будущий рост оттока (churn — lagging-метрика).

Какие источники данных использовать?

Для более полной аналитики и правильных выводов использовать нужно несколько источников сразу. Какие источники бывают:

• Встроенная аналитика продукта (события, логи, платежи);

• CRM и биллинг (чтобы видеть реальные транзакции и поведение клиентов);

• Поддержка и обратная связь — тикеты, комментарии, соцсети. Иногда данные о качестве (они же — фидбек пользователей) важнее цифр;

• Маркетинговые каналы — рекламные кабинеты, UTM-метки, трекинг кампаний;

• A/B-тесты — источник причинно-следственных связей, а не просто корреляций.

Какие метрики «лежат» в этих источниках:

1. Платёжка и биллинг: выручка (Revenue), ARPU/ARPPU, возвраты, налоги, комиссии;

2. Маркетинг/атрибуция: каналы, CAC (стоимость привлечения), payback (возвраты средств), ROAS (возвращаемость рекламных затрат), доля органического трафика;

3. CRM/саппорт: количество обращений, причины оттока, сегменты клиентов, SLA (уровень обслуживания);

4. Качественные источники: интервью, дневниковые исследования, in-product опросы (NPS — индекс лояльности к бренду, CES — индекс усилий);

5. Наблюдаемость/логирование: производительность, ресурсоёмкость, стабильность;

6. Открытые источники/бенчмарки: отчёты рынка, анализ отзывов на приложение, общение с комьюнити.

Правило 70/20/10: 70% решений — на поведенческих данных, 20% — на качественных инсайтах, 10% — на рыночных референсах — позволит держать идеальный баланс контекста для принятия решений.

Количественные источники

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

• Финансовые системы — для бизнес-метрик. CRM, биллинговые системы, accounting software. Здесь живут данные о revenue, LTV, CAC;

• Технические логи — для метрик производительности и надёжности. Server logs, error tracking systems, performance monitoring;

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

Качественные источники

• Пользовательские интервью — золотая шахта инсайтов. Регулярные интервью с пользователями дают контекст к цифрам. Рекомендую проводить минимум 5 интервью в месяц;

• Данные из поддержки — тикеты, логи чатов, FAQ. Здесь видны реальные проблемы пользователей;

• Отдел продаж — они на передовой, знают возражения клиентов и причины отказов;

• Записи визитов пользователей — наблюдение за тем, как пользователи взаимодействуют с продуктом в реальном времени.

Интеграция источников данных

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

Как выбирать метрики для новых функций?

1. Определи гипотезу — чего мы хотим достичь? (например, увеличить удержание на 7‑й день);

2. Выбери ключевую метрику — ту, по которой будет приниматься решение о релизе;

3. Добавь связанные метрики продукта — чтобы новая функция не ухудшила другие важные показатели;

4. Определи срок — установи, когда функция должна показать эффект (неделя, месяц и т. д.).

5. Протестируй измеримость — часто при релизе метрики оказываются не привязаны к событиям, и ты получаешь «чёрную дыру» в аналитике.

Определи цель функции

Перед запуском новой функции чётко сформулируй, какую проблему она решает. Это определит тип метрик:

• Экономят время — измеряй время выполнения сценария, конверсию в последний шаг воронки;

• Увеличивают использование — adoption rate, частота использования;

• Приносят доход — конверсия в оплату, ARPU;

• Удерживают пользователей — retention, churn impact.

Используй трёхуровневую систему метрик

Level 1: Внедрение

• Сколько пользователей обнаружили функцию;

• Сколько попробовали использовать;

• Сколько смогли успешно завершить первое использование.

Level 2: Вовлечение

• Daily/Weekly Active Users; 

• Частота использования;

• Количество созданных элементов (постов, добавленных товаров в корзину, комментариев и т. д.).

Level 3: Влияние на бизнес метрики

• Основные продуктовые метрики;

• Ретеншн;

• Выручка.

Сформулируй план до начала разработки

• Как сейчас — зафиксируй текущее состояние ключевых метрик перед запуском;

• Критерии успеха — определи конкретные цифры успеха. Например: «30% пользователей попробуют функцию в течение первого месяца»;

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

A/B тестирование новых функций

Если продукт большой, не запускай функции сразу для всех пользователей.

«Раскатывай» постепенно:

• Доступ только для команды продукта — проверка базовой функциональности на настоящих данных;

• Бета‑тест на ограниченной группе пользователей — 1–5% пользователей;

• Постепенное расширение сегмента — 25% → 50% → 100%.

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

На небольшом продукте с маленькой активной аудиторией второй этап можно пропустить. А иногда и третий, если совсем небольшой продукт. Тут главное — быть уверенным, что новая фича ничего не ломает в продукте. А это не всегда можно выявить на тестовых стендах.

Как внедрить аналитику, если сейчас её совсем нет?

Подобная ситуация может встречаться в стартапах. Продукт есть, а никакой аналитики по нему ещё нет. Более того, культуры смотреть на цифры может не быть.

Начни с малого

Не пытайся построить идеальную систему метрик сразу. Начни с 3–5 ключевых показателей, которые действительно влияют на принятие решений. Постепенно расширяй список по мере роста зрелости команды.

Самый простой способ получить первую аналитику — подключить коробочную систему аналитики (Яндекс.Метрика, AppMetrica — как вариант).

Создай культуру данных

Метрики работают, только если вся команда их понимает и использует. Проводи data reviews, обучай команду интерпретации данных, празднуй успехи в достижении целевых показателей.

Не забывай про контекст

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

Какие главные ошибки при работе с аналитикой?

• Гонишься за vanity-метриками (метриками тщеславия). Просмотры без их качества ≠ ценность. Одним словом, большое MAU вообще ничего не говорит о качестве продукта;

• Не смотришь на метрики по всему продукту. Улучшил клик на баннер — уронил удержание через неделю;

• Сравниваешь несравнимое. Сравнивай с похожими периодами (месяц к месяцу, год к году, но не неделя к месяцу или день к году), используй контрольные группы (например, в рамках A/B-тестов);

• Смешивание сегментов. Новички ≠ старички; платящие ≠ неплатящие. Делай срезы и сравнивай влияние в рамках сегментов;

• Подгонка цели под результат. Сначала нужно определить цель и уже потом делать выводы о её достижении. Не наоборот. Не нужно формулировать или корректировать цель, исходя из результатов эксперимента.

Метрики вовлечения

Что такое вовлеченность и как её измерить?

Что такое

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

Примеры вовлечённости в разных продуктах:

• В играх (да, они тоже продукт): игрок завершает 3+ сессии в неделю, открывает новые уровни, совершает покупки;

• В таск-трекере: команда создаёт и закрывает задачи ежедневно, не теряет темп работы;

• В соцсети: пользователь читает, сохраняет и шэрит посты ежедневно.

Как измерить

Чтобы измерять вовлечённость, определись с core value loop (ключевой сценарий / воронка) и выдели ведущие метрики, отражающие получение этой ценности.

Три слоя вовлечённости:

• Частота — как часто пользователь взаимодействует с продуктом (DAU, WAU, количество сессий на пользователя в сутки);

• Глубина — насколько «внутрь» продукта заходит (завершённые сценарии: прочитанные статьи, уровни, созданные объекты; прохождение воронки);

• Регулярность — образуется ли привычка (сколько дней в неделю/месяц пользователь использует продукт).

Что показывает коэффициент удержания пользователей?

Степень удержания можно определить по показателю Retention — это зеркало вовлечённости. Он показывает, сколько пользователей продолжают возвращаться за ценностью спустя N дней/недель после первой сессии.

Варианты удержания

• Классический N-day retention: вернулся именно на N-й день (D1, D7, D30);

• Rolling retention: был активен на N-й день или позже. Удобно для верхнеуровневых ориентиров, но всегда выше классического и может «маскировать» проседания;

• Weekly/Monthly retention: для сценариев с естественной недельной/месячной периодичностью (финансы, покупки, B2B). Например, СМИ часто используют Retention W1, то есть удержание в первую неделю. Срок жизни пользователя в медиа небольшой, и дневное удержание очень низкое, поэтому оно может быть не статзначимым.

Что нам «рассказывает» удержание

• Форма кривой выживания (survival curve): ранняя «ступенька» — про первое впечатление; пологий «хвост» — про истинную ценность и привычку;

• Где узкое место: D1 низкий — проблема онбординга/неясна ценность; D7 падает — нет «причины вернуться» (контент-луп, уведомления и социальный контекст в помощь); D30 низкий — не сформирована регулярность/ритуал, маленькое ядро пользователей (норма для новых продуктов);

• Связка с монетизацией: устойчивое удержание — база для LTV (Lifetime Value — сколько клиент принёс денег за время жизни). Без него рост выручки держится на рекламе/акциях и быстро выдыхается.

Важно: чётко определи ключевое действие, подтверждающее «возврат за ценностью». «Открыл приложение» — слабый сигнал; «сыграл раунд / завершил задачу / создал документ» — сильный.

Бизнес метрики

Какие метрики отражают экономическую ценность продукта?

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

1. Revenue (выручка)

Базовая и важнейшая метрика. Она показывает, сколько денег принёс продукт за определённый период. Полезно делить её:

• по сегментам (например, пользователи из SMB и Enterprise или, банально, новые и вернувшиеся);

• по источникам (подписки, разовые покупки, реклама и пр.);

• по каналам привлечения (закупка трафика, промо-акции, реферальная программа и т. д.).

2. ARPU / ARPPU

• ARPU — Average Revenue Per User. Средняя выручка на пользователя. Считается как общая выручка, делённая на общее число активных пользователей за период.

• ARPPU — Average Revenue Per Paying User. Средняя выручка на платящего пользователя. То же самое, что и ARPU, но учитываются только те, кто платил.

Важно: если цель — понять не просто поток денег, а сколько зарабатывает твой продукт, то лучше использовать AMPU и AMPPU, где M — Gross Margin (маржа). То есть вычесть из выручки все переменные расходы и так определять, сколько заработали за период.

3. LTV — Lifetime Value

Суммарный доход, который один пользователь приносит за всё время использования продукта. Это ядро unit economics.

Классическая формула:

LTV = ARPU × Средняя продолжительность жизни клиента (в месяцах)

Формула выше общепринята, и именно её ты найдёшь, если загуглишь, что такое LTV. Но важно понимать: LTV нельзя рассматривать в отрыве от стоимости привлечения (CAC). Ты сколько-то потратил на то, чтобы этот пользователь пришёл, и какое-то количество пользователей вообще не «дожили» до покупки. А деньги потрачены, и их важно учесть.

Более корректная формула:

LTV = AMPU × Средняя продолжительность жизни клиента (в месяцах)

В AMPU уже учтены затраты на привлечение и все переменные затраты на «содержание пользователя». Подробнее

4. CAC — Customer Acquisition Cost

Сколько ты тратишь на привлечение одного клиента. Это может быть стоимость рекламы, комиссии партнёрам и посредникам, затраты на SEO-продвижение и даже зарплаты маркетолога (хотя постоянные расходы лучше не включать).

Твоя цель — добиться: LTV > CAC, то есть прибыль с клиента больше, чем стоимость его привлечения. Тогда экономика, что называется, сходится. Или ещё лучше: LTV / CAC ≥ 3.

5. Gross Margin / Gross Profit

Это Revenue за вычетом переменных расходов. Чем выше GM, тем больше денег остаётся на масштабирование и развитие продукта.

В Gross Margin намеренно не входят зарплаты и налоги, потому что эти траты не зависят от количества пользователей и не влияют напрямую на экономику продукта. Твой продукт не начнёт зарабатывать больше, если ты вдруг начнёшь разработчику платить не 250 тысяч, а 500.

6. Average Price

Средняя стоимость одной транзакции или, если проще, средний чек. Рассчитывается как: Revenue поделить на количество оплат за период.

Как связать поведение пользователей с доходом?

Ты не можешь влиять напрямую на выручку — но можешь влиять на поведение пользователей. А значит, можешь управлять доходом через метрики продукта и вовлечённости.

Цепочка ценности: от поведения к выручке

Простой фреймворк: Привлечение → Активация → Возврат → Доход

Разберём на примере подписного сервиса: Пользователь приходит → пробует функциональность → получает ценность → остаётся → платит.

Если ты хочешь увеличить выручку, тебе нужно:

1. найти ключевые действия, после которых вероятность оплаты возрастает;

2. оптимизировать путь до этих действий;

3. удерживать пользователей, которые уже платят.

Индикаторы поведения, влияющие на монетизацию

Активация

Важно, чтобы пользователь не просто заходил в продукт, но использовал его по прямому назначению, то есть активировался. Если пользователь не активировался, значит он не увидел для себя ценности в продукте и платить не будет.

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

Глубина использования

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

Использование = Выручка

Можно прямо связать использование конкретных фич с платёжами. Ты должен понимать за что люди платят в твоём продукте. Что именно кажется им наиболее ценным и важным? Вот именно это ты и продаешь пользователям в продукте. Таких фич может быть множество. А иногда они могут быть вообще не связаны со сценарием, который ты считаешь ключевым в продукте.

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

Удержание и отток

Повторные покупки и подписки возможны только при регулярном возвращении. Тут всё снова упирается в ценность. Люди знают за что платят и их устраивают условия, поэтому они возвращаются и платят еще.

Глядя на метрики удержания и оттока можно понимать как реагируют платящие пользователи на изменения в продукте. Всегда сверяйся с ними как с часами. Если Retention изменился, то стоит разбираться почему и не приведет ли это в росту оттока.

Когортный анализ и сегментация

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

• какие фичи они используют;

• через какие каналы пришли;

• какой у них путь активации.

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

Продуктовые эксперименты, направленные на доход

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

Например: если сделать новый onboarding, больше людей дойдут до первого успешного действия → это повысит retention → это увеличит ARPU.

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

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