Перейти к основному содержимому

Аналитика и бизнес-аналитика

Версия: 1.0 Дата: 26.04.2026 Статус: Готов к обсуждению

Назначение документа​

Документ определяет аналитический и бизнес-аналитический слой (analytics and business intelligence, BI) Vitiana — витринный слой поверх хранилища данных (data warehouse, DWH) платформы. Включает:

  • Каноничную модель витрин (AnalyticalDataset, Dashboard, AnalyticsExport, DataMart, AnalyticsAlert).
  • Разделение на внутреннюю аналитику платформы и партнёрский продукт аналитики (partner-facing analytics product) — два разных продукта с разной семантикой и разными правилами.
  • Базовые тематические витрины (data marts) — потребление партнёров, конверсия путей бронирования, здоровье поставщиков, экономика тенантов, инциденты, медиа, переводы.
  • Каналы доставки аналитики — дашборды, программный интерфейс аналитики (analytics API), экспорт данных.
  • Соглашение об уровне обслуживания на свежесть данных по классам.
  • Защиту приватности при аналитике: k-анонимизацию, агрегационные правила.
  • Интеграцию с платформой машинного обучения (insights generation, anomaly detection в аналитике).
  • Связь с тарифами (доступность аналитического продукта по уровням).
  • Фазы развёртывания.

Документ читается после:

В корневых документах зафиксировано что платформа предоставляет в виде аналитики и кому. Этот документ описывает как — каноничные витрины, способы доставки, фазы.

Аналитика — продукт второго уровня платформы. Внутренняя аналитика обслуживает решения команды платформы (продукт, инжиниринг, finance, поддержка). Партнёрский продукт аналитики — это дополнительная коммерческая ценность для тарифа Professional и выше.

Реальное состояние реализации (home-to-go-api): уже работают базовые операционные метрики через Grafana, но самостоятельного аналитического слоя нет. Это нормально для фазы Bootstrap; этот документ описывает целевое состояние.

Правило 00000 (платформа главенствует над поставщиками) применяется здесь напрямую: каноничная аналитика ставится над платформой целиком, не над данными отдельных поставщиков. Партнёр не получает «аналитику Stuba» — он получает единую аналитику Vitiana, унифицирующую данные всех поставщиков.

Главное решение​

Аналитика — продуктовый слой со своей каноничной моделью, своим жизненным циклом и своей коммерческой моделью, не «отчёты по запросу».

Это означает:

  • Витрины (data marts) — каноничные сущности с явными определениями метрик, измерений, правил агрегации.
  • Дашборды — версионируемые продукты — каждый дашборд имеет владельца, схему, политику обновления.
  • Свежесть данных — соглашение, не «как получится» — каждая витрина имеет SLA по свежести.
  • Партнёрский продукт аналитики — отдельный продукт с собственными метриками, собственными ограничениями (k-анонимизация для кросс-тенантных сравнений), собственным программным интерфейсом.
  • Защита приватности — встроена — кросс-тенантные агрегаты только с минимальным числом тенантов в выборке (k_min_tenants).
  • Один язык метрик через каноничные определения — никакой команды «считаем конверсию по-своему».
  • Интеграция с ML — ML-приложения работают над аналитическим слоем (anomaly detection в метриках, автоматические insights).

Каноничная модель аналитики​

Главные сущности​

AnalyticalDataset — аналитический набор данных​

Сущность, представляющая именованную витрину (data mart) поверх gold layer DWH.

{
  dataset_id: UUID,
  dataset_key: string,
  dataset_namespace: string,
  dataset_class: enum,
  source_tables: array,
  refresh_class: enum,
  schema_version: string,
  privacy_class: enum,
  cross_tenant_aggregation_rules: object,
  retention_class: string,
  documentation: string,
  owners: array,
  is_active: boolean,
  created_at: timestamp,
  updated_at: timestamp
}

Поля:

  • dataset_class — класс (partner_usage / booking_funnel / supplier_health / tenant_economics / incident_analytics / media_quality / translation_coverage / experiment_results / platform_health).
  • refresh_class — класс свежести (real_time / near_real_time / hourly / daily / weekly).
  • privacy_class — класс приватности (наследуется из Платформа данных и захват событий).
  • cross_tenant_aggregation_rules — правила межтенантной агрегации, включающие k_min_tenants и k_min_events.

