Бизнес‑вопрос редко звучит как готовая аналитическая задача. Руководитель может спросить: «Какие подразделения требуют внимания?», «Пользуются ли приложением?» или «Почему результат изменился?». В этих формулировках понятен общий интерес, но ещё нет показателей, правил расчёта и структуры будущего отчёта.
Можно сразу выбрать несколько доступных метрик и построить графики. Но тогда система будет отвечать не на исходный вопрос, а на то, что оказалось проще посчитать.
В моих проектах эта проблема возникала и при разработке BI‑отчётности для сравнения подразделений, и при проектировании аналитики мобильного приложения. В обоих случаях работа начиналась с широкого вопроса. Затем его нужно было разложить на более узкие аналитические задачи, определить объекты наблюдения, выбрать основные и объясняющие показатели, а после проверить, можно ли их достоверно получить из существующих данных.
В этой статье разберу сам переход от вопроса к показателям. Без универсального каталога KPI, потому что один и тот же показатель может быть полезен в одном процессе и бесполезен в другом.
Бизнес‑вопрос и аналитический вопрос — не одно и то же
Бизнес‑вопрос описывает неопределённость, которая мешает принять решение. Например:
Какие подразделения требуют дополнительного внимания?
Аналитическая система не может напрямую рассчитать ответ на слово «требуют». Сначала нужно определить, по каким признакам подразделение попадает в эту категорию.
Вопрос приходится разделить:
какой результат сравнивается;
с чем он сравнивается;
за какой период;
какое отклонение считается существенным;
можно ли сравнивать абсолютные значения;
какие факторы объясняют результат;
достаточно ли полны и актуальны исходные данные.
После этого появляются аналитические вопросы:
как распределён показатель между подразделениями;
как он изменился относительно прошлого периода;
насколько значение отличается от общего ориентира;
связано ли отклонение с размером подразделения;
какие категории внесли основной вклад в изменение;
не объясняется ли результат неполным обновлением данных.
Только теперь можно переходить к показателям. Один исходный вопрос почти всегда требует не одной метрики, а связанного набора.
Начать с решения
Перед выбором показателей необходимо понять, какое действие последует после просмотра аналитики.
Если руководитель хочет просто получить общую картину, ему может быть достаточно нескольких итоговых значений и динамики. Если нужно определить проблемное подразделение, потребуется сравнение по единой методике. Если после этого проводится разбор причин, понадобятся дополнительные разрезы и переход к детализации.
Я использую простую цепочку:
Бизнес‑вопрос → решение → аналитические подзадачи → показатели → данные → проверка.
Если пропустить решение, цепочка начинается сразу с показателей. Тогда в отчёт обычно попадает всё, что доступно в базе, а пользователь вынужден самостоятельно искать смысл среди карточек и диаграмм.
Для BI‑кейса решение можно сформулировать так:
Выбрать подразделения с отклонением, проверить причины и определить, где требуется дополнительный анализ.
Эта формулировка уже задаёт несколько требований:
нужен показатель результата;
нужен ориентир для сравнения;
требуется единая база расчёта;
должны быть видны факторы отклонения;
пользователь должен перейти от общего значения к деталям.
Определить объект и единицу наблюдения
До формулы необходимо понять, что именно считается.
Показатель «количество операций» может рассчитываться по строкам таблицы, уникальным документам, пользователям или завершённым процессам. Все четыре варианта технически возможны, но отвечают на разные вопросы.
Поэтому для каждого показателя нужно определить:
объект анализа;
событие, при котором объект попадает в расчёт;
уровень детализации исходных данных;
признаки уникальности;
временную привязку;
статус, при котором запись считается действующей.
Например, при аналитике мобильного приложения недостаточно написать «количество пользователей». Необходимо определить, идёт ли речь обо всех зарегистрированных пользователях, уникальных запустивших приложение, успешно авторизовавшихся или совершивших целевое действие.
Без этого два отчёта с названием «Пользователи» могут показывать разные значения и при этом оба формально будут рассчитаны без ошибок.
Разложить вопрос на четыре слоя
Практически любой широкий вопрос я раскладываю как минимум на четыре группы показателей.
1. Результат
Основной показатель должен прямо отражать предмет решения. Это число, по которому пользователь понимает, есть ли отклонение или изменение.
Основных показателей не должно быть много. Если на один вопрос предлагается десять равноправных KPI, значит, приоритет ещё не определён.
2. Объясняющие факторы
Они помогают понять, почему изменился результат. Это может быть структура по категориям, подразделениям, типам операций, периодам или этапам процесса.
Объясняющий показатель не обязан находиться на главной странице. Его место может быть на следующем уровне детализации.
3. Контекст
Одного значения недостаточно без базы сравнения. Контекстом могут быть:
прошлый период;
общий результат организации;
плановое значение;
размер подразделения;
количество объектов, из которых рассчитан итог;
доля в общем объёме.
Именно контекст позволяет отличить реальное отклонение от разницы в масштабе.
4. Качество данных
Пользователь должен понимать, насколько результат пригоден для решения. Для этого могут потребоваться:
дата обновления;
полнота загрузки;
количество записей без нужного атрибута;
наличие неподтверждённых данных;
статус источника;
доля записей, исключённых из расчёта.
Эти показатели часто считают техническими и убирают из пользовательского отчёта. Но без них можно принять решение на основе неполного периода или частично загруженного подразделения.
Пример: какие подразделения требуют внимания
Исходный запрос к BI‑отчёту включал значения по подразделениям, динамику, общий результат организации, фильтры и выделение лучших и худших значений.
Если просто построить рейтинг, крупнейшие подразделения могут оказаться сверху из‑за масштаба, а небольшие — внизу из‑за меньшего объёма. Поэтому вопрос нужно разложить.
Аналитическая задача | Возможный показатель |
|---|---|
Показать общий результат | Абсолютное значение за выбранный период |
Обеспечить сопоставимость | Относительный показатель с согласованным знаменателем |
Показать изменение | Абсолютное и относительное изменение к предыдущему периоду |
Найти отклонение | Разница между подразделением и выбранным ориентиром |
Объяснить отклонение | Структура результата по значимым категориям |
Проверить масштаб | Количество объектов, участвующих в расчёте |
Проверить пригодность данных | Дата обновления, полнота и пропуски |
Это ещё не окончательный перечень KPI. Таблица показывает логику: каждый показатель закрывает конкретную часть исходного вопроса.
Если показатель нельзя связать ни с одной аналитической задачей, его включение стоит пересмотреть.
Абсолютное значение почти всегда требует знаменателя
Одна из распространённых ошибок — сравнивать объекты только по количеству событий.
Предположим, одно подразделение имеет больше операций, пользователей или документов. Высокое значение может означать хороший результат, проблему или просто больший масштаб.
Чтобы понять смысл, добавляется относительный показатель:
$$K = \frac{N_{target}}{N_{base}} \times 100%,$$
где $N_{target}$ — количество объектов с нужным признаком, а $N_{base}$ — общий объём объектов, для которых этот признак мог возникнуть.
Основная сложность находится не в самой формуле, а в знаменателе. Нужно определить:
какие объекты входят в базу;
исключаются ли незавершённые записи;
учитываются ли дубли;
совпадает ли период числителя и знаменателя;
доступны ли одинаковые данные по всем сравниваемым объектам.
Неправильный знаменатель создаёт убедительный процент, который нельзя корректно интерпретировать.
Поэтому в отчёте полезно сохранять рядом и относительное значение, и объём базы. Пользователь видит не только процент, но и количество наблюдений, на котором он рассчитан.
Динамика — это не просто линия на графике
Запрос «покажите динамику» тоже нужно уточнять.
Минимально можно рассчитать абсолютное изменение:
$$\Delta X = X_{current} — X_{previous}.$$
Для объектов разного масштаба дополнительно используется относительное изменение:
$$\Delta X_{rel} = \frac{X_{current} — X_{previous}}{X_{previous}} \times 100%.$$
Но перед расчётом необходимо определить:
какие периоды сравниваются;
являются ли они полными;
одинаково ли формировались данные;
не менялся ли состав подразделения;
что происходит, если в предыдущем периоде значение равно нулю;
нужно ли учитывать сезонность процесса.
Линия на графике не отвечает на эти вопросы. Она только визуализирует уже принятую методику.
Отдельно важно не смешивать изменение показателя и изменение качества данных. Если источник начал передавать больше записей, рост может быть связан с полнотой загрузки, а не с реальным процессом.
Среднее значение может скрыть проблему
Среднее удобно для общей картины, но оно сглаживает структуру.
Если несколько подразделений показывают высокий результат, а несколько — низкий, общий средний показатель может выглядеть стабильным. Пользователь не увидит, что внутри системы увеличился разброс.
Поэтому к среднему значению могут понадобиться:
распределение по объектам;
медиана;
минимальное и максимальное значения;
количество объектов выше или ниже заданного ориентира;
структура по категориям;
объём наблюдений в каждой группе.
Не все эти показатели нужно выводить одновременно. Выбор зависит от решения. Если задача состоит в поиске отдельных отклонений, распределение полезнее ещё одной итоговой карточки.
Пример: пользуются ли мобильным приложением
При проектировании аналитики мобильного приложения исходный вопрос звучал шире набора метрик: нужно было понимать, используется ли продукт, какие разделы востребованы, возвращаются ли пользователи и где возникают проблемы.
Один вопрос пришлось разделить на несколько аналитических блоков.
Охват
уникальные пользователи;
новые пользователи;
активные пользователи за день, неделю и месяц;
распределение по Android и iOS.
Интенсивность использования
количество сессий;
средняя длительность использования;
частота возвращения пользователей.
Использование функций
открытия основных экранов;
успешный вход и ошибка входа;
переключение даты или периода;
открытие информации об объекте;
выбор раздела, категории или семестра;
другие действия внутри ключевых пользовательских сценариев.
Техническое качество
падения приложения;
необработанные ошибки;
версия приложения;
устройство и операционная система.
Каждая группа отвечает только на часть исходного вопроса. Большое количество установок не доказывает регулярное использование. Высокое число сессий не показывает, смог ли пользователь выполнить нужное действие. Частое открытие экрана может означать как востребованность, так и необходимость несколько раз повторять неудачную операцию.
Поэтому продуктовую метрику нужно связывать с пользовательским сценарием.
От метрики к событию
После выбора показателя необходимо определить, какие события и параметры позволяют его рассчитать.
Например, показатель «успешность авторизации» требует как минимум двух результатов:
успешный вход;
ошибка входа.
Но даже этих событий недостаточно, если нужно понять причину проблемы. Могут потребоваться параметры:
время события;
версия приложения;
платформа;
тип ошибки;
этап сценария;
результат повторной попытки.
При этом в аналитику не следует передавать больше данных только потому, что технически это возможно. Каждый параметр должен быть связан с будущим разрезом, фильтром или проверкой.
Логика работает в обратную сторону:
Какой вопрос задаст аналитик?
Какой показатель поможет ответить?
По каким признакам его нужно разложить?
Какие события и параметры дадут эти признаки?
Где и когда событие должно фиксироваться?
Если начать сразу с логирования всех действий, получится большой поток событий без понятного назначения.
Основной показатель, диагностические и ограничители
Полезно заранее разделить показатели по роли в анализе.
Основной показатель
Отвечает на центральную часть вопроса и используется для принятия решения.
Диагностические показатели
Объясняют изменение основного результата. Они раскрывают структуру, этапы процесса и различия между сегментами.
Ограничители
Не позволяют признать результат хорошим, если нарушено важное условие. Например, рост использования приложения не должен считаться положительным результатом, если одновременно увеличилась доля ошибок в ключевом сценарии.
Показатели качества данных
Показывают, можно ли доверять расчёту: насколько полон период, все ли источники обновились и какая часть записей исключена.
Такой подход защищает от оптимизации одной удобной метрики. Система оценивается не по максимальному числу, а по сочетанию результата, качества сценария и надёжности данных.
Зафиксировать паспорт показателя
Название и формула не описывают показатель полностью. Для воспроизводимого расчёта нужен паспорт.
Поле | Содержание |
|---|---|
Бизнес‑вопрос | Какую неопределённость уменьшает показатель |
Решение | Что пользователь делает после просмотра |
Название | Как показатель отображается в системе |
Тип | Основной, диагностический, ограничитель или качество данных |
Формула | Правило расчёта |
Числитель и знаменатель | Состав обеих частей относительного показателя |
Объект | Что именно считается |
Период | За какой интервал формируется значение |
Источник | Откуда поступают данные |
Исключения | Какие записи не участвуют в расчёте |
Разрезы | По каким признакам доступна детализация |
Обновление | Когда значение считается актуальным |
Владелец | Кто подтверждает смысл показателя |
Проверка | Как сверяется результат |
Паспорт особенно важен, когда один показатель используется в нескольких отчётах. Без единого описания в каждом разделе постепенно появляется собственная версия расчёта.
Проверить доступность данных до утверждения KPI
Показатель может быть полезным, но недоступным на текущем уровне данных.
Перед включением в систему нужно проверить:
существует ли нужный объект в источнике;
фиксируется ли событие, необходимое для расчёта;
можно ли определить уникальность;
хранится ли история изменений;
доступны ли нужные статусы и даты;
совпадают ли справочники между системами;
можно ли применить одинаковую методику ко всем объектам;
не требует ли расчёт персональных данных, которые не нужны для решения.
После проверки показатель относится к одной из групп:
Рассчитывается на доступных данных.
Требует подготовки витрины или изменения модели.
Требует нового события или параметра.
Не может быть достоверно рассчитан на текущих источниках.
Четвёртый результат не означает провал аналитика. Это честное ограничение, которое защищает систему от недоказанных значений.
Не путать KPI с тем, что легко получить
Доступность данных часто влияет на набор метрик сильнее, чем бизнес‑задача. Если в базе уже есть количество записей, его проще вывести, чем определить прохождение целевого сценария. Если система хранит открытия экранов, возникает соблазн оценивать продукт только по просмотрам.
Я проверяю каждую метрику тремя вопросами:
Какое решение изменится при росте или снижении значения?
Может ли показатель измениться без реального изменения процесса?
Какие дополнительные данные нужны, чтобы правильно его интерпретировать?
Если на первый вопрос нет ответа, показатель, скорее всего, информационный. Он может быть полезен для контекста, но не должен занимать место основного KPI.
Если ответ на второй вопрос положительный, нужны ограничители или показатели качества данных.
Если третий вопрос остаётся без ответа, метрика слишком неоднозначна для самостоятельного использования.
Ограничить итоговый набор
После декомпозиции одного бизнес‑вопроса легко получить несколько десятков потенциальных показателей. Показывать их все не нужно.
Для первого уровня отчёта я бы оставил:
один или несколько основных результатов;
понятный ориентир для сравнения;
изменение во времени;
объём базы расчёта;
признак качества или актуальности данных.
Диагностические показатели переходят на следующие уровни. Технические метрики могут находиться в отдельном разделе мониторинга. Редко используемые разрезы остаются в выгрузке или специализированном отчёте.
Хороший набор показателей не стремится описать систему целиком. Он позволяет пройти путь от вопроса к решению без лишних переключений и ручных расчётов.
Проверить набор на сценарии
Перед разработкой дашборда полезно взять один реальный сценарий и пройти его только по описанным показателям.
Для сравнения подразделений:
Пользователь видит общий результат.
Находит объект с отклонением.
Проверяет, не связано ли значение с масштабом.
Смотрит изменение по периодам.
Переходит к структуре и находит основной фактор.
Проверяет полноту и дату обновления.
Получает достаточно информации для следующего действия.
Для мобильного продукта:
Аналитик видит изменение активной аудитории.
Проверяет возвращаемость и количество сессий.
Определяет, какие основные экраны и действия изменились.
Смотрит ошибки по версии и платформе.
Отделяет изменение поведения от технической проблемы.
Если в середине сценария возникает вопрос, на который набор метрик не отвечает, требуется дополнительный показатель или разрез. Если показатель ни разу не используется, его место в отчёте стоит пересмотреть.
Что получилось в проектах
В BI‑кейсе широкий запрос на сравнение подразделений был преобразован в показатели результата, динамики, масштаба, детализации и качества данных. Один из построенных отчётов используется в работе.
Для мобильного приложения набор аналитики был спроектирован до полноценного накопления данных: общая активность, сессии, возвращаемость, просмотры экранов, основные действия, ошибки и технические параметры. Поэтому здесь я не могу приводить фактические значения или заявлять об эффекте внедрения. Подтверждённым результатом является сформированный план измерений, а не изменение продуктовых метрик.
Это различие важно. Проектирование показателя и получение результата по нему являются разными этапами. Наличие формулы ещё не означает, что данные накоплены, качество проверено и показатель уже можно использовать для выводов.
Чек‑лист преобразования вопроса в показатели
Как звучит исходный бизнес‑вопрос?
Какое решение должно быть принято?
Кто принимает это решение?
Какой объект и событие анализируются?
Какой показатель напрямую отражает результат?
Какие факторы объясняют его изменение?
Какой контекст нужен для сравнения?
Нужен ли знаменатель для сопоставимости?
Какие ограничители не позволяют неверно оценить результат?
Как пользователь увидит качество и актуальность данных?
Какие источники, события и параметры нужны для расчёта?
Можно ли воспроизвести формулу на детализации?
Как показатель будет проверяться?
Используется ли каждый показатель в реальном сценарии?
Итог
Бизнес‑вопрос нельзя механически заменить одной удобной метрикой. Сначала нужно определить решение, затем разложить вопрос на результат, объясняющие факторы, контекст и качество данных.
После этого показатель связывается с объектом расчёта, периодом, источником, формулой, разрезами и способом проверки. Только такая связка превращает число в аналитический инструмент.
Главный критерий здесь простой: пользователь должен понимать не только значение показателя, но и почему оно изменилось, можно ли ему доверять и какое действие следует дальше. Если набор метрик не позволяет пройти этот путь, он описывает данные, но ещё не отвечает на бизнес‑вопрос.
