Сообщить об ошибкеКороткий ответ
Долгосрочный holdout — группа пользователей, намеренно не получающая накопленные со временем изменения продукта, чтобы можно было измерить совокупный долгосрочный эффект множества последовательных изменений, который невозможно увидеть в коротких отдельных A/B-тестах; размер и длительность holdout — всегда компромисс между качеством измерения и упущенной выгодой для пользователей в нём.
Как это работает подробнее
отдельные A/B-тесты измеряют эффект одного изменения на коротком горизонте, но не улавливают совокупный эффект десятков последовательных улучшений, их взаимодействие между собой, и отложенные эффекты на удержание и лояльность, которые проявляются только через месяцы; holdout-группа, не получающая изменений, даёт точку сравнения для такого совокупного эффекта.
Sanity check: ежемесячно сравнивать guardrail-метрики holdout-группы с остальной базой — если расхождение становится слишком большим и явно вредит пользователям раньше запланированного срока, предусмотренный план должен позволять досрочно завершить holdout.
Пример кода
Дизайн долгосрочного holdout:
- Размер: 2% пользователей, рандомизированных на уровне user_id при первом визите в квартале.
- Длительность: 6 месяцев, с ежемесячным мониторингом ключевых guardrail-метрик
(retention, жалобы) именно у holdout-группы, чтобы вовремя остановить эксперимент
при чрезмерном вреде.
- Исключение: критичные security- и compliance-изменения применяются ко всем, включая holdout.Что использовать на практике
- При проектировании holdout важно зафиксировать её размер исходя из ожидаемой величины совокупного эффекта (обычно он больше эффекта отдельного теста, поэтому holdout может быть меньше типичной тестовой группы), длительность (от нескольких месяцев до года, в зависимости от скорости релизов), и явные правила обновления состава (ротация участников holdout, чтобы не удерживать одних и тех же пользователей от всех улучшений слишком долго, если это создаёт для них заметно худший опыт). Нужно также заранее продумать, что произойдёт с holdout-группой в конце периода — постепенное "подтягивание" к актуальной версии продукта, а не резкое включение всех изменений разом.
Подводные камни
- Делать holdout слишком маленьким, из-за чего совокупный эффект невозможно статистически выявить с нужной мощностью
- Держать одних и тех же пользователей в holdout бесконечно долго, ухудшая их опыт без ограничения по времени и без информирования ответственных о связанных с этим рисках (отток, недовольство)
- Не учитывать, что за время существования holdout product team могла выпустить критичные с точки зрения безопасности/соответствия требованиям изменения, которые нельзя пропускать даже holdout-пользователям.