Dashboard — дашборд​

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

{
  dashboard_id: UUID,
  dashboard_key: string,
  dashboard_namespace: string,
  audience: enum,
  applicable_surfaces: array,
  applicable_tenant_tiers: array,
  panels: array,
  filters: array,
  refresh_class: enum,
  schema_version: string,
  privacy_class: enum,
  is_active: boolean,
  owners: array,
  created_at: timestamp,
  updated_at: timestamp
}

Поля:

  • audience — для кого предназначен (platform_internal — внутренние команды; partner_facing — партнёры; agency_facing — агентства; public — публичная страница статуса).
  • applicable_tenant_tiers — для каких тарифных уровней доступен (например, [professional, enterprise]).
  • panels — массив панелей дашборда (графики, таблицы, числа), каждая ссылается на AnalyticalDataset.
  • filters — допустимые фильтры (например, период, тенант, поверхность).

AnalyticsExport — экспорт аналитических данных​

Сущность, представляющая запрос на экспорт сырых аналитических данных.

{
  export_id: UUID,
  requested_by_tenant_id: UUID,
  requested_by_user_id: UUID,
  dataset_id: UUID,
  filter_parameters: object,
  format: enum,
  destination: enum,
  state: enum,
  privacy_review_state: enum,
  approved_by: string,
  generated_at: timestamp,
  expires_at: timestamp,
  size_bytes: integer
}

Поля:

  • format — формат файла (csv / parquet / json).
  • destination — куда (signed_url — подписанная ссылка для скачивания; partner_s3_share — в S3-bucket партнёра; sftp — SFTP-путь партнёра).
  • privacy_review_state — состояние ревью приватности (для крупных экспортов — обязательное ревью).
  • approved_by — кто одобрил (для тарифов ниже Enterprise — автоматическое одобрение для определённых классов; для крупных — ручное).

DataMart — тематическая витрина​

Логическое объединение AnalyticalDataset для конкретной темы. Это не отдельная сущность в БД, а именованная коллекция с общими правилами доступа и обновления.

Пример: partner_usage_mart объединяет dataset_partner_quotas, dataset_partner_request_volume, dataset_partner_complexity_distribution, dataset_partner_billing_summary.

AnalyticsAlert — алерт по аналитике​

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

{
  alert_id: UUID,
  alert_key: string,
  audience: enum,
  metric_definition: object,
  threshold: object,
  evaluation_window: object,
  notification_channels: array,
  state: enum,
  is_active: boolean
}

Каноничные применения:

  • Партнёр приближается к лимиту тарифа.
  • Resource-пик в потреблении.
  • Аномальное поведение в воронке бронирований.
  • Деградация конверсии после релиза.
  • Аномальная нагрузка от поставщика.

Связь с другими каноничными сущностями​

Два разных продукта аналитики​

Внутренняя аналитика платформы (platform internal analytics)​

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

Аудитория: внутренние сотрудники по ролям.

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

Содержимое:

  • Полная картина платформы — потребление всех тенантов, экономика всех поставщиков, инциденты, релизы.
  • Кросс-тенантные индивидуальные данные доступны команде платформы (с журналом аудита).
  • Прогнозы и моделирование (через ML).
  • Расследование инцидентов с углублённой детализацией.

Тарификация: не имеет смысла — это собственный инструмент платформы.

Партнёрский продукт аналитики (partner-facing analytics product)​

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

Аудитория: тенанты тарифов Starter / Professional / Enterprise (разный объём по тарифу).

Доступ: через партнёрскую консоль (см. Программный интерфейс как продукт) и через программный интерфейс аналитики.

Содержимое:

  • Только свои данные тенанта — никаких индивидуальных данных других тенантов.
  • Кросс-тенантные агрегаты с k-анонимностью — для бенчмаркинга позиции тенанта на платформе.
  • Прогнозы потребления для прогноза счёта.
  • Выгрузки данных (только Enterprise).

Тарификация: часть тарифного уровня, не отдельная подписка. Расширение функциональности по тарифам:

