Словарь метрик: как согласовать определения до сравнения отчётов

Два отчёта могут показывать «конверсию», «пользователей» или «выручку» и при этом считать разные вещи. Иногда различие видно сразу: в одном отчёте конверсия считается от сеансов, в другом — от пользователей. Иногда расхождение скрыто глубже: одна система исключает возвраты, другая нет; одна считает активных пользователей, другая всех уникальных; одна привязывает продажу к дате заказа, другая — к дате оплаты.

Пока определение не зафиксировано, одинаковое название метрики создаёт ложное ощущение сопоставимости. Поэтому до сравнения отчётов полезно договориться не о том, как назвать колонку, а о том, что именно она считает.

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

Одинаковое название ещё не делает показатели одинаковыми

Возьмём простую колонку «Пользователи».

В Google Analytics 4 существует несколько разных показателей пользователей:

все пользователи;
активные пользователи;
новые пользователи;
вернувшиеся пользователи.

Google определяет их по-разному. Например, «активные пользователи» — это не просто все уникальные люди, появившиеся на сайте за период. У показателя есть собственные условия включения пользователя.

Поэтому формулировка «В этом месяце у нас 120 тысяч пользователей» неполна, пока не известно, какой именно показатель стоит за словом «пользователи».

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

Первое поле словаря — не формула, а смысл показателя

Формула сама по себе не всегда объясняет, зачем метрика существует.

оплаченные заказы / сеансы × 100%

Это формула. Но бизнес-смысл может звучать так: «Доля сеансов сайта, которые завершились оплаченным заказом».

Оба элемента нужны. Если оставить только название «Конверсия» и формулу, через несколько месяцев команда может заменить оплаченные заказы на оформленные, сохранив прежнее название. Если оставить только словесное описание, два аналитика могут реализовать его разными запросами.

Название
→ что показатель означает для бизнеса
→ как именно он рассчитывается

Конверсия особенно быстро распадается на несколько определений

Название в отчёте	Возможная формула
Конверсия	заказы / сеансы
Конверсия	покупатели / пользователи
Конверсия	оплаченные заказы / сеансы
Конверсия	лиды / переходы из рекламы
Конверсия	квалифицированные лиды / все лиды

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

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

Объект подсчёта важнее названия события

Допустим, один пользователь сделал три заказа. В одном отчёте это один покупатель, в другом — три заказа, а в третьем может оказаться четыре события purchase, если одно событие отправилось повторно.

Поэтому в словаре нужно отвечать на вопрос: что именно является одной учитываемой единицей — пользователь, сеанс, заказ, событие, товарная позиция или другой объект?

Уникальные показатели нельзя бездумно складывать

Если в понедельник было 100 уникальных пользователей, а во вторник 120, это не означает 220 уникальных пользователей за два дня: часть людей могла прийти в оба дня.

Поэтому словарь должен описывать допустимое агрегирование: можно ли складывать показатель по дням и каналам, нужно ли пересчитывать уникальность на всём периоде и можно ли усреднять значения между сегментами.

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

Среднее значение метрики не всегда считается как среднее видимых строк

Сегмент	Клики	Показы	CTR
A	5	10	50%
B	95	990	9,6%

Среднее арифметическое двух процентов — около 29,8%. Но общий CTR равен:

(5 + 95) / (10 + 990) = 10%

Значит, в словаре для отношения полезно записать не только «CTR = клики / показы», но и правило агрегирования: общий показатель пересчитывается из общей суммы кликов и общей суммы показов.

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

Период — часть определения метрики

Для одних показателей период просто ограничивает выборку, для других влияет на сам способ подсчёта. «Уникальные пользователи за день» и «уникальные пользователи за месяц» — не одно значение, только показанное в другом масштабе.

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

Если один отчёт закрывает день по Москве, а другой по UTC, одинаковая дата уже не гарантирует одинаковую выборку.

Нужно определить, к какой дате относится событие

Для продажи возможны дата создания заказа, оплаты, отгрузки, закрытия сделки, поступления денег и возврата.

Если дашборд «Выручка за август» использует дату заказа, а финансовый отчёт — дату оплаты, расхождение может быть нормальным следствием определения.

Дата учёта:
по какому временному признаку запись попадает в отчёт

Источник данных тоже входит в определение

Фраза «Заказы = 5 420» без источника оставляет несколько вариантов: события аналитической системы, заказы из CRM, база интернет-магазина, платёжная система или выгрузка рекламной платформы.

Даже если названия полей совпадают, системы могут видеть разные стадии процесса.

Основной источник
Таблица / отчёт / событие
Поле
Дополнительные источники, если есть

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

Словарь не должен скрывать расхождения между системами

Если GA4 показывает пользователей, CRM — контакты, а рекламная система — охват, переименование всех трёх колонок в «Пользователи» не создаёт единой метрики.

