Ухудшающий A/B тест

Предположим, что руководство компании хочет инвестировать значительные ресурсы в разработку инфраструктуры, необходимой для увеличение скорости работы приложения. Гипотеза состоит в том, что если продукт будет работать быстрее, то это позитивно повлияет на опыт пользователей и их ключевые метрики.

Наша задача: придумать эксперимент (A/B тест) для проверки этой гипотезы.

Большинство предложат ускорить приложение, а потом замерить эффект с помощью A/B теста.
Согласитесь, не самый экономный подход. Мы хотим проверить влияние скорости приложения на ключевые продуктовые метрики, как раз для того, чтобы понять, стоит ли вкладывать ресурсы в проект по ускорению приложения или нет.

Быстрый и дешевый способ проверить гипотезу – сделать ухудшающий эксперимент. В тестовой версии замедлить приложение (лучше сделать несколько тестовых групп с разной степенью замедления), чтобы узнать, есть ли негативное влияние от замедления или нет. Если есть, значит, скорость приложения влияет на ключевые метрики, и команде стоит оценить целесообразность инвестирования ресурсов в ускорение продукта на основе полученной зависимости. Если изменений нет, то и делать ничего не надо.

В реальной работе все немного сложнее, так как зависимости далеко не всегда линейны. Например, скорость продукта может быть уже настолько низкой, что ухудшение никак не повлияет на метрики. Но сути подхода это не меняет, а лишь показывает рамки его применимости, которые надо учитывать при дизайне и интерпретации результатов ухудшающих A/B тестов.

В компаниях без культуры экспериментов и работы с данными идея ухудшающего A/B теста вызовет шок и яростное сопротивление. Даже в компаниях, где данные уже стали частью процесса управления продукта, предложение провести ухудшающий эксперимент вполне может вызвать недоумение окружающих.