АтрибутFreeStarterProfessionalEnterprise
Базовые метрики потребления❌✅✅✅
Воронка бронирования❌БазоваяПолнаяПолная + кастом
Кросс-тенантный бенчмаркинг❌❌✅ (k-анонимизация)✅
Программный интерфейс аналитики❌❌✅✅
Экспорт сырых данных❌❌❌✅
Кастомные витрины❌❌❌✅ (по запросу)
АлертыБазовыеСтандартныеРасширенныеКастомные

Запрет на смешение продуктов​

Запрещено возвращать партнёру индивидуальные данные другого тенанта или внутренние данные платформы. Это:

  • Архитектурно блокировано — партнёрский программный интерфейс работает только с partner-facing dataset, не с internal.
  • Журналируется через audit log.
  • Регулярно проверяется ревью.

Базовые тематические витрины​

Витрина 1. Партнёрское потребление (partner_usage_mart)​

Назначение: ответить на вопросы партнёра «сколько я использую» и команды платформы «как партнёры используют».

Содержимое:

  • Объём вызовов программного интерфейса по типам (поиск, коммерческая фиксация, бронирование, и т.д.) с разбивкой по дням / часам.
  • Сложность запросов (complexity_score) — распределение и тренды.
  • Профиль нагрузки на поставщиков — какие поставщики наиболее часто запрашиваются.
  • Доля успешных и неудачных вызовов с разбивкой по причинам.
  • Прогноз счёта на текущий период.
  • Соответствие лимитам тарифа.

Свежесть: real-time (для текущего потребления) + дневная (для трендов).

Аудитория: партнёр (свои данные) + команда платформы (все).

Витрина 2. Воронка бронирования (booking_funnel_mart)​

Назначение: проанализировать путь от поиска до подтверждённого бронирования.

Содержимое:

  • Распределение исходов поисков (количество результатов, доля отказов).
  • Конверсия поиск → коммерческая фиксация.
  • Конверсия коммерческая фиксация → бронирование.
  • Конверсия бронирование → подтверждение поставщика.
  • Конверсия подтверждение → исполнение (без отмены).
  • Воронка с разбивкой по поверхности, региону, языку, тарифу.

Свежесть: часовая.

Аудитория: партнёр (своя воронка) + команда платформы (все).

Витрина 3. Здоровье поставщиков (supplier_health_mart)​

Назначение: мониторить операционное состояние поставщиков и выявлять деградации.

Содержимое:

  • Задержки ответа поставщика (p50, p95, p99).
  • Доля успешных вызовов.
  • Свежесть данных от поставщика.
  • Доля коммерческих фиксаций, у которых поставщик не подтвердил бронирование.
  • Тренды по дням/неделям.

Свежесть: real-time для алертов + дневная для трендов.

Аудитория: только команда платформы (поставщики не видят друг друга).

Витрина 4. Экономика тенантов (tenant_economics_mart)​

Назначение: понять unit-economics платформы — сколько каждый тенант приносит и сколько стоит.

Содержимое:

  • Доходы платформы по тенантам.
  • Расходы платформы по тенантам (стоимость инфраструктуры, тарифные расходы).
  • Маржа на тенанта.
  • Жизненный цикл тенанта (LTV — lifetime value).
  • Распределение по тарифам.

Свежесть: дневная.

Аудитория: только команда платформы (finance, leadership).

Витрина 5. Инциденты (incident_analytics_mart)​

Назначение: ретроспектива инцидентов, выявление паттернов.

Содержимое:

  • Все зарегистрированные инциденты с временными метками и затронутыми компонентами.
  • Среднее время обнаружения (MTTD), среднее время восстановления (MTTR).
  • Распределение по причинам, по компонентам, по тяжести.
  • Тренды по периодам.

Свежесть: часовая.

Аудитория: команда платформы (инжиниринг, поддержка).

Витрина 6. Качество медиа и контента (media_content_quality_mart)​

Назначение: мониторить качество поступающего контента.

Содержимое:

  • Распределение quality_score медиа по поставщикам.
  • Доля медиа, прошедших и не прошедших автомодерацию.
  • Покрытие переводов по языкам.
  • Доля устаревших переводов.
  • Время обработки медиа от поступления до активации.

