Контекстная аналитика

1) Что такое контекстная аналитика и зачем она нужна

Контекстная аналитика — это извлечение и использование ситуационных сигналов (кто, где, когда, на каком устройстве, с какой целью, в каком состоянии системы/рынка) для улучшения решений в моменте: рекомендации, офферы, лимиты риска, алерты, следующая лучшая реакция (Next Best Action).
Преимущества: выше релевантность, меньше шумных действий, выигрыш в конверсии и удержании, снижение операционных затрат и рисков.

2) Таксономия контекста

Пользовательский: сегмент, стадия жизненного цикла, намерение, история поведения, язык.
Устройство/клиент: тип и модель, ОС/браузер, сеть, качество соединения, батарея/CPU.
Временной: время суток, день недели, сезон, календарные события, «свежее окно» активности.
Гео/локальный: страна/регион/точка продаж, гео-правила и прайсы, локальные праздники.
Операционный: загрузка системы, очереди, лимиты API, текущие инциденты.
Контентный: тема/жанр/категория просматриваемого объекта, метаданные.
Бизнес-контекст: кампания, промо, цена, лимиты, правила антириска.
Средовой/внешний: погода, трафик, курсы валют, макротренды (если релевантно).

3) Источники сигналов и сбор

События и логи: клики, просмотры, транзакции, системные метрики.
Клиентские SDK/edge: датчики устройства, latency, локальные фичи.
Специализированные справочники: календари/праздники, гео-слои, классификаторы контента.
Модели-наблюдатели: намерение (intent), топики, токсичность/риск, эмбеддинги контента.
Конфигурация и правила: активные кампании, фич-флаги, лимиты.

Практика: для каждого сигнала — контракт (схема, частота, допустимые значения) и качество (freshness/completeness).

4) Нормализация и формирование контекстных фич

Категоризация и хэшинг: high-cardinality признаки → hashing trick/embeddings.
Временные фичи: cyclical encoding (sin/cos) для часа/дня, скользящие окна «последние N минут/часов/дней».
Сессионность: детекция границ сессии (inactivity threshold), признаки «внутри сессии».
Иерархии: страна→регион→город; категория→подкатегория→тег.
Взаимодействия: фичи типа `device_os × locale × hour_bucket`.
Онлайн против оффлайн: один Spec фич в Feature Store с вариантами materialization: online (мс) и offline (батчи).

5) Архитектура контекстной аналитики

Контур: Ингест → Обогащение контекстом → Feature Store (online/offline) → Модель/Правила → Сервинг → Обратная связь.

1. Event Bus (Kafka/Pulsar/NATS) с контрактами (Avro/Protobuf).

• Online: KV/кэш для низкой латентности (Redis/RocksDB).
• Offline: DWH/Lake для обучения и аналитики (Parquet/Delta/ClickHouse).
• 3. Context Enrichment Service: сбор контекста из SDK/edge/справочников, нормализация, TTL и версии.
• 4. Decisioning: модели (онлайн-скоринг) + rule engine, contextual bandits.
• 5. Delivery: API, вебхуки, UI-виджеты, push/чат, CRM/CDP.
• 6. Observability: SLO, дрейф контекста, эффекты действий.

6) Модели и методы, адаптированные к контексту

Контекстные бэндиты (LinUCB/Thompson): балансировка исследование/эксплуатация для NBA/офферов.
Uplift-моделирование: модель эффекта действия с учетом контекста (T-/S-/DR-методы).
GBDT/Tabular NN с взаимодействиями: авто-поиск сплайнов/пересечений контекстов.
Последовательные модели (RNN/Transformer): сессионные паттерны, HRED/GRU4Rec, self-attention по событиям и контекстам.
Кластеризация контекста: онлайн-кластеры для маршрутизации политик/моделей.
Правила и пороги с контекстом: risk-порог зависит от часа/локации/качества сигнала.

7) Реальное время vs оффлайн

Real-time: решения ≤ (100–500) мс. Контекст в online Feature Store, предзагруженные справочники, кэш.
Near-real-time: окна 1–5 мин, инкрементальные витрины, дешевые обогащения.
Offline: обучение/калибровка, дизайн фич-взаимодействий, анализ эффектов.

Правило: одинаковые определения фич в обоих контурах; тесты согласованности online/offline.

8) Качество контекста и SLO

Freshness: не старше X минут/секунд (по типу сигнала).
Completeness: доля заполненности ключевых контекстов.
Accuracy/Consistency: соответствие справочникам, валидные пересечения.
Latency p95/p99 для чтения online-фич и принятия решения.
Uplift/CTR/ARPPU/Recall@K — бизнес-метрики, чувствительные к контексту.

9) Причинность и эксперименты

