North Star и конфликты метрик: почему одна метрика ломает продукт

Кратко

North Star Metric (NSM) — одна метрика, которая лучше всего отражает ценность продукта для пользователя и предсказывает долгосрочный рост. Вокруг неё строится дерево метрик: input → output → business result, а guardrail’ы защищают систему от локальной оптимизации. Без этой обвязки NSM превращается в рулетку: команды оптимизируют число, а продукт деградирует. Закон Гудхарта — «когда метрика становится целью, она перестаёт быть хорошей метрикой» — не теория, а документированная практика Bing, Яндекса и десятков B2B SaaS.

Система метрик, а не одна цифра

North Star Metric — это компас, не dictator. Метрика работает только в связке с тремя уровнями:

УровеньЧто измеряемПример
Business ResultФинальный итог бизнесаRevenue, Retention, LTV
Output (NSM)Ключевое действие ценностиЗавершённые сделки в месяц
InputТриггеры, ведущие к NSMПервый поиск, активация фичи

Input-метрики — leading indicators: они сдвигаются раньше, чем NSM и revenue. Если вы смотрите только на NSM, вы узнаёте о проблеме, когда уже поздно. Если только на input — не понимаете, дошёл ли сигнал до денег. Дерево метрик связывает оба конца через причинность, а не корреляцию.

Примеры NSM для разных продуктов:

ПродуктNorth Star MetricПочему подходит
SaaS-редакторСовместные документы в месяцОтражает вовлечение команд
СтримингЧасы просмотра ключевого контентаСвязано с удержанием и подписками
МаркетплейсЗавершённые сделкиПокупатель и продавец получили ценность

NSM выбирают через воронки, event tracking, корреляционный анализ и A/B-тесты. Корреляция с retention — необходимое, но не достаточное условие. Без проверки причинности метрика превращается в суеверие.

NSM vs OMTM

КритерийNorth Star MetricOne Metric That Matters
ГоризонтДолгосрочный, стабильныйКраткосрочный, меняется по фазе
РольОбщий компас компанииПриоритет квартала/спринта
Связь с бизнесомЦенность + ростКонкретный рычаг сейчас

NSM не отменяет OMTM. Это разные инструменты: NSM задаёт направление на годы, OMTM фокусирует квартал. Путать их — значит либо потерять долгосрочный фокус, либо пытаться двигать одной метрикой всю компанию разом.

Guardrail’ы — броня NSM

Guardrail metrics защищают NSM от локальной оптимизации. Они сигнализируют, когда улучшение одного показателя вредит другому. Типичные guardrail’ы:

  • Время на задачу
  • NPS / рейтинг удовлетворённости
  • Обращения в поддержку
  • Качество аудитории, маржа
  • Retention по когортам

Правило простое: оптимизируем NSM, но guardrail’ы не падают ниже порога. Если растём в выручке, а churn ползёт вверх — это не рост, а перекачка денег из будущего в настоящее.

Как Goodhart ломает метрики

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

В продуктах это проявляется так: промежуточная метрика растёт, пользовательская ценность стоит на месте или падает. A/B-тесты побеждают по primary metric, а качественная обратная связь говорит, что стало хуже. Без guardrail’ов и качественных сигналов это обнаруживают спустя месяцы — когда рушится retention или revenue.

Реальные кейсы конфликтов метрик

Дальше — документированные кейсы, где оптимизация под одну метрику ломала другую. Я использую их в работе как напоминание: «а какой guardrail мы забыли?».

Bing: Queries per User как ложная North Star

Microsoft Bing выбрал метрику «количество запросов на пользователя» как North Star для борьбы с Google. Команды начали выпускать фичи, которые заставляли пользователей делать больше запросов, чтобы найти тот же ответ: сдвиг результатов вниз, больше блоков «похожих запросов», лишние промежуточные клики. A/B-тесты побеждали по primary metric.

Конфликт: пользователи искали больше, но находили ответ медленнее. Качественная обратная связь показывала растущее недовольство. Метрика инцентивизировала ухудшение UX — классический Goodhart.

