Прапори експериментів і 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/pe-консайлер.
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 «stavka→settl», auth-success PSP.
Guardrails: error_rate, p99 латентності, SLO-burn-rate, скарги/тікети, RG-порогові (відповідальна гра).
Довгострокові: churn, LTV-проксі, 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→avto -пауза прапора, повідомлення 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: воронки (registratsiya→depozit→stavka), сегменти GEO/PSP/пристрій.
Catalog: база знань із завершених експериментів (що намагалися, що спрацювало/ні, ефекти на RG/комплаєнс).
14) KPI/KRI функції
Time-to-Test: ideya→start (дні).
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, спостережуваність і аудит. Такий підхід дозволяє швидко вчитися на проді, підвищуючи конверсію і якість без зростання ризиків, з доказовим ефектом для бізнесу і регуляторів.