Метрики после запуска сайта или сервиса: что отслеживать

Какие IT-метрики смотреть после запуска

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

Контроль нельзя сводить и к посещаемости: рост трафика не компенсирует потерянные обращения и сбои оплаты. Рабочая система наблюдения соединяет результат компании, опыт пользователя, техническое состояние и скорость реакции команды. Руководителю нужны не сотни графиков, а несколько сигналов с исходным уровнем, владельцем и условием проверки.

Кратко: минимальный набор показателей после запуска

Для первого управленческого дашборда обычно достаточно контролировать:

• качество исходных данных и объём миграции (особенно номенклатура/остатки);
• число интеграций и легаси-систем;
• степень кастомизации vs готовые процессы;
• количество филиалов и различия процессов между ними;
• доступность владельцев процессов и скорость принятия решений;
• зрелость проектного управления (управление изменениями и приоритетами).

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

Начните с ключевого пользовательского сценария

Перед настройкой отчётов определите главное действие. Для B2B-сайта это отправка обращения, для магазина — путь от карточки до оплаты, для кабинета — авторизация и основная операция. Если сценариев несколько, расположите их по значимости для бизнеса.

Путь разбивают на наблюдаемые этапы. Например: пользователь открыл форму, отправил данные, увидел подтверждение, запись появилась в CRM, менеджер получил уведомление. Так интерфейсная конверсия отделяется от фактического результата.

Магазин может открываться, но терять оплаты; форма — показывать подтверждение при остановленной интеграции с CRM; кабинет — пропускать авторизацию, но не выполнять запрос. Поэтому базовый показатель — доля успешных завершений среди всех попыток. Для неудач фиксируют этап, устройство, версию и тип ошибки.

Бизнес-метрики: получает ли компания результат

Этот уровень показывает, превращается ли продукт в обращения, заказы, регистрации или завершённые операции. Отправка формы ещё не равна полученной заявке: отдельно проверяют событие в интерфейсе, запись в CRM, уведомление сотруднику и дальнейший статус. В магазине связывают оформление, оплату, создание заказа и передачу в учётную систему.

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

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

Продуктовые метрики: возвращаются ли пользователи

Для регулярно используемого решения важно понять, получил ли человек первую ценность и продолжает ли работу. Активацией считают не регистрацию, а значимое действие: создание проекта, отправку отчёта или завершение основной операции.

Retention показывает долю пользователей одной группы, вернувшихся через выбранный период. Период должен соответствовать реальной частоте использования: ежедневный срез уместен для рабочего инструмента, но вводит в заблуждение для ежемесячного сервиса. Churn также определяют через понятный признак ухода.

DAU, WAU и MAU полезны, если описано, кого считать активным. Открытие страницы и выполнение операции — разные уровни вовлечённости. Для корпоративного сайта возвращаемость часто вторична: важнее путь до контакта и качество обращения.

Технические метрики: работает ли система стабильно

Доступность показывает, отвечает ли система, но не подтверждает работу её функций. Главная страница может открываться, пока поиск, авторизация, оплата или обмен с CRM недоступны. Поэтому критичные страницы, API и операции проверяют отдельно.

Доля успешных транзакций — это отношение завершившихся без ошибки операций ко всем попыткам. Ошибки разделяют на серверные 5xx, клиентские 4xx, сбои JavaScript, отказы внешних сервисов и нарушения бизнес-логики: причины и ответственные у них разные.

Среднее время ответа скрывает редкие медленные запросы. Дополнительно используют p95 — значение, быстрее которого завершились 95% операций. Так заметно ухудшение для части аудитории, растворяющееся в среднем.

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

Скорость и пользовательский опыт

Лабораторный тест проверяет страницу в контролируемой среде и помогает искать причины. Полевые данные отражают опыт реальных посетителей с разными устройствами и сетями. Для оценки качества нужны оба источника.

