# Проектирование дашбордов и показателей для ITECH

Приложение АйТека (самописная CRM/ERP): модель данных, стыковка, механика статусов и воронок. Источник зёрен для аналитики.

# Типы тендеров и статусы проекта (как реализовано в Grace)

Техническая механика воронок продаж. Бизнес-смысл — полка «Коммерческий отдел», книга «БЗ-7 Клиентская база», страница «Воронки продаж — 3 типа тендеров».

## Поле «тип тендера»

- Выбирается **радио-кнопкой при создании проекта**, обязательное. Определяет набор доступных статусов проекта.
- В данных (индекс `itech_projects`) лежит в поле **`type_of_calculation`** (keyword) — имя историческое, по смыслу это тип тендера, а не тип расчёта.
- Значения: `Прескрипция` · `Внешний тендер` · `Внутренний тендер`.
- Распределение (20 138 проектов): пусто 10 106 · Внутренний 5 693 · Внешний 4 228 · Прескрипция 111.

## Наборы статусов по типу (из инструкции «Проекты»)

**Прескрипция:** Регистрация проекта · Заявка на расчёт · Работа по стадии «П» · Работа по стадии «Р» · Работа выполнена.

**Внешний:** Регистрация проекта · Заявка на расчёт · Расчёт выполнен · Отправлено КП · Работа с возражениями · Приостановлено · (пусто = выход / отказ).

**Внутренний:** Регистрация проекта · Заявка на расчёт · Расчёт выполнен · Отправлено КП · Работа с возражениями · Согласование договора · Реализация · Закрытие сделки · Приостановлено · (пусто = отказ покупателя).

Статус в данных: `project_status` (text, есть `.keyword`) + `project_status_id` (int). Дата перехода: `status_updated_at` (text, пуст ~53%).

## Авто-переходы статуса (кто / что двигает)

- Создание **заявки на расчёт** → проект: «Регистрация проекта» → «Заявка на расчёт» (**кроме Прескрипции** — она из авто-перехода исключена).
- Расчёт получил статус **«КП выставлено»** → проект: «Расчёт выполнен» → «Отправлено КП».
- Прочие статусы менеджер ставит **вручную** в карточке проекта.
- При создании заявки на расчёт также обновляются поля проекта: предполагаемая дата реализации, вероятность реализации, вероятность %.

## Оговорки по качеству данных

- «Работа с возражениями» доступна в UI, но **не заполняется ни в одном проекте** → стадия переговоров для аналитики не захвачена.
- Перетекание статусов между типами — единицы процентов (внешний / внутренний); у Прескрипции ~половина статусов «чужие».
- `status_updated_at` пуст ~53% → длительность стадий (cycle time) посчитать нельзя без обогащения.

> Источник: инструкция Grace «Проекты» (`/reactapp/projects/projects`) + проверка на OpenSearch 89 (19–20.06.2026).

# Карта метрик продаж (дерево + покрытие)

# Карта метрик продаж ITECH (Grace)

> Дерево показателей системы управления продажами Баранова, разложенное до операционных драйверов и сшитое с **реальными полями** `itech_*`. Каждая метрика помечена покрытием — где данных нет, написано честно «нет источника», чтобы дашборд не врал.
> Ось всей модели = **продажа часов** (план меряется в нормо-часах; рубли и маржа производны). Проверено на 89, 2026-06-20.

## Как читать

Формат строки: **метрика → формула → тип → уровень → владелец → источник `itech_*` → покрытие**.

- **Тип:** `Р` результат (lagging, что меряем по факту) · `Д` драйвер (leading, на что команда влияет) · `К` коэффициент/норматив.
- **Уровень дерева:** `L0` вершина бизнес-плана · `L1` декомпозиция результата · `L2` драйвер воронки · `L3` операционный/коэффициент.
- **Владелец (этап воронки):** `ПРЕ` прескрипция · `РАС` расчёты/КП · `ПРО` продажи/коммерция · `ИСП` исполнение/производство.
- **Покрытие:** `✅ есть` (поле заполнено надёжно) · `🟡 частично` (есть, но пробелы/датировка слабая) · `❌ нет источника` (в данных не captured — драйвер известен, но не считается).

---

## L0 — вершина бизнес-плана (результаты Баранова)

