Неудачные эксперименты

Guardrails: что если эксперимент случайно сделал хуже

Лотти не хочет, чтобы “проверка цвета” внезапно:

• увеличила ошибки,
• замедлила экран,
• уронила конверсию.

Поэтому у эксперимента есть guardrails — простая страховка.

Это правила вида: “Если ошибок стало заметно больше — останови эксперимент”
или “Если стало медленнее — останови эксперимент”.

Смысл один: если стало опасно для продукта или бизнеса — эксперимент быстро выключается.

Что видит аналитик в конце

Когда прошло достаточно времени и накопились ивенты, аналитик открывает отчёт.

Там видно по каждому варианту:

• сколько людей увидели кнопку,
• сколько нажали,
• сколько дошли до целевого действия (например, покупки),
• не ухудшились ли ошибки и скорость.

Чтобы было совсем наглядно, отчёт обычно читается так: “Синий вариант дал +X% к кликам, при этом ошибки не выросли → можно выкатывать всем”.
Или: “Красный дал больше кликов, но увеличил ошибки → лучше не выкатывать”.
Или: “Разницы нет → закрываем эксперимент и идём проверять другую гипотезу”.

В этот момент Лотти получает главное: не спор, а решение на данных.

Одна схема, чтобы закрепить

Аналитик создаёт эксперимент
        ↓
Приложение спрашивает “что показать?” → показывает вариант
        ↓
Приложение отправляет “что произошло?”
        ↓
Платформа следит за guardrails
        ↓
Платформа строит отчёт
        ↓
Лотти выбирает победителя и принимает решение

Edge-case сценарии

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

1. События приходят с задержкой и не по порядку.
   Проблема: если считать «как прилетело», отчёт становится шумом и искажает воронку.
   Пример: у части пользователей событие buttonClicked прилетает раньше buttonShown (ретраи, офлайн‑режим, сетевые задержки), а часть конверсий доезжает через несколько часов. Если обработка идёт только по времени приёма, одни конверсии теряются, другие ошибочно привязываются к неправильному показу.
   Ожидание: аналитика устойчиво обрабатывает задержки и переупорядочивание событий, отчёт остаётся интерпретируемым и воспроизводимым при повторном пересчёте.

2. Эксперимент улучшает целевую метрику, но портит стабильность.
   Проблема: «победа» по бизнес‑метрике может быть достигнута ценой ошибок и деградации, что делает такой результат неприемлемым для продакшена.
   Пример: вариант B даёт рост CTR, но одновременно увеличивает долю ошибок и время ответа. Без ограничителей такой вариант может выглядеть «лучшим» только по одной метрике, хотя фактически ухудшает пользовательский опыт.
   Ожидание: guardrails автоматически отслеживают критичные метрики и останавливают рискованный сценарий до массового ущерба, даже если целевая метрика формально растёт.

3. Несколько команд одновременно тестируют изменения в одной зоне продукта.
   Проблема: конфликты смешивают эффекты и делают результаты необъяснимыми.
   Пример: один аналитик проверяет цвет кнопки (blue/green), а другой одновременно проверяет текст на той же кнопке (Купить/Оформить). Если оба эксперимента идут параллельно в одной зоне, итоговый CTR нельзя однозначно объяснить: сработал цвет, текст или их комбинация.
   Ожидание: конфликты решаются прозрачно и воспроизводимо, без «магии».

4. Один и тот же пользователь слишком часто попадает в эксперименты.
   Проблема: если пользователь постоянно оказывается в «экспериментальном» сегменте, он видит нестабильный опыт, а данные становятся смещёнными.
   Пример: Вася участвует в трёх экспериментах и каждый раз попадает в первые 30% аудитории, получающей экспериментальное значение feature flag. В результате именно на нём непропорционально часто тестируются изменения, а «спокойного» базового опыта почти нет.
   Ожидание: платформа ограничивает частоту и плотность участия одного пользователя в экспериментах, обеспечивает периоды обычного опыта и делает распределение воспроизводимым без систематического перекоса в пользу одних и тех же людей.