План веб‑приложения для SaaS‑основателей: сбор событий, расчёт MRR/retention/churn, дашборды, сегменты, алерты, безопасность и запуск MVP.
Инструмент метрик для SaaS — это не «красивый дашборд», а система поддержки решений. До выбора формул и источников данных важно договориться, какие управленческие ответы вы хотите получать регулярно, а какие — только во время расследований.
Рост. Понимать, какие каналы и сегменты дают не просто регистрации, а платящих и удерживающихся пользователей. Решения: куда масштабировать маркетинг, какие сегменты приоритизировать в продукте, где «протекает» воронка.
Удержание. Рано замечать ухудшение поведения и отток, находить причины и проверять эффект изменений. Решения: какие сценарии онбординга чинить, какие функции повышают удержание, какие группы пользователей «уходят молча».
Монетизация. Управлять ценностью и оплатами: апгрейды, даунгрейды, скидки, просрочки, возвраты. Решения: когда менять цену, какие ограничения тарифа работают, какой вклад даёт расширение функциональности.
Если у вас несколько планов, add‑ons или разные продуктовые линейки, в метриках важно учитывать:
Примеры рабочих вопросов:
Когда эти вопросы сформулированы, дальше проще определить набор метрик, необходимые события и структуру интерфейса дашбордов.
Система метрик для SaaS ломается не из‑за формул, а из‑за разного понимания слов. Поэтому первый шаг — зафиксировать глоссарий: что вы считаете «активным пользователем», когда клиент «ушёл», что считается «оплатой», а что — «обещанием оплатить». Это снимает споры между продуктом, продажами и финансами и делает отчёты сопоставимыми месяц к месяцу.
На старте достаточно набора, который отвечает на три вопроса: сколько зарабатываем, сколько теряем, сколько стоит рост.
Удержание можно считать по‑разному, и выбор влияет на решения:
Активный пользователь — это не «заходил в приложение», а совершил набор действий, связанных с ценностью (например, создал/обновил сущность, запустил отчёт, отправил инвайт). Зафиксируйте правило и минимальный порог (одно событие или несколько).
Отток тоже требует точности: вы считаете churn по аккаунтам, по пользователям или по MRR? И что является фактом ухода: отмена подписки, неуспешное списание, конец оплаченного периода без продления? Один раз согласуйте эти правила и внесите их в глоссарий — тогда любые дашборды будут говорить на одном языке.
Чтобы веб‑приложение для SaaS действительно помогало считать метрики SaaS, важно заранее определить «скелет» данных: какие сущности вы фиксируете и из каких систем они приходят. Тогда MRR и ARR, отток клиентов churn, удержание retention и вовлечённость пользователей будут строиться на одних и тех же фактах, а не на догадках.
Базовый набор для большинства продуктов:
Важно сразу отделить: пользователь может «активно кликать», но платить будет аккаунт. Если эти сущности смешаны, когортный анализ и сегментация пользователей начнут давать странные результаты.
Источники обычно распределяются так:
Заведите стабильные ключи: user_id, account_id и external_id (ID из платёжки/CRM). Храните таблицу соответствий, чтобы склейка не зависела от e‑mail.
Для качества данных закрепите правила:
Событийная аналитика отвечает на простой вопрос: что именно делают пользователи в продукте и как это связано с удержанием и выручкой. Чтобы метрики вовлечённости были сопоставимыми во времени, сначала фиксируют «словарь» событий и единый формат записи.
Минимальный контракт события удобно держать одинаковым для всех источников:
name — имя событияtimestamp — время (лучше в UTC)user_id — пользовательaccount_id — аккаунт/организация (если есть B2B‑модель)properties — параметры (контекст)В properties обычно кладут: plan, role, source, feature, page, device, country, utm_*, session_id, experiment_variant. Важно не раздувать свойства «на всякий случай»: каждое свойство должно поддерживать конкретный сценарий анализа.
Хорошее правило: событие — это действие в прошедшем времени, свойства — уточняют «что/где/как».
Примеры:
signup_completed (properties: method=email, invite=true)onboarding_step_completed (properties: step=import_data)project_created (properties: template=kanban)integration_connected (properties: provider=slack)billing_subscription_updated (properties: action=upgrade, to_plan=pro)Соглашения, которые помогают не спорить потом:
snake_case для name и ключей свойствduration_ms, size_bytesВовлечённость лучше считать не по кликам, а по «ценностным действиям». Выберите 3–7 ключевых фич, которые действительно коррелируют с удержанием (например: создание проекта, приглашение коллеги, подключение интеграции, экспорт отчёта).
Для онбординга полезна линейка событий:
onboarding_startedonboarding_step_viewed / onboarding_step_completedonboarding_completedТак вы сможете увидеть, на каком шаге люди застревают, и связать это с последующим retention.
Клиентский трекинг (веб) хорош для экранов, кликов и времени в интерфейсе. Серверный — для фактов, которые «точно случились»: успешная оплата, создание сущности, завершение фоновой задачи.
Практичный вариант — поддержать оба канала:
account_id, статус операции)Главное — обеспечить идемпотентность (например, event_id в properties) и единые идентификаторы, чтобы не получить «двойной» подсчёт вовлечённости.
Хорошая модель данных для аналитики SaaS решает две задачи: помогает точно считать метрики (MRR, churn, retention) и позволяет объяснять «почему так получилось» — через историю изменений тарифов, статусов и поведения пользователей.
На старте обычно достаточно пяти таблиц (или коллекций) с понятными границами ответственности:
Важно: subscriptions отвечает за «что обещано», а invoices — за «что реально произошло в деньгах». Это снижает ошибки при расчёте MRR/ARR.
Типичная схема выглядит так:
Не храните только «текущий план». Для корректного MRR и анализа churn нужны изменения во времени:
Так вы сможете отвечать на вопросы: «когда именно вырос MRR?» и «сколько downgrade предшествовало оттоку?».
Если продаёте в разных валютах, в invoices храните:
Главное правило: аналитика должна опираться на неизменяемые финансовые факты (инвойсы/платежи) и исторические статусы подписок — тогда метрики будут воспроизводимыми и проверяемыми.
Пайплайн — это «конвейер», который превращает сырые события и платежные записи в понятные метрики на дашборде. Чем он проще и предсказуемее, тем меньше споров про цифры и тем быстрее вы замечаете проблемы с удержанием и оттоком.
Обычно удобно мыслить в четырёх шагах.
Ingestion (импорт): вы принимаете события из веб‑приложения (клики, активации, ключевые действия), данные биллинга, CRM и поддержки. На этом шаге важно сразу фиксировать минимальный набор полей: user_id/account_id, event_name, timestamp, source, а также версию схемы.
Валидация и очистка: проверяете типы и обязательные поля, нормализуете часовые пояса, приводите названия событий к единому словарю, отбрасываете «мусор» (например, тестовые аккаунты). Всё, что не прошло проверку, лучше складывать в отдельный «карантин», чтобы не терять данные и быстро чинить отправителя.
Хранение сырья (raw): сохраняете данные как есть, с минимальными преобразованиями. Это страховка: если завтра изменится формула MRR или логика когорт, вы сможете пересчитать витрины без паники.
Витрины (marts): готовите таблицы и агрегаты для отчётов: ежедневные активные, retention по когортам, MRR/ARR, churn, сегменты. Витрины должны обновляться по расписанию и быть воспроизводимыми.
Стрим (через очередь) нужен, когда важна оперативность: алерты по падению активаций, всплеск ошибок, резкие изменения конверсии. Батч‑обработка проще и дешевле для большинства метрик: ежедневные обновления retention, недельные отчёты, перерасчёт исторических периодов.
Хорошая практическая комбинация: события принимаются в очередь, а витрины пересчитываются батчем (например, раз в час/день), чтобы дашборды были стабильными.
Повторная отправка — норма: браузер перезагрузился, сеть «моргнула», SDK сделал ретрай. Поэтому:
event_id на стороне клиента/сервера;event_id или сочетание user_id + event_name + timestamp + source) в слое raw или на входе в витрины.Добавьте понятные правила ретраев: сколько попыток, с какой задержкой, когда переводить запись в карантин. Затем — наблюдаемость: метрики пайплайна (объём входа, доля ошибок, задержка обработки), логирование с контекстом (источник, версия схемы, идентификаторы) и алерты на «немые» сбои, когда событий внезапно стало слишком мало.
Такой пайплайн делает цифры в SaaS‑дашборде защищёнными: вы видите не только метрики, но и уверенность в том, что они рассчитаны из корректных данных.
Метрики SaaS полезны только тогда, когда вы одинаково их считаете в продукте, финансах и отчетах. Ниже — практичные формулы и места, где чаще всего возникают расхождения.
MRR (Monthly Recurring Revenue) — регулярная выручка в пересчёте на месяц.
MRR = сумма активных подписок за месяц.MRR = сумма(цена_периода / кол-во_месяцев_в_периоде).ARR = MRR * 12 (важно: по тем же правилам нормализации).Разложение MRR помогает понять динамику:
Проверка: MRR_end = MRR_start + New + Expansion - Contraction - Churned.
Churn_logo = churned_customers / customers_at_start.Churn_rev = churned_MRR / MRR_at_start.Ключевой нюанс — период (месяц/неделя) и правило «кто считается ушедшим»: например, подписка стала неактивной и истёк льготный период оплаты. Если нужно приоритизировать причины, начинайте с revenue churn: он быстрее показывает реальные потери.
Retention ломается из‑за разных знаменателей.
retained_users_dayN / users_in_cohort_day0.login или ключевое действие), а не «любая активность», иначе метрика будет завышена.Сверка с биллингом: итоговый MRR и списания за период должны сходиться после нормализации (учтите налоги, округления, возвраты).
Контрольные выборки: возьмите 20–50 аккаунтов разных тарифов и вручную пересчитайте MRR, churn и изменения по дням.
Инварианты: проверки типа «MRR не может быть отрицательным», «у churned аккаунта нет активной подписки», «сумма компонентов MRR сходится» — обязательны перед публикацией метрик в дашбордах.
Хороший дашборд для SaaS — это не «всё сразу», а быстрые ответы на типовые вопросы: что происходит с выручкой, где проседает удержание, какие действия в продукте ведут к оплате и кто в зоне риска оттока. Поэтому интерфейс лучше строить вокруг нескольких основных экранов, а детали прятать за фильтрами и понятными переходами.
Обзор — стартовая точка для руководителя и продукта. Здесь 6–10 ключевых карточек: MRR/ARR, net revenue retention, churn, активные пользователи, конверсия в оплату, средний чек. Важно добавить блок «что изменилось» (дельта к прошлой неделе/месяцу) и короткие пояснения к метрикам.
Выручка — динамика MRR/ARR, расширение/сокращение, новые/возвратные платежи, просрочки. Полезно показывать вклад сегментов и планов, а также список «топ‑движущих» клиентов (рост/падение).
Удержание — когорты, retention по неделям/месяцам, churn по подпискам и по пользователям (если применимо). Здесь же — причины оттока (если собираете) и связь с вовлечённостью.
Вовлечённость — активность по ключевым событиям, частота использования, adoption важных функций. Хорошая практика — отдельный блок «активация»: какие шаги коррелируют с удержанием.
Воронки — путь от регистрации до первой ценности и оплаты. Делайте 1–3 «главные» воронки, остальное — в настройках.
Фильтры должны быть едиными для всех экранов: план, канал, сегмент, страна, дата регистрации. Добавьте сохранённые наборы фильтров («SMB из EU», «Enterprise trial») и сравнение двух периодов.
Показывайте когорты сначала в виде тепловой карты и одного графика по выбранной когорте. Для трендов используйте «умные подсказки»: аннотации к всплескам (релиз, акция, изменение цен). Детализацию открывайте по клику в таблицу.
Нужны два режима: ссылка внутри команды (с закреплёнными фильтрами) и экспорт CSV для разовых сверок. Для ссылок удобно хранить параметры в URL, чтобы обсуждать один и тот же срез на встрече и в чате.
Сырые «средние по больнице» метрики редко помогают принять решение. Чтобы веб‑приложение для SaaS действительно подсказывало, что делать, нужны сегменты, воронки и понятный разбор причин churn — с привязкой к действиям пользователей.
Минимальный набор сегментов для ежедневной работы:
Важно: «в риске» лучше определять не только по давности последнего визита, а по динамике — пользователь мог заходить, но не получать ценность.
Классическая воронка для SaaS:
регистрация → активация → платёж → повторная ценность.
Где «активация» и «повторная ценность» нужно описать через конкретные события. Пример: активация = «подключил интеграцию» или «создал первый проект»; повторная ценность = «выполнил ключевое действие 3 раза за 14 дней». В интерфейсе дашборда полезно показывать воронку по сегментам (новые vs. высокоценные) — так быстрее видно, где именно «течёт» путь.
Чтобы понять причины оттока клиентов churn, сравнивайте churned vs. retained по трём осям:
Фичи и сценарии: какие функции использовали/не использовали до ухода.
Частота: падение числа сессий/ключевых событий за 2–4 недели до churn.
Время до первой ценности (TTFV): сколько времени прошло до первого «ценностного» действия. Часто именно длинный TTFV предсказывает уход.
Практичный подход — построить простую модель правил: «если не сделал событие X за Y дней после регистрации → высокий риск». Даже без сложной статистики это даёт управляемые сигналы.
Сегменты должны превращаться в задачи:
Хорошее правило: каждый сегмент в дашборде должен иметь действие «передать в процесс» (экспорт списка, создание задачи, рассылка) — иначе аналитика остаётся теорией.
Метрики полезны только тогда, когда на них можно вовремя реагировать. Поэтому в веб‑приложении для SaaS стоит заранее продумать не только графики, но и алерты: что считать проблемой, кому и как сообщать, и что делать дальше.
Есть два базовых типа алертов:
Отдельный класс — алерты по качеству данных. Если «сломались» события (вдруг стало в 10 раз меньше product events) или вырос процент ошибок импорта, это может выглядеть как падение retention, хотя проблема в трекинге.
Чаще всего хватает двух каналов: почта и корпоративный мессенджер. Важно не превратить уведомления в белый шум — иначе их начнут игнорировать.
Практики против «шума»:
У каждого алерта должен быть владелец и короткий плейбук:
Удобно хранить плейбуки прямо в приложении рядом с алертом или ссылкой на /blog/incident-playbook.
Чтобы алерты не выглядели «магией», сохраняйте:
Так вы быстрее разберётесь, почему сработал алерт, и сможете отличить реальный рост оттока клиентов churn от ошибки измерения.
Метрики и отчёты быстро превращаются в «единую правду» для бизнеса — поэтому к доступу и безопасности стоит относиться как к продуктовой функции, а не как к настройке «на потом». Ошибка в правах или утечка событийной аналитики почти всегда бьёт по доверию и деньгам.
Удобно начинать с простых ролей и постепенно детализировать:
Ключевой принцип — минимально необходимый доступ. Отдельно продумайте «опасные» операции: экспорт данных, удаление, смена источников, пересчёт витрин — их лучше защищать подтверждением (например, повторным вводом пароля) и логированием.
Минимальный набор практик для веб‑приложения метрик:
Собирайте только то, без чего нельзя посчитать метрики SaaS. Часто достаточно стабильных идентификаторов (user_id, account_id), таймстемпов и коротких атрибутов сегментации.
Определите:
Если продукт продаётся нескольким компаниям, изоляция — обязательна. На практике это означает:
Такой фундамент позволяет спокойно масштабировать дашборды, алерты и когортный анализ, не рискуя безопасностью и приватностью.
MVP для веб‑приложения для SaaS должен доказать главное: метрики SaaS считаются стабильно, обновляются предсказуемо и помогают принимать решения про удержание retention, отток клиентов churn и вовлечённость пользователей. Всё остальное — позже.
Начните с 5–8 метрик и 2–3 дашбордов. Типичный набор: MRR и ARR, churn (логотипный и по выручке), retention по когортам, активация, базовые показатели вовлечённости (например, DAU/WAU и ключевые события).
Дашборды лучше сделать «по ролям»:
Сегментацию в MVP держите простой: план, канал привлечения, страна/язык, «новые vs активные», размер команды. Это уже позволяет видеть, где ломается воронка и почему растёт отток.
Если задача — быстро собрать рабочий прототип дашбордов, витрин и базовых сущностей (users/accounts/subscriptions/invoices/events), удобно использовать подход vibe‑coding: вы описываете требования словами, а платформа помогает собрать каркас приложения и итеративно довести его до нужной логики.
Например, в TakProsto.AI можно в формате чата задать структуру данных, сценарии (MRR/ARR, churn, retention, когорты, алерты), роли доступа и экраны. Платформа ориентирована на российский рынок и позволяет:
Если для вас критична локализация и контур данных, отдельный плюс — работа на серверах в России и использование локализованных/opensource LLM‑моделей без отправки данных за пределы страны.
По тарифам обычно достаточно начать с free, а по мере роста перейти на pro или business; для крупных команд и требований по безопасности — enterprise.
Для первой версии чаще всего достаточно модульного монолита: проще деплой и меньше интеграций. Очереди подключайте, когда появятся тяжёлые импорты и пересчёты (событийная аналитика, ретро‑пересчёт когортного анализа).
По хранению практичный старт: транзакционная БД для сущностей (клиенты, подписки, платежи) + отдельное аналитическое хранилище/витрины для агрегатов по дням/неделям. Так вы не «убьёте» прод запросами к отчётам.
Дальше развивайте продукт циклом: новые источники данных (support, in‑app события), улучшение моделей (события, атрибуция), алерты по метрикам — и только затем A/B‑эксперименты и более тонкую сегментацию пользователей. Главное правило: добавляйте метрику или отчёт только если он меняет решение, а не «чтобы было».
Если вы развиваете продукт публично, можно дополнительно снизить стоимость экспериментов через «earn credits program» (кредиты за контент) или реферальные приглашения: это особенно полезно на этапе, когда вы много итеративно тестируете гипотезы и инфраструктуру MVP.
Начните с управленческих вопросов, а не с формул. Минимальный набор:
Если эти ответы нужны регулярно, под них и проектируйте события, сущности и витрины.
Зафиксируйте роли и их типовые задачи:
Практика: сделайте 2–3 дашборда «по ролям», а детализацию открывайте фильтрами и drill‑down.
Глоссарий — это ваш «контракт» между продуктом, продажами и финансами. В нём минимум:
Для MVP обычно достаточно 5–8 метрик:
Разделяйте «человек» и «плательщик». Минимальный каркас:
Сделайте единый контракт события:
name, timestamp (лучше UTC)user_id, account_idproperties (plan, role, source, feature, utm_*, и т. п.)Правила:
Лучший практический подход — двухканальный:
Обязательно:
Быстрые проверки перед публикацией дашбордов:
Если эти проверки автоматизировать в пайплайне, «поломки» будут ловиться до того, как их увидит бизнес.
Внедряйте алерты вместе с процессом реакции:
Для каждого алерта нужен владелец и плейбук: проверить данные → локализовать сегмент/шаг воронки → гипотезы → действие. Плейбуки удобно хранить рядом, например ссылкой на /blog/incident-playbook.
Соблюдайте принцип минимально необходимого доступа и выделите опасные операции.
Практика:
tenant_id на уровне запросов и витрин.Без глоссария цифры будут «прыгать» из‑за разной трактовки терминов.
Далее расширяйте только те метрики, которые меняют решения (например, дают понятные действия для продукта или CS).
Критично: subscriptions = что обещано, invoices/payments = что реально произошло в деньгах. Это снижает ошибки в MRR и churn.
snake_case для имён;event_id для идемпотентности и дедупликации.Это позволит сравнивать метрики во времени и не «ломать» воронки из‑за хаоса в трекинге.
user_id/account_id (не по e‑mail);Так вы уменьшите расхождения и получите доверие к цифрам.
Это защищает доверие к продукту и снижает риск утечек.