Ухудшающие A/B тесты – cамый недооцененный инструмент менеджера продукта

Давайте начнем с практической задачи.

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

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

Ухудшающие A/B тесты - инструмент продакт менеджер

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

Это одна из задач, с которой сталкиваются студенты, обучающиеся в Симуляторе. Через нее уже прошли более 100 человек, и 70% в ответе предложили ускорить приложение, а потом замерить эффект с помощью A/B теста.

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

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

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

Приведенный же пример с тестированием влияния скорости имеет реальный прототип – по ссылке результаты теста с замедлением скорости сайта, который провела команда Financial Times.

Замедлить приложение в Симуляторе предложили лишь 30% студентов (стоит отметить, что у них не было подсказки в виде названия статьи). В реальной работе доля тех, кто осмелился бы озвучить такое предложение, была бы значительно меньше, а доля тех, кто реально провел бы ухудшающий тест, стремилась бы к нулю.

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

 

Три стадии эволюции A/B тестирования в компаниях

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

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

Ухудшающие эксперименты — как раз один из способов снизить уровень неизвестности с помощью предварительно оценки потенциала влияния определенной составляющей продукта.

 

Примеры использования ухудшающих A/B тестов

В компании X верят, что пуши – драйвер Retention для приложения. Для большинства компаний такой веры вполне достаточно, чтобы принять решение о формировании выделенной команды, которая будет заниматься пушами. Но менеджмент компании X хочет убедиться, что это лучшее из возможных применений ресурсов, поэтому запускает ухудшающий эксперимент. Отключает пуши для части пользователей, чтобы замерить влияние уведомлений на ключевые метрики продукта.

Результаты такого теста дают базу для принятия взвешенного решения. Эксперимент покажет, каково влияние текущей реализации пуш нотификаций на ключевые метрики. Сделав предположение о том, насколько выделенная команда могла бы увеличить эффект, менеджмент сможет принять решение о целесообразности создания команды.

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

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

Предложение: если мы быстро не отвечаем пользователям в саппорте, то рискуем их потерять, поэтому нужно работать над снижением времени ответа, а для этого…
Способ проверки: сформировать несколько групп из клиентов, обращающихся в поддержку, которые будут получать ответы с разной скоростью. Оценить взаимосвязь времени ответа и ключевых метрик, на которые предположительно скорость реации саппорта должна влиять.

Предложение: мы получаем много жалоб на качество поиска нашего интернет-магазина. Мы должны выделить команду, которая будет на постоянной основе заниматься его развитием.
Способ проверки: убрать поиск и проверить, каково его влияние на ключевые метрики. Оценить, насколько команда сможет его улучшить, какой выигрыш это принесет, как он соотносится со стоимостью проекта и с тем, что могут дать другие инициативы.

Эксперименты – единственный способ проверить, является ли наблюдаемая корреляция в продукте причинно следственной связью или нет. Ухудшающие эксперименты — часто единственный способ сделать это дешево. Именно поэтому они так хорошо работают, когда дело доходит до приоритизации проектов.

 

Аргументы против ухудшающих A/B тестов

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

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

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

Либо же вы можете провести ряд ухудшающих экспериментов, испортив небольшой доле пользователей опыт в продукте на короткое время, но в результате повысить в разы вероятность правильного распределения ресурсов. И, в конечном итоге, сделать продукт лучше для всех пользователей, в том числе и для будущих.

 

Неумышленные ухудшающие A/B тесты

Если мои доводы не убедили вас начать умышленно использовать ухудшающие A/B тесты, то это не значит, что вы не можете извлечь из них пользу.

Все компании c определенной периодичностью запускают ухудшающие эксперименты. Преимущественно неумышленные, когда случайно ломают что-то в продукте.

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

 

История из личного опыта. Неумышленный ухудшающий эксперимент, который повлиял на стратегию развития продукта

В API.AI (теперь уже Dialogflow) я занимался развитием умного голосового ассистента Assistant.ai.

Это была очень сложная и нетривиальная продуктовая задача. Большинство сервисов строятся вокруг одной задачи, которую они хорошо решают. В случае же умных ассистентов ожидания пользователей столь разнообразны, что задачи выбора фокуса и дизайна опыта нового пользователя становятся практически нерешаемыми.

Наша изначальная стратегия сводилась к тому, чтобы выявить наиболее востребованные способности Ассистента и вынести их на первый план (тоже непростая задача для продукта, где дизайн строится не на визуальном, а на голосовом уровне). Подобный подход принес ряд небольших побед, но ввиду естественных ограничений (время первой сессии, голосовой интерфейс, разнообразие паттернов использования) имел конечный потециал.

Помощь пришла с неожиданной стороны и в неожиданном обличии. В один день ключевые продуктовые метрики обвалились на 20 процентов.

Расследование заняло день и осложнялось тем, что прямо перед падением мы выкатили новую версию. Как оказалось, апдейт отношения к провалу метрик не имел, дело было в изменениях в стороннем сервисе распознавания голоса от Google, который мы использовали на Android для некоторых языков.

Оказалось, что Google стал экспериментировать с разным временем паузы, на основе которой сервис распознавания голоса определял, что человек закончил говорить. Спад всех метрик произошел тогда, когда они резко сократили время слушания, в результате чего пользователи стали часто не успевать закончить фразу целиком.

Снижение качества одной из фундаментальных технологий, на которой строилось общение между пользователем и Ассистентом, привело к большему изменению метрик, чем какое-либо из сделанных нами изменений ранее.

Модель продукта после этого «ухудшающего эксперимента» кардинально изменилась. Если до в фокусе было то, что Ассистент умеет и как это преподносит, то после стало очевидно, что намного более мощными рычагами воздействия являются качество ключевых технологий, лежащий в основе коммуникации пользователя и продукта — распознавания голоса и NLU (Natural Language Understanding).

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

P.S. Если вы хотите научиться управлять продуктом на основе аналитики и данных, то Симулятор (новый образовательный продукт от Go Practice) вам в этом поможет.

Запись опубликована в рубрике Uncategorized, Аналитика. Добавьте в закладки постоянную ссылку.