Давайте начнем с практической задачи.
Руководство компании хочет инвестировать значительные ресурсы в разработку инфраструктуры, необходимой для увеличения скорости работы приложения. Гипотеза состоит в том, что если продукт будет работать быстрее, то это позитивно повлияет на опыт пользователей и ключевые метрики продукта.
Придумайте эксперимент (A/B-тест) для проверки этой гипотезы.
Ухудшающие A/B тесты
Это одна из задач, с которой сталкиваются студенты, обучающиеся в «Симуляторе управления продуктом на основе данных». Около 70% студентов из тестовой группы на запуске симулятора выбрали вариант ускорить приложение.
Согласитесь, не самый экономный подход. Мы хотим проверить, как скорость приложения повлияет на ключевые продуктовые метрики, чтобы понять, стоит ли вкладывать ресурсы в проект по ускорению приложения или нет.
Гораздо быстрее и дешевле проверить эту гипотезу можно через ухудшающий эксперимент. Для этого в тестовой версии можно замедлить приложение (в идеале — сделать несколько тестовых групп с разной степенью замедления) и оценить негативное влияние от него. Если оно есть, значит, скорость приложения влияет на ключевые метрики, и команде стоит оценить целесообразность инвестирования ресурсов в ускорение продукта на основе полученной зависимости. Если изменений нет, то и делать ничего не надо.
В реальной работе все немного сложнее, так как зависимости далеко не всегда линейны. Например, скорость продукта может быть уже настолько низкой, что ухудшение никак не повлияет на метрики. Но сути подхода это не меняет, а лишь показывает рамки его применимости, которые надо учитывать при дизайне и интерпретации результатов ухудшающих A/B тестов.
Приведенный же пример с тестированием влияния скорости имеет реальный прототип — по результаты теста с замедлением скорости сайта, который провела команда газеты Financial Times.