Свежесть: дневная.

Аудитория: команда контента + команда платформы.

Витрина 7. Кросс-тенантный бенчмаркинг (cross_tenant_benchmarking_mart)​

Назначение: дать партнёру сравнение его метрик с платформенным бенчмарком.

Содержимое:

  • Конверсия партнёра vs платформенная медиана (с k-анонимизацией).
  • Распределение использования возможностей платформы.
  • Профиль регионов, в которых работает партнёр.
  • Распределение тарифов среди сравнимых партнёров.

Свежесть: еженедельная.

Аудитория: партнёр (только агрегаты по платформе, без индивидуальных данных других) + команда платформы.

k-анонимизация: обязательна. Если в выборке для агрегата меньше k_min_tenants (типично 5) — агрегат не возвращается, отображается «недостаточно данных».

Витрина 8. Результаты экспериментов (experiment_results_mart)​

Назначение: анализ A/B-экспериментов.

Содержимое:

  • Результаты всех активных и завершённых экспериментов.
  • Метрики (главная, вторичные, защитные) по вариантам.
  • Расчёт значимости с учётом sequential testing.
  • Историческая база решений по экспериментам.

Свежесть: real-time для активных + долгосрочное хранение для исторических.

Аудитория: команды-владельцы экспериментов + leadership.

Витрина 9. Здоровье платформы (platform_health_mart)​

Назначение: общая операционная картина для эксплуатации.

Содержимое:

  • Метрики доступности по сервисам.
  • Задержки запросов (p50/p95/p99).
  • Состояние очередей (eventing).
  • Состояние внешних интеграций (поставщики, провайдеры платежей).
  • Использование ресурсов (CPU, память, диск).

Свежесть: real-time.

Аудитория: команда платформы + публичная страница статуса (с упрощением).

Каналы доставки аналитики​

Канал 1. Дашборды​

Веб-интерфейс с интерактивными визуализациями.

Внутренние дашборды​

  • Технологический выбор: Grafana для операционных, Apache Superset / Metabase для бизнес-аналитики (открытая развилка).
  • Доступ: через единое корпоративное единое окно входа (single sign-on, SSO).
  • Авторизация: по ролям (engineering / product / finance / support / leadership).

Партнёрские дашборды​

  • Технологический выбор: встроены в партнёрскую консоль (см. Программный интерфейс как продукт) на основе общей библиотеки компонентов визуализации.
  • Доступ: через партнёрскую авторизацию.
  • Изоляция: строгая по тенанту.

Канал 2. Программный интерфейс аналитики (analytics API)​

Машинно-читаемый доступ к аналитическим данным.

Применение:

  • Партнёр интегрирует аналитику в свою собственную систему (типично корпоративный тенант).
  • Платформенные сервисы запрашивают агрегаты для собственной логики (например, сервис тарификации запрашивает текущее потребление).

Структура:

  • REST-эндпоинты с аутентификацией через программные ключи доступа (analytics-scope).
  • AsyncAPI для real-time подписок на алерты.
  • Спецификации (OpenAPI + AsyncAPI) опубликованы в портале разработчиков.

Тарификация:

Канал 3. Экспорт сырых данных​

Выгрузка набора строк аналитической витрины в файл.

Применение:

  • Корпоративные партнёры (Enterprise tier) с собственным data warehouse, желающие интегрировать платформенные данные.
  • Внутренние команды для расследований.

Форматы:

  • CSV (для базового использования).
  • Parquet (для крупных объёмов и интеграции с современными аналитическими инструментами).
  • JSON (для интеграции с программными системами).

Доставка:

  • Подписанная ссылка для скачивания (короткий срок действия).
  • В S3-bucket партнёра (для регулярных выгрузок).
  • Через SFTP (для legacy-партнёров).

Ревью приватности:

  • Для экспортов выше определённого объёма — обязательное ревью командой compliance.
  • Журнал всех экспортов с возможностью аудита регулятором.

Канал 4. Алерты​

Push-уведомления при достижении порогов метрик.

