Что не так с A/B тестированием

Автор оригинала: MICHAEL KAMINSKY
  • Перевод


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


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


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


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


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


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


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


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


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


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


image


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


image


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


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


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


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


Задачи


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


Выводы


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


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


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

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

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

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

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

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

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

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

Комментарии 12

    0
    А АА/ВВ тестирование лучше?
      0
      Ниже написали, зачем нужны AA-тесты, это полезная штука, чтобы понять, вообще можно ли проводить AB-тест, насколько большой разброс и неоднородность, но ни как не помогает понять, какому пользователю что показывать и по какой ветке customer journey его вести.
      0

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

        0
        Автор статьи специально пропустил все технические аспекты проведения AB-тестов, в том числе AA-тесты, чтобы сконцентрироваться на рассмотрении идеи суперкастомных пользовательских сценариев, а в таких условиях AA-тесты никак не помогут.
        +2
        Что, если мы будем поддерживать оптимизированную мобильную версию для пользователей, которые заходят на сайт через телефон?


        А что если ресурсы есть только на то, чтобы поддерживать какую то одну версию? Вообще странная статья. Лично я так и не понял о чем она и зачем написана.
          0
          Статья о светлом будущем, когда разработка ПО будет позволять полностью индивидуализировать customer journey для каждого конкретного пользователя.
          0
          > Понятие A/B-тестирования основано на в корне неверном предположении, что существует
          > единственное решение, которое в среднем лучше для всех клиентов.

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

              А дальше идет математика на уровне арифметики. Поддержка двух решений стоит в два раза дороже, а если первое решение как-то удовлетворяет 80% пользователей, то второе будет давать 16%, третье 3.2% и чем больше тем меньше отдача.

              Разумеется я упрощаю, но и в статье упрощения.
                0
                Когда технология позволяет, мы добираемся до длинного хвоста распределения пользователей и придумываем, как на нем заработать.
                Штука в том, что одно решение удовлетворяет далеко не 80% пользователей и далеко не в лучшей степени.
                Конечно Netflix мог тоже продолжать всем пользователям рекомендовать одно и то же, те же блокбастеры, которые удовлетворяют 80% пользователей, но вместо этого они сделали персонализированные рекомендации и научились на этом зарабатывать гораздо больше.
                  +1
                  > Штука в том, что одно решение удовлетворяет далеко не 80% пользователей и
                  > далеко не в лучшей степени.

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

                  > Конечно Netflix мог тоже продолжать всем пользователям рекомендовать одно и то
                  > же, те же блокбастеры, которые удовлетворяют 80% пользователей

                  И netflix, и mcdonalds, и boeing, и ford, и apple, и много кто еще. Диверсификация — это способ работы с рисками и чаще всего является признаком того, что принимающий решение не уверен в нем. Недостаточно информации. И кстати A/B тестирование — способ исправить ситуацию малой кровью.

                  > но вместо этого они сделали персонализированные рекомендации и научились на
                  > этом зарабатывать гораздо больше.

                  Да сделали. Они сначала сделали решение, покрывающее потребности 80%, а затем, когда 16% стали достаточно серьезной суммой, чтобы перекрыть рассходы на поддержку — сделали второй шаг. Еще более глубокая кастомизация тоже может случиться, если a) netflix станет еще больше, причем значительно (что вряд ли) b) рынок станет еще более конкурентным и им придется внедрять такую поддержку себе в ущерб (дилемма заключенного). c) прогресс приведет к тому, что поддержка более глубокого ветвления станет дешевле (разработка и поддержка еще существенно подешевеют) — но это тоже вряд ли.
                    0
                    Ну вот вся статья как раз про твой пункт c) — потенциальное будущее, в котором будут для этого дешёвые готовые решения

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

          Самое читаемое