A/B с стратификацией по контекстам или CUPED для снижения дисперсии.
Бэндиты с guardrails: ограничение ущерба при исследовании.
Квази-эксперименты: Difference-in-Differences/Synthetic Control для внешних изменений (регион/сезон).
Мульти-целевые trade-off: оптимизация парных целей (выгода/риск/жалобы) под контекст.

10) Приватность, согласия и безопасность

Согласия (consent) и назначение целей для каждого источника контекста.
PII-минимизация и токенизация до обогащения/хранения.
RLS/CLS: контекст-зависимые правила видимости, гео-локализация хранения.
Политики TTL: жесткие сроки хранения чувствительных контекстов.
Аудит и DSAR: способность показать/удалить контекст по субъекту данных.

11) Наблюдаемость и диагностика

Дашборды контекста: coverage по фичам, доля «unknown/other», старение сигналов.
Drift контекста: PSI/JS по распределениям; автоматические алерты.
Trace-id: сквозной трейc события → обогащение → решение → действие.
Post-action атрибуция: какие контексты были ключевыми для эффекта.

12) Интеграция с графами знаний и семантикой

Онтологии контекста: строгие значения и иерархии (время/гео/устройство).
KG-обогащение: извлечение «родственных» фактов (например, провайдер↔категория↔регион).
Семантический поиск: контекст как фильтр/вес в ранжировании.

13) Edge-контекст

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

14) Антипаттерны

“Контекста много — значит лучше”. Переобучение, рост латентности и стоимости.
Несогласованные фичи online/offline. Противоречивые выводы и деградации.
Эфемерные сигналы без TTL. Накопление мусора, нарушения приватности.
SELECT и «свободные» схемы. Ломаются потребители при MINOR-эволюции.
Одинаковые политики для разных контекстов. Потеря эффективности и справедливости.
Игнор причинности. Реакция на корреляции → ущерб.

15) Дорожная карта внедрения

1. Discovery: карты решений и дедлайнов, список контекстов, владельцы, риски.
2. Контракты и словари: схемы сигналов, справочники, TTL, согласия.
3. Feature Store: единая спецификация фич (online/offline), тесты согласованности.
4. MVP-модель/политика: 3–5 ключевых контекстов, метрики, каналы доставки.
5. Эксперименты: A/B стратифицированный, бэндиты на малой доле.
6. Наблюдаемость: SLO по latency/freshness/coverage, алерты дрейфа.
7. Безопасность/priv: RLS/CLS, токенизация, DSAR-процессы.
8. Scale: больше контекстов, персонализация, KG/семантика, edge.

16) Чек-лист перед релизом

• Сигналы контекста имеют контракты, TTL, владельцев и согласия.
• Фичи задекларированы в Feature Store; online/offline вычисляются одинаково.
• Latency p95 чтения фич и принятия решения в целевом окне.
• Дрейф/coverage мониторятся; есть алерты и runbook’и.
• A/B или бэндиты настроены; guardrails определены.
• Политики приватности и RLS/CLS включены; экспорт обезличен.
• Документация: глоссарий контекстов, схемы, примеры запросов и правил.

17) Мини-шаблоны

17.1 Спецификация контекстной фичи (псевдо-YAML)

yaml feature:
name: hour_bucket type: categorical source: event_time transform: "floor(minute/15)"  # 15-минутные окна ttl: 30m online: true offline: true dq:
allowed: [0..95]
freshness_sla: 60s

17.2 Политика Next Best Action с контекстом

yaml nba_policy:
context_require:
- locale in ["en","ru","tr"]
- device_os in ["Android","iOS"]
model: "linucb_v5"
guardrails:
- latency_p95_ms <= 200
- complaint_rate_24h < 0. 02 fallback: "rule_based_offer_if_model_conf<0. 55"

17.3 Idempotent merge для онлайновой витрины

sql merge into fs_online as t using incoming as s on t. key = s. key and t. feature = s. feature when not matched then insert (key, feature, val, ts) values (...)
when matched and s. ts > t. ts then update set val=s. val, ts=s. ts;

17.4 Стратифицированный эксперимент

yaml ab_test:
strata: [device_os, hour_bucket, region]
allocation: {control: 0. 5, treatment: 0. 5}
metrics: [uplift_cr, arppu, complaints]
duration_min_days: 7 stop_rules: {p_value<=0. 05, min_effect_size: 0. 5pp}

18) Итог

Контекстная аналитика — это не просто «подставить час и страну», а сквозной инженерный контур: четко описанные сигналы и TTL, согласованные фичи online/offline, модели и политики, учитывающие контекст, доказательная оценка эффекта и строгие правила приватности. Правильно настроенный контекст превращает каждое взаимодействие в умный, своевременный и безопасный выбор, который измеримо улучшает продукт и бизнес-метрики.