Применение:

  • Партнёрские (приближение к лимиту, аномалии в воронке).
  • Внутренние (инциденты, деградация показателей).

Каналы доставки:

Канал 5. Публичная страница статуса (status page)​

Публичный канал об операционном состоянии платформы (без чувствительных данных).

Содержимое:

  • Текущее состояние компонентов.
  • Текущие инциденты.
  • Историческая статистика доступности.
  • Запланированное обслуживание.

См. Наблюдаемость и реагирование на инциденты.

Соглашение об уровне обслуживания на свежесть​

Класс свежестиОписаниеПрименениеРеализация
real_timeЗадержка десятки секундАлерты, потребление в текущий моментStreaming-обработка
near_real_timeЗадержка минутыДашборды активного эксперимента, нагрузкаStreaming с микро-партициями
hourlyЗадержка часыВоронка бронирования, трендыЧасовая batch-обработка
dailyЗадержка деньТренды по дням, экономикаДневная batch-обработка
weeklyЗадержка неделяДолгосрочные тренды, кросс-тенантный бенчмаркингЕженедельная batch

Каждая витрина имеет явный класс свежести в AnalyticalDataset.refresh_class. Партнёру в дашборде показывается метка свежести данных.

Каноничные определения метрик​

Главное правило: один язык метрик​

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

Реестр метрик (metrics registry)​

Каждая метрика — сущность с определением:

  • Имя метрики (например, quote_to_booking_conversion).
  • Описание на нескольких языках.
  • Точное вычисление (формула на каноничных полях DWH).
  • Размерности (dimensions) — допустимые группировки (по тенанту, по поверхности, по региону).
  • Применимость — на каких витринах используется.
  • Ответственная команда — кто владеет определением.

Запрет на «подсчёт в дашборде»​

Дашборды отображают готовые метрики из витрин, не считают их «на лету» из сырых событий. Это:

  • Гарантирует одинаковое значение метрики во всех представлениях.
  • Снижает нагрузку на DWH (сложные расчёты — один раз при материализации витрины).
  • Упрощает аудит — определение метрики в одном месте.

Защита приватности при аналитике​

k-анонимизация для кросс-тенантных агрегатов​

При формировании любого агрегата, включающего данные нескольких тенантов:

  • Минимум k_min_tenants тенантов в выборке (типично 5).
  • Минимум k_min_events событий в каждом тенанте (типично 100).
  • Минимум k_min_total_events событий в общей выборке (типично 1000).

Если хотя бы одно условие не выполнено — агрегат не возвращается. Партнёр видит сообщение «недостаточно данных для сравнения».

Запрет на индивидуальную идентификацию​

Аналитический канал никогда не раскрывает партнёру:

  • Идентификаторы других тенантов.
  • Конкретные суммы, привязываемые к другим тенантам.
  • Детальные паттерны, по которым можно ре-идентифицировать другого тенанта.

Журнал аудита​

Все запросы к partner-facing analytics журналируются для аудита:

  • Кто запросил (тенант + пользователь).
  • Когда.
  • Какой набор данных.
  • Какие фильтры применены.

Это позволяет:

  • Расследовать инциденты потенциальной утечки.
  • Отвечать регулятору при запросах.
  • Контролировать злоупотребления.

Право на удаление​

При запросе субъекта данных на удаление (по общему регулированию защиты данных):

  • Каноничные витрины с полями actor_hash — анонимизируются (хеш заменяется на специальный forgotten).
  • Сохраняется агрегационная целостность.
  • Подробности — в Платформа данных и захват событий.

Интеграция с платформой машинного обучения​

Применения ML над аналитикой​

Anomaly detection в метриках​

Модель детектирует аномалии в:

  • Воронке бронирования (внезапное падение конверсии).
  • Здоровье поставщиков (резкая деградация).
  • Партнёрском потреблении (внезапные всплески или падения).
  • Инцидентах (паттерны, предвещающие крупный инцидент).

При обнаружении — AnalyticsAlert со срабатыванием.

Автоматические insights (фаза 3)​

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

  • «Конверсия вашей воронки за последнюю неделю выросла на 15% относительно предыдущей. Главный фактор — рост конверсии на потребительской витрине в регионе CZ».
  • «Ваше потребление превысило 80% месячной квоты на 22-й день — рекомендуем рассмотреть повышение тарифа».

