Мы подготовили для читателей Хабры перевод статьи Майкла Камински, бывшего директора по аналитике в Harry’s. Он рассуждает о том, что не так с A/B тестированием. Комментирует материал Глеб Сологуб, директор по аналитике Skyeng.

Понятие A/B-тестирования основано на в корне неверном предположении, что существует единственное решение, которое в среднем лучше для всех клиентов. Аналитикам стоит отказаться от предположения об однородности их аудитории и начать разрабатывать системы, которые позволяют использовать (и поощряют) результаты иных тестов, кроме бинарных.

За последние несколько недель были опубликованы две очень интересные статьи о нестандартных интерпретациях A/B-тестов. Одна из статей, из инженерного блога Uber, — о расчете эффекта воздействия по квантилям, а другая (из неизменно превосходного блога StitchFix о Data Science) — об использовании контекстных алгоритмов бандита для достижения персонализации.

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

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

К сожалению, применить такой подход к тестированию, оптимизации и разработке ПО непросто. Это требует новых статистических инструментов, новых инструментов разработки и поддержки программных решений, а также обучения заинтересованных лиц, если вы хотите, чтобы они тоже были вовлечены в процесс. В данной статье я приведу мотивирующий пример, а затем расскажу о некоторых проблемах, с которыми придется столкнуться при создании систем, которые адаптируются к новой действительности. Я не буду обсуждать статистические данные, лежащие в основе и связанные с построением данных типов систем (лучше почитайте статью StitchFix и эту статью от Google), но расскажу о возможностях, которые я вижу, на стратегическом и архитектурном уровнях.

Мотивирующий пример

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

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

Команда запускает тестирование и получает следующие результаты:

Черт побери, разницы нет! Интуитивно вы решаете разделить трафик на мобильный и ПК.

Вау! Новая версия… продемонстрировала ровно то, чего ожидали дизайнеры! Ситуация стала лучше для пользователей мобильных устройств и хуже — для пользователей ПК.

Плохо, что наш А/В тест не показал никакого эффекта. Возможно, нам стоит отправить наших дизайнеров думать над новой версией формы заказа.

Но подождите! Что, если мы будем поддерживать оптимизированную мобильную версию для пользователей, которые заходят на сайт через телефон? А оптимизированную десктопную версию — для пользователей за стационарными компьютерами? Что, если бы мы создали лендинг, который будет лучше работать по выходным, когда у людей больше времени читать? Что, если бы мы создали рекламу, которая будет работать лучше в Калифорнии, а не в штате Массачусетс?

Что, если веб-страница не должна подходить всем сразу?

Задачи

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

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

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

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

Инструменты программирования

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

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

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

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

Наконец, без единого, целостного сценария использования нам нужны инструменты, чтобы менеджеры по продуктам и дизайнеры могли представить себе путь клиента в саду расходящихся тропок. Как мы представляем и оцениваем новые функции? Как мы проследим, какие шаги данный пользователь прошёл, когда он использовал наше приложение? Как мы можем предотвратить превращение приложения в бесформенную массу спагетти-кода?

Коммуникации и обучение

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

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

Статистические инструменты

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

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

Выводы

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

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

Комментарий от Глеба Сологуба, директора по аналитике Skyeng

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

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

Так, у Skyeng конечно же есть оптимизированные мобильные версии сайта и учебной платформы, а также различные варианты этих продуктов для пользователей разных возрастов. Кроме того, мы провели AB-тесты и поняли, что пользователи из разных регионов имеют разные потребности, после чего ввели дифференциацию маркетингового описания в зависимости от региона.

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

Однако всё это удаётся сделать, продолжая использовать старые методы разработки и аналитики.

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

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