События, данные и единая модель показателей (KA5.6.1)

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

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

Что должна обеспечивать модель

Модель должна позволять ответить на шесть вопросов:

1. Что именно произошло: заказ, отгрузка, выкуп, возврат, изменение цены, пополнение или другое событие?
2. С каким объектом это произошло: товаром, размером, клиентом, каналом, складом, заказом или кампанией?
3. Когда событие произошло и к какому управленческому периоду относится?
4. Из какой системы получен факт и можно ли восстановить его происхождение?
5. Как событие изменило деньги, товарный ресурс, клиентский путь и обязательства компании?
6. Какое решение может быть принято на основании этого сигнала?

Показатель, который не связан с решением, может оставаться справочной статистикой. Канонический показатель KA5 должен иметь назначение, владельца, периодичность и порог реакции.

Базовые сущности

Минимальная коммерческая модель связывает:

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

Идентификаторы должны быть устойчивыми. Если один артикул в учетной системе, на маркетплейсе и у партнера записан по-разному, сначала создается таблица соответствий. Без нее невозможно надежно объединить продажи, остатки, возвраты и экономику.

Событие, состояние и расчетный показатель

Эти три слоя нельзя смешивать.

Событие

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

Состояние

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

Расчетный показатель

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

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

Минимальная модель коммерческих событий

показ / контакт
-> переход / визит
-> просмотр товара
-> примерка / добавление в корзину / запрос
-> заказ / резерв
-> подтверждение
-> отгрузка
-> доставка / выдача
-> выкуп / оплата
-> возврат / отмена / рекламация
-> окончательно удержанная продажа
-> повторная покупка

Не каждый канал содержит все события и не в каждом канале они доступны компании. Общей должна быть не длина воронки, а таблица соответствий между фактом канала и управленческим смыслом.

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

Паспорт показателя

Для каждого показателя закрепляется:

Одинаковое название при разных формулах запрещает прямое сравнение. Разные названия при одной формуле требуют нормализации словаря.

Сверка источников

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

Проверяются:

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

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

Роли и права решения

Владелец канала отвечает за полноту операционного факта и объяснение отклонений.

Товарная функция поддерживает справочник SKU, вариантов и размерного ряда.

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

Маркетинг передает источники контакта и стоимость привлечения, но не подменяет коммерческий факт KA5 медиаметриками KA3.

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

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

Стадии зрелости

На XS достаточно единой таблицы заказов, оплат, возвратов, товара и каналов с устойчивыми названиями полей.

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

На M данные нескольких каналов объединяются на уровне SKU, заказа и периода; фиксируются владельцы, качество и журнал исправлений.

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

Связанный DocKA

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

MBSE-представление

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

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

SBS - компоненты. Товар, канал, клиент, заказ, цена, затраты, остаток, системы учета, справочники, формулы, роли и журналы качества.

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

DSM - связи. Цели и финансовые определения KA1, аудитория и продуктовая форма KA2, источники контакта KA3, товарные справочники KA4 и коммерческие события KA5 соединяются в одной модели показателей.

Шлюз экспертной валидации

До публикации необходимо подтвердить:

1. минимальный набор событий для разных каналов;
2. определения заказа, продажи, выкупа и окончательно удержанной продажи;
3. обязательные справочники и ключи сопоставления;
4. момент признания показателей по стадиям зрелости;
5. допустимую задержку и качество данных для ежедневных, недельных и месячных решений.