| Метрика | Формула | Тип | Владелец | Источник `itech_*` | Покрытие |
|---|---|---|---|---|---|
| Годовой оборот, руб. | `Σ order_amount` по реализованным | Р | ПРО+ИСП | `orders.order_amount` | ✅ есть |
| Выработка нормо-часов (ось плана) | `Σ total_hours_fact` (план: `total_hours_plan`) | Р | ИСП | `orders.total_hours_*` | 🟡 present 100%, содержательно (часы>0) 43% = 1996 заказов-производство; Товары/Услуги=0. Σ=789 289 ч |
| Маржинальная прибыль чистая, руб. | `Σ margin_amount` | Р | ПРО+ИСП | `orders.margin_amount` | ✅ 100% (реальна с 2024) |
| Маржинальность чистая, % | `Σ margin_amount / Σ order_amount` | Р | ПРО | `orders` | ✅ есть (2024+) |
| Кол-во проектов, шт. | `count(distinct project_id)` | Р | ПРО | `projects` | ✅ есть |

---

## L1 — декомпозиция результата

| Метрика | Формула | Тип | Уров. | Владелец | Источник | Покрытие |
|---|---|---|---|---|---|---|
| ⭐ Маржа на нормо-час | `margin_amount / total_hours_fact` | Р | L1 | ИСП | `orders` | 🟡 только заказы с часами>0 (1996); у Товаров не определена (0 часов) |
| Оборот по линиям (НКУ/СН/Товары/Услуги) | `Σ order_amount` по `ТипСчёта+вольтаж` | Р | L1 | ПРО | `order_items` / линия | 🟡 классиф. линии в items |
| Средний чек | `оборот / кол-во сделок` | Р | L1 | ПРО | `orders` | ✅ есть |
| Кол-во закрытых сделок | `count(status='Закрытие сделки')` | Р | L1 | ПРО | `projects.status` | ✅ срез / 🟡 динамика |
| Структура затрат (ПерЗ/ПостЗ/Трасх) | `В − margin`; ПостЗ = часы×Сп | Р | L1 | ИСП | `orders.total_cost` | 🟡 агрегат, без разбивки |
| Маржа по объекту | `Σ margin` ⋈ `properties` | Р | L1 | ПРО | `projects.property_id`→`properties` | 🟡 объект 79% |
| Маржа по отрасли/типу объекта | `Σ margin` ⋈ `sector`/`property_type` | Р | L1 | ПРО | `properties.sector` + `property_type` | 🟡 sector 35%; property_type гранулярнее (тип здания, нужен `.keyword`) |
| Маржа по региону объекта (доставка) | `Σ margin` ⋈ регион из адреса | Р | L1 | ПРО | `properties.address_full` (парсинг) | 🟡 адрес 99.8%, регион парсится (поле `region` пусто) |
| Маржа по отрасли/региону клиента | `Σ margin` по обогащённому ИНН | Р | L1 | ПРО | ИНН-обогащение (внешн.) | ❌ Grace пусто → строим (см. ниже) |

---

## L2 — драйверы воронки (leading) по владельцам

### ПРЕ — Прескрипция (посев на стадии проектирования)

| Метрика | Формула | Тип | Источник | Покрытие |
|---|---|---|---|---|
| Кол-во регистраций (вход воронки) | `count(projects, type='Прескрипция')` по `created_at` | Д | `projects` (`type_of_calculation`) | 🟡 тип заполнен ~50% |
| Кол-во объектов в проработке | `count(distinct property_id)` в прескрипции | Д | `projects.property_id`→`properties` | 🟡 объект 79% |
| Конверсия Регистрация→Работа П→Р→Выполнено | переходы по стадиям прескрипции | Д | `projects.status` + снапшот | ❌ переходы не датированы (`status_updated_at` 53% пуст) |
| Повторные посевы на объект | объект с >1 проектом во времени | Д | граф `properties.accounts` | 🟡 (через объект) |

### РАС — Расчёты / подготовка КП

