История продаж, которую можно анализировать
Данные касс перенесены в аналитическое хранилище с повторяемой загрузкой, сверкой метрик и разбором по клиентам.
Сделал: Миграция, модель витрин, контроль качества данных
ВопросОткуда берётся цифра в отчёте и где её проверяют?
Цифра проходит 4 проверки на пути от 4 источников до 3 отчётов
Выручка, загрузка, удержание, RFM и магазин сведены в повторяемый аналитический слой Book&Track.
Источники
- Evotor Cloud API
- Evotor Webhook
- Gizmo / CRM DB
- club operational DB
Загрузка и правила
- batch ELT
- webhook ETL
- mapping
- validation / dedup
Хранение и модель
- ClickHouse raw
- ClickHouse facts
- ClickHouse marts/views
- quality logs
Отчёты и решения
- Book&Track Analytics UI
- Revenue / Retention / RFM
- Host Load / Inventory / Predictive
Контрольные точки
- Row count validation после загрузки.
- Checksum validation для критичных полей.
- Benchmark query suite для оценки производительности.
- Hardware sizing report до роста объёма.
В заявку попадёт тема История продаж, которую можно анализировать: откуда берётся цифра и где её проверяют
.
Ситуация
С чего всё начиналось
Проект поддерживает аналитику компьютерных клубов: выручка, клиенты, удержание, RFM, маркетинг, нагрузка PC/PS, магазин, остатки и прогноз.
Данные по выручке, клиентам, игровому времени, удержанию, RFM, магазину и загрузке PC/PS были разнесены между кассой, CRM/Gizmo и клубными базами.
Что изменено
Что я сделал
Разложил контур на C4-уровни, источники, data planes, lineage, runtime и контрольные проверки; связал загрузку, витрины и UI-решения.
- Контур разделен на real-time/operational plane для текущего состояния клуба и historical/aggregated plane для тяжелой аналитики.
- Evotor webhook не смешивается с ночной batch-загрузкой: оперативные документы проходят свой ETL-flow и incremental refresh.
- Контрольные проверки отделяют raw-факт от управленческой витрины: mapping, актуальность данных, dedup, reconciliation, normalization и final validation.
Что получилось
Результат
Выручка, загрузка, удержание, RFM и магазин сведены в повторяемый аналитический слой Book&Track
- Аналитика Book&Track получила читаемую архитектуру: sources → ClickHouse analytics layer → API → UI → decisions.
- Ошибки качества обнаруживаются до публикации витрин, а не после просмотра экрана пользователем.
- Руководитель видит готовые срезы по выручке, клиентам, удержанию, RFM, нагрузке, магазину и прогнозу.
Как это проверено
Проверка и границы
- Row count validation после загрузки.
- Checksum validation для критичных полей.
- Benchmark query suite для оценки производительности.
- Hardware sizing report до роста объёма.
публичная история раскрыта как архитектурный паттерн без закрытых данных. показан контур миграции, а не коммерческий результат бизнеса.
Техническое приложение
Как устроено внутри
Для тех, кто проверяет решение по существу: источники, слои данных, правила расчёта и артефакты передачи.
Архитектура, данные и методология
Архитектура
| Источники | Evotor Cloud API · Evotor Webhook · Gizmo / CRM DB · club operational DB |
|---|---|
| Загрузка | batch ELT · webhook ETL · mapping · validation / dedup |
| Хранение | ClickHouse raw · ClickHouse facts · ClickHouse marts/views · quality logs |
| Представление | Book&Track Analytics UI · Revenue / Retention / RFM · Host Load / Inventory / Predictive |
Модель данных
| Объект | Слой | Назначение |
|---|---|---|
| evotor_* / crm_* / gizmo_* | raw | сырые события кассы, CRM и клубных систем |
| evotor_sales_fct / crm_payments_fct / gizmo_user_sessions_fct | fact | нормализованные факты для управленческой аналитики |
| mart_revenue_daily / mart_host_load_daily / mart_user_retention | mart | витрины для экранов Book&Track Analytics |
Методология и правила
- Переупаковал миграционный контур в Architecture Explorer: L0 бизнес-контекст, L1 C4 Context, L2 data planes, L3 components, L4 lineage, L5 runtime, L6 контрольные проверки.
- Связал каждый экран решения с backend/service layer и источником данных, чтобы архитектура читалась как продуктовый analytics layer.
- Развел raw, facts, marts/views и service normalization, чтобы UI не получал невозможные или технически сырые значения.
- Data lineage показывает цепочки Evotor sales, CRM payments и Gizmo sessions от raw tables до конкретных экранов аналитики.
- ClickHouse semantic layer разделяет facts, marts, views и dimensions вместо прямого чтения сырых таблиц в интерфейсе.
- Service-layer normalization защищает UI от невозможных значений, например host load выше 100%.
Артефакты и стек
C4 Architecture · Data Lineage · Quality Gates · Runbook
Что бы сделал иначе
- Discovery и DDL generation снижают ручные ошибки миграции.
- Validation должна быть частью pipeline, а не отдельной ручной задачей.
- Sizing полезен до продового роста нагрузки.
Похожая задача?
Расскажите, где у вас расходятся цифры или не хватает картины. Отвечу, чем это лечится и с чего начать.