A/A тестирование  — способ проверить корректность работы механизма A/B-тестирования | Урок 2

Задача A/A тестирования — убедиться, что система, в которой мы проводим эксперименты, работает правильно. В этой статьей мы рассмотрим несколько нюансов, с которыми вы можете столкнуться в процессе тестирования.

← Предыдущий урок

Авторы английской версии: Дэвид Стейнберг, профессор, KPA Group; Рон Кенет, профессор, KPA Group

Вы читаете перевод бесплатного курса по A/B тестированию от компании Dynamic Yield. Над переводом работали Оля Жолудова и Ринат Шайхутдинов. При поддержке koptelnya.ru.

Коптельня — команда по быстрой разработке веб-приложений и сайтов.

(Если вы здесь впервые, то лучше начните сначала)

Клиентский опыт (customer experience), который по сути является отражением всех отношений между брендом и клиентом, складывается из множества взаимодействий через самые разные каналы и точки контакта. Поэтому неудивительно, что компании вкладывают столько усилий в проработку этих взаимодействий — ведь они хотят привлечь больше клиентов.

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

Есть один эффективный, основанный на данных метод проверки подобных идей — A/B тестирование. Суть этого метода проста: мы сравниваем две версии страницы, показывая одну версию одним посетителям, а другую — другим, и потом оцениваем результаты.

Распределение пользователей между двумя вариациями контента происходит случайным образом. Это, согласно общепринятым научным принципам, позволяет обеспечить “чистоту эксперимента”. Далее мы анализируем поведение пользователей посредством различных KPI, таких как коэффициент кликабельности (click-through rate, CTR), коэффициент конверсии (conversion rate, CR) или доход (revenue). Мы сравниваем средние KPI каждой вариации и принимаем решение. То есть по сути в A/B тестировании решение принимают сами клиенты и их поведение — и нам не нужно полагаться на интуицию. Ведь клиент, как гласит одна старая пословица, всегда прав 😉

Но, хотя принцип работы A/B тестирования звучит очень просто, при более детальной работе с методом, возникает ряд вопросов, которые мы и рассмотрим в этой статье:

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

Для подведения итогов по собранным данным мы рассчитываем вероятность того, что одна версия лучше другой или, как это называют в experience-агентстве Dynamic Yield, показатель P2BB — Probability to Be Best. (Вот еще статья по этой теме от Академии Яндекса). Это простая статистическая величина, которая показывает вероятность того, что B — это лучший вариант, то есть у него самые большие KPI среди посетителей вашего сайта. К примеру, если P2BB для B составляет 0,8, то вероятность того, что B — лучшая опция для рассматриваемого сценария составляет 80%. Вероятность того, что A — лучшая опция соответственно составляет 20%. Показатель P2BB (вероятность, что одна опция лучше другой) — это идеальная основа для принятия бизнес-решений по результатам A/B тестирования.

Как вычислить P2BB?

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

Раньше человечество волновали вопросы типа “какова вероятность, что завтра встанет солнце?” Тогда многие задумывались, есть ли вообще смысл рассуждать о подобных вещах в контексте вероятностей. Идея подвергнуть априорную информацию байесовскому анализу часто считалась выражением субъективности.

Байесовский подход отличается от классического частотного, который вы, скорее всего, проходили на вводном курсе статистики: где либо А лучше B, либо B лучше А, либо А и B идентичны. Вопрос “какова вероятность, что B лучше” вообще не стоит: ответить на него нельзя, более того, и сам вопрос нельзя задавать!

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

Байесовский подход приводит все к общему знаменателю, обобщая вероятности. По итогу A/B теста мы получим описания вероятностей в свете того, что мы знаем о KPI по А и KPI по B. Объединив эти два распределения, мы сможем высчитать P2BB.

Еще одно преимущество P2BB в том, что метод легко растягивается на тесты с более чем двумя вариантами. В конце эксперимента мы можем высчитать P2BB каждого из этих вариантов. Для явных победителей P2BB будет близок к 1. P2BB явных лузеров будет ближе к 0. Возможно, у вас будет два похожих варианта, которые явно лидируют. В этом случае, P2BB каждого из лидеров будет где-то около 0,5.

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

Вот что может пойти не так:

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

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

К примеру, онлайн-торговля подвержена разным сезонным колебаниям данных. В отдельные часы или дни недели может наблюдаться необычная активность или затишье. В этом случае нужно убедиться, что (i) мы включили в эксперимент хотя бы один полный временной цикл, и что (ii) механизм случайного распределения корректно работает на протяжении всего цикла. Еще один пример: часть трафика может приходить с компьютеров, а другая часть — с телефонов. Нужно убедиться, что в эксперимент включены пользователи как компьютеров, так и смартфонов.

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

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

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

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

Поэтому нужно продумать, сколько вы намерены крутить A/A тест и сколько A/A тестов нужно провести, прежде чем вы сможете двигаться дальше.

