А/Б тестирование – один из основных инструментов продакт менеджмента, пока еще не придумали более надежного и дешевого способа достоверно оценить влияние одного конкретного изменения на бизнес-метрики продукта, изолировав его от всех остальных факторов.
В этой статье я хочу рассказать об альтернативном методе тестирования изменений в продукте: тестировании переплетением, в англоязычной литературе – interleaving testing. Чтобы раскрыть его достоинства и недостатки, мы будем частно сравнивать его с традиционным A/B тестом, но не потому что это какой-то новый более лучший способ, который быстрее и точнее, и должен заменить собой A/B тесты. Это дополнительный инструмент для менеджера продукта с другой областью применения и отвечающий на другой вопрос, сравнение просто позволяет легко показать, в чем отличия и сильные стороны переплетения.
Краткое содержание:
В многочисленных попытках донести до коллег и других менеджеров продукта основную идею переплетения, я пришла к тому что лучше всего ее иллюстрирует следующий пример. Уделите минуту тому, чтобы войти в контекст, я обещаю, что к концу примера вы согласитесь, что это очень наглядно.
Допустим нам нужно определить, какую газировку нужно предлагать в нашем баре, чтобы продавать как можно больше напитков: Кока-колу или Пепси. Если подойти к этому решению с точки зрения A/B тестирования, то мы должны открыть два абсолютно одинаковых бара в одном из которых будет только кола, в другом только пепси, и направлять посетителей в один из этих баров случайным образом.
Затем мы сравним, посетители какого из баров заказали больше доступного там напитка, и сделаем вывод о том, какой напиток обеспечивает большую выручку.
Я думаю, вы уже видите, в чем проблема: очень многие посетители того бара, где нет их любимого напитка все равно будут заказывать то, что дают, потому что они все равно хотят пить. И лишь очень немногие будут настолько принципиальны в своих предпочтениях, что не будут пить совсем или выпьют значительно меньше. Не очень принципиальные посетители снижают чувствительность нашего теста к предпочтениям относительно напитков, потому что они фактически не дадут нам никакого сигнала своим поведением.
Как решить ту же задачу методом переплетения? Если у нас есть физическая возможность предложить пользователям одновременно оба сравниваемых варианта и посмотреть, какой они предпочтут, мы сможем гораздо быстрее выявить их истинные предпочтения.
Если применить переплетение к нашей метафоре с баром, то мы поставим за стойкой два крана и просто посмотрим, какой из напитков больше заказывают посетители. Я думаю, вы интуитивно чувствуете, что этот тест гораздо быстрее выдаст нам значимый результат, потому что каждый заказ будет «голосом» в пользу одного или другого варианта, в то время как в A/B тесте только разница в количестве заказов является сигналом.
В статье в Netflix Tech Blog, приводятся данные о том, что переплетение в 100 раз быстрее A/B определяет предпочтения пользователей. Свой личный опыт использования переплетения я, к сожалению, не могу публиковать, но в моем случае эта оценка подтвердилась, переплетение при почти любом разумном трафике даст значимый результат меньше, чем за 24 часа. Однако, делать длительность теста меньше суток все равно не получится, поскольку нужно обеспечить репрезентативность выборки (утренние, дневные и вечерние посетители могут иметь разные паттерны поведения, недельные циклы позволим себе проигнорировать).
Изначально переплетение придумали для тестирования ранжирования: если у вас есть некоторый набор объектов (товары в интернет-магазине, или ссылки на страницы в интернете для поисковой системы) и вам нужно отсортировать их так, чтобы сверху оказались те, которые наиболее точно соответствуют запросу пользователя.
Если у вас есть два алгоритма ранжирования и вы хотите их сравнить, то можно не показывать пользователю либо ранжирование А, либо ранжирование Б, а показать ему страницу, которая будет выглядеть как:
A1 Б1 A2 Б2 A3 Б3… и так далее, где А2 – это вторая строка выданная алгоритмом ранжирования А, а Б3 – это третья строка в ранжирование Б.
Иллюстрация переплетения из статьи в Netflix Tech Blog
Мы направляем весь доступный трафик на это переплетенное ранжирование и считаем, результаты порожденные каким из двух алгоритмов получили больше кликов или позволили получить больше целевых действий ниже по воронке конверсии.
На самом деле элементов, которые фактически являются результатом ранжирования, в продуктах очень много, приведу примеры:
И все эти элементы можно и нужно тестировать с помощью переплетения. Переплетение позволяет вам тестировать не один альтернативный алгоритм подбора рекомендаций за неделю, а проверять семь гипотез за неделю.
Когда мы проводим A/B тест мы можем измерить влияние изменения пользовательского опыта на любую интересующую нас метрику, которую мы считаем в разрезе одного пользователя. От конверсии в продажу до количества обращений в службу поддержки.
Тест переплетением позволяет нам сравнивать только те события, которые напрямую можно связать с кликом на один из переплетенных вариантов. Но это сравнение не позволяет отвечать на вопрос «что будет если в нашем продукте мы заменим А на Б», потому что не знаем, что будет, если пользователь будет видеть только ранжирование Б. Мы производили измерение на комбинации, которая не является самостоятельным вариантом пользовательского опыта.
Поэтому переплетение рекомендуется применять как предварительный этап для отбора наиболее перспективной из множества гипотез, для которой уже имеет смысл провести более длительный A/B тест, чтобы проверить, как это изменение влияет на целевую метрику.
Очень часто может оказаться, что на бизнес метрику улучшение алгоритма никак не повлияло, но как минимум вы уверены, что опыт пользователей стал лучше, а еще теперь вы знаете какой блок скорее всего бессмысленно оптимизировать в попытках улучшить ту метрику, которая является для вас целевой.
Давайте подведем краткий итог плюсам и минусам теста переплетением.
В этой статье я хочу рассказать об альтернативном методе тестирования изменений в продукте: тестировании переплетением, в англоязычной литературе – interleaving testing. Чтобы раскрыть его достоинства и недостатки, мы будем частно сравнивать его с традиционным A/B тестом, но не потому что это какой-то новый более лучший способ, который быстрее и точнее, и должен заменить собой A/B тесты. Это дополнительный инструмент для менеджера продукта с другой областью применения и отвечающий на другой вопрос, сравнение просто позволяет легко показать, в чем отличия и сильные стороны переплетения.
Краткое содержание:
- Почему переплетение быстрее A/B теста
- Когда можно применять тест переплетением
- В чем отличие результатов A/B теста и переплетения
- Как комбинировать сильные стороны переплетения и A/B теста
Почему тестирование переплетением гораздо быстрее A/B тестирования
В многочисленных попытках донести до коллег и других менеджеров продукта основную идею переплетения, я пришла к тому что лучше всего ее иллюстрирует следующий пример. Уделите минуту тому, чтобы войти в контекст, я обещаю, что к концу примера вы согласитесь, что это очень наглядно.
Допустим нам нужно определить, какую газировку нужно предлагать в нашем баре, чтобы продавать как можно больше напитков: Кока-колу или Пепси. Если подойти к этому решению с точки зрения A/B тестирования, то мы должны открыть два абсолютно одинаковых бара в одном из которых будет только кола, в другом только пепси, и направлять посетителей в один из этих баров случайным образом.
Затем мы сравним, посетители какого из баров заказали больше доступного там напитка, и сделаем вывод о том, какой напиток обеспечивает большую выручку.
Я думаю, вы уже видите, в чем проблема: очень многие посетители того бара, где нет их любимого напитка все равно будут заказывать то, что дают, потому что они все равно хотят пить. И лишь очень немногие будут настолько принципиальны в своих предпочтениях, что не будут пить совсем или выпьют значительно меньше. Не очень принципиальные посетители снижают чувствительность нашего теста к предпочтениям относительно напитков, потому что они фактически не дадут нам никакого сигнала своим поведением.
Как решить ту же задачу методом переплетения? Если у нас есть физическая возможность предложить пользователям одновременно оба сравниваемых варианта и посмотреть, какой они предпочтут, мы сможем гораздо быстрее выявить их истинные предпочтения.
Если применить переплетение к нашей метафоре с баром, то мы поставим за стойкой два крана и просто посмотрим, какой из напитков больше заказывают посетители. Я думаю, вы интуитивно чувствуете, что этот тест гораздо быстрее выдаст нам значимый результат, потому что каждый заказ будет «голосом» в пользу одного или другого варианта, в то время как в A/B тесте только разница в количестве заказов является сигналом.
В статье в Netflix Tech Blog, приводятся данные о том, что переплетение в 100 раз быстрее A/B определяет предпочтения пользователей. Свой личный опыт использования переплетения я, к сожалению, не могу публиковать, но в моем случае эта оценка подтвердилась, переплетение при почти любом разумном трафике даст значимый результат меньше, чем за 24 часа. Однако, делать длительность теста меньше суток все равно не получится, поскольку нужно обеспечить репрезентативность выборки (утренние, дневные и вечерние посетители могут иметь разные паттерны поведения, недельные циклы позволим себе проигнорировать).
Когда можно применить переплетение
Изначально переплетение придумали для тестирования ранжирования: если у вас есть некоторый набор объектов (товары в интернет-магазине, или ссылки на страницы в интернете для поисковой системы) и вам нужно отсортировать их так, чтобы сверху оказались те, которые наиболее точно соответствуют запросу пользователя.
Если у вас есть два алгоритма ранжирования и вы хотите их сравнить, то можно не показывать пользователю либо ранжирование А, либо ранжирование Б, а показать ему страницу, которая будет выглядеть как:
A1 Б1 A2 Б2 A3 Б3… и так далее, где А2 – это вторая строка выданная алгоритмом ранжирования А, а Б3 – это третья строка в ранжирование Б.
Иллюстрация переплетения из статьи в Netflix Tech BlogТонкости реализации
Я позволю себе оставить за скобкой несколько технических проблем:
- Очевидно надо каждый раз случайным образом определять, какое из ранжирование идет первым, чтобы они были в равном положении
- Нужно решить проблему повторных результатов: что если оба алгоритма выдали один и тот же результат, но на разных позициях?
- Из теста нужно исключать случаи, когда оба ранжирования вернули очень близкие или одинаковые результаты
- Чтобы посчитать статистическую значимость разницы полученных кликов, понадобятся более хитрые тесты, чем обычно применяются для интерпретации результатов A/B
Мы направляем весь доступный трафик на это переплетенное ранжирование и считаем, результаты порожденные каким из двух алгоритмов получили больше кликов или позволили получить больше целевых действий ниже по воронке конверсии.
На самом деле элементов, которые фактически являются результатом ранжирования, в продуктах очень много, приведу примеры:
- Список товаров или каталог разделов на главной странице сайта
- Список товаров внутри раздела или в ответ на поисковый запрос
- Список статей на новостном ресурсе
- «Похожие объявления»
- «С этим товаром также покупают»
- Статьи в разделе «Помощь»
- Любое перечисление элементов: друзья в соц. сети, посты в ленте, музыка на странице, фильмы в кинотеатре
- и так далее
И все эти элементы можно и нужно тестировать с помощью переплетения. Переплетение позволяет вам тестировать не один альтернативный алгоритм подбора рекомендаций за неделю, а проверять семь гипотез за неделю.
В чем разница результатов A/B теста и теста переплетением
Когда мы проводим A/B тест мы можем измерить влияние изменения пользовательского опыта на любую интересующую нас метрику, которую мы считаем в разрезе одного пользователя. От конверсии в продажу до количества обращений в службу поддержки.
Тест переплетением позволяет нам сравнивать только те события, которые напрямую можно связать с кликом на один из переплетенных вариантов. Но это сравнение не позволяет отвечать на вопрос «что будет если в нашем продукте мы заменим А на Б», потому что не знаем, что будет, если пользователь будет видеть только ранжирование Б. Мы производили измерение на комбинации, которая не является самостоятельным вариантом пользовательского опыта.
Поэтому переплетение рекомендуется применять как предварительный этап для отбора наиболее перспективной из множества гипотез, для которой уже имеет смысл провести более длительный A/B тест, чтобы проверить, как это изменение влияет на целевую метрику.
Очень часто может оказаться, что на бизнес метрику улучшение алгоритма никак не повлияло, но как минимум вы уверены, что опыт пользователей стал лучше, а еще теперь вы знаете какой блок скорее всего бессмысленно оптимизировать в попытках улучшить ту метрику, которая является для вас целевой.
Сильные и слабые стороны переплетения
Давайте подведем краткий итог плюсам и минусам теста переплетением.
Минусы
- К сожалению, переплетение на дает нам ответа на один из основных вопросов тестирования: как изменится такая-то бизнес-метрика если мы заменим A на Б. Он отвечает на вопрос, что более предпочтительно для пользователя, А или Б, а это далеко не всегда связанные вещи.
- Чтобы запрограммировать и провести тест переплетением, нужно гораздо больше усилий, чем для того, чтобы просто создать альтернативную версию пользовательского опыта и запустить A/B тест.
- Поскольку в переплетении у нас будет причудливая смесь из двух вариантов А и Б, то иногда их комбинация может создавать неожиданные артефакты, например Б настолько плох, что на его фоне все активно выбирают А, хотя на самом деле А ничем не примечателен.
Плюсы
- Переплетение можно делать только если есть физическая возможность предложить сразу два сравниваемых варианта в какой-то комбинации (на самом деле таких случаев больше, чем кажется, см. следующий раздел).
- Переплетение гораздо чувствительнее к предпочтениям пользователей (по оценке Netflix оно способно в 100 раз быстрее определить, какой из вариантов предпочтительнее для пользователя).
- Переплетение несколько снижает риски при тестировании. Даже если альтернативный вариант, который мы тестируем, очень плох, за счет того, что мы «переплели» его с заведомо рабочим вариантом, у пользователя всегда останутся нормальные опции.
Материалы по теме
- Статья в блоге Netflix, где в частности приводятся данные о том, что переплетение в 100 раз быстрее A/B определяет предпочтения пользователей
- Более научная статья с описанием стат. методов необходимых для интерпретации результатов тестов переплетением (Chapelle, O., Joachims, T., Radlinski, F., and Yue, Y. 2012. Large-scale validation and analysis of interleaved search evaluation. ACM Trans. Inf. Syst. 30, 1, Article 6 (February 2012)