Для тарифов Professional и выше.

Прогнозирование​

  • Прогноз счёта — модель прогнозирует конец месяца на основе текущей траектории.
  • Прогноз отмен — модель прогнозирует ожидаемое количество отмен по сегментам.
  • Прогноз нагрузки — модель прогнозирует пиковые периоды для capacity-планирования.

Каноничный путь интеграции​

ML работает над аналитическим слоем, не над сырыми событиями DWH:

  • Признаки (MlFeature) формируются из аналитических витрин.
  • Результаты ML возвращаются в аналитические витрины как дополнительные колонки.
  • Аналитические дашборды отображают как фактические данные, так и ML-выводы.

Подробности — в Платформа машинного обучения.

Учёт потребления​

Аналитика — компонент с переменной стоимостью:

  • Запросы программного интерфейса аналитики — analytics_api_calls. Метрика тарификации.
  • Объём экспортов — analytics_export_volume. Для крупных партнёров.
  • Хранение кастомных витрин (Enterprise) — analytics_custom_storage.

См. Учёт потребления и квоты.

События аналитического слоя​

СобытиеКогдаГлавные потребители
analytics.dataset.materializedЗавершена материализация витриныКонтур наблюдаемости, партнёрские дашборды
analytics.dataset.staleness_exceededПревышено окно свежестиКонтур наблюдаемости, оперативная команда
analytics.export.requestedЗапрос на экспортКонтур аудита
analytics.export.completedЭкспорт готовПартнёр (через уведомления)
analytics.export.privacy_review_requiredТребуется ревьюКоманда compliance
analytics.alert.triggeredСрабатывание алертаПартнёр (для партнёрских), команда (для внутренних)
analytics.api.cross_tenant_queryКросс-тенантный запрос команды платформыКонтур аудита
analytics.dashboard.viewedПросмотр дашборда (для метрик использования)Платформа данных, опционально
analytics.metric.definition_changedИзменено каноничное определение метрикиВсе потребители метрики, команды-владельцы

Полная таксономия — в Первоначальная таксономия событий.

Технологический выбор по фазам​

ФазаВнутренние дашбордыПартнёрские дашбордыПрограммный интерфейс аналитикиЭкспортРеестр метрик
BootstrapGrafana базовая(нет)(нет)Прямой SQL по DWHФайл-документация
2Grafana + базовый MetabaseБазовые встроенные виджеты в партнёрской консолиБазовый RESTПодписанные ссылки CSVРеестр в БД
3Расширенный Metabase / Apache SupersetПолнофункциональные дашбордыПолный REST + AsyncAPIParquet + S3 shareРеестр с версионированием
4Self-service BI с custom dashboardsКастомные дашборды для EnterpriseРасширенный с GraphQLSFTP + S3 + custom destinationsFederated metric catalog

Конкретный выбор внутреннего BI-инструмента — открытая развилка, эскалируется при подходе к фазе 2.

Фазы развёртывания​

Фаза Bootstrap (0–6 месяцев)​

Что разворачивается:

  • Каноничная модель (AnalyticalDataset, Dashboard, AnalyticsExport, AnalyticsAlert) зафиксирована.
  • Базовые внутренние дашборды через Grafana по операционным метрикам.
  • Базовый прямой SQL-доступ к DWH для команды платформы.
  • Реестр метрик в виде документации.
  • Простые алерты по основным метрикам через Grafana.

Триггер выхода:

  • Готовность к запуску партнёрского продукта аналитики (фаза 2).
  • Расширение команды платформы — нужен зрелый внутренний BI.

Фаза 2 — Production analytics (6–18 месяцев)​

Что разворачивается:

  • Базовые партнёрские дашборды в партнёрской консоли (потребление, воронка).
  • Базовый программный интерфейс аналитики для тарифов Professional и Enterprise.
  • Расширенные внутренние дашборды через Metabase или Apache Superset.
  • Реестр метрик в БД с владельцами.
  • Алерты для партнёров (приближение к лимиту тарифа).
  • Базовый бенчмаркинг с k-анонимизацией.

