Давайте начнем с практической задачи.
Руководство компании хочет инвестировать значительные ресурсы в разработку инфраструктуры, необходимой для увеличения скорости работы приложения. Гипотеза состоит в том, что если продукт будет работать быстрее, то это позитивно повлияет на опыт пользователей и ключевые метрики продукта.
Придумайте эксперимент (A/B-тест) для проверки этой гипотезы.
Ухудшающие A/B тесты
Это одна из задач, с которой сталкиваются студенты, обучающиеся в «Симуляторе управления продуктом на основе данных». Около 70% студентов из тестовой группы на запуске симулятора выбрали вариант ускорить приложение.
Согласитесь, не самый экономный подход. Мы хотим проверить, как скорость приложения повлияет на ключевые продуктовые метрики, чтобы понять, стоит ли вкладывать ресурсы в проект по ускорению приложения или нет.
Гораздо быстрее и дешевле проверить эту гипотезу можно через ухудшающий эксперимент. Для этого в тестовой версии можно замедлить приложение (в идеале — сделать несколько тестовых групп с разной степенью замедления) и оценить негативное влияние от него. Если оно есть, значит, скорость приложения влияет на ключевые метрики, и команде стоит оценить целесообразность инвестирования ресурсов в ускорение продукта на основе полученной зависимости. Если изменений нет, то и делать ничего не надо.
В реальной работе все немного сложнее, так как зависимости далеко не всегда линейны. Например, скорость продукта может быть уже настолько низкой, что ухудшение никак не повлияет на метрики. Но сути подхода это не меняет, а лишь показывает рамки его применимости, которые надо учитывать при дизайне и интерпретации результатов ухудшающих A/B тестов.
Приведенный же пример с тестированием влияния скорости имеет реальный прототип — по результаты теста с замедлением скорости сайта, который провела команда газеты Financial Times.
Замедлить приложение в симуляторе предложили лишь 30% студентов. Но в реальной работе доля тех, кто осмелился бы озвучить такое предложение, была бы значительно меньше, а доля тех, кто реально провел бы ухудшающий тест, стремилась бы к нулю.
В компаниях с неразвитой культурой экспериментов и работы с данными идея ухудшающего A/B теста, вероятно, может вызвать шок. Даже в компаниях, где данные уже стали частью процесса управления продуктом, предложение провести ухудшающий эксперимент вполне может вызвать недоумение окружающих.
Три стадии эволюции A/B тестирования в компаниях
Для большинства компаний A/B тесты — это теоретическая концепция, которая не имеет отношения к реальной работе. В некоторых компаниях эксперименты используются для изучения влияния сделанных изменений на ключевые метрики. И лишь совсем небольшая доля компаний применяет A/B тесты для определения вектора развития продукта.
Эксперименты позволяют понять, что является рычагом воздействия на продукт, а что нет, измерить, насколько велик потенциал каждого из рычагов. Без этой информации приоритизация ресурсов и проектов больше похожа на гадание, чем на взвешенный рациональный процесс.
Ухудшающие эксперименты — один из способов снизить уровень неизвестности с помощью предварительной оценки потенциала того, насколько сильно определенная составляющая продукта влияет на его ключевые метрики.
Примеры использования ухудшающих A/B тестов
В компании X верят, что пуши — драйвер Retention для приложения. Для большинства компаний такой веры вполне достаточно, чтобы принять решение о формировании выделенной команды, которая будет заниматься пушами. Но менеджмент компании X хочет убедиться, что это лучшее из возможных применений ресурсов, поэтому запускает ухудшающий эксперимент: отключает пуши для части пользователей, чтобы замерить влияние уведомлений на ключевые метрики продукта.
Результаты такого теста дают базу для принятия взвешенного решения. Эксперимент покажет, каково влияние текущей реализации пуш-нотификаций на ключевые метрики. Сделав предположение о том, насколько выделенная команда могла бы увеличить эффект, менеджмент сможет принять решение о целесообразности создания выделенной команды.
Подобный подход применим ко многим предложениям, которые на первый взгляд могут показаться очевидными способами улучшения метрик и опыта пользователей, но далеко не всегда такими являются.
Предложение: нам нужно добавлять больше новых уровней, так как это ядро игры, от которого зависит все остальное.
Способ проверки: убрать часть имеющихся уровней для половины новых пользователей и проверить влияние дополнительного контента на ключевые метрики.
Предложение: если мы быстро не отвечаем пользователям в саппорте, то рискуем их потерять, поэтому нужно работать над снижением времени ответа, а для этого…
Способ проверки: сформировать несколько групп из клиентов, обращающихся в поддержку, которые будут получать ответы с разной скоростью. Затем оценить взаимосвязь времени ответа и ключевых метрик, на которые, как мы полагаем, должна повлиять скорость реакции поддержки.
Предложение: мы получаем много жалоб на качество поиска нашего интернет-магазина. Мы должны выделить команду, которая будет на постоянной основе заниматься его развитием.
Способ проверки: убрать поиск и проверить, каково его влияние на ключевые метрики. Оценить, насколько команда сможет его улучшить, какой выигрыш это принесет, как он соотносится со стоимостью проекта и с тем, что могут дать другие инициативы.
Эксперименты — единственный способ проверить, является ли наблюдаемая корреляция в продукте причинно-следственной связью или нет. Ухудшающие эксперименты — часто единственный способ сделать это дешево. Именно поэтому они так хорошо работают, когда необходимо приоритизировать проекты.
Аргументы против ухудшающих A/B тестов
Аргументы против ухудшающих A/B тестов обычно сводятся к тому, что такие эксперименты портят опыт пользователей, увеличивают отток, приводят к негативному фидбеку, плохо влияют на бренд.
Мой опыт показывает, что такие опасения сильно преувеличены. Уверен, вы удивитесь, как часто ухудшающие тесты не окажут никакого значимого влияния на продукт (и это очень важное знание).
Но даже если негативное влияние будет, то посмотрите на этот вопрос с другой стороны. У вас есть ограниченные ресурсы, и вы можете распределить их между проектами вслепую (или почти вслепую, то есть на основе ваших текущих представлений о продукте). В этом случае вы с вероятностью X улучшите опыт пользователей в продукте спустя несколько месяцев.
Либо же вы можете провести ряд ухудшающих экспериментов, испортив небольшой доле пользователей опыт в продукте на короткое время, но в результате повысить в разы вероятность правильного распределения ресурсов. В конечном итоге это позволит сделать продукт лучше для всех пользователей, в том числе и для будущих.
Неумышленные ухудшающие A/B тесты
Все компании c определенной периодичностью запускают ухудшающие эксперименты. Преимущественно неумышленные, когда случайно ломают что-то в продукте.
Но в следующий раз, когда подобное случится, бросьте силы не только на срочное исправление ситуации, но и на изучение влияния негативного изменения на метрики. Так ущерб от поломки может с лихвой компенсироваться нахождением нового рычага воздействия на продукт.
История из личного опыта. Неумышленный ухудшающий эксперимент, который повлиял на стратегию развития продукта
В API.AI (теперь Dialogflow) я занимался развитием умного голосового ассистента Assistant.ai.
Это была очень сложная и нетривиальная продуктовая задача. Большинство сервисов строятся вокруг одной задачи, которую они хорошо решают. В случае же умных ассистентов ожидания пользователей столь разнообразны, что задачи выбора фокуса и дизайна опыта нового пользователя становятся практически нерешаемыми.
Изначальная стратегия сводилась к тому, чтобы выявить наиболее востребованные способности Ассистента и вынести их на первый план. Это сама по себе непростая задача для продукта, где дизайн интерфейса не визуальный, а голосовой. Подобный подход принес ряд небольших побед, но ввиду естественных ограничений (время первой сессии, голосовой интерфейс, разнообразие паттернов использования) имел конечный потенциал.
Помощь пришла с неожиданной стороны. В один день ключевые продуктовые метрики обвалились на 20%.
Расследование заняло день и осложнялось тем, что прямо перед падением мы выкатили новую версию. Как оказалось, апдейт не имел отношения к провалу метрик. Все дело было в изменениях в стороннем сервисе распознавания голоса от Google, который мы использовали на Android для некоторых языков.
Оказалось, что Google стал экспериментировать с разным временем паузы, на основе которой сервис распознавания голоса определял, что человек закончил говорить. Метрики провалились тогда, когда в Google резко сократили время слушания, в результате чего пользователи часто не успевали закончить фразу целиком.
Снижение качества одной из фундаментальных технологий, на которой строилось общение между пользователем и Ассистентом, привело к большему изменению метрик, чем какое-либо из сделанных нами изменений ранее.
Модель продукта после этого «ухудшающего эксперимента» кардинально изменилась. Если прежде мы фокусировались на навыках Ассистента и их донесении до пользователя, то после стало очевидно, что намного более мощным рычагом воздействия является качество ключевых технологий, лежащих в основе коммуникации пользователя и продукта, то есть распознавания голоса и NLU (Natural Language Understanding).
Так мы получили важное знание для правильной расстановки приоритетов в работе над продуктом. Знание, которое было получено в результате неумышленного ухудшающего эксперимента.
Если вы хотите глубже разобраться в том, как создаются, развиваются и масштабируются продукты, пройдите обучение в симуляторах GoPractice.
→ «Симулятор управления продуктом на основе данных» поможет научиться принимать решения с помощью данных и исследований при создании продукта (путь от 0 к 1).
→ «Симулятор управления ростом продукта» поможет найти пути управляемого роста и масштабирования продукта. Вы построите модель роста и составите стратегию развития продукта (путь от 1 к N).
→ «Симулятор SQL для продуктовой аналитики» поможет освоить SQL и применять его для решения продуктовых и маркетинговых задач.
→ «Симулятор управления ML/AI-проектами» научит применять технологии машинного обучения с пользой для бизнеса.
Не знаете с чего начать? Пройдите бесплатный тест для оценки навыков управления продуктом. Вы определите свои сильные стороны и слепые зоны, получите план профессионального развития.
Еще больше ценных материалов и инсайтов — в телеграм-канале .
