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

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), ознаки «всередині сесії».
Ієрархії: strana→region→gorod; kategoriya→podkategoriya→teg.
Взаємодії: фічі типу'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: наскрізний трейс події → збагачення → рішення → дію.
Post-action атрибуція: які контексти були ключовими для ефекту.

12) Інтеграція з графами знань і семантикою

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

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, моделі і політики, що враховують контекст, доказова оцінка ефекту і суворі правила приватності. Правильно налаштований контекст перетворює кожну взаємодію в розумний, своєчасний і безпечний вибір, який вимірно покращує продукт і бізнес-метрики.