Хороший словарь может сохранить три отдельных показателя: «Активные пользователи GA4», «Уникальные контакты CRM», «Охваченные пользователи рекламной системы» — и описать, почему их нельзя сравнивать напрямую.

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

Поле «Формула» должно быть достаточно точным для повторного расчёта

Слабая запись:

CAC = расходы / клиенты

Возникают вопросы: какие расходы, только реклама или вся стоимость привлечения, новые клиенты или все, по какой дате клиент относится к периоду, учитывается ли НДС, входят ли агентские комиссии и как распределяются общие расходы.

Более рабочее определение:

CAC =
расходы на платное привлечение новых клиентов за период
/
число новых клиентов, впервые оплативших заказ в том же периоде

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

Фильтры являются частью расчёта, а не настройкой дашборда

Допустим, в отчёте по заказам исключены тестовые заказы сотрудников, отменённые заказы, полностью возвращённые заказы, дубликаты и один внутренний канал.

Если это записано только внутри SQL-запроса или настройки отчёта, другой аналитик может построить такой же показатель без этих условий.

Поэтому в словаре должны быть видимы ключевые правила исключения:

Заказ учитывается, если:
status in ('paid', 'shipped', 'completed')
is_test = false
is_duplicate = false

Необязательно переносить в словарь весь программный код. Нужно сохранить бизнес-правило, от которого зависит значение.

Возвраты и отмены должны быть определены заранее

«Выручка» особенно чувствительна к обработке возвратов.

Возможны разные показатели:

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

Если финансовый и маркетинговый отчёт используют разные варианты, переименование обоих в «Выручку» проблему только маскирует.

Лучше дать показателям разные имена и записать правила: «Валовая сумма заказов», «Чистая выручка после возвратов», «Оплаченная выручка», «Выручка для расчёта ROMI».

Правило дедупликации тоже должно быть явным

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

Поэтому показатель «Количество заказов» требует ответа: по какому идентификатору мы считаем заказ уникальным?

COUNT(DISTINCT order_id)

Отдельно нужно определить, что происходит, если order_id отсутствует или изменился.

Не смешивайте метрику и измерение

Google Analytics разделяет метрики и измерения. Метрика — количественный показатель, обычно число. Измерение описывает данные и используется для группировки, например страна или название события.

Для словаря это важное различие.

Метрика:
выручка

Измерения:
канал
страна
устройство
категория товара

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

Именно поэтому статья о метриках Search Console отдельно показывает клики, показы, CTR и среднюю позицию как связанные показатели, а запросы, страницы, страны и устройства — как разрезы, через которые эти показатели читаются.

Сегментация не должна создавать новые скрытые определения

После разбивки по сегментам метрика должна оставаться той же.

Конверсия всего сайта =
оплаченные заказы / сеансы

Конверсия mobile =
оплаченные заказы mobile / сеансы mobile

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

Поэтому в словаре полезно указать, какие измерения совместимы с показателем, есть ли ограничения при сегментации и меняется ли метод расчёта при другом уровне детализации.

Сам анализ неоднородности между сегментами — отдельная задача. Здесь важно другое: сегмент не должен незаметно менять определение метрики.

Одинаковая формула ещё не гарантирует одинаковый результат

Представим, что две системы используют:

CTR = клики / показы

Формула совпадает. Но результаты всё равно могут различаться, если по-разному определены сам показ, клик, дедупликация, группировка URL, типы результатов, период или часовой пояс.

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

Следовательно, карточка метрики не может ограничиваться только арифметической формулой.

Внешняя система имеет собственное определение

Если показатель приходит из Google Analytics, Search Console, рекламной платформы или другого внешнего сервиса, часть правил задаёт сама система.

Например, Google Analytics определяет «активных пользователей» по собственным условиям. Команда может создать другой внутренний показатель, но не стоит называть его тем же именем и затем сравнивать как идентичный.

В словаре в таком случае полезны поля:

Название внутри компании
Оригинальное название в системе
Ссылка на официальное определение
Что мы меняем при выгрузке, если меняем

Так сохраняется граница между исходной метрикой платформы и внутренней производной.

Производная метрика должна показывать, из чего она собрана

Часть бизнес-показателей не существует в одной исходной системе.

Например:

ROMI =
(дополнительная прибыль от маркетинга − расходы на маркетинг)
/
расходы на маркетинг

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

Иначе ROMI становится одним названием для нескольких внутренних моделей.

Не называйте один показатель KPI только потому, что он есть в отчёте

Словарь метрик и система KPI связаны, но это не одно и то же.

Метрика отвечает: «Что и как мы считаем?». KPI отвечает: «Какой показатель используется для оценки конкретной цели и какое значение считается целевым?»

Один показатель может быть обычной диагностической метрикой в одном проекте и KPI — в другом.

