North Star Metric для B2B SaaS: как связать ценность аккаунта, события и выручку
North Star Metric помогает B2B SaaS-команде связать ценность для клиента с действиями, на которые может влиять продуктовая команда. Ниже — не список чужих метрик, а воспроизводимая проверка кандидата: контракт данных, формула, заполненный синтетический пример и решение pass/fail.
Скачать CSV-шаблон контракта North Star. В нём рядом находятся пустые поля для вашей команды, синтетический пример и критерий проверки каждого поля.
Что такое North Star Metric и зачем она нужна
North Star Framework строится вокруг одной метрики, которая отражает получаемую клиентом ценность. В описании фреймворка Amplitude у неё три свойства: связь с пользовательской ценностью, возможность влиять на неё работой продукта и маркетинга и роль опережающего индикатора выручки. Это методический источник, а не доказательство того, что конкретный кандидат подойдёт вашему продукту.
Одна итоговая метрика не отменяет рабочие показатели. Команды используют входные метрики, на которые могут влиять ежедневно, но связывают их с общей North Star Metric. Защитные метрики при этом показывают, не ухудшается ли качество, надёжность или экономика продукта.
Почему в B2B SaaS единица ценности — аккаунт или рабочее пространство
В B2B SaaS ценность часто получает аккаунт, рабочее пространство или организация, а действия разных ролей складываются в один общий сценарий.
Практика объединения пользователей, ролей и рабочих пространств описана в материале про аналитику аккаунтов B2B SaaS.
Это ключевой момент: если ценность аккумулируется на уровне аккаунта, то и North Star, и знаменатель активации, и retention должны учитывать именно эту единицу расчёта.
Как отделить продуктовые события от финансовых показателей
Определение активации должно фиксировать единицу расчёта, наблюдаемое событие ценности, окно после старта и подходящий знаменатель; чужой универсальный сценарий копировать нельзя.
Определение события ценности и окна подробно разобрано в статье про воронку активации SaaS.
MRR и ARR требуют данных биллинга, договоров или финансовой витрины; продуктовые события объясняют поведение, но не заменяют финансовый факт.
Граница систем-источников подробно разобрана в материале про MRR, ARR, CAC, LTV и продуктовые метрики.
В результате важно держать границу ответственности: продуктовая аналитика работает с inputs и поведением пользователей, а финансовая витрина фиксирует факт выручки и договорные события.
Контракт кандидата: что зафиксировать до расчёта
Карточка проверки не даёт команде незаметно менять смысл показателя после запуска. Заполните её до построения дашборда.
| Поле | Что должно быть в контракте | Причина отклонить кандидата |
|---|---|---|
| Единица ценности | один account_id, workspace или организация |
числитель считает пользователей, а ценность получает аккаунт |
| Событие ценности | серверный факт результата и точный момент фиксации | обычный просмотр, клик или действие без результата |
| Формула и окно | COUNT(DISTINCT account_id) и календарная неделя либо другое фиксированное окно |
окно или правила дедупликации можно менять задним числом |
| Допуск в расчёт | тестовые, внутренние и удалённые аккаунты исключены по явному правилу | знаменатель зависит от ручной очистки |
| System of record | названы таблица/поток, обязательные поля и владелец схемы | расчёт собирает несовместимые источники без приоритета |
| Inputs | 3–5 наблюдаемых шагов, которыми команда может управлять | список повторяет итоговую метрику другими словами |
| Guardrails | качество доставки событий, ошибки и коммерческое ограничение | рост NSM может скрывать деградацию продукта |
| Проверка связи | план сравнения когорт NSM с retention и финансовым фактом | связь с выручкой объявлена без наблюдения |
Поля шаблона следуют официальному чек-листу North Star Amplitude: кандидат должен выражать ценность, соответствовать стратегии, быть опережающим и управляемым показателем, оставаться понятным и измеримым. В контракт добавлены B2B-границы — единица аккаунта, system of record и guardrails.
Формула без смешения аккаунтов и действий
Для счётчика активных ценностных аккаунтов формула выглядит так:
NSM_week = COUNT(DISTINCT account_id)
где value_event = true
и week_start <= event_time < next_week_start
и account_is_eligible = trueЗдесь одно событие не равно одной единице North Star: десять повторов внутри аккаунта всё равно дают один аккаунт за неделю. Если команде дополнительно нужна доля, знаменатель фиксируют отдельно:
value_rate_week = NSM_week / eligible_accounts_weekСчётчик и доля отвечают на разные вопросы. Первый показывает масштаб полученной ценности, вторая — проникновение сценария в доступную базу.
Заполненный синтетический пример с решением
Пример ниже полностью синтетический. Он не описывает клиента ActionPulse, не является отраслевым бенчмарком и не обещает результат.
| Поле | Синтетическое решение | Как проверить |
|---|---|---|
| Единица ценности | корпоративный account_id |
каждое событие связано ровно с одним существующим аккаунтом |
| Событие ценности | report_shared: сохранённый отчёт открыт приглашённым участником |
сервер фиксирует report_id, account_id, автора и получателя после успешного открытия |
| North Star | аккаунты с подтверждённым report_shared за календарную неделю |
distinct по account_id; повторные открытия не увеличивают счётчик |
| Допуск | активные внешние аккаунты; тестовые и внутренние исключены | правило хранится в версии контракта, а не в ручном фильтре отчёта |
| Inputs | data_connected, report_created, teammate_invited |
для каждого input есть owner и отдельная конверсия до события ценности |
| Guardrails | доля потерянных событий, ошибки открытия отчёта, обращения в поддержку | ни один guardrail не ухудшается при росте кандидата |
| Финансовая граница | статус договора и MRR берутся только из финансовой витрины | событие report_shared не считается оплатой или выручкой |
| Итог | pass в пилот, не финальная North Star | сначала проверить стабильность определения и связь с retention на нескольких когортах |
Допустим, за неделю в расчёт вошли 120 аккаунтов. Событие встретилось 67 раз, но после дедупликации его выполнили 46 аккаунтов. Тогда NSM_week = 46, а диагностическая доля value_rate_week = 46 / 120 = 38,3%. Число 67 нельзя выдавать за North Star: оно вознаграждает повторы внутри тех же аккаунтов.
Вердикт pass в пилот означает только то, что кандидат вычислим и проходит контрактную проверку. Чтобы зафиксировать его как North Star, команда должна на собственных данных проверить, предшествует ли событие удержанию аккаунта и не расходится ли рост с финансовым фактом. Порог связи заранее задают в плане анализа; из этого синтетического примера его вывести нельзя.
Проверить события, сегменты и отчёты на одной единице расчёта можно на странице продуктовой аналитики для SaaS.
Критерий pass/fail перед запуском
Кандидат получает pass только если одновременно выполнены семь условий:
- ценность сформулирована как результат аккаунта, а не активность интерфейса;
- формула, окно, дедупликация и исключения воспроизводимы;
- system of record и обязательные поля названы;
- продуктовая команда может влиять на inputs;
- guardrails защищают качество и экономику;
- финансовые данные не подменяются продуктовым событием;
- связь с retention и выручкой будет проверена на собственных когортах, а не объявлена заранее.
Если хотя бы одно условие не выполнено, результат — fail: исправьте контракт или выберите другой кандидат. CSV-шаблон можно хранить рядом со словарём событий и версионировать при каждом изменении определения.
Резюме и следующий шаг
Закрепите контракт North Star в виде короткого документа: единица, событие, период, inputs, guardrails, system of record, владелец и правило решения. После этого настройте сбор данных и отчётность.
Для следующего шага выберите один реальный сценарий, сверьте определения с материалами об аналитике аккаунтов B2B SaaS и воронке активации, затем проверьте доступные отчёты на странице продуктовой аналитики для SaaS на одной и той же единице расчёта.