Разворот: перешли к минимизации queries per session + максимизации sessions per user. Идея — довольный пользователь заходит часто и уходит быстро, потому что сразу находит ответ. North Star осталась (рост engagement), но форма метрики сменилась с «больше запросов» на «быстрый ответ».

Урок: форма NSM определяет направление оптимизации. «Больше запросов» и «быстрый ответ» — разные цели, даже если обе про engagement.

Яндекс: оффлайн-копии страниц в мобильном браузере

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

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

Конфликт: метрика «открыто вкладок» росла, метрика «показов рекламы» падала. Команда оптимизировала UX, но била по бизнес-модели.

Урок: UX-метрика без привязки к revenue — это половина картины. Guardrail’ом здесь должен быть rate revenue per session.

Яндекс: промо-страница браузера — микро vs макроконверсия

Оптимизация под клик «Скачать» показала рост. Но:

  • Микроконверсия «клик по загрузке» растёт.
  • Макроконверсия «установка» не гарантируется — скачают, но не установят.
  • Выше — usage и возвращаемость: установил, но не пользуется.

Команда взяла в качестве прокси высокоуровневую метрику — суммарные переходы на сайты из браузера. Это сместило фокус с «скачали» на «пользуются».

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

Яндекс: обои для стартового экрана

Считали количество смен обоев в день как прокси вовлечённости. Оказалось: пользователи меняли фон, который им не нравился. Метрика росла, ценности не было.

Команда попыталась отслеживать точные предпочтения, ушла в «глухие дебри» и вернулась к retention — медленному, но честному сигналу. Решили: если retention останется flat после релиза, фичу убивают.

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

Яндекс Браузер: виджеты Дзена на стартовой

Добавили виджеты с новостями и погодой прямо в браузер.

  • Retention браузера и переходы на сайты внутри браузера выросли.
  • Пользователи перестали заходить на главную страницу Яндекса за этим же контентом.
  • На главной странице есть другие фичи (оповещения о ЧС, социальная ответственность), которые пострадали.

Команда браузера «съела» метрики соседнего продукта. Решение: виджеты стали вести на главную страницу Яндекса, а не показывать контент внутри браузера.

Урок: в экосистеме продуктов метрика одной команды может каннибализировать метрику другой. Guardrail — это не только внутри продукта, но и между продуктами компании.

Amoeba: $120M ARR B2B SaaS — acquisition vs retention

Квартал рекордного роста: CAC снизился на 15%, лиды выросли на 30%, конверсия MQL→SQL стабильна, новые логотипы +22%. Команда оптимизировала воронку.

Через 6 месяцев:

  • NRR рухнул с 118% до 104% для этих когорт.
  • 90-дневный churn вырос с 6% до 11% (особенно из paid social).
  • Time-to-first-expansion вырос на 40%.
  • Product engagement упал на 18%.

Причина: оптимизация под конверсию и дешёвый CAC привлекла low-fit клиентов. Продукт не изменился — изменилось качество аудитории. Ущерб: $2.3M в at-risk ARR, CAC payback вырос с 18 до 26+ месяцев.

Урок: acquisition-метрики без retention-guardrail’а — это роскошь, которую может позволить себе только продукт с бесконечным LTV. В реальности low-fit клиенты убивают unit-экономику.

Fortune 150 Energy Company: UX-редизайн убил enrollment

Команда запустила редизайн домашней страницы: страница стала на 40% короче, брендовый месседжинг, модальное окно вместо отдельной страницы поиска планов, упрощённая навигация. Основная метрика — инициация поиска плана — показала flat-результат.

Через 21 день после полного раската обнаружили двузначное падение завершённых регистраций (enrollment).

Почему: модальное окно убрало «порог обязательства». Переход на отдельную страницу был сигналом «я начал задачу», а модалка воспринималась как легкоотключаемый поп-ап. Короче — «улучшение UX» убило макроконверсию.

Урок: flat на primary metric не значит flat везде. Если не смотреть downstream-метрики, можно праздновать удачный редизайн, пока отваливаются регистрации.

Конфликт определений, не чисел

