Модуль 5. Данные и метрики для BA (без углубления в dev)
Что BA должен уметь «про данные»
Ваша задача — связать бизнес-смысл с данными: где взять, как интерпретировать, какие ограничения, как посчитать метрику и как проверить результат. Вы не пишете сложный код и не оптимизируете запросы, но:
- понимаете предметную модель (сущности/атрибуты/связи);
- знаете, какие есть справочники и мастер-данные (MDM), кто их владелец;
- формулируете правила качества данных (DQ) и реакции на их нарушение;
- способны выполнить базовые выборки SQL для валидации;
- чётко определяете метрики (формула, гранулярность, фильтры, допуски) и готовите эталонные расчёты для UAT.
Предметная модель: сущности, атрибуты, связи
Ключевые сущности (розница/опт как пример)
- Product (SKU): Код, Наименование, Бренд, Категория, Ед.изм., НДС, Статус.
- Customer/Account: ID, Тип (B2B/B2C), Сегмент, Регион, Дата активации/закрытия.
- Store/Channel/Region: торговые точки/каналы продаж (офлайн/онлайн/дистрибуция).
- Order / OrderLine: Номер, Дата, Валюта, Статус; по строке — SKU, Кол-во, Цена, Скидка.
- Invoice/Shipment/Return: отгрузки и возвраты (важны даты и связи с заказом).
- Inventory / StockMovement: остатки, движения, дата/время фиксации, склад/магазин.
- Promotion/Price: тип промо, период действия, признак «промо»-продажи, базовая/промо-цена.
- Calendar: календарь дней/недель/месяцев, фискальные периоды, рабочие/праздничные дни, «LFL-флаги».
Атрибуты
- Обязательность (NOT NULL), тип (число/строка/дата), единицы измерения, справочники (enum/кодовые списки), правила валидации (например, Кол-во ≥ 0).
- Ключи: естественные (например, код SKU) и суррогатные (ID SKU в DWH). BA важно знать, каким ключом стыкуются источники.
Связи (кардинальности)
- Customer 1..* — Order 1..* — OrderLine ..1 — Product 1...
- Store 1..* — Inventory (снимки по времени).
- Promotion 1..* — OrderLine (через ключ промо или правило).
Практика: вынесите это в простую «доменную карту» (см. Модуль 4, UML Class). Она станет основой словаря данных и STT в SRS.
Справочники и мастер-данные (MDM)
Справочник — список значений (Каналы, Категории, Налоги, Валюты).
Мастер-данные — «золотая запись» (единая карточка клиента, SKU, сети, цен).
Что важно BA:
- Владелец каждого справочника/мастер-сущности (Data Owner/Steward).
- Процесс изменения (кто и как вносит/утверждает).
- Идентификаторы и кросс-маппинги (Oracle→1С→DWH, «словари соответствий»).
- Версионирование (когда изменилась категория/НДС/цена).
- Проверяемость (DQ-правила: дубликаты, «дыры», просроченные записи).
Риск: один и тот же Brand в двух написаниях → распад метрик. Мера: MDM/маппинги, «стоп-листы» некорректных значений, SLA на публикацию обновлений.
Качество данных (DQ): правила и реакции
Ключевые измерения: полнота, уникальность, валидность, точность, своевременность, согласованность.
Примеры DQ-правил
- Полнота: у ежедневной загрузки продаж покрытие строк за D-1 ≥ 99,5%.
- Уникальность: (OrderNumber, LineNumber) уникальны в периоде.
- Валидность: НДС ∈ {0, 10, 20}; Регион ∈ справочник.
- Своевременность: данные логистики приходят до 09:30 D.
- Согласованность: сумма по строкам заказа = сумме по шапке ± 0,5%.
- Точность: контрольные SKU сходятся с первичными ведомостями (допуск ± 0,2 п.п. по GM%).
Что делать при нарушениях (BA-политика реакции)
- Порог A (критично): ставим «баннер» в BI («данные черновые»), блокируем экспорт, рассылаем алерт.
- Порог B (умеренно): показываем предупреждение, включаем в дашборд «Качество данных».
- Ретро-исправления: логируем факт исправления и пересчёт метрик (методология версия X.Y).
Базовые SQL для BA (только чтение)
Задача — уметь самостоятельно проверить метрику на выборке. Ниже — фрагменты, которые часто нужны. (Синтаксис близок к ANSI SQL.)
Агрегация GM по SKU-каналу за период
SELECT cal.month, s.channel, ol.sku_id, SUM(ol.qty) AS qty, SUM(ol.revenue) AS revenue, SUM(ol.cogs) AS cogs, SUM(ol.logistics) AS logistics, (SUM(ol.revenue) - SUM(ol.cogs) - SUM(ol.logistics)) / NULLIF(SUM(ol.revenue),0) AS gm_pct FROM fact_order_line ol JOIN dim_calendar cal ON ol.date_id = cal.date_id JOIN dim_store s ON ol.store_id = s.store_id WHERE cal.date BETWEEN DATE '2025-05-01' AND DATE '2025-05-31' AND ol.is_return = 0 GROUP BY cal.month, s.channel, ol.sku_id;
Like-for-Like (LFL) YoY по магазинам
- Отберём магазины, которые были открыты не позже чем T-12 мес и не закрывались:
WITH active_stores AS (
SELECT store_id
FROM dim_store
WHERE open_date <= DATE '2024-05-01'
AND (close_date IS NULL OR close_date > DATE '2025-05-31')
)
SELECT
cal.month,
SUM(CASE WHEN cal.year = 2025 THEN revenue ELSE 0 END) AS revenue_2025,
SUM(CASE WHEN cal.year = 2024 THEN revenue ELSE 0 END) AS revenue_2024,
(SUM(CASE WHEN cal.year = 2025 THEN revenue ELSE 0 END)
- SUM(CASE WHEN cal.year = 2024 THEN revenue ELSE 0 END))
/ NULLIF(SUM(CASE WHEN cal.year = 2024 THEN revenue ELSE 0 END),0) AS lfl_yoy
FROM fact_sales fs
JOIN dim_calendar cal ON fs.date_id = cal.date_id
WHERE fs.store_id IN (SELECT store_id FROM active_stores)
AND cal.month IN (5) -- сравним май к маю
GROUP BY cal.month;
Замечания BA: календарь должен быть сопоставлен «май-2025 к маю-2024», а не «последние 30 дней к предыдущим 30».
OOS (out-of-stock) по дням/магазинам
Простая прокси-метрика: доля SKU-дней с нулевым/отрицательным остатком при наличии спроса.
SELECT
cal.date,
st.store_id,
COUNT(*) FILTER (WHERE inv.stock_qty <= 0 AND dem.demand_qty > 0) * 1.0
/ NULLIF(COUNT(*),0) AS oos_rate
FROM fact_inventory inv
JOIN dim_calendar cal ON inv.date_id = cal.date_id
JOIN dim_store st ON inv.store_id = st.store_id
LEFT JOIN fact_demand dem
ON dem.store_id = inv.store_id AND dem.sku_id = inv.sku_id AND dem.date_id = inv.date_id
WHERE cal.date BETWEEN DATE '2025-05-01' AND DATE '2025-05-31'
GROUP BY cal.date, st.store_id;
ARPU (Average Revenue Per User) за месяц
WITH active_users AS ( SELECT user_id FROM dim_customer_activity WHERE month = 202505 AND is_active = 1 ) SELECT 202505 AS month, SUM(revenue) / NULLIF(COUNT(DISTINCT user_id),0) AS arpu FROM fact_revenue WHERE month = 202505 AND user_id IN (SELECT user_id FROM active_users);
Критично: чётко определить «активного пользователя»: хотя бы одна сессия/покупка? оплаченный тариф? исключить триалы?
Как считать ключевые бизнес-метрики (и не попасть в ловушки)
GM / GM%
Базовая формула:
GM = Выручка − Себестоимость − Логистика;
GM% = GM / Выручка.
Риски:
- НДС/налоги: выручка с НДС или без? фиксируйте.
- Возвраты/сторно: дата отражения и взаимосвязь с периодом продажи.
- Трансферы/самовыкупы: исключить.
- Логистика: полная/только последняя миля?
- Валюта: курс на дату отгрузки или закрытия?
-
Гранулярность: уровень расчёта (SKU×канал×неделя).
Эталон: таблица сверки на 10 SKU×2 канала×1 месяц.
LFL (Like-for-Like)
Смысл: рост сопоставимых магазинов/каналов без эффекта открытий/закрытий/ремонтов.
Правила:
- Магазин активен T-12 (или T-13 фиск.) на обе даты.
- Исключить магазины на ремонте/переформате.
- Сопоставлять одинаковые периоды календаря (май к маю).
-
Валюта/НДС/метод выручки фиксированы.
Риск: «скользящее 30 дней» ≠ LFL, несопоставимо по календарю.
OOS (Out-of-Stock) / Service Level
Базовые прокси OOS:
- Складской OOS: stock_qty ≤ 0 (или < safety stock).
-
Полочный OOS: по данным POS (в продажах нули при наличии спроса) — требует сигналов.
Расчёт: доля SKU-дней с OOS; или «потерянные продажи» = прогнозный спрос − фактические продажи при OOS.
Риски: лагающие данные, склейка магазинов, нет признака спроса.
ARPU
Определение активного пользователя (установите критерий).
Выручка: только «core revenue» или включая доп. услуги?
Исключения: фрод/возвраты/сертификаты?
Риск: перемешивание валют/НДС, выбросы (требуются тримминг или медиана).
Валидация метрик: как BA доказывает правильность
- Словарь метрики: формула, гранулярность, источники, исключения, владелец, версия.
- Эталонные наборы (reference): файлы/SQL-снапшоты с «правильными» расчётами на небольшой выборке.
- Контрольные точки: 10–20 SKU/клиентов/магазинов «маяки».
- Перекрёстные проверки: равенство «по строкам vs по шапке», сверка с бухгалтерией/ERP.
- Допуски: по GM% ±0,2 п.п.; по ARPU ±0,5%.
- UAT-сценарии (Given/When/Then) и чек-лист DQ перед приемкой.
Частые риски и как их снимать
|
Риск |
Симптом |
Решение (BA) |
|---|---|---|
|
Несогласованный словарь |
«Маржа не бьётся» |
Утвердить формулы/исключения/владельцев, версия методологии |
|
Валюта/НДС/часовые пояса |
«По курсу не сходится» |
Единая политика конвертации, флаг НДС, TZ в календаре |
|
Поздние возвраты/сторно |
«Задним числом» |
Политика отражения: в периоде продажи или текущем; отметить в дашборде |
|
Дубликаты/дыры |
«Продаж больше, чем отгрузок» |
DQ-правила + алерты, блок экспорта при критике |
|
Несопоставимый период |
LFL «неправильно хороший» |
Точные правила LFL (календарь, активность), фильтры |
|
Промо-признак недостоверен |
«Не отделить промо» |
Согласовать источник признака и fallback-правила |
|
Роль-доступы ломают расчёты |
«Гм% “прыгает” у разных» |
RLS по фактам/измерениям, тест роли «Регион Х» в UAT |
|
Нет версии методологии |
История метрик «плавает» |
Версионирование словаря + заметные баннеры «изменена методология» |
Теория «ровно сколько нужно»
- Гранулярность: уровень, на котором хранится/считается факт. Сверху агрегируете — ОК; снизу восстанавливать нельзя.
- Историчность (SCD/снимки): SCD2 для измерений (категория SKU менялась), снимки фактов для состояния (остатки на конец дня).
- Инкремент vs snapshot: инкремент — добавили события; снапшот — заменили состояние. Для ARPU и OOS обычно нужны снапшоты.
- Data Contract: явное соглашение «какие поля/типы/частота/качество» источник обязан давать.
- Lead/Lag-метрики: ранние (coverage, MAU) и итоговые (GM%, OOS) — планируйте обе.
Практика (что сдать по итогу модуля)
A. Словарь показателей (минимум 6 шт.)
Для каждой метрики: Название/код, Формула, Единицы, Гранулярность, Фильтры/исключения, Источник(и), Владелец, Допуски, Версия/дата.
B. Таблица «Метрика → Источник данных»
Какие таблицы/поля используются, ключи стыковки, календарь, валюта/НДС.
C. Выборка «как проверить метрику» (3–5 SQL/Excel-расчётов)
— GM% по 10 SKU×2 канала×1 месяц;
— LFL YoY по магазинам (май к маю);
— OOS по SKU-дням;
— ARPU за месяц с определением «активного» пользователя.
К каждому — эталонная таблица и допуск.
D. План DQ-правил и реакций
Минимум 5 правил (полнота/уникальность/валидность/своевременность/согласованность) + пороги A/B + действия.
Вопрос–ответ (FAQ)
Q: Кто владелец метрики?
A: Бизнес-владелец (финконтролер/методолог). BA оформляет формулу, владелец утверждает и версионирует.
Q: Как выбрать допуск для сверки?
A: От бизнес-риска и источника: для GM% часто ±0,2 п.п., для выручки абсолютный порог (например, ±0,1%).
Q: Что делать, если нет признака промо?
A: Временный прокси (календарь маркетинга + правило по типу скидки/SKU-лист), маркировка точности, план донасыщения источника.
Q: Нужен ли BA SQL?
A: Базовый SELECT/JOIN/GROUP BY/CASE/WINDOW — да. Это экономит недели на UAT и снимает споры по расчётам.
Q: Как жить с поздними возвратами?
A: Зафиксировать методологию (в периоде продажи или текущем), показывать корректировки отдельно, версионировать.
Q: Почему LFL иногда «портит» рост?
A: Потому что убирает эффект открытий/закрытий. Это честная метрика органики — именно поэтому её любят финансы и инвесторы.
Мини-шаблоны (перенесите в Confluence/Notion)
Шаблон метрики
- Код/Название: GM%
- Формула: (Revenue − COGS − Logistics) / Revenue
- Единицы: доля (процент)
- Гранулярность: SKU×Канал×Месяц
- Фильтры/исключения: возвраты вне периода → корректировка текущего; трансферы исключить
- Источники: fact_order_line, dim_calendar, dim_store, dim_product
- Допуск: ±0,2 п.п. к эталону
- Владелец: Финконтролер ФИО
- Версия: 1.3 от 2025-05-15
Шаблон DQ-правила
- Код: DQ-COMP-001
- Описание: полнота строк продаж за D-1 ≥ 99,5%
- Проверка: COUNT(продажи D-1) / COUNT(ожидаемые строки)
- Порог A: < 98,5% (блок экспорта, баннер, алерт)
- Порог B: 98,5–99,5% (предупреждение)
- Владелец: Data Steward Продажи
Шаблон валидации
- Что проверяем: GM% за май по 10 SKU
- Как: SQL-выборка + Excel-эталон GM_reference_May.xlsx
- Допуск: ±0,2 п.п.
- Ответственный: BA/QA
- Результат: Протокол UAT-XX
Чек-листы готовности
Словарь метрик
- Формулы и единицы измерения понятны и проверяемы
- Гранулярность и источники указаны
- Исключения/фильтры перечислены
- Владелец и версия проставлены
- Есть эталонные выборки и допуски
DQ
- Определены 5+ правил с порогами
- Настроена реакция A/B (баннер, алерт, блок)
- В отчёте есть виджет качества данных
- Ведётся лог нарушений и исправлений
Валидация
- SQL/Excel-эталоны подготовлены
- 10–20 контрольных SKU/магазинов
- Кросс-проверки «строки vs шапка», ERP/GL
- UAT-сценарии Given/When/Then
Вы переводите бизнес-язык в данные: закрепляете предметную модель, справочники/MDM, правила качества, «каментизируете» метрики и умеете их проверять короткими выборками. С таким набором вы уверенно разговариваете с ИТ и бизнесом, снижаете риски ошибочных решений и ускоряете приемку. Если нужно, соберу для вашего кейса полный словарь показателей и пакет эталонных сверок (SQL+Excel) под ваш источник данных и методологию.