Триггер выхода:

  • Появление спроса на экспорт сырых данных от корпоративных партнёров.
  • Появление ML-приложений в аналитике.

Фаза 3 — Smart analytics (18–30 месяцев)​

Что разворачивается:

  • Полнофункциональные партнёрские дашборды с интерактивностью.
  • ML-приложения (anomaly detection, автоматические insights, прогнозирование).
  • Экспорт сырых данных в Parquet через S3 share для тарифа Enterprise.
  • Расширенный программный интерфейс аналитики с AsyncAPI для подписок.
  • Реестр метрик с версионированием и журналом изменений.

Фаза 4 — Самообслуживание (30+ месяцев)​

Что разворачивается:

  • Self-service BI для тарифа Enterprise — партнёр строит собственные дашборды на платформенных витринах.
  • Кастомные витрины по запросу для крупных корпоративных партнёров.
  • Расширенный программный интерфейс с GraphQL.
  • Multi-region аналитика с локализацией данных.
  • Federated metric catalog для крупных партнёров с собственными системами.

Архитектурные решения с тезисным обоснованием​

Решение 1. Аналитика — отдельный продуктовый слой, не «отчёты по запросу»​

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

Тезисы:

  1. Без отдельного продуктового слоя аналитика «по запросу» — это ad-hoc SQL разных команд с разными определениями метрик. Это разрушает консистентность.
  2. Соглашение об уровне обслуживания на свежесть невозможно без структурированной материализации.
  3. Партнёрский продукт аналитики — отдельный коммерческий продукт. Без структурированной модели его нельзя продавать.

Решение 2. Внутренний и партнёрский продукты разделены архитектурно​

Цель: исключить класс ошибок, при которых партнёру попадают индивидуальные данные другого тенанта.

Тезисы:

  1. Архитектурное разделение даёт защиту независимо от добросовестности кода. Один общий слой с ролевой моделью — путь к ошибке.
  2. Партнёрский программный интерфейс работает только с partner-facing dataset; даже при ошибке кода доступ к internal невозможен.
  3. Регулятор (общее регулирование защиты данных) требует строгой изоляции — архитектурное разделение проще доказать аудиту, чем процесс.

Решение 3. Каноничные определения метрик в едином реестре​

Цель: обеспечить «один язык метрик» по всей платформе.

Тезисы:

  1. Без реестра одна и та же метрика считается по-разному в разных дашбордах — создаётся когнитивный разрыв и недоверие к данным.
  2. Реестр с владельцами обеспечивает ответственность за качество.
  3. Современные платформы (LinkedIn, Airbnb, Spotify) — все строят metric registries как стандарт. Это база.

Решение 4. k-анонимизация для кросс-тенантных агрегатов как закон​

Цель: обеспечить корректную приватность при бенчмаркинге.

Тезисы:

  1. Без k-анонимизации мелкие тенанты идентифицируются в агрегатах по характерным паттернам.
  2. Архитектурное правило защищает от ошибок реализации.
  3. Регулятор требует приватности кросс-tenant аналитики — k-анонимизация — стандарт.

Решение 5. Метрики потребляются из витрин, не считаются «на лету»​

Цель: обеспечить консистентность и предсказуемую стоимость.

Тезисы:

  1. Расчёт «на лету» в дашборде — каждый просмотр генерирует запрос. На масштабе платформы это не масштабируется.
  2. Витрины с предварительным расчётом — стандарт BI-индустрии (data marts, materialized views, OLAP cubes).
  3. Витрины обеспечивают консистентность — все потребители видят одинаковое значение.

Открытые развилки​

Развилка 1. Конкретный внутренний BI-инструмент​

Metabase open-source (простой, бесплатный) vs Apache Superset (расширенный, бесплатный) vs Looker (commercial).

Эскалируется: при подготовке к фазе 2.

Развилка 2. Технология материализации витрин​

Прямые SQL-views в DWH vs dbt-модели vs специализированный движок витрин (Cube.dev и подобные).

Эскалируется: при выходе из фазы Bootstrap.

Развилка 3. Самообслуживание BI для партнёров​

