Флаги экспериментов и A/B-тесты
1) Зачем это нужно
Экспериментирование — управляемый способ улучшать конверсию и надежность без риска “ломать прод”. В iGaming это влияет на: регистрацию, депозит/вывод, ставки/сеттл, KYC/AML-воронки, лобби/UX, бонусы и антифрод. Фичефлаги дают быстрые, обратимые изменения; A/B-тесты — доказательства эффекта до масштабирования.
2) Принципы платформы
1. Safety-by-design: флаги с TTL, откатами и лимитами охвата; запрет включения при красных SLO.
2. Compliance-aware: SoD/4-eyes для чувствительных флагов (платежи, RG, PII); гео-резиденство данных.
3. Single Source of Truth: все флаги/эксперименты — как данные (Git/репозиторий политик).
3) Таксономия флагов
Release-флаги: управление раскаткой версий (canary/rollout/kill-switch).
Experiment-флаги: A/B/n, multi-armed bandit, interleaving для ранжирования.
Ops-флаги: деградация фич (временная), переключение провайдеров (PSP/KYC).
Config-флаги: параметры без релиза (лимиты, тексты, коэффициенты).
Safety-флаги: экстренные выключатели (export PII off, bonus caps).
Каждый флаг имеет: `owner`, `risk_class`, `scope(tenant/region)`, `rollout_strategy`, `ttl`, `slo_gates`, `audit`.
4) Архитектура платформы
Flag Service (CDN-кэш): отдает решение за ≤10–20 мс; подписан на GitOps/ре-консайлер.
Assignment Engine: стабильный хеш + стратификация (GEO/brand/device) → бакеты.
Experiment Service: каталог тестов, расчет MDE/мощности, SRM/guardrails, статистика.
Exposure Logger: идемпотентный лог “попадания под флаг/вариант” + ключ события.
Metrics API: агрегаты SLI/KPI/KRI и экспериментов (CUPED/корректировки).
Policy Engine: SoD/4-eyes, freeze-окна, гео-ограничения, SLO-гейты.
Dashboards & Bot: отчеты, алерты guardrail, короткие команды в чат-боте.
5) Модель данных (упрощенно)
Flag: `id`, `type`, `variants`, `allocation{A:0.5,B:0.5}`, `strata{geo,tenant,device}`, `constraints`, `ttl`, `kill_switch`, `slo_gates`, `risk_class`, `audit`.
Experiment: `id`, `hypothesis`, `metrics{primary,secondary,guardrails}`, `audience`, `power`, `mde`, `duration_rule`, `sequential?`, `cuped?`, `privacy_scope`.
6) Процесс “от идеи до вывода”
1. Гипотеза: метрика-цель, риск/комплаенс-оценка, MDE (минимально заметный эффект).
2. Дизайн: выбор аудитории и стратификаций (GEO/tenant/device), расчет мощности и длительности.
3. Рандомизация и старт: включение через Policy-Engine (SLO зеленые, SoD пройден).
4. Мониторинг: SRM-проверки (искажение рандомизации), guardrails (ошибки/латентность/выручка).
5. Аналитика: частотная (t-test, U-test) или Bayesian; CUPED для снижения дисперсии.
6. Решение: promote/rollback/iterate; запись в каталог знаний.
7. Архивация: выключение флага по TTL, выпуск конфигурации/кода, чистка телеметрии.
7) Назначение и бакетирование
Детерминистичность: `bucket = hash(secret_salt + user_id) mod N`.
Стратификация: отдельно по `geo, tenant, device, new_vs_returning` → равномерность в слоях.
Единая соль на период: меняется контролируемо для избежания коллизий/утечек.
Экспозиции: логируются до первой целевой метрики (чтобы избежать выборочного логирования).
8) Метрики и guardrails
Primary: конверсия регистрации/депозита, ARPPU, удержание D1/D7, скорость KYC, CTR лобби.
Secondary: LCP/JS-ошибки, p95 “ставка→сеттл”, auth-success PSP.
Guardrails: error_rate, p99 латентности, SLO-burn-rate, жалобы/тикеты, RG-пороговые (ответственная игра).
Долгосрочные: churn, LTV-проксe, chargebacks, RG-флаги.
9) Статистика и принятие решений
MDE & мощность: заранее заданы (например, MDE=+1.0 п.п., power=80%, α=5%).
SRM (Sample Ratio Mismatch): χ²-тест раз в N минут; при SRM — паузим тест и расследуем.
CUPED: ковариата — предтестовое поведение/базовая конверсия (уменьшает дисперсию).
Коррекции множественности: Bonferroni/Holm или контролируем FDR.
Sequential: group sequential/always-valid p-values (SPRT, mSPRT) — безопасные ранние остановки.
Bayesian: постериорная вероятность улучшения и expected loss; хорошо для принятия решений с асимметрией цены ошибки.
Interference/peeking: запрет “глянуть и решить” вне процедур sequential; логи всех просмотров.
Непараметрические: Mann-Whitney для тяжелых хвостов; бутстрэп для устойчивости.
10) Приватность и комплаенс
Без PII в лейблах и экспозициях: токенизация, geo-scope хранения.
SoD/4-eyes: эксперименты, влияющие на выплаты/лимиты/PII/ответственную игру.
Holdout по RG/Compliance: часть трафика всегда в контроль (чтобы видеть регуляторные/этические эффекты).
Data minimization: хранить только необходимые агрегаты и ключи.
Аудит WORM: кто запустил/изменил/остановил, параметры, версии.
11) Интеграции (операционные)
CI/CD & GitOps: флаги как данные; PR-ревью, валидации схем.
Алертинг: guardrail→авто-пауза флага, уведомление IC/владельца.
Инцидент-бот: команды `/flag on/off`, `/exp pause/resume`, `/exp report`.
Release-gates: запрещают релизы, если активные эксперименты в чувствительных областях без owner-онлайна.
Metrics API: отчеты, SLO-гейты, exemplars (trace_id для деградаций).
Status-страница: не публикует детали экспериментов; только если влияет на доступность.
12) Конфигурации (примеры)
12.1 Флаг раскатки по канареечной схеме
yaml apiVersion: flag.platform/v1 kind: FeatureFlag metadata:
id: "lobby.newLayout"
owner: "Games UX"
risk_class: "medium"
spec:
type: release scope: { tenants: ["brandA"], regions: ["EU"] }
allocation:
steps:
- { coverage: "5%", duration: "30m" }
- { coverage: "25%", duration: "1h" }
- { coverage: "100%" }
slo_gates: ["slo-green:auth_success","slo-green:bet_settle_p99"]
ttl: "30d"
kill_switch: true12.2 Эксперимент A/B с guardrails и CUPED
yaml apiVersion: exp.platform/v1 kind: Experiment metadata:
id: "payments.depositCTA.v3"
hypothesis: "Новая кнопка повышает депозит-конверсию на +1 п.п."
owner: "Payments Growth"
spec:
audience:
strata: ["geo","tenant","device"]
filters: { geo: ["TR","EU"] }
split: { A: 0.5, B: 0.5 }
metrics:
primary: ["deposit_conversion"]
secondary: ["signup_to_kyc","auth_success_rate"]
guardrails: ["api_error_rate<1.5%","latency_p99<2s","slo_burnrate<1x"]
stats:
alpha: 0.05 power: 0.8 mde: "1pp"
cuped: true sequential: true operations:
srm_check: "5m"
pause_on_guardrail_breach: true ttl: "21d"13) Дашборды и отчетность
Exec: lift по ключевым метрикам, процент успешных экспериментов, экономический эффект.
Ops/SRE: guardrail-алерты, SRM, деградации SLO, влияние на лаги/очереди.
Domain: воронки (регистрация→депозит→ставка), сегменты GEO/PSP/устройство.
Catalog: база знаний по завершенным экспериментам (что пытались, что сработало/нет, эффекты на RG/комплаенс).
14) KPI/KRI функции
Time-to-Test: идея→старт (дни).
Test Velocity: экспериментов/мес на команду/домен.
Success Rate: доля тестов с положительным, статистически значимым эффектом.
Guardrail Breach Rate: частота автопауз по SLO/ошибкам.
SRM Incidence: доля тестов с нарушенной рандомизацией.
Documentation Lag: время от завершения до записи в каталог.
Cost per Test: $ телеметрии/расчетов/сопровождения.
Long-term Impact: изменение LTV/churn/chargebacks на когортах победивших вариантов.
15) Дорожная карта внедрения (6–10 недель)
Нед. 1–2:- Репозиторий флагов/экспериментов, схемы (JSON Schema), базовый Flag Service с кэшем.
- Policy-Engine (SoD/4-eyes, SLO-гейты), интеграция с GitOps.
- Assignment Engine (хеш+страты), Exposure Logger, SRM-чек, guardrails-алерты.
- Первый набор флагов: release+ops (kill-switch), 1–2 безопасных A/B.
- Статистический модуль: CUPED, частотные и Bayesian отчеты, sequential-контроль.
- Дашборды (Exec/Ops/Domain), команды инцидент-бота `/flag`, `/exp`.
- Автопауза по guardrails, интеграция с Release-gates, каталог знаний.
- Документация процессов, обучение команд (Growth/Payments/Games).
- Мульти-регион и гео-резиденство, FinOps-лимиты кардинальности, хаос-учения (срыв SRM).
- Сертификация владельцев экспериментов, аудит WORM.
16) Антипаттерны
Включать флаги “всем сразу” без канареек и SLO-гейтов.
Смешивать release-флаги и экспериментальные в одну сущность без явных целей.
Рандомизация “на клиенте” без соли/детерминизма → SRM/манипуляции.
Peeking без sequential-контроля; постфактум выбирать метрику-победителя.
Отсутствие guardrails и owner-дежурного → рост инцидентов.
Хранить PII в экспозициях/лейблах; игнор гео-резиденства.
Не выключать флаги по TTL → “зависшие” ветки и разъезд поведения.
17) Best Practices (кратко)
Малые, четкие гипотезы; один Primary-метрик на тест.
Старт с 5–10% трафика и строгими guardrails.
CUPED почти всегда; Bayesian — когда важна скорость решения и стоимость ошибок асимметрична.
Всегда проверяйте SRM и инвариантные метрики.
Пишите пост-анализ и добавляйте в каталог знаний.
Уважайте ответственную игру (RG): не стимулируйте вредное поведение метриками краткосрочной выручки.
Итог
Флаги и A/B-тесты — это производственный контур изменений: флаги как данные, безопасная рандомизация и строгая статистика, SLO/комплаенс-guardrails, наблюдаемость и аудит. Такой подход позволяет быстро учиться на проде, повышая конверсию и качество без роста рисков, с доказуемым эффектом для бизнеса и регуляторов.