Поэтому в словаре можно иметь дополнительное поле:

Роль:
диагностическая метрика / KPI / контрольный показатель / справочный показатель

но сама формула не должна зависеть от того, достигнута цель или нет.

Словарь полезнее строить вокруг решений, а не вокруг всех доступных полей

Аналитическая система может содержать сотни метрик. Переносить их все в корпоративный словарь бессмысленно.

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

Если метрика не влияет ни на одно решение и нигде не используется, её документация может подождать.

Минимальная карточка метрики

Для большинства рабочих отчётов достаточно следующего набора.

Поле	Что фиксируем
Название	Единая форма в отчётах
Смысл	Что показатель означает для бизнеса
Формула	Как получается значение
Числитель / знаменатель	Для отношений и процентов
Единица подсчёта	Пользователь, сеанс, заказ, событие и т. д.
Источник	Система, таблица, отчёт или событие
Дата учёта	По какому времени запись попадает в период
Часовой пояс	Если влияет на границы периода
Фильтры	Что исключается и включается
Дедупликация	Как определяется уникальность
Правило агрегирования	Можно ли суммировать или нужно пересчитывать
Допустимые разрезы	Какие измерения можно применять без смены смысла
Ответственный	Кто подтверждает изменение определения
Версия / дата изменения	Когда определение было пересмотрено

Пример карточки: конверсия в оплаченный заказ

Название:
Конверсия сеанса в оплаченный заказ

Смысл:
Доля сеансов сайта, завершившихся хотя бы одним оплаченным заказом.

Формула:
сеансы с оплаченным заказом / все учитываемые сеансы × 100%

Единица подсчёта:
сеанс

Источник сеансов:
Google Analytics

Источник заказов:
база заказов

Дата учёта:
дата первого оплаченного заказа в рамках сеанса

Фильтры:
исключены тестовые пользователи и внутренний трафик

Дедупликация:
один сеанс учитывается в числителе максимум один раз

Агрегирование:
для общего периода пересчитывается из общего числителя и знаменателя

Даже если команда выберет другую формулу, карточка делает выбор видимым и воспроизводимым.

Пример карточки: выручка

Название:
Чистая выручка по оплаченным заказам

Смысл:
Сумма фактически оплаченных заказов за вычетом подтверждённых возвратов.

Источник:
CRM + платёжная система

Дата учёта:
дата оплаты

Налоги:
включены / исключены — зафиксировать явно

Возвраты:
вычитаются по дате возврата

Отменённые заказы:
не включаются

Валюта:
рубли

Правило пересчёта валют:
курс и дата курса зафиксированы отдельно

Такой показатель уже заметно отличается от «суммы созданных заказов», хотя в разговоре оба могут называться выручкой.

Пример карточки: пользователи из Google Analytics

Здесь особенно важно не придумывать своё определение поверх платформы.

Название в отчёте:
Активные пользователи GA4

Исходное название:
Active users

Источник:
Google Analytics 4

Определение:
используем официальное определение Google Analytics без собственной подмены

Период:
выбранный период отчёта

Примечание:
не считать показатель эквивалентом Total users

Google отдельно описывает различия между всеми, активными, новыми и вернувшимися пользователями. Значит, словарь должен сохранять эти различия, а не стирать их переводом в одно слово «пользователи».

Изменение определения должно создавать новую версию метрики

Представим, что раньше лид считался по отправке любой формы, а с сентября — только после прохождения проверки качества.

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

На одной линии окажутся разные показатели.

Правильнее:

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

Лиды v1 — все отправленные формы
Лиды v2 — формы, прошедшие проверку качества
Переход: 1 сентября 2026

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

Переименование не должно скрывать смену методики

Слабый сценарий:

до сентября:
«Лиды»

после сентября:
«Лиды»

но формула изменилась

На графике всё выглядит непрерывно, хотя смысл ряда разорван.

Если методика существенно меняется, это нужно показать пользователю отчёта: подписью, примечанием, новой серией или пересчётом истории.

Изменение источника тоже может изменить метрику

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

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

В аналитической модели одно определение лучше хранить в одном месте

Если формула CAC записана отдельно в SQL одного отчёта, в формуле Excel, в BI-дашборде, в презентации и в инструкции аналитика, пять копий постепенно расходятся.

Системы с семантическим слоем решают эту проблему технически. Например, Looker позволяет один раз описать измерения, агрегаты, вычисления и связи в модели, а затем повторно использовать их при построении запросов.

Даже если команда не использует такую платформу, организационный принцип тот же:

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

Словарь не обязан жить в отдельном дорогом сервисе

На старте достаточно таблицы, markdown-файла или страницы во внутренней базе знаний.

Критичны не технология и дизайн, а несколько условий:

определение можно найти;
у него есть ответственный;
видна дата изменения;
старую версию можно восстановить;
дашборды ссылаются на одно и то же определение.

Кто должен утверждать определение

Аналитик может реализовать формулу, но бизнес-смысл часто определяется не только аналитикой.

Например, для «нового клиента» могут понадобиться решения маркетинга, продаж, финансов, продукта и CRM-команды.

Поэтому у критичных метрик полезно указать ответственного за смысл:

Ответственный:
руководитель аналитики / финансов / маркетинга / продукта

Это не означает, что один человек вручную утверждает каждую выгрузку. Он отвечает за изменение самого определения.

Как согласовать спорную метрику между командами

Допустим, маркетинг считает новым клиентом человека, впервые пришедшего из рекламы. Финансы — человека, впервые оплатившего заказ. CRM — новый контакт без предыдущей записи.

Не нужно искать, кто «правильнее» вообще.

Команда	Что считается новым клиентом
Маркетинг	Первый рекламный контакт
CRM	Первое создание контакта
Финансы	Первая оплаченная покупка

Затем нужно задать вопрос: для какого решения нужен показатель?

В итоге словарь может сохранить все три: «Новый рекламный пользователь», «Новый контакт CRM», «Новый платящий клиент».

Унификация не обязана сводить разные бизнес-сущности к одной колонке.

Перед сравнением двух отчётов пройдите определения по одинаковым полям

Полезно сравнивать не числа, а карточки метрик.

Поле	Отчёт A	Отчёт B
Название	Конверсия	Конверсия
Числитель	Оплаченные заказы	Все оформленные заказы
Знаменатель	Сеансы	Пользователи
Источник	CRM + GA4	Веб-аналитика
Дата учёта	Дата оплаты	Дата оформления

После такой таблицы вопрос «почему 3,8% не равно 5,1%» может исчезнуть сам: это просто разные метрики с одинаковым названием.

Если определения совпали, только тогда начинается сверка чисел

1. Совпадает ли смысл?
2. Совпадает ли объект подсчёта?
3. Совпадает ли формула?
4. Совпадает ли источник?
5. Совпадают ли период и дата учёта?
6. Совпадают ли фильтры?
7. Совпадает ли дедупликация?
8. Совпадает ли уровень агрегирования?
↓
только после этого
9. Сравниваем значения

Если расхождение обнаружено на шаге 2 или 3, дальнейшая сверка до единицы не имеет смысла.

Словарь особенно важен перед автоматизацией отчётности

Ручной отчёт позволяет аналитику помнить контекст в голове. Автоматический дашборд этого не умеет.

Если определения не согласованы до автоматизации, система лишь быстрее распространяет неоднозначность:

неясное определение
→ автоматический расчёт
→ несколько дашбордов
→ десятки пользователей
→ разные решения на одной и той же колонке

Поэтому сначала стоит закрепить определения ключевых показателей, а уже затем переносить их в автоматическую отчётность.

Что проверять при добавлении новой метрики

Есть ли уже показатель с тем же смыслом. Не создаём ли дубль под другим названием.
Какое решение поддерживает метрика. Зачем она нужна.
Что является единицей подсчёта.
Какая формула используется.
Какие данные входят и исключаются.
Как определяется период.
Из какого источника приходит значение.
Как обрабатываются дубликаты, возвраты и пропуски.
Как метрика агрегируется.
Кто отвечает за изменение определения.

Типичные ошибки словаря метрик

Ошибка	Что происходит	Что сделать
Есть только название и описание	Разные аналитики реализуют метрику по-разному	Добавить формулу и правила подсчёта
Есть только SQL-формула	Непонятен бизнес-смысл показателя	Добавить понятное определение
Не указан знаменатель	Две «конверсии» оказываются несопоставимыми	Фиксировать обе части отношения
Не указан источник	Одно имя используется для данных GA4, CRM и финансов	Закрепить исходную систему
Нет правила по возвратам	«Выручка» зависит от конкретного дашборда	Зафиксировать обработку возвратов и отмен
Не описано агрегирование	Уникальные и процентные показатели складывают неверно	Указать правило пересчёта
Формула меняется без версии	Временной ряд содержит разные метрики под одним именем	Версионировать или пересчитывать историю
Все команды заставляют использовать одно определение	Разные бизнес-задачи искусственно склеиваются	Оставить несколько чётко названных показателей

Итог

Словарь метрик нужен не для того, чтобы у команды появился ещё один справочник. Он нужен, чтобы число сохраняло один и тот же смысл при переходе между людьми, системами и отчётами.

Минимально полезное определение включает:

смысл
→ формулу
→ единицу подсчёта
→ источник
→ период
→ фильтры
→ дедупликацию
→ правило агрегирования
→ версию

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

Главное правило: сначала согласовать, что считается метрикой, и только потом сравнивать её значение.