Иногда конфликт метрик — это конфликт определений. Разные команды смотрят на «одно и то же» и видят разное.

$5M Single Source of Truth → 17 Sources of Lies

Компания потратила $5M на data warehouse, data lake, lakehouse, MDM и data mesh. На вопрос борда «сколько у нас клиентов» четыре команды дали четыре ответа:

КомандаКлиентовИсточникОпределение
Finance42 573Data warehouseRecognized revenue
Sales38 912CRMSigned contracts
Product51 246LakehouseКто логинился
Marketing67 892CDPEmail subscribers

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

InfluxData: 10 минут сверки на каждой встрече

Данные были разбросаны по PostgreSQL (продукт), Marketo (маркетинг), Salesforce (CRM), Domo (BI), Google Analytics (web). Маркетинг и продажи смотрели на один бизнес и видели разные цифры. Первые 10 минут leadership-meetings уходили на сверку дашбордов вместо обсуждения роста.

Что делать

Сергей Громов в эссе The Single Source of Truth Illusion аргументирует: проблема не техническая, а семантическая. Revenue для продукта — $1000 в момент оплаты. Для финансов — $83/месяц по расписанию признания выручки. Обе цифры правильные в своём контексте.

Вывод Громова: нужна не «одна версия правды», а система, которая объясняет каждую версию правды — governed, documented, contextual metrics. Аналитик не выбирает, какая команда «права», — он сверяет определения и делает разницу явной.

Как проектировать guardrail’ы

Guardrail — это не «ещё одна метрика», а ограничение. Несколько практических правил:

  1. Один guardrail на одну угрозу. Если NSM можно «накрутить» через снижение качества — guardrail на качество. Если через каннибализацию соседнего продукта — guardrail на метрику соседа. Если через низкокачественную аудиторию — guardrail на retention/quality.
  2. Порог, а не тренд. «Churn не выше 5%» работает лучше, чем «churn не должен расти». Порог даёт явный сигнал срабатывания.
  3. guardrail связан с NSM причинно, не корреляционно. Если между ними нет механизма, guardrail просто шум.
  4. guardrail измеряется на той же когорте, что NSM. Сравнивать NSM этого квартала с churn прошлого — ловушка лага.
  5. Качественные сигналы — тоже guardrail. NPS, обращения в поддержку, session replay ловят то, что числа не видят сразу.

Балансировка метрик

Когда NSM и guardrail конфликтуют, команда принимает решение явным образом, а не «по умолчанию». Формат:

  • Зафиксировать NSM и guardrail’ы с порогами до запуска эксперимента.
  • Описать правило решения: «рост NSM + guardrail в пределах порога → раскатываем; рост NSM + guardrail нарушен → обсуждаем trade-off».
  • Логировать решения: почему приняли рост ценой падения NPS на 2 пп. Без этого через полгода не вспомните, почему метрика поехала.

Выводы

  • NSM без дерева метрик — это число без рычагов. Input-метрики дают то, что можно двигать сегодня; output и business result — то, куда это приведёт завтра.
  • guardrail — обязательная часть системы, не опция. Без guardrail’ов Goodhart срабатывает не сразу, но всегда. Лучше заложить ограничение до запуска, чем разруливать последствия через 6 месяцев.
  • Форма NSM определяет направление оптимизации. Bing доказал: «больше запросов» и «быстрый ответ» — разные цели. Выбирайте метрику, которая поощряет ценность, а не активность ради активности.
  • Микроконверсия без макро — это половина картины. Рост кликов «Скачать» без роста установок — это шум, а не победа. Связывайте слои воронки явно.
  • Конфликт метрик в экосистеме — это конфликт команд. Каннибализация главной страницы Яндекса виджетами браузера — пример, где метрика одной команды «съела» метрику другой. Guardrail должен быть межпродуктовым.
  • Единый источник правды — иллюзия, если определения не согласованы. Аналитик начинает с согласования определений, а не с выбора «правильного» дашборда. Цель — система, которая объясняет каждую версию правды, а не навязывает одну.

Смотрите также

← К статьям