North Star и дерево метрик: как собрать систему продуктовых метрик

Коротко

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

• North Star — наблюдаемое событие регулярно получаемой ценности, а не итог работы всей компании за квартал.
• Выручка плохо работает в этой роли: она реагирует с задержкой, и вклад продуктовой работы в ней тонет в нескольких крупных сделках.
• Дерево метрик собирается умножением: если произведение узлов не воспроизводит корень, это список чисел, а не дерево.
• У каждого уровня есть guardrail — метрика, которая запрещает засчитывать рост, купленный за счёт качества.
• Карточка метрики содержит зерно, фильтры, окно, источник, владельца и контрольное число, по которому новый запрос проверяет себя.
• Adoption функции считается от тех, кому она доступна, и разделяется на первое использование, повторное и результат.
• NPS измеряет мнение ответивших, поэтому годится как источник гипотез и как guardrail, но не как цель команды.

Выручка в роли North Star: рост 12%, из которых продукт сделал 3%

North Star Metric — это операционное приближение ценности, которую продукт создаёт регулярно. Практическая проверка звучит так: если число растёт, пользователь получил больше пользы, а если падает — продукт стал помогать хуже. Выручка этому условию удовлетворяет только в среднем и на длинном горизонте. В квартале «Планёрки» она выросла на 12%, из которых 9 процентных пунктов дали два контракта по 1,4 млн ₽ — их подписали до релизов, за которые отчитывалась продуктовая команда. На продуктовую работу остаётся 3%, и эти 3% невозможно отличить от обычного колебания выручки между кварталами.

Вторая типичная подмена — метрика объёма: регистрации, MAU, установки. Она двигается быстро и легко растёт от любой рекламной кампании, но ничего не говорит о полученной ценности: в «Планёрке» 1 840 платящих команд, при этом отчёт в обычную неделю собирают 846 из них. Аудитория в роли главной метрики даёт команде разрешение считать успехом рост той половины базы, которая продуктом не пользуется.

Рабочий кандидат для «Планёрки» — недельный отчёт, доставленный хотя бы одному получателю, кроме самого автора. Это событие лежит в точке, где ценность становится наблюдаемой: отчёт собран, отправлен и дошёл до того, кому он нужен. Частота события совпадает с ритмом продукта — раз в неделю, значит метрика успевает отреагировать на релиз внутри спринта, а не через квартал. За квартал таких отчётов 12 400, в среднем 956 в неделю, и это число команда может изменить своими руками: шаблонами, подключением источников, напоминанием в пятницу.

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

Guardrail — это не вторая цель, а условие, при котором рост считается ростом

У любой одиночной метрики есть дешёвый способ роста. Для доставленных отчётов он очевиден: включить автоматическую отправку по расписанию всем получателям из адресной книги. Число отчётов вырастет в тот же день, а ценность — нет, потому что рассылку перестанут открывать. Поэтому рядом с North Star ставится ограничение, которое делает такой рост неучитываемым: доля доставленных отчётов, открытых получателем в течение трёх дней. В «Планёрке» она держится на 62%, и порог записан явно — ниже 55% прирост отчётов не считается достижением, а становится поводом для разбора.

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

• Качество результата: доля отчётов, открытых получателем — 62%, порог 55%.
• Скорость: p90 времени сборки отчёта — 41 секунда, порог 90 секунд.
• Доверие к данным: доля отчётов с расхождением к источнику больше 1% — 0,8%, порог 2%.
• Экономика: отток платящих команд за месяц — 1,9%, порог 3%.

Дерево метрик проверяется умножением: 1 840 × 0,46 × 1,13 = 956

Дерево метрик — это не иерархия важности, а разложение корневого числа на множители, каждый из которых кто-то может двигать. Для «Планёрки» разложение такое: число доставленных отчётов за неделю равно числу платящих команд, умноженному на долю команд, собравших отчёт на этой неделе, и на среднее число отчётов от собравшей команды. Подставь: 1 840 × 0,46 × 1,13 = 956. Совпадение с фактическим средним — это и есть проверка, что дерево построено верно.