Для веб-страниц используют Core Web Vitals. LCP оценивает появление основного содержимого, INP — отзывчивость после взаимодействия, CLS — визуальную стабильность. Ориентиры хорошего опыта: LCP не более 2,5 секунды, INP не более 200 мс и CLS не более 0,1. Результат оценивают по 75-му перцентилю посещений и отдельно анализируют мобильные и десктопные устройства.

Хорошие Core Web Vitals не гарантируют высокую конверсию: быстрая страница может содержать неудобную форму или ошибку на следующем шаге. Связь проверяют по времени, устройствам и этапам пользовательского пути.

Метрики поддержки и качества релизов

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

Повторяемость причин важнее общего количества обращений. Один и тот же сбой требует устранения источника и автоматической проверки. Для часто обновляемого продукта также смотрят долю релизов с откатом, срочным исправлением или ручным вмешательством и время восстановления.

Метрика — то, что измеряется; целевое значение — желаемый уровень; алерт — условие уведомления. SLO фиксирует внутреннюю цель надёжности, а SLA — обязательство перед заказчиком. Для каждого числа нужно пояснить период и метод расчёта.

Минимальный дашборд после запуска

В дашборд стоит включать только те данные, по которым кто-то принимает решение. Для каждого показателя нужны источник, ритм проверки, условие реакции и владелец.

Что проверять в первые 30 дней

Как действовать при ухудшении показателя

1. Проверьте сбор данных. Убедитесь, что счётчики, логи, цели и передача статусов работают, а определение показателя не менялось.
2. Определите момент и масштаб. Найдите время начала, затронутые устройства, регионы, источники и версии продукта.
3. Сопоставьте изменение с событиями. Проверьте релизы, рекламные кампании, настройки, внешние сервисы и изменение состава трафика.
4. Локализуйте сценарий. Выясните, на каком шаге возникает потеря и воспроизводится ли она на тестовой среде.
5. Назначьте владельца и срок. Зафиксируйте ответственного за диагностику, коммуникацию и проверку результата.
6. Подтвердите восстановление. После исправления выполните контрольный сценарий и проследите показатель на реальных данных.
7. Предотвратите повторение. Добавьте мониторинг, тест, ограничение или изменение процесса, которое обнаружит причину раньше.

Падение конверсии не всегда связано с интерфейсом: причиной может быть нецелевой трафик, недоступность товара или сбой CRM. Рост ошибок не всегда вызван перегрузкой: он может начаться после изменения API партнёра. Последовательная проверка защищает команду от быстрых, но неверных выводов.

Ошибки при построении системы метрик

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

Система контроля также теряет смысл, если:

мобильные и десктопные данные объединены без возможности сравнения;

отправка формы считается заявкой без проверки поступления в CRM;

собираются десятки показателей без приоритетов;

чужой отраслевой ориентир используется вместо собственной базы;

мониторинг работает без уведомлений и регламента реакции;

никто не отвечает за проверку отклонения;

данные не связаны с версиями и временем релизов;

подрядчика оценивают количеством закрытых задач, а не состоянием продукта.

Лучше иметь восемь понятных сигналов с владельцами и действиями, чем несколько экранов, которые открывают только перед отчётной встречей.

Когда нужна постоянная техническая поддержка

Регулярное сопровождение особенно важно, если сайт влияет на продажи, принимает оплату, содержит кабинеты, зависит от интеграций или часто обновляется. Здесь позднее обнаружение создаёт прямые потери.

Поддержка должна наблюдать за ключевыми сценариями, получать алерты, вести историю инцидентов и устранять повторяющиеся причины. Формат поддержки сайта или сервиса по SLA помогает определить критичность, сроки реакции и эскалацию.

Если наблюдение показывает, что продукту нужны новые функции или переработка архитектуры, мониторинг становится источником задач для разработки и развития веб-приложений. Для сложных решений полезно смотреть, как техническая реализация связана с пользовательским путём: такой подход виден на примере крупного e-commerce проекта.

Перед передачей проекта новой команде согласуют определения, источники, доступы, пороги и владельцев. Иначе исполнители будут сравнивать разные цифры вместо устранения причины.