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

Метрика активации может вырасти после релиза, хотя новых пользователей, которые дошли до ключевого действия, стало меньше. Часто причина не в продукте, а в расчёте: команда поменяла окно, знаменатель или способ считать пользователей. Ниже — практические приёмы для событийной продуктовой аналитики: как зафиксировать смысл показателя, выбрать формулу и не принять технический сдвиг данных за улучшение продукта.
Сначала договоритесь, на какой вопрос отвечает метрика
Название показателя — не определение. «Активные пользователи» может означать людей, которые открыли приложение, выполнили ключевое действие или просто отправили любое событие. Эти числа отвечают на разные вопросы. Перед настройкой отчёта запишите определение так, чтобы другой аналитик мог получить тот же результат.
Для каждой метрики укажите как минимум:
- Сущность: пользователь, аккаунт, заказ или сессия. Для B2B-продукта число активных аккаунтов не равно числу активных сотрудников.
- Событие или условие: что именно считается действием. Например, не просто «создал проект», а «создал проект и добавил в него хотя бы один элемент», если именно это означает первую ценность.
- Период: за какой интервал считаем действие и к какой дате относим результат.
- Знаменатель: от какого множества считаем долю: от всех зарегистрировавшихся, новых пользователей конкретного дня или пользователей, которым функция была доступна.
- Исключения: тестовые аккаунты, внутренние пользователи, повторы событий, отменённые заказы — если они влияют на смысл показателя.
Такое определение должно жить рядом с дашбордом или в каталоге метрик, а не только в чате. Иначе при передаче отчёта команда унаследует число, но потеряет его смысл.
Три способа посчитать один продуктовый результат
Представим задачу: понять, помогает ли первый опыт в продукте новым пользователям. В качестве целевого действия выбрали создание первого проекта. Разные способы подсчёта покажут разные стороны результата.
1. Считать события
Количество событий создания проекта отвечает на вопрос, сколько раз действие произошло. Это полезно для объёма операций, но не показывает, сколько людей получили пользу: один пользователь может создать несколько проектов, а часть событий может повториться после сетевого сбоя или повторной отправки.
2. Считать уникальных пользователей и долю конверсии
Посчитайте пользователей, совершивших целевое действие, и разделите на подходящую группу. Например: уникальные новые пользователи, создавшие проект в течение семи дней после регистрации, / все новые пользователи этой когорты. Это уже показатель прохождения этапа, но только если события регистрации и создания проекта можно связать с одним идентификатором, а окно одинаково для всех.
3. Сравнивать когорты с одинаковым окном
Когорта — группа пользователей, объединённых общим моментом или условием, например неделей регистрации. Это помогает сравнить группы, не смешивая новых пользователей с теми, кто пришёл давно. Для активации дождитесь, пока у каждой сравниваемой когорты завершится семидневное окно. Иначе у самой свежей группы просто было меньше времени на целевое действие, и её результат окажется занижен.
| Подход | На какой вопрос отвечает | Главный риск |
|---|---|---|
| Число событий | Сколько раз действие произошло? | Повторы и активность нескольких пользователей раздувают значение |
| Уникальные пользователи | Сколько людей выполнили действие? | Без знаменателя нельзя сравнить группы разного размера |
| Конверсия в когорте | Какая доля новых пользователей дошла до действия за заданное время? | Незавершённое окно искажает сравнение |
Не усредняйте проценты по маленьким сегментам, если нужен общий показатель: результат может отличаться от расчёта по суммарным числителю и знаменателю. Для общей конверсии сначала сложите число пользователей с целевым действием и число пользователей в базе сравнения, затем вычислите долю.
Метрика становится полезной не тогда, когда у неё появляется красивый график, а когда два человека независимо друг от друга одинаково понимают, кого и за что посчитали.
Как выбрать главный показатель и не пропустить побочный ущерб
Для продуктового решения обычно нужны основной показатель и несколько проверочных. Основной отражает ожидаемое изменение: например, долю новых пользователей, создавших проект в течение семи дней. Проверочные помогают заметить, что рост достигнут ценой ухудшения другого результата: выросло ли число ошибок при создании проекта, увеличилось ли время до первого действия, не упала ли доля пользователей, завершивших настройку.
Не превращайте все показатели в равноправные цели. Если команда отвечает сразу за десять метрик, она не понимает, какой компромисс допустим. Запишите заранее, какой результат считается успехом, а какие изменения — причиной остановить запуск или исследовать проблему. Для выбора пользовательских показателей полезна рамка HEART от Google: она связывает цели продукта с наблюдаемыми сигналами, а не предлагает копировать универсальный набор KPI.
Когда выбирать каждый вариант
- Считайте события, когда важен объём операций: число отправленных документов или созданных заказов. Дополнительно проверьте уникальные сущности и повторы.
- Считайте уникальных пользователей, когда вопрос звучит «сколько людей попробовали функцию». Уточните, что означает уникальность: идентификатор пользователя, аккаунта или устройства.
- Считайте конверсию по когорте, когда сравниваете прохождение пути во времени или эффект изменения первого опыта. Фиксируйте окно и сравнивайте только группы, у которых оно завершилось.
Если продукт использует несколько устройств или люди работают внутри общих аккаунтов, сначала определите, какую сущность хотите измерить. Склейка устройств, смена идентификатора и приглашение коллег могут менять результат сильнее, чем новый экран.
Что ломается чаще всего
Меняется событие. После обновления клиента одно и то же действие отправляется под новым названием или с другими параметрами. Ряд на графике выглядит непрерывным, но до и после релиза в нём могут оказаться разные определения. Храните описание события и отмечайте изменения схемы.
Событие теряется или приходит дважды. Сравните число событий с независимым источником, например внутренним журналом операций, если он доступен. Проверьте повторы, задержку доставки и долю записей без идентификатора. Не считайте расхождение доказательством ошибки аналитической системы, пока не проверили, одинаково ли источники определяют операцию.
Смешаны пользователи и аккаунты. Один аккаунт с десятью сотрудниками может дать десять активных пользователей, но оставаться одним активным клиентом. Подписывайте единицу измерения прямо в названии метрики.
Незрелые когорты попали в сравнение. Последние дни периода ещё не накопили полное число целевых действий. Показывайте дату отсечения данных и не трактуйте неполный интервал как падение конверсии.
Изменился состав аудитории. Общая доля может сдвинуться потому, что стало больше пользователей из сегмента с иным поведением. Смотрите разрезы, но не делайте вывод по множеству сегментов без плана: случайные колебания легко принять за закономерность.
Что сделать дальше
Возьмите одну метрику, на которую команда уже опирается, и оформите её определение: сущность, условие, период, знаменатель, исключения и источник данных. Затем пересчитайте показатель на двух соседних периодах и сравните его с независимым сигналом — например, числом операций в основной системе. В дашборде укажите дату обновления и отметьте изменения в событиях. Если используете конкретную аналитическую платформу, отдельно проверьте её правила дедупликации, идентификации пользователей и атрибуции: здесь инструменты могут считать по-разному.
Логотип и фирменный стиль: Три концепции разного характера, палитра с обоснованием, проверка на читаемость в малом размере и в один цвет.
Спросить за 60 ₽Источники: Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications — Google Research, События в Google Analytics
Частые вопросы
Можно ли сравнивать конверсию за неделю с конверсией за месяц?
Что выбрать: пользователей или аккаунты?
Почему в аналитике число событий больше, чем в базе заказов?
Нужно ли менять формулу метрики после изменения продукта?
Как понять, что рост метрики — не случайное колебание?
Подойдут ли эти приёмы для другой аналитической платформы?
Материал носит информационный характер и подготовлен редакцией «Агентуры». Он не является офертой, рекламой или индивидуальной консультацией. Упомянутые продукты, компании и торговые знаки принадлежат их правообладателям. Перед принятием решений, влекущих юридические или финансовые последствия, обратитесь к профильному специалисту.