Проверка умножением отсеивает главную ошибку в деревьях метрик. В «Планёрке» первая версия схемы содержала узлы «NPS», «скорость загрузки страницы» и «число интеграций». Все три связаны с продуктом, но из них нельзя собрать 956: они не множители, а гипотезы о причинах. Такие показатели остаются в системе, но живут как guardrails и как диагностические разрезы, а не как уровень дерева. Если корень не воспроизводится из дочерних узлов, ни одно изменение внизу не получится честно пересчитать в изменение вверху.

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

Главная польза дерева проявляется, когда корень меняется. Квартал назад средняя неделя давала 870 отчётов, сейчас 956, и прирост 86 раскладывается по множителям. Команд стало больше: (1 840 − 1 710) × 0,45 × 1,13 = +66. Доля собравших выросла с 0,45 до 0,46: 1 840 × 0,01 × 1,13 = +21. Глубина не изменилась: 1,13 в оба квартала, вклад нулевой. Сумма 87 против фактических 86 — единица расхождения приходится на перекрёстный член, её обычно относят к последнему множителю и упоминают отдельно. Вывод из этой арифметики неприятный для квартального отчёта: рост почти целиком объясняется закупкой новых команд, а продуктовая работа добавила 21 отчёт в неделю.

Расхождение 956 и 1 034 — это не баг запроса, а отсутствие карточки метрики

На том же квартальном разборе два человека показали разные числа для одной метрики: 956 отчётов в неделю и 1 034. Оба запроса корректны. Разница в 78 отчётах — это 12 внутренних рабочих пространств самой «Планёрки», на которых команда тестирует шаблоны: в одном определении они исключены, в другом нет. Спор длился двадцать минут и закончился договорённостью «давайте считать как в дашборде», то есть ничем: через месяц третий человек написал третий запрос. Метрика без письменного определения — это название, вокруг которого каждый достраивает свою логику.

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

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

Хороший тест готовности карточки — попросить коллегу воспроизвести метрику по ней, не задавая устных вопросов. Если у него получилось контрольное число, карточка работает. Если он спросил «а тестовые аккаунты считаем?», в карточке не хватает строки фильтров, и именно в этой строке потом возникнет расхождение на 8%.

Adoption считается от тех, кому функция доступна: 46%, а не 29%

Дерево метрик отвечает за продукт целиком, но команда работает функциями, и у каждой нужна своя метрика распространения. В «Планёрке» выпустили автосбор по расписанию: отчёт собирается и уходит получателям сам, без пятничного ритуала. Через месяц в релизном обзоре написали «adoption 29%» — 540 команд настроили расписание, поделённые на 1 840 платящих. Число неверное не арифметически, а по смыслу: функция доступна только на тарифах Team и Business, а это 1 180 команд из 1 840. Остальные 660 физически не могли её включить и попали в знаменатель как отказавшиеся. Честное значение — 540 из 1 180, то есть 46%.

Знаменатель adoption — это eligible-база: пользователи, у которых функция была и доступна по тарифу, и включена раскаткой, и достижима в интерфейсе на момент измерения. Раскатка добавляет второе осложнение, про которое забывают чаще, чем про тариф. Автосбор включали волнами: 470 команд получили его шесть недель назад, остальные 710 — две недели назад. У первой группы было втрое больше времени на то, чтобы дойти до настройки, поэтому общий процент смешивает две когорты разной зрелости. Сравнивать adoption имеет смысл по возрасту доступа: «доля настроивших за первые 14 дней после включения» — метрика, которую можно считать для любой волны.

Второе расхождение возникает в числителе. 812 команд открыли меню расписания, 637 довели настройку до сохранения, 366 получили автоотчёт в двух неделях подряд, и только 260 получили отчёт, который хотя бы один получатель открыл. Если называть adoption первым числом, функция выглядит принятой почти двумя третями eligible-базы. Поэтому воронку стоит держать из четырёх явных шагов — доступ, первое использование, повторное использование, результат — и в релизном обзоре называть, какой именно шаг имеется в виду.

Adoption отвечает только на вопрос о распространении сценария, и подменять им вопрос о ценности нельзя. Функцию, настроенную 637 командами, стоит проверять по соседним метрикам: выросла ли у этих команд доля собранных отчётов, сократилось ли время до отправки, держится ли открываемость. В «Планёрке» у команд с автосбором доля недель с отчётом выше (0,71 против 0,46 в среднем), но открываемость ниже на 4 пункта — ровно тот эффект, от которого защищает guardrail. Без него автосбор выглядел бы чистой победой.

• Назови знаменатель в имени метрики: «adoption среди Team и Business», а не просто «adoption».
• Считай долю по возрасту доступа, иначе волны раскатки смешиваются в одно число.
• Раздели открытие интерфейса, первое использование, повторное и результат.
• Исключи из eligible-базы тех, кто не мог увидеть функцию: старые версии приложения, отключённые интеграции.
• Проверяй ценность соседними метриками, а не ростом самого adoption.

NPS 38 против 34 — это смена состава отвечающих, а не рост впечатления

Опросная метрика в системе тоже нужна: поведение показывает, что человек сделал, но не показывает, чего он ждал и что его раздражает. NPS устроен просто: на вопрос о готовности рекомендовать ответы 9–10 считаются promoters, 0–6 — detractors, 7–8 не участвуют, а итог — разность долей в процентных пунктах. Из этой конструкции следует первое ограничение: одно число не восстанавливается обратно в состав. NPS 36 — это и 46% promoters против 10% detractors, и 58% против 22%. Вторая пара означает продукт, который половину пользователей радует, а пятую часть раздражает, и работать с ней нужно иначе.

В «Планёрке» три волны дали 34, 38 и 36. Рост во второй волне обсуждали как результат работы над скоростью сборки, пока не посмотрели на охват. Первую волну отправляли письмом по всей базе контактов: 620 ответов из 4 430, отклик 14%. Вторую показывали баннером внутри продукта сразу после успешной отправки отчёта: 290 ответов при 3 600 показов, отклик 8%, и 96% ответивших — команды, собравшие отчёт на этой неделе, хотя в базе таких 46%. Опрос задали людям в лучший момент их недели. Плюс 4 пункта — это разница выборок, а не разница опыта, и доказать обратное по этим данным невозможно.

Отсюда правило сопоставимости: волны сравниваются только при одинаковой формулировке вопроса, одинаковой шкале, одинаковом канале приглашения и сопоставимом отклике. Перевод вопроса на другой язык, замена шкалы 0–10 на 1–5, переезд опроса из письма в продукт — каждое из этих изменений сдвигает уровень метрики на единицы пунктов. Поэтому NPS показывают рядом с откликом и составом ответивших, а не одним числом на слайде. И по той же причине NPS — плохая цель команды: самый дешёвый способ поднять его не требует касаться продукта, достаточно поменять момент и аудиторию опроса.

Польза NPS начинается там, где ответ перестаёт быть числом и становится строкой с идентификатором. Сохраняй ответ на уровне респондента, связывай с продуктовым контекстом на момент опроса и смотри, чем detractors отличаются поведением. В «Планёрке» такое сопоставление дало конкретную зацепку: среди detractors 41% сталкивались с расхождением данных в отчёте за последние 30 дней, среди promoters — 12%. Это не доказательство причины, но хорошая гипотеза и готовый список команд для интервью. Дальше тема проверяется поведением: доля отчётов с расхождением уже стоит в guardrails, и её падение будет видно без нового опроса.

Что положить в один документ на квартал

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

• Корневая метрика с формулой, текущим значением и датой замера: 956 отчётов в неделю на 14.09.2026.
• Разложение корня на множители с проверкой подстановкой: 1 840 × 0,46 × 1,13.
• Владелец каждого множителя — человек и его следующее действие на квартал.
• Два-три guardrail с числовыми порогами и правилом, что происходит при пробое.
• Карточки десяти метрик, попадающих в решения, с контрольными числами.
• Метрики уровня функции с явно названной eligible-базой и шагами воронки.
• Опросный блок: NPS с откликом и составом, рядом — поведенческая проверка тем.
• Журнал версий: что в определениях менялось, когда и почему.

Итог: роль числа важнее его точности

Разница между системой метрик и списком чисел не в количестве показателей и не в качестве SQL. Она в том, что у каждого числа есть роль: это цель, рычаг, ограничение или мнение. Как только роли названы, квартальный разбор перестаёт быть обменом слайдами: прирост корня раскладывается по множителям, рост одного множителя проверяется на guardrails, а спор о формуле решается карточкой и контрольным числом за минуту вместо двадцати.

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