В фазе 4 — возможность партнёрам строить собственные дашборды. Глубина возможностей (только панели vs полная разработка) — открытая развилка.

Эскалируется: при появлении спроса от корпоративных партнёров.

Развилка 4. Federated query layer​

Для крупных корпоративных партнёров — возможность federated query: партнёр запрашивает данные платформы из своей собственной BI-системы напрямую, без экспорта. Это требует специальной инфраструктуры.

Эскалируется: в фазе 4 при появлении партнёрских запросов.

Развилка 5. Conversational analytics (LLM-based интерфейс)​

В фазе 4 — возможность задавать аналитические вопросы на естественном языке через LLM-интерфейс. Платформа отвечает агрегатами и визуализациями.

Эскалируется: при создании conversational-стратегии в Платформа машинного обучения.

Связанная документация​

Корневые архитектурные документы​

Связанные доменные документы​

Документы развития​

Операционная сторона​

Архитектурные правила​

Уточнение под Фазы 5–6 (28.04.2026) — связь с isolation, compliance DSR, SLA-reporting​

Документ опубликован 26.04.2026 в Фазе 4. После Фаз 5–6 аналитика интегрирована со специализированными доменами; эта секция фиксирует обязательные связи.

Связь с уровнями тенантной изоляции и k-anonymization​

reference/multi-tenant-isolation-strength.md (Фаза 5) определяет правила межтенантной агрегации:

  • Cross-tenant aggregation rules — минимальный размер группы k=10 (k-anonymity);
  • partner-facing analytics dashboards — только данные собственного tenant + benchmark anonymized данные (median по сегменту);
  • запрос с aggregation менее k → suppress values или deny;
  • audit log каждого cross-tenant aggregation request.

Этот документ обязан реализовать k-anonymization на уровне queries, не на уровне UI — фильтрация только UI = security gap.

Связь со SLA reporting​

operations/sla-and-on-call-model.md (Фаза 6) — partner-facing SLA reports:

  • Tenant SLA dashboard — actual uptime, latency, webhook delivery, freshness, broken-by-tier;
  • Service credits applied — historical credits per period;
  • SLA breach incidents — published per partner с severity и resolution status;
  • Comparative benchmarks — позиция партнёра относительно median своего tier (anonymized).

SLA reporting — часть partner-facing analytics product (Professional+ tier).

Связь с GDPR DSR API​

reference/compliance-and-legal.md (Фаза 4) определяет Data Subject Rights API:

  • Right of Access — GET /privacy/data-export — analytics должна включать собранные analytical events (с правильной анонимизацией где applicable);
  • Right to Erasure — POST /privacy/data-delete — analytics должна удалить все события subject из DWH (включая backups, archived data);
  • Right to Portability — machine-readable export.

Реализация требует subject-aware indexing в DWH — каждое событие связано с subject через user_id_hash, что позволяет efficient retrieval/deletion. Без этого DSR на больших volumes невозможен в SLA 30 дней (target 7 дней).

Связь с security audit logging​

reference/security-architecture.md (Фаза 10) определяет audit log как immutable WORM storage:

  • Все access к partner-facing analytics — log с actor, tenant, query, timestamp;
  • Все cross-tenant aggregation queries — log с k-anonymization params;
  • Все exports — log + размер + recipient (для exfiltration monitoring);
  • Suspicious analytics activity (например, попытка извлечь PII через clever queries) → security alert.

Analytics audit log — Tier 1 retention (7 лет), tamper-evident.

Связь с booking events и tour saga​

Aналитика построена на event streams от:

Все эти события поступают через data-platform-and-events-tracking.md — единый источник истины для analytics.

Каноничный итог уточнения​

Analytics & BI — потребитель централизованной data platform с обязательствами:

  • k-anonymization для cross-tenant queries (источник правил — multi-tenant-isolation-strength);
  • SLA reporting как product feature (источник metrics — sla-and-on-call-model);
  • DSR fulfillment в 7 дней (target) / 30 дней (legal max);
  • Security audit для всех access к analytics;
  • Subject-aware indexing для GDPR erasure efficiency.

Уточнение выполнено через no-destruction.