| Метрика | Формула | Тип | Источник | Покрытие |
|---|---|---|---|---|
| Кол-во подготовленных КП | `count(status='Отправлено КП')` | Д | `projects.status` | 🟡 срез есть, поток — нет |
| SLA расчёта (норматив 8ч/заявка) | `kp_exposed_at − created_at` | Д | `itech_calculations` (21065: created_at, kp_exposed_at, start/completed/due) | 🟡 индекс есть (live API заблокирован, но данные синкнуты) |
| Цикл расчёта / в срок | `completed_at − start_fact`; vs `due_date` | Д | `itech_calculations` | 🟡 индекс есть |
| Очередь расчётов / WIP | кол-во «в расчёте» на дату | Д | `itech_calculations.status` + снапшот | 🟡 через снапшот |
| Точность маржи (факт vs расчёт) | `orders.margin` − `calc.amount` по `project_id` | Д | `orders` ⋈ `itech_calculations` | 🟡 обе части есть (calc.amount синкнут) |
| Загрузка инженеров (часы факт) | `Σ time` тайм-трекинг / норму | Д | `engineer_worklog` (открыт, LEV-147) | 🟡 источник открыт, не в витрине |

### ПРО — Продажи / коммерция

| Метрика | Формула | Тип | Источник | Покрытие |
|---|---|---|---|---|
| Кол-во отправленных КП | `count(status='Отправлено КП')` | Д | `projects.status` | 🟡 срез / поток нужен снапшот |
| Win-rate (внешний тендер) | `закрыто / (закрыто+проиграно)` по терминалам | Д | `projects.status` + `type` | 🟡 терминалы есть, датировка слабая |
| Win-rate (внутренний тендер) | то же по внутр. воронке | Д | `projects.status` + `type` | 🟡 то же |
| Конверсия КП→Согласование→Закрытие | переходы стадий | Д | `projects.status` + снапшот | ❌ переходы не датированы |
| Цикл сделки (дни) | `cycle_time_days` | Д | `orders.cycle_time_days` | 🟡 есть в заказах |
| Активность / событийный поток по сделке | `count(comments)` по автору/сущности/периоду; дней с последнего касания | Д | `itech_comments` (120k: автор+дата+текст) | 🟡 derived (`reminders` пуст, но comments живые и растут) |
| Соблюдение маржинальности (анти-демпинг) | цена↑ при рентабельности↓ | Д | `orders` + `order_items` | 🟡 считается из факта |

### ИСП — Исполнение / производство

| Метрика | Формула | Тип | Источник | Покрытие |
|---|---|---|---|---|
| Выполнение плана по часам | `total_hours_fact / total_hours_plan` | Р/Д | `orders.total_hours_*` | 🟡 план 62% / факт 43% |
| Маржа факт (по реализации) | `margin_amount` на отгрузке | Р | `orders.margin_amount`, `shipping_date_fact` | ✅ 100% |
| Цикл производства | `cycle_time_days` / `status_production_id` | Д | `orders` | 🟡 есть |
| Часы по линиям (НКУ/СН/Товары/Услуги) | `Σ hours` по линии | Д | `order_items` + норматив часов | 🟡 норматив артикулов |

---

## Клиентская база и приток (⚠️ карточки ≠ клиенты)

Проверено на 89: всего карточек контрагентов **7643**, из них покупателей (`order_count`>0) — **751 (10%)**, лидов без заказов — **6892 (90%)**; активных (`last_order_at` ≥ 2025) — **290**. Дата создания карточки **не годится** как приток: 2020 = 3203 карточки (дамп миграции, не привлечение) + 90% карточек мёртвые.

| Метрика | Формула | Тип | Уров. | Владелец | Источник | Покрытие |
|---|---|---|---|---|---|---|
| ⭐ Приток новых покупателей / период | контрагент с **первым** заказом в периоде = `min(orders.created_at)` по `account_id` | Д | L1 | ПРО | `orders.account_id`+`created_at` (витрина) | 🟡 считается в витрине (НЕ `accounts.created_at`) |
| Активная клиентская база | `count(accounts, last_order_at ≥ окно)` | Р | L1 | ПРО | `accounts.last_order_at`, `order_count` | ✅ (290 с 2025) |
| Конверсия лид→покупатель | `покупатели / всего карточек` | Д | L2 | ПРО | `accounts.order_count` | ✅ (751/7643 ≈ 10%) |
| Отток / спящие | был заказ, но `last_order_at` вне окна | Д | L2 | ПРО | `accounts.last_order_at` | ✅ |
| Концентрация выручки на клиенте | доля топ-клиента; ≥15% = зависимость | Д | L2 | ПРО | `accounts.revenue_mln` | ✅ |
| ❌ «Новые карточки / период» | `count(accounts) by created_at` | — | — | — | `accounts.created_at` | ❌ не использовать как приток (дамп 2020 + 90% без заказов) |

## Портрет покупателя + обогащение по ИНН

Проверено на 89 (покупатели, 751): у клиентов `sectors` (отрасль) и `region` **ПУСТЫ**, но `inn` есть у **100%**. → отрасль и регион **клиента** **не из Grace**, а **обогащением по ИНН** из внешнего реестра (Dadata/ЕГРЮЛ/ФНС-открытые/Контур.Фокус). Это параллельный трек ELT-«дообогащения» (живёт в слое нормализации ArangoDB на 147), не блокирует витрину.

Две разные оси — не путать: **объект** (`properties`: `sector`/`property_type` building-derived + регион из `address_full`, ~100% адресов) = «куда/во что продаём»; **клиент** (ОКВЭД/регион по ИНН) = «кому продаём». Сектор Grace проставляет по зданию (`property_type` → `sector`).

| Признак портрета | Источник | Покрытие |
|---|---|---|
| Роль контрагента (Покупатель/Поставщик/Субподряд/Проектировщик) | `accounts.account_types` | ✅ (роли пересекаются) |
| Надёжность | `accounts.reliability` | 🟡 ~30% (227/751) |
| Выручка / оплачено / долг | `accounts.revenue_mln`/`paid_mln`/`debt_mln` | ✅ |
| Заказы/проекты, последний заказ | `accounts.order_count`/`project_count`/`last_order_at` | ✅ |
| Только предоплата | `accounts.is_prepayment_only` | ✅ |
| ⭐ Отрасль клиента (ОКВЭД) | ❌ Grace пусто → **ИНН-обогащение** | строим |
| ⭐ Регион/город клиента | ❌ Grace пусто (`region` пуст) → **ИНН-обогащение** | строим |
| Размер (МСП/крупный), статус (действ./ликвид.), дата регистрации | **ИНН-обогащение** | строим |
| Отрасль/тип объекта (куда продаём) | `properties.sector` + `property_type` (building-derived) | 🟡 sector 35%; тип здания гранулярнее |
| Регион/город объекта (доставка) | `properties.address_full` (парсинг) | 🟡 адрес 99.8%; регион парсится |

Портрет = (роль + надёжность + платёжная дисциплина из Grace) × (отрасль + регион + размер из ИНН) × (отрасль объекта). Под сегментацию, таргетинг допродаж и оценку нового лида ещё до сделки.

## Слой комментариев (`itech_comments`, 120k) — качественный + активность

Отдельный индекс, **полиморфный** (`commentable_type` + `commentable_id`); у каждого комментария: `comment` (текст, ru-анализатор), `author_name`, `created_at`, денормализованы `project_id`/`project_status`/`account_id`/`calculation_id`. Растёт: 2023=16k → 2024=36k → 2025=53k (живой, в отличие от пустого `reminders`).

Привязка (топ): SupplyRequest 22k · PaymentRequest 15k · Delivery 11k · Contract 7.5k · ContractAnnex 6.4k · **Project 6407** · ComponentDefect 6.2k · Problem 5.8k · **Calculation 4347** · Account 2446 · Order 2259 · Task 2112; **объекты:** Property 107 + ObjectRegistration 264.

| Что даёт | Как | Тип | Покрытие |
|---|---|---|---|
| Активность/застой сделки | объём комментов + дней с последнего касания по проекту/расчёту | Д | 🟡 derived (заменяет пустой `reminders`) |
| Нарратив воронки (возражения/блокеры/причины) | NLP по Project+Calculation коммент. + `projects.refusal_reason` | Д | 🟡 derived (NLP) |
| Качество/рекламации | коммент. ComponentDefect/Problem/Reclamation | Д | 🟡 derived |
| История сделки для агентов | RAG/граф по коммент. (Onyx) | — | вход для агентов |

⚠️ `commentable_type` именуется непоследовательно (`Property` vs `Modules\Projects\Entities\Project`) → нормализация типа (трек Arango). Комментарии **не агрегируются как метрики напрямую** — это производный слой: витрина берёт счётчики/скорость/NLP-метки, граф — события таймлайна, Onyx — RAG.

## Модель «объект → проект» (корень и счётчики притока)

Порядок ввода в Grace: **сначала объект (`property`), потом проект** (цепляется через `property_id`), далее расчёт → заказ. Объект — **корень** модели и центральное измерение витрины/графа. `itech_object_registrations` (445) — мост регистрации.

Отсюда **три раздельных счётчика притока** (не путать): **новые объекты** (`properties.created_at`) · **новые проекты** (`projects.created_year`) · **новые покупатели** (первый заказ, `min(orders.created_at)` по `account_id`).

## Финансовый слой / ДДС (`itech_expected_payments`, 7896 — из 1С)

Платёжный календарь и факт поступлений, грузится в Grace **из 1С** → бухгалтерский факт, не CRM-оценка. Поля: `exp_payment_status` (план/**факт**), `type` (Предоплата/После отгрузки/…), `pay_amount` (план) / `paid_amount` (факт), `pay_date` / `paid_date`, привязка `order_id`/`project_id` (88%)/`account_id`/`manager_id`. Факт = 7776 (Σ оплачено 12,19 млрд, реализация плана 99,2%); даты 2020→2027.

| Метрика | Формула | Тип | Владелец | Источник | Покрытие |
|---|---|---|---|---|---|
| Поступления (ДДС-факт) | `Σ paid_amount` по `paid_date` | Р | ИСП/фин | `expected_payments` (status=факт) | ✅ 7776 |
| Дисциплина оплат (в срок) | `paid_date − pay_date`; доля просрочки | Д | ПРО/фин | `expected_payments` | ✅ |
| Предоплата vs постоплата (оборот. капитал) | доля `type=Предоплата` vs «После отгрузки» | Д | ПРО | `expected_payments.type` | ✅ |
| Дебиторка / ожидаемые поступления | `Σ pay_amount` где не оплачено | Р | фин | `expected_payments` (status=план) + `accounts.debt_mln` | 🟡 план тонкий (120) |
| Форвард платёжный календарь | `Σ pay_amount` по будущим `pay_date` | Д | фин | `expected_payments` | 🟡 будущих лишь 36 (план почти не ведётся) |
| Мост маржа→кэш | `paid_amount` ⋈ `orders.margin_amount` по order_id | Р | фин | `expected_payments`⋈`orders` | ✅ связь есть |

Закрывает «cashFlowAnalysis» из Grace UI на уровне витрины + даёт то, чего нет в `orders`: реальные поступления и дисциплину оплат.

## L3 — коэффициенты и нормативы (из Положения о премии / методики)

| Показатель | Формула | Тип | Владелец | Источник | Покрытие |
|---|---|---|---|---|---|
| Кк — качество данных | доля корректно заполненных полей | К | все | `itech_quality_managers` (есть, Кк≈69.7%) | ✅ есть |
| Ку — коэф. участия по стадии | норматив по стадии воронки | К | ПРО | Положение о премии §2.x | ✅ норматив (не из данных) |
| Сп — ставка нормо-часа (3250/3660/4170) | норматив грейда | К | ИСП | Положение о премии §2.2 | ✅ норматив |
| Утилизация инженеров | `часы факт / доступный фонд` | К | ИСП | `engineer_worklog` + штат | 🟡 фонд не в витрине |
| Премия П | `[Σ((Пр×Ку) − КРр)] × Кк` | К | ПРО | производная всех выше | 🟡 собирается из частей |

---

## Сводка покрытия (что сразу, что закрыть)

**Считаем сегодня (✅/🟡):** оборот, маржа (сумма и %), маржа/час, средний чек, кол-во сделок, win-rate (как срез), цикл сделки, выполнение плана по часам, срезы по объекту/региону/линии, Кк. → **этого достаточно для дашборда «план/факт по часам + рентабельность» v1.**

**Дыры → не выдумывать, закрыть инструментом (❌):**
1. **Поток воронки (конверсии, скорость стадий)** — `status_updated_at` пуст 53%, переходы не датированы → **лечится датированным снапшотом в ETL** (см. LEV-171 шаг 3). Частично восстановимо из `itech_comments` (датированные события активности по сделке).
2. ~~SLA расчёта / WIP / точность маржи~~ → **ЗАКРЫТО индексом** `itech_calculations` (21065: `created_at`/`kp_exposed_at`/`completed_at`/`due_date`/`amount`). Live API заблокирован (LEV-147), но данные синкнуты → SLA, цикл, WIP (через снапшот), точность маржи считаются.
3. **Активность менеджера** — `itech_reminders` пуст, **НО** `itech_comments` (120k, автор+дата) даёт активность-прокси и «застой сделки» → дыра закрывается комментариями (derived), не пустым reminders.

**Принцип карты:** дашборд показывает только метрики с покрытием ✅/🟡; ❌-метрики выводятся как «требует данных X» — белые пятна видны, не маскируются нулём.

---

Refs: LEV-171 (витрина часов), LEV-169 (3 воронки), LEV-147 (часы/calc API), Положение о премии (BookStack, полка HR), Бизнес-план `itech_1/docs/input/Бизнес план с формулами.xlsx`, Стрелкова `docs/Strelkova/generatory_pribyli.md`.

# Линзы рентабельности (метод анализа продаж)

# Линзы рентабельности — метод анализа продаж

> Набор аналитических «линз», которые превращают цифры витрины в управленческие решения. Метод адаптирован под данные ITECH (поля `itech_*`) по идеям книги З. Стрелковой «Генераторы прибыли» (источник-референс; полный текст — у нас в разборе, не в KB). Здесь — только применимое под наши разрезы и поля.

## Главная адаптация под «продажу часов»

Книга про «отдачу на ресурс». Наш главный ресурс — **часы**. Отсюда сшивающая метрика:

> ⭐ **Маржа на нормо-час** = `margin_amount / total_hours_fact` — по линии / менеджеру / клиенту / типу тендера.

Прямой ответ на логику Баранова: не «сколько часов продали», а **сколько прибыли приносит час** в каждом разрезе. Сразу видно, какая линия/менеджер «жжёт» дорогой производственный час впустую.

## Откуда берутся цифры (три слоя, не дублируем)

| Класс вопроса | Слой | Примеры |
|---|---|---|
| «Что было» — дескриптив | **Grace native** (уже есть) | cashFlow, account-агрегаты `totalTime`/`costTimeRatio`, отчёты воронки |
| «Сколько / доля / рейтинг по разрезу» — диагностика | **Витрина** (DuckDB→OpenSearch+Dashboards) | бóльшая часть линз ниже |
| «Кто с чем связан / обход / путь» — связи | **Граф (ArangoDB)** | объект-хаб, повторные продажи, клиент×продукт-дырки, цепочки вендоров |

Глубина аналитики (лесенка): **Grace = что было → линзы = почему → снапшоты + reverse-funnel = прогноз → агенты = что делать**.

## Линзы (считаются прямо из витрины)

### По линиям (НКУ / СН / Товары / Услуги)
- **Матрица «доля в выручке × рентабельность»** — найти **АГП** (большая доля, низкая рентабельность → системно резать себестоимость) и **ПГП** (высокая рентабельность, малая доля → растить).
- **«Расчёска»: доля в выручке vs доля в марже** — недооценённые генераторы прибыли.
- **Маржа на нормо-час по линии** (см. выше).

### По клиентам
- **Топ-N + концентрация:** клиент с долей ≥15% выручки = флаг зависимости.
- **Выручка vs рентабельность:** в топе по выручке, но вне топа по марже → разобрать.
- **Клиент × Продукт (дырки):** кто берёт НКУ, но не берёт Услуги/Сервис → резерв допродаж (бьётся с маркетинговой политикой «сервис — приоритет» и «привлечённым клиентом» из премии). *(связевой вопрос — лучше через граф.)*

### По менеджерам
- **Структура выручки + концентрация** — зависимость от 1–2 продавцов (флаг: собственник = главный продавец).
- **Бенчмаркинг — отклонение от среднего** по марже/час и `cycle_time` на сопоставимых условиях: эталон vs аутсайдер.

### Динамика (сигналы)
- **Парадоксальные отрывы от среднего:** резкий рост рентабельности у одного → тиражируемая практика; провал → риск.
- **Детектор демпинга:** цена↑ при рентабельности↓ или рост выручки только за счёт снижения цены (прямо про KPI «соблюдение маржинальности» из профиля менеджера).

### Ассортимент
- **ABC / Парето по SKU** (`order_items`) + концентрация топ-N.

## Чего честно НЕ потянем (нет данных)

Бренды; «этап-2» рентабельность (расходы по клиенту/каналу); оборачиваемость склада; сравнение со структурой рынка.

**Доступно через обогащение/объект (не из карточки напрямую):** отрасль и регион **клиента** — `region`/`sectors` в Grace пусты → берём **обогащением по ИНН** (ИНН у 100% покупателей). Отрасль **объекта** — `properties.sector` (~35%).

---

Refs: «Карта метрик продаж» (книга GRACE) · LEV-171 (витрина часов) · полный разбор книги — `docs/Strelkova/generatory_pribyli.md` (репозиторий, внутренний).