📈 Продуктовые и бизнес-метрики

Короткий ответ Простая оценка: LTV ≈ ARPU × средний срок жизни пользователя (lifetime); при постоянном месячном churn средний lifetime можно приближённо оценить как 1 / churn rate. Как это работает подробнее ARPU — средняя выручка на пользователя за период (например, месяц), lifetime — сколько периодов в среднем пользователь остаётся активным; перемножая, получаем ожидаемую суммарную выручку с одного пользователя за весь срок использования. Что использовать на практике Применение. формула 1/churn работает только как грубое приближение при допущении, что churn постоянен во времени (геометрическое распределение) — в реальности churn обычно выше в первые месяцы и снижается для "выживших" пользователей, поэтому такая оценка завышает LTV для новых продуктов. Проверка или пример. Проверка: сравнить эту оценку с фактической суммарной выручкой старых когорт (тех, кто уже прошёл 20+ месяцев) — если реальная выручка сильно ниже, значит допущение о постоянном churn не выполняется. Подводные камни Частая ошибка. использу

Читать полностьюarpu

Короткий ответ Хороший продуктовый дашборд должен строиться вокруг иерархии: North Star Metric наверху, input-метрики (драйверы), на которые команда может влиять, и guardrail-метрики, предупреждающие о побочном вреде — а не представлять собой произвольный набор десятков несвязанных графиков. Как это работает подробнее иерархическая структура позволяет быстро понять, "что происходит в целом" (NSM), "почему это происходит" (input-метрики) и "не ломаем ли мы что-то ещё" (guardrails); каждая метрика на дашборде должна иметь чёткое, задокументированное определение (окно, фильтры, таймзона), одинаковое для всех потребителей. Структура дашборда для B2C-приложения: Такая структура позволяет менеджеру за 30 секунд понять общее состояние продукта и куда смотреть при отклонениях. Что использовать на практике Практика. стоит ограничивать число метрик на главном экране (5-10), выносить детализацию в drill-down; обязательно фиксировать на дашборде момент последнего обновления данных и источник, чтобы избежать путаницы при

Читать полностьюdashboard

Короткий ответ Нужно посчитать конверсию отдельно на каждом переходе между шагами за текущую и предыдущую неделю, найти, на каком именно переходе относительное падение наибольшее, а затем разбить этот шаг по сегментам (платформа, канал трафика, гео) и по времени (внутри недели), чтобы локализовать причину. Как это работает подробнее общая конверсия воронки — это произведение конверсий на каждом шаге (view→cart→pay = conv1 × conv2); падение общей конверсии может быть вызвано падением на любом из шагов, и без пошаговой разбивки невозможно понять, где искать причину. Пример кода Что использовать на практике Практика. после локализации проблемного шага стоит проверить технические причины (ошибки в форме оплаты, деплой за день до падения, проблемы с платёжным провайдером), затем — изменение состава трафика (например, выросла доля низкокачественного трафика с одного канала) и только потом content/UX-гипотезы; важно сопоставить момент падения с логом релизов и маркетинговых кампаний. Подводные камни Частые ошибки. д

Читать полностьюconversion

Короткий ответ Нужно сначала перевести время события из UTC (как обычно хранится в событийных логах) в локальную таймзону пользователя, затем определить календарный день по локальному времени и сравнить его с днём регистрации + 7 — в ClickHouse это делается функциями toTimeZone/toDate с динамической таймзоной из поля пользователя. Как это работает подробнее если считать Day 7 retention по UTC-дате для пользователей из разных часовых поясов, для части из них "день 7" фактически может означать день 6 или 8 по их локальному времени — особенно критично для продуктов с ежедневной активностью (например, привычка "заходить утром"). Проверка: сравнить итог с расчётом по UTC без поправки на таймзону — для продукта с глобальной аудиторией расхождение должно быть заметным. Что использовать на практике Практика. в ClickHouse таймзону можно задавать per-row через toTimeZone(event_time, user_timezone), где user_timezone — строковое поле вида 'Europe/Moscow'; для больших объёмов данных стоит заранее проверить, что поле тайм

Читать полностьюclickhouse

Короткий ответ Нужно посчитать число уникальных user_id среди событий, попадающих в выбранный календарный месяц. Как это работает подробнее фильтруем события по диапазону дат месяца и считаем COUNT(DISTINCT user_id); важно использовать правильные границы интервала, чтобы не захватить первый день следующего месяца или потерять последний день текущего. Пример кода Что использовать на практике Практика. для сравнения MAU между месяцами разной длины (28-31 день) иногда дополнительно нормируют на число дней или используют DAU/MAU как более устойчивую метрику; также стоит явно зафиксировать таймзону, если пользователи распределены по разным часовым поясам. Подводные камни Частые ошибки. используют event_date BETWEEN '2024-03-01' AND '2024-03-31' без учёта типа данных (если это timestamp, то такой BETWEEN отсечёт события после полуночи 31 марта) — безопаснее использовать полуоткрытый интервал >= месяц AND ; забывают DISTINCT и считают число событий вместо числа пользователей.

Читать полностьюactive-users

Короткий ответ Нужно определить для каждого пользователя неделю когорты (неделя первой активности), затем для каждой пары (неделя когорты, номер недели с момента входа) посчитать число уникальных активных пользователей и разделить на размер когорты. Как это работает подробнее сначала строим таблицу когорт (user_id → cohort_week), затем джойним с событиями, вычисляем week_number = date_part('week', event) - date_part('week', cohort) (или через разницу дат, поделённую на 7), группируем по (cohort_week, week_number) и делим на размер когорты. Пример кода Что использовать на практике Практика. использование date_trunc('week', ...) зависит от того, с какого дня недели считать (в PostgreSQL неделя по умолчанию начинается с понедельника, ISO-8601); для продуктов без выраженной недельной сезонности можно использовать дни вместо недель, но для B2C-продуктов с выраженной разницей будни/выходные недельные когорты обычно устойчивее к шуму. Подводные камни Частые ошибки. считают week_number простым вычитанием номеров кале

Читать полностьюcohorts

Короткий ответ Система метрик строится сверху вниз (от гипотезы о ценности продукта к North Star Metric, затем к 3-5 input-метрикам, на которые команды реально влияют, и к guardrail-метрикам, защищающим от побочного вреда), но единственно верной структуры не существует — выбор всегда компромисс между простотой, измеримостью и полнотой отражения ценности. Как это работает подробнее сначала формулируется гипотеза о том, в какой момент пользователь получает основную ценность продукта ("aha-moment"), затем ищется метрика, которая одновременно растёт вместе с этой ценностью и с бизнес-результатом; под NSM выстраивается дерево input-метрик через декомпозицию (например, NSM = активные команды × частота ключевых действий), и для каждого input-а назначается ответственная команда. Для нового B2B-инструмента совместной работы: гипотеза ценности — "команды, которые создают и совместно редактируют документы, остаются дольше"; NSM = число команд с ≥3 активными участниками в неделю; input-метрики = activation rate новых ком

Читать полностьюguardrails

Короткий ответ DAU — число уникальных пользователей, совершивших целевое действие за календарный день, MAU — то же самое за 30 дней или календарный месяц; отношение DAU/MAU (sticky factor) показывает, какая доля месячной аудитории возвращается в продукт ежедневно. Как это работает подробнее обе метрики считаются по уникальным идентификаторам пользователя (user_id), а не по числу событий или сессий; "активностью" может быть открытие приложения, логин или конкретное целевое действие — это определяется продуктом. Пример кода Что использовать на практике Применение. перед расчётом нужно зафиксировать точное определение "активности" и окно MAU (скользящие 30 дней или календарный месяц — это разные числа); типичные значения sticky factor для большинства приложений 0.1–0.3, для мессенджеров и соцсетей — 0.4–0.6+. Проверка или пример. Проверка: DAU/MAU должен лежать в диапазоне (0;1]; если DAU > MAU — ошибка в фильтрах периода. Подводные камни Частая ошибка. считают MAU как сумму DAU за месяц (неверно — один и тот же

Читать полностьюdau

Короткий ответ North Star Metric (NSM) — единая метрика, которая лучше всего отражает ценность, получаемую пользователями от продукта, и при этом коррелирует с долгосрочным ростом бизнеса; она нужна, чтобы согласовать фокус разных команд вокруг одной общей цели. Как это работает подробнее NSM выбирается так, чтобы расти вместе с удовлетворённостью пользователей и выручкой одновременно, а не быть просто показателем активности или дохода по отдельности; хорошая NSM — измеримый, понятный и actionable индикатор ценности продукта. Что использовать на практике Применение. под NSM выстраивают дерево input-метрик (метрик-драйверов), на которые команды могут влиять напрямую; NSM редко меняется каждый квартал — это стратегический ориентир, а не KPI спринта. Проверка или пример. Spotify использует суммарное время прослушивания, Airbnb — число забронированных ночей: обе метрики одновременно отражают пользу для пользователя и движут выручку компании, в отличие от, например, просто числа регистраций. Подводные камни Частая

Читать полностьюmetric-tree