А хорошее мерило мы вам уже предложили: Probability to Be Best (P2BB). Этот показатель учитывает вариативность данных. Важно также сравнивать между собой средние KPI. Поскольку вы сравниваете опыт с самим собой, и показатели KPI должны быть близки по значению. Также обратите внимание на долю трафика, направленную на каждый вариант. Распределение должно быть примерно по 50% на каждый. Если у вас не так — это тревожный сигнал.

Хотя P2BB — отличный способ подытожить выводы, полученные в ходе эксперимента, есть несколько нюансов, с которыми нужно быть начеку:

Во-первых, данные по своей природе изменчивы. P2BB зависит от данных, поэтому это тоже переменная величина. Следовательно, по результатам A/A теста вполне вероятно получить P2BB близкое к 0 или к 1, несмотря на то, что разницы между вариантами нет. От таких случайностей не застрахован ни один A/B тест.

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

В-третьих, не увлекайтесь проверками. Механизмы тестирования позволяют отслеживать результаты эксперимента. И, естественно, вы будете регулярно проверять, не наметился ли победитель. P2BB в течение эксперимента будет меняться, отражая поведение и предпочтения посетителей сайта. Если в процессе двухнедельного A/A теста вы будете проверять “текущий P2BB” каждый час, у вас на руках будет более 300 значений P2BB. Некоторые из них будут близки к 1, другие — к 0. Очень частая (но опасная практика) — останавливать тест, как только P2BB дойдет до определенного порога (скажем, упадет ниже 0,05 или скакнет выше 0,95). Почему это опасно? Потому что нет ничего удивительного в том, что каждый час будут наблюдаться крайние величины P2BB, которые выходят за обозначенные вами границы. К примеру, финальный P2BB будет составлять менее 0,05 примерно в 5% всех ваших A/A тестов. А вероятность увидеть такую величину P2BB в процессе теста — в разы выше. Если будете подглядывать — можете выбрать не того победителя. Для оценки механизма тестирования следует опираться только на финальный P2BB и в совокупности со средними KPI.

И наконец, если вы хотите тщательно проверить механизм тестирования, проведите несколько A/A тестов. Все мы знаем, как опасно делать заключения, опираясь только на результат 1. Значения итоговых P2BB должны “распределиться” между 0 и 1.

В ситуациях когда из-за большого объема данных наблюдаются крайние значения P2BB на фоне относительно небольшой разницы в средних KPI, бывает полезно провести более детальный анализ, чтобы обозначить уровень влияния сравнения на бизнес-результаты. Как вариант, можно определить минимальную критическую разницу в KPI, которая будет весома для бизнеса. К примеру, вы можете договориться, что если разница в KPI двух вариантов менее 0,5%, смысла в изменении нет. В таком случае, можно применить байесовский анализ, чтобы разбить результаты A/B тестирования на три четких сценария: (1) вариант B лучше, (2) вариант B хуже и (3) В такой же, как и A (или разница ниже критической границы). При проведении A/A тестов, вероятность выпадения последнего сценария выше, чем первых двух, что как раз означает, что значимой разницы между тестируемыми вариантами нет.

Также следует помнить, что добавление нескольких вариантов для сравнения — например когда тест не A/B, а A против B1, B2, B3, B4 и т.д. — создает дополнительную сложность. Таким образом, если у вас есть A и четыре варианта, нам нужно показать, какой из них лучше, потом — что они лучше A, и потом уже выбрать двух лидеров. Провести дополнительное тестирование не сложно, но когда дойдет до внедрения этих альтернатив, дизайн и анализ комбинаций потребуют гораздо больше ресурсов.

Вся суть A/A теста в том, чтобы сделать тестовый прогон системы. Мы хотим убедиться, что трафик распределяется поровну между вариантами, и при этом KPI не сильно отличаются — а показатель P2BB не выявляет четкого лидера.

Размер выборки будет зависеть от нескольких факторов:

Ниже мы поговорим про каждый пункт и рассмотрим примеры.

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

В этом случае, мы предлагаем принимать за достаточный результат уровень важности наблюдаемых изменений. К примеру, если у вас KPI 0,010, 10-процентное улучшение (до уровня 0,011) можно установить в качестве порогового. Если ваш средний доход составляет 1$ на посетителя, то рост этого показателя всего на 3% (с 1$ до 1,03$) может оказаться значительным.

Самое простой способ — спросить себя “какой порядок улучшений мы точно хотели бы зафиксировать?” Степень вариативности также играет важную роль, если мы говорим о непрерывных KPI. Обычно нас устраивает нормальное отклонение от результата среди посетителей-конвертеров.

Стоит отметить, что те же вводные применимы и к A/B тесту и они используются по сути так же. Но есть один принципиальный момент — цель A/B тестирования состоит в том, чтобы обнаружить различие, поэтому нам важно убедиться, что различие будет достаточно значимым для нас. Наращивая объем выборки, мы постепенно сужаем фокус. А вот в случае с A/A тестированием, цель состоит в том, чтобы проверить систему. И поскольку нет цели получить максимально точные данные сравнения, как в A/B тесте, мы можем работать с меньшими объемами выборки.

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

Проиллюстрируем все эти нюансы на примере:

← Назад | Продолжение (Глава 3) →

#маркетинг #a_b_тестрование #a_b_тест