А/В-тесты на Android от А до Я / Redmadrobot corporate blog / Habr

Большая часть статей об A/B-тестах посвящена веб-разработке, и несмотря на актуальность этого инструмента и для других платформ, мобильная разработка несправедливо остаётся в стороне. Мы попытаемся эту несправедливость устранить, описав основные шаги и раскрыв особенности реализации и проведения A/B-тестов на мобильных платформах.

Концепция A/B-тестирования

A/B-тест нужен для проверки гипотез, направленных на улучшение ключевых метрик приложения. В простейшем случае пользователи делятся на 2 группы контрольную (A) и экспериментальную (B). Фича, реализующая гипотезу, раскатывается только на экспериментальную группу. Далее на основе сравнительного анализа показателей метрики для каждой из групп делается вывод о релевантности фичи.

Реализация

1. Делим пользователей на группы

Для начала нам необходимо понять, как мы будем делить пользователей на группы в нужном процентном соотношении с возможностью динамически его менять. Такая возможность будет особенно полезна, если вдруг выяснится, что новая фича повышает конверсию на 146%, а раскатана, например, всего на 5% пользователей! Наверняка нам захочется выкатить её на всех пользователей и прямо сейчас — без обновления приложений в сторе и сопутствующих временных издержек.

Конечно, можно организовать разбивку на сервере и каждый раз при необходимости что-то менять дёргать backend-разработчиков. Но в реальной жизни бэк зачастую разрабатывается на стороне заказчика или третьей компанией, и у серверных разработчиков и так хватает дел, поэтому оперативно регулировать разбивку, работая с третьими лицами, удаётся не всегда, а точнее, почти никогда, поэтому такой вариант нам не подходит. И тут на помощь приходит Firebase Remote Config!

В Firebase Console, в группе Grow есть вкладка Remote Config, где вы можете создать свой конфиг, который Firebase доставит пользователям вашего приложения.

Конфиг представляет собой мапу <ключ параметра, значение параметра> с возможностью присваивать значение параметра по условию. Например, пользователям с конкретной версией приложения значение X, всем остальным — Y. Более подробно о конфиге можно узнать в соответствующем разделе документации.

Также в группе Grow есть вкладка A/B Testing. Здесь мы можем запускать тесты со всеми вышеописанными плюшками. В качестве параметров используются ключи из нашего Remote Config. В теории можно прямо в A/B-тесте создать новые параметры, но это только внесёт лишнюю путаницу, поэтому делать так не стоит, проще добавить соответствующий параметр в конфиг. Значение в нем традиционно является значением по умолчанию и соответствует контрольной группе, а экспериментальное значение параметра, отличное от дефолтного — экспериментальной.

Прим. Контрольная группа обычно называется группой A, экспериментальная — группой B. Как видно на скрине, в Firebase по умолчанию экспериментальная группа называется “Variant A”, что вносит некоторую путаницу. Но ничто не мешает изменить её название.

Далее запускаем A/B-тест, Firebase разбивает пользователей на группы, которым соответствуют разные значения параметра, получив конфиг на клиенте, мы достаём из него нужный параметр и на основе значения применяем новую фичу. Традиционно параметр имеет имя соответствующее названию фичи, и 2 значения: True — фича применяется, False — не применяется. Подробнее о настройках A/B-тестов в соответствующем разделе документации.

2. Кодим

Не будем останавливаться непосредственно на интеграции с Firebase Remote Config — она подробно описана здесь.

Разберём способ организации кода для проведения A/B-тестирования. Если мы просто меняем цвет кнопки, то говорить об организации нет смысла, ибо организовывать особенно нечего. Мы рассмотрим вариант, в котором в зависимости от параметра из Remote Config показывается текущий (для контрольной группы) или новый (для экспериментальной) экран.

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

Если мы говорим об MVP в Presentation слое, выглядеть это будет примерно так:

Наиболее гибкой и прозрачной представляется следующая иерархия классов:

BaseOrderStatusFragment будет содержать весь функционал текущей реализации, кроме методов, которые не могут быть размещены в абстрактном классе из-за ограничений архитектуры. Они будут располагаться в OrderStatusFragment.

AbOrderStatusFragment будет переопределять методы, различающиеся в реализации, и иметь необходимые дополнительные. Таким образом, в текущей реализации изменится лишь разбивка одного класса на два и некоторые методы в базовом классе станут protected open вместо private.

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

В рамках такой организации скорее всего придётся отступить от принятого CodeStyle, что в данном случае допустимо, ибо соответствующий код будет удалён или отрефакторен по завершению A/B-теста (но, конечно, в местах нарушения CodeStyle стоит оставить коммент)

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

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

Ну, и, естественно, важно не забыть прокинуть значение параметра из конфига в параметры событий аналитики, чтобы была возможность сравнить метрики

Анализ результатов

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

Подводные камни

1. Ошибка при получении Remote Config

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

Рассмотрим следующий кейс: у нас есть пользователь, которого Firebase отнёс к экспериментальной группе. Пользователь первый раз запускает приложение и запрос Remote Config возвращает ошибку — пользователь видит старый экран. При следующем запуске запрос Remote Config отрабатывает корректно и пользователь видит новый экран. Важно понимать, что такой пользователь не является релевантным для эксперимента, поэтому нужно придумать, как отсеивать такого пользователя на стороне системы аналитики, либо доказать, что число таких пользователей пренебрежимо мало.

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

Примечание. Данные за последние 30 дней. Общее кол-во запросов 673 529. Первый столбец, помимо сетевых запросов, содержит получения конфига из кеша, поэтому выбивается из общей формы распределения.

Данные графика:

 

Миллисекунды	Кол-во запросов
200	227485
400	51038
600	59249
800	84516
1000	63891
1200	39115
1400	24889
1600	16763
1800	12410
2000	9502
2200	7636
2400	6357
2600	5409
2800	4545
3000	3963
3200	2699
3400	3184
3600	2755
3800	2431
4000	2176
4200	1950
4400	1804
4600	1607
4800	1470
5000	1310
> 5000	35375

2. Накатка обновления Remote Config

Необходимо понимать, что Firebase кеширует запрос Remote Config. Дефолтное время жизни кеша составляет 12 часов. Время можно регулировать, но у Firebase, есть ограничение на частоту запросов, и если его превысить, Firebase нас забанит и будет возвращать ошибку на запрос конфига (Прим. для тестирования можно прописать настройку setDeveloperModeEnabled, в таком случае лимит применяться не будет, но сделать так можно для ограниченного числа устройств).

Поэтому, например, если мы хотим завершить A/B-тест и раскатать новую фичу на 100%, нужно понимать, что переход осуществится только в течение 12 часов, но это не главная проблема. Рассмотрим следующий кейс: мы провели A/B-тест, завершили его и подготовили новый релиз, в котором есть другой A/B-тест с соответствующим конфигом. Мы выпустили новую версию приложения, но у наших пользователей уже есть конфиг, закешированный с прошлого A/B-теста, и, если время жизни кеша ещё не истекло, запрос конфига не подтянет новые параметры, и мы опять получим пользователей отнесённых к экспериментальной группе, которые при первом запросе получат дефолтные значения конфига и в перспективе испортят данные нового эксперимента.

Решение этой проблемы весьма простое — необходимо форсировать запрос конфига при обновлении версии приложения путём обнуления времени жизни кеша:

val cacheExpiration = if (isAppNewVersion) 0L else TWELVE_HOURS_IN_SECONDS
FirebaseRemoteConfig.getInstance().fetch(cacheExpiration)

Так как обновления выпускаются не так часто, лимиты мы не превысим
Подробнее о подобных проблемах здесь.

Выводы

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

Всем добра, удачного A/B-тестирования и повышения конверсий на 100500%.

Банальности про АБ–тест / Habr

В интернете кто–то неправ

Случайно выяснил, что существует непонимание того, что такое АБ–тест и как его проводить. Поэтому небольшая статья с базовыми принципами и примерами как делать не надо может быть полезна. Советы рассчитаны на читателя только начинающего знакомство с АБ–тестами и проект с небольшой аудиторией. Если у вас большая аудитория, то вы и так знаете как проводить тесты.

Мой опыт проведения АБ–тестов связан с мобильными приложениями, поэтому какая–то специфика может прорваться несмотря на намерения писать только о базовых вещах.

Определение

АБ–тест — это способ понять стал ли ваш продукт лучше при изменении его части. Скажем, у вас есть гипотеза, что какое–то изменение увеличит ключевую метрику продукта больше чем на 10%. Вы берёте новых пользователей и одной половине даёте контрольный вариант продукта, а другой — с реализованной гипотезой. Дожидаетесь пока разница между значениями метрики станет статистически достоверна, то есть не изменится при продолжении теста с вероятностью 90–95%. Как только результаты достоверны — оставляем победителя и запускаем следующий тест.

Зачем это вообще нужно?

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

Так нам говорит наш внутренний голос. Ну, или по крайней мере говорил мне. И иногда он прав. А иногда — нет.

— Давайте выпустим изменение и посмотрим вырастут ли метрики!

Допустим вырастут. Но они могли вырасти из–за исправления креша в этом же обновлении, а не из–за нововведения. Такая ошибка оценки называется «false positive». Или метрики могли не измениться, или даже упасть, а хотя изменение на самом деле увеличило. Просто параллельно вышла реклама которая привела не только целевую, но и много нецелевой аудитории, которая быстро ушла, не заинтересовавшись продуктом. Это ошибка «false negative».

Причиной ошибки может быть большое количество факторов. И что самое пугающее — это непредсказуемость их появления и сила влияние не результат. Научиться предсказывать и оценивать искажающие факторы не представляется возможным. Так что выпуск изменений под девизом «мне повезёт!» скорее всего не приведёт к стабильному увеличению метрик продукта.

АБ–тесты нужны нам чтобы обеспечить проверяемый рост метрик продукта, который вызван именно улучшением продукта, а не внешними факторами или временным изменением аудитории.

Когда останавливать тест

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

Вводим данные о конверсии в базовой и тестовой вариации и получаем размер выборки для каждой вариации который позволит сказать, что вариации статистически достоверно различаются. Вероятность ошибки false negative 20%, ошибки false positive 5%.

Если в тесте приняло достаточное количество участников и тестовая вариация достоверно лучше контрольной, то тест можно считать завершённым, а изменение удачным.

АБ–тест цвета кнопок

Это пример который обычно используют для объяснения что такое АБ–тест. Этот пример хорош для объяснения, но на практике обычно не даёт значимого увеличения метрики. Потому что ваш продукт больше чем кнопка. Если, конечно, весь ваш трестируемый продукт не баннер.

Как и всякий инструмент, АБ–тест можно использовать неправильно, так что метрики проекта не будут расти, а усилия на их проведение будут тратиться. Поставьте дополнительное условие для тестов: изменение должно увеличить важную метрику продукта на 15%. Если эксперимент набрал достаточную выборку для определения разницы в 15%, но тестовый результат ниже необходимого, то возвращайтесь к контрольной вариации и ищите более дерзкую гипотезу. Так вы сможете быстро проверять действительно важные изменения, что важно на начальном этапе развития продукта.

И пару советов напоследок:

• делайте как можно меньше вариаций, это позволит уменьшить время проведения теста;
• по началу старайтесь не проверять конверсии, значение которых меньше 10% — на это потребуется много времени. Обычно к таким метрикам принадлежит такая важная как конверсия в платящего пользователя. Для неё проверяйте гипотезу, если вы уверены, что она принесёт существенно улучшение.

Послесловие

АБ–тест — очень полезный инструмент, который помогает нам не только когда гипотеза подтвердилась. Вся прелесть метода в том, что даже неположительный результат даёт нам новую информацию о продукте. Почему мы думали, что это изменение сработает, а оно не сработало? Возможно, наши представления о том, что нужно пользователям не совсем верны? Поиск ответов может привести вас к новым гипотезам и какая–то из них сработает.

что это, какие нюансы и чем его проводить?

AB test, полезная штука, которая просто должна быть по-умолчанию в интернет проектах. Как проводить и что для этого нужно?

Сегодня тестирование гипотез и проверка идей, обязательная программа. Под эту задачу отлично подходит AB test. Давайте разберём подробнее, что это вообще такое, в чём польза и какие есть инструменты.

AB test: что это и зачем

AB test или Split test — метод маркетингового исследования, суть которого заключается в том, что вы берёте и сравниваете несколько вариантов элемента продукта с одним определенным изменением. А после смотрите какой из вариантов показал себя лучше.

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

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

Что можно анализировать с помощью AB test?

• Конверсии. Кол-во успешных целевых действий на вашем сайте. Это может быть нажатие на кнопку “Купить”, посещение какой-то страницы или что-то ещё.
• Экономика. Средний чек или объём выручки.
• Поведенческие факторы. Глубина просмотра, длительность сеанса.

Нюансы и тонкости

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

–

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал. Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

–

Важно про данные

Всё было бы очень просто, если бы не одно “Но”. Можно провести AB test, получить результаты, где откровенно видно, что один из вариантов сильно лучше другого.

Например, мы показали 2 варианта страниц с разным цветом кнопок по 1000 раз каждый. Проводили тест одну неделю. И получили следующие результаты:

При одинаковых показах баннера (это важно), кол-во кликов у варианта B больше в три раза. Делаем вывод, что этот вариант более эффективный и берём его в рабочую версию, а старый удаляем.

А если, к примеру, так?

Стоит ли брать вариант B? Или может быть это просто погрешность? Да и достаточно ли показать 1000 раз каждый из вариантов, чтобы принять решение? Может к нам на сайт в день заходит 10 000 пользователей и выборка очень мала, чтобы сделать вывод? А если, данные которые мы анализируем, не просто кол-во кликов, а средний чек с транзакций?

Статистика нам в помощь

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

Большой соблазн, когда получили результаты эксперимента, принять решение и всё, вот оно, “светлое будущее”. Но, ведь, если копнуть немножечко глубже, то за неделю распределение кликов по дням было неравномерным. Давайте распишем.

В таблице видно, что клики по дням распределены по-разному. А значит, наши значения варианта A и варианта B могут меняться каждый день. То есть, мы имеем дело со случайными величинами. Для таких случаев применяют средние значения. Но ведь, если мы проведем эксперимент ещё раз, то какова вероятность, что результат повториться?

Изобразим на графике распределение всех данных за неделю по варианту A и B.

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

Статистическая значимость, это то, насколько верны полученные результаты. То есть в нашем примере, ответ на вопрос “нужно ли брать вариант B?”.

Обычно, по-умолчанию принимают уровень значимости равный 95%. Это означает, что мы с 95% вероятностью хотим знать, стоит ли выбирать другой вариант (B) при сравнении. Оставшиеся 5%, это вероятность ошибки, которую мы допускаем или p-value в терминологии статистики.

Интересно, что многие забывают проверять уровень значимости в своих экспериментах и тем самым могут получать ошибочные данные. 8 из 10 AB тестов проходят мимо этой оценки. (источник)

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

Инструменты для расчета значимости

Для оценки значимости данных советую использовать этот инструмент.

Здесь у нас A и B соответственно наши варианты. А по цифрам:

1. Число посетителей/можно кол-во показов вставлять.
2. Кол-во конверсий. Нажали на кнопку, зарегистрировались. В общем выполнили целевое действие.
3. P-value. Вероятность ошибки, которую мы опускаем при заданных данных.
4. Ответ на вопрос существенны ли, полученные изменения в нашем эксперименте.

Пример: берём данные по показам и кликам из таблицы, которую показывал выше.

Забиваем их в сервис, нажимаем на кнопку “Calculate Significance” и…

Получаем ответ “No” или “Нет” (по-русски) в нижней строке, а чуть выше p-value 0,283. Что это означает? А то, что с вероятностью 28,3%  (0,283*100), если мы выберем вариант “B”, то он не принесёт никаких существенных результатов.

Чтобы эксперимент считался успешным, p-value должен быть меньше 5%

Есть ещё один сервис, в который также вбиваете данные и смотрите результат, доступен по ссылке.

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

Как понять сколько нужно данных?

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

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

Благодаря этому сервису вы поймете размер выборки для каждого из вариантов.

Подробнее по пунктам:

1. Существующий уровень конверсии. Или, например, сколько процентов из всех пользователей сейчас нажимают кнопку.
2. Минимально значимое изменение, которое нас интересует. На сколько мы хотели бы изменить базовый показатель конверсии.
3. Значимое отклонение, которое мы ввели на предыдущем шаге показывает, что конверсия может увеличится, так и уменьшиться.
4. Вы выбираете значение: absolute (абсолютный) или relative (относительный). Выбирайте то значение, которое хотите получить. Если у вас baseline уровень конверсий равен 30% (как в примере с картинки) и вы хотите повысить его на 5% с помощью ab тестов, то выбирайте “relative”. То есть, финальный результат изменения в случае успешности эксперимента будет 5% от 30%, то есть 31,5%.
5. Размер выборки для каждого варианта. Сколько мы должны раз показать страницу отдельно A и страницу B, чтобы сделать выводы по эксперименту. Очень важно! Чтобы сделать выводы по эксперименту, мы показываем 24 409 раз A и 24 409 раз B!
6. Статистическая значимость. На сколько точный эксперимент мы хотим провести.
7. Погрешность p-value. Какую вероятность ошибки допускаем.

Можно ли останавливать эксперимент раньше?

Можно. Существует вариант, когда мы можем не дожидаться окончания эксперимента, а на определенном этапе уже сделать выводы. Для этого используйте уже известный инструмент, вкладка “Sequental Sampling“.

По шагам:

1. Вбиваете свой уровень конверсии сейчас. К примеру 30%, именно столько из 100% заходящих к нам на страницу нажимает кнопку.
2. Набираете, на сколько вы хотели бы повысить ранее введенный показатель. Поставил на 10%. Было 30, хочу до 33 поднять.
3. Кол-во конверсий одного из экспериментов, после которого останавливаем эксперимент и принимаем решение.
4. Разница в конверсиях между вариантом A и B, после которой останавливаем эксперимент и берем, тот, что больше набрал.
5. Выставляем уровень значимости 95% (как положено, см.выше материал).
6. Устанавливаем погрешность p-value (опять же, см.выше материал).

Здесь нет никакой хитрости, просто статистика. Используйте этот инструмент, когда эксперименты занимают много ресурсов (время на разработку, бюджеты на рекламу для проверки гипотез и т.д.). Теперь у вас есть два правила, при которых вы можете останавливать эксперимент и делать выводы.

Чем проводить AB test?

Готовые решения:

• Optimizely, vwo.com, zarget.com
• http://alternativeto.net/software/optimizely
• Google Analytics (ссылка как проводить)

Собственное решение:

• Пишем админку.
• Пишем и настраиваем каждый эксперимент.

Вот статья про 10 сервисов для AB test. Есть из чего выбрать.

Всё

Теперь у вас есть общее представление, что такое AB test, какие существуют нюансы и какими инструментами его проводить. В заключение добавлю что данное исследование гипотез является одним из самых полезных в развитии digital проекта. Разве не прекрасно, что можно проверить практически любую идею? Главное правильно, теперь вы знаете как.

Алексей А.

---

Читайте также:

---

Сегодня ролик о том, когда подарок, это ты.

Вконтакте

Facebook

Twitter

Google+

Загрузка…

A/B-тестирование | Data Science

A/B-тестирование (A/B testing, Split testing) — метод маркетингового исследования, суть которого заключается в том, что контрольная группа элементов сравнивается с набором тестовых групп, в которых один или несколько показателей были изменены, для того, чтобы выяснить, какие из изменений улучшают целевой показатель. Примером может служить исследование влияния цветовой схемы, расположения и размера элементов интерфейса на конверсию сайта.

A/B-тестирование в вебе

Метод часто используется в веб-дизайне. Тестируются две очень похожие веб-страницы (страница А и страница В), которые различаются лишь одним элементом или несколькими элементами (тогда метод называют A/B/n-тестированием). Страницы А и В показываются различным пользователям в равных пропорциях, при этом посетители, как правило, не знают об этом. По прошествии определенного времени или при достижении определённого статистически значимого числа показов, сравниваются числовые показатели цели и определяется наиболее подходящий вариант страницы. Преимуществом метода является использование при проектировании объективных данных.

Разновидностью A/B-тестирования является многовариантное тестирование. В этом случае тестируются не два целостных варианта, а сразу несколько элементов дизайна в различных сочетаниях, при которых каждый тестируемый элемент может быть двух видов (A или B).

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

Для A/B-тестирования веб-дизайна можно использовать инструменты вроде Google Analytics или Google Web Optimizer. Для многовариантного тестирования подойдёт Vertster. Кроме того, будет необходим механизм для разбиения пользователей, которым будет показан тот или иной вид дизайна (одному и тому же пользователю нужно показывать тот же самый вариант дизайна). Например, на основе IP-адреса и затем установкой HTTP cookie.

Источник: Википедия

<-идём дальше>

Как проводить A/B-тесты?

Идея A/B-тестирования очень проста. Пользователи ресурса случайным образом делятся на сегменты. Один из сегментов остается без изменений — это контрольный сегмент “A”, на основе данных по этому сегменту мы будем оценивать эффект от вносимых изменений. Пользователям из сегмента “B” показываем измененную версию ресурса.

Чтобы получить статистически значимый результат, очень важно исключить влияние сегментов друг на друга, т.е. пользователь должен быть отнесен строго к одному сегменту. Это можно сделать, например, записав метку сегмента в cookies браузера.

Для снижения влияния внешних факторов, таких как рекламные кампании, день недели, погода или сезонность, замеры в сегментах важно делать параллельно, т.е. в один и тот же период времени.

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

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

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

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

Что улучшаем?

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

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

Конверсия

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

Экономические метрики

Как правило, эти метрики применимы для интернет-магазинов: величина среднего чека, объем выручки, отнесенный на число посетителей интернет-магазина.

Поведенческие факторы

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

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

Анализ результатов

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

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

Эффект от внесения изменения определяют как разность между средними значениями ключевого показателя в сегментах. Тут возникает следующий вопрос, насколько мы уверены в достоверности полученного результата? Если мы еще раз проведем тест, то какова вероятность того, что мы сможем повторить результат?

Ниже на картинках приведены примеры распределения значений показателя в сегментах.

Графики распределения характеризуют частоту появления того или иного значения случайной величины в выборке. В данном случае все значения распределены вокруг среднего.

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

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

Чем меньше пересечение, тем с большей уверенностью мы можем сказать, что эффект действительно значим. Эта “уверенность” в статистике называется значимостью результата.

Как правило, для принятия положительного решения об эффективности изменений уровень значимости выбирают равным 90%, 95% или 99%. Пересечение распределений при этом равно соответственно 10%, 5% или 1%. При невысоком уровне значимости существует опасность сделать ошибочные выводы об эффекте, полученном в результате изменения.

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

Кстати, на практике примерно 8 из 10 A/B тестов не являются статистически значимыми.

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

Оценить значимость результатов

Для сравнения случайных величин математики придумали целый раздел под названием проверка статистических гипотез. Гипотез всего две: “нулевая” и “альтернативная”. Нулевая гипотеза предполагает, что разница между средними значениями показателя в сегментах незначительна. Альтернативная гипотеза предполагает наличие существенной разницы между средними значениями показателя в сегментах.

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

Небольшой пример

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

В случае, если вы измеряете только конверсию, то вы имеете дело с бинарной слуайной величиной, которая принимает только два значения: посетитель “сконвертировался” и “не сконвертировался”. Для оценки статистической значимости в этом случае можно воспользоваться он-лайн калькулятором (калькулятор оценки значимости результатов при A/B-тестировании).

Инструменты

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

Если ваши ресурсы позволяют, то такой инструмент можно реализовать самостоятельно на основе анализа логов действий пользователей. Если ресурсы ограничены, то стоит воспользоваться сторонним инструментом. Например, в Google Analytics есть возможность задавать пользовательские сегменты.

Существует ряд сервисов, которые позволяют полностью автоматизировать процесс тестирования, например, тот же Google Analytics Experiements.

Источник: Мегамозг

Дополнительную информацию об инструментах тестирования и примере работы с google analytics можно найти здесь.

Резюме

В теории все невероятно просто:

1. Выдвигаем гипотезу о том, что какое-то изменение (например, персонализация главной страницы) увеличит конверсию интернет-магазина.

2. Создаем альтернативную версию сайта «Б» — копию исходной версии «А» с изменениями, от которых мы ждем роста эффективности сайта.

3. Всех посетителей сайта случайным образом делим на две равные группы: одной группе показываем исходный вариант, второй — альтернативный.

4. Одновременно измеряем конверсию для обеих версий сайта.

5. Определяем статистически достоверно победивший вариант.

Но на практике часто это тестирование делают неправильно. О типичных ошибках можно почитать здесь.

В заключении, вот вам 70 советов и подсказок.

Как устроено A/B-тестирование в Авито / Авито corporate blog / Habr

Всем привет. Меня зовут Данила, я работаю в команде, которая развивает аналитическую инфраструктуру в Авито. Центральное место в этой инфраструктуре занимает А/B-тестирование.

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

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

Основные функции платформы A/B мы формулируем следующим образом.

1. Помогает быстро запускать эксперименты
2. Контролирует нежелательные пересечения экспериментов
3. Считает метрики, стат. тесты, визуализирует результаты

Другими словами, платформа помогает наиболее быстро принимать безошибочные решения.

Если оставить за скобками процесс разработки фич, которые отправляются в тестирование, то полный цикл эксперимента выглядит так:

• Заказчик (аналитик или продакт-менеджер) настраивает через админку параметры эксперимента.
• Сплит-сервис, согласно этим параметрам, раздает клиентскому устройству нужную группу A/B.
• Действия пользователей собираются в сырые логи, которые проходят через агрегацию и превращаются в метрики.
• Метрики «прогоняются» через статистические тесты.
• Результаты визуализируются на внутреннем портале на следующий день после запуска.

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

Теперь давайте погрузимся в детали.

В админке для конфигурации экспериментов используется формат YAML.

Это удобное решение для небольшой команды: доработка возможностей конфига обходится без фронта. Использование текстовых конфигов упрощает работу и пользователю: нужно делать меньше кликов мышкой. Похожее решение используется A/B-фреймворке Airbnb.

Для деления трафика на группы используем распространенную технику хеширования с солью.

Для устранения эффекта «памяти» пользователей, при запуске нового эксперимента, мы делаем дополнительное перемешивание второй солью:

Этот же принцип описан в презентации Яндекса.

Чтобы не допускать потенциально опасных пересечений экспериментов, мы используем логику, схожую со «слоями» в Google.

Сырые логи мы раскладываем в Vertica и агрегируем в таблицы-препараты со структурой:

Observations (наблюдения) — это, как правило, простые каунтеры событий. Наблюдения используются как компоненты в формуле расчета метрик.

Формула расчета любой метрики — это дробь, в числителе и знаменателе которой стоит сумма наблюдений:

В одном из докладов Яндекса метрики подразделялись на два типа: по юзерам и Ratio. В этом есть бизнес-смысл, но в инфраструктуре удобнее все метрики считать единообразно в виде Ratio. Это обобщение валидно, потому что «поюзерная» метрика очевидно представима в виде дроби:

Наблюдения в числителе и знаменателе метрики мы суммируем двумя способами.
Простым:

Это обычная сумма любого набора наблюдений: количество поисков, кликов по объявлениям и т. д.
И посложнее:

Уникальное количество ключей, в группировке по которым сумма наблюдений больше заданного порога.

Такие формулы легко задаются с помощью YAML-конфига:

Параметры groupby и threshold опциональны. Как раз они и определяют второй способ суммирования.

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

Значимость отклонений по метрикам мы измеряем классическими методами: T-test, Mann-Whitney U-test. Главное необходимое условие для применения этих критериев — наблюдения в выборке не должны зависеть друг от друга. Почти во всех наших экспериментах мы считаем, что пользователи (Uid) удовлетворяют этому условию.

Теперь возникает вопрос: как провести T-test и MW-test для Ratio-метрик? Для T-test нужно уметь считать дисперсию выборки, а для MW выборка должна быть «поюзерной».

Ответ: нужно разложить Ratio в ряд Тейлора до первого порядка в точке :

Данная формула преобразует две выборки (числитель и знаменатель) в одну, сохраняя среднее и дисперсию (асимптотически), что позволяет применять классические стат. тесты.

Похожую идею коллеги из Яндекса называют методом линеаризации Ratio (выступления раз и два).

Использование быстрых для CPU стат. критериев дает возможность проводить миллионы итераций (сравнений treatment vs. control) за считанные минуты на вполне обычном сервере с 56 ядрами. Но в случае больших объемов данных производительность упирается, в первую очередь, в хранение и время считывания с диска.

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

Идея проста: хешируем Uid’ы и по остатку от деления «разбрасываем» их на некоторое количество бакетов (обозначим их число за B):

Теперь переходим к новой экспериментальной единице — бакет. Наблюдения в бакете суммируем (числитель и знаменатель независимо):

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

Чем больше бакетов, тем меньше информации теряется, и тем меньше ошибка в равенстве. В Авито мы берем B = 200.

Плотность распределения метрики после бакетного преобразования всегда становится схожа с нормальным.

Сколь угодно большие выборки можно сокращать до фиксированного размера. Рост в количестве хранимых данных в таком случае лишь линейно зависит от количества экспериментов и метрик.

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

Результаты каждого эксперимента — это простыня из нескольких тысяч чисел. Визуализация обязана быть такой, чтобы минимизировать неправильные выводы в случае реализации ошибок I и II рода, и при этом не «проморгать» изменения в важных метриках и срезах.

Во-первых, мы мониторим метрики «здоровья» экспериментов. Т. е. отвечаем на вопросы: «Поровну ли участников «налилось» в каждую из групп?», «Поровну ли авторизованных или новых пользователей?».

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

Главный дашборд с метриками выглядит так:

Каждая строка — сравнение групп по конкретной метрике в конкретном разрезе. Справа — панель с фильтрами по экспериментам и метрикам. Снизу — панель фильтров по разрезам.

Каждое сравнение по метрике состоит из нескольких показателей. Разберем их значения слева направо:

1. MDE. Minimum Detectable Effect

⍺ и β — заранее выбранные вероятности ошибки I и II рода. MDE очень важен, если изменение статистически не значимо. При принятии решения заказчик должен помнить, что отсутствие стат. значимости не равносильно отсутствию эффекта. Достаточно уверенно можно утверждать лишь то, что возможный эффект не больше, чем MDE.

2. MW | T. Результаты Mann-Whitney U- и T-test

На панель выводим значение z- и t-статистики (для MW и T соответственно). В тултип — динамику p-value. Если изменение значимое, то клетка подсвечивается красным или зеленым цветом в зависимости от знака разницы между группами. В таком случае мы говорим, что метрика «прокрасилась».

3. Lift. Разница между группами в процентах

4. Mean | Num | Den. Значение метрики, а также числитель и знаменатель отдельно

К числителю и знаменателю применяем еще один T-test, который помогает понять, чей вклад решающий.

5. Std. Выборочное стандартное отклонение
6. Hist. Тест Шапиро-Уилка на нормальность «бакетного» распределения.

Если индикатор красный, то, возможно, в выборке есть выбросы или аномально длинный хвост. В таком случае принимать результат по этой метрике нужно осторожно, либо не принимать вовсе. Клик на индикатор открывает гистограммы метрики по группам. По гистограмме однозначно видны аномалии — так проще делать выводы.

Появление платформы A/B в Авито — переломная точка, когда наш продукт стал развиваться быстрее. Каждый день мы принимаем «зеленые» эксперименты, которые заряжают команду; и «красные», которые дают полезную пищу для размышлений.

Нам удалось построить эффективную систему A/B-тестинга и метрик. Часто сложные проблемы мы решали простыми методами. Благодаря этой простоте, инфраструктура имеет хороший запас прочности.

Уверен, те, кто собирается построить платформу A/B в своей компании, нашли в статье несколько интересных инсайтов. Я рад поделиться с вами нашим опытом.

Пишите вопросы и комментарии — постараемся на них ответить.

A/B тесты не нужны* / Habr

Вас всех обманывают. Наглый миф IT-индустрии — утверждение, что А/В-тестирование универсальное и полезное средство для оптимизации.
* для сайтов и мобильных приложений
Немного об авторе и причинах написать этот текст 😉

Привет, меня зовут Чудинов Денис. Сейчас я развиваю свою студию дизайна и разработки мобильных приложений. Я хочу бороться с заблуждениями и стереотипами, которые бродят среди заказчиков.
Мой путь в IT начинался с UX-специалиста (да-да), то есть с проектирования решений и аналитики. Текущий пост является, в каком-то смысле, результатом работы в этом направлении.

По своему опыту и опыту коллег, могу сказать, что почти ни у одной компании нет нормального А/В тестирования, поставленного на поток. Говорят, кто-то где-то видел, но, по сути, честное А/В-тестирование не найти.

Почему так? Давайте разбираться.

Однажды, на одном проекте (суточный трафик порядка 800 000 уникальных пользователей) мы задались целью внедрить А/В тестирование.

Вот с чем мы столкнулись:

1. Трудно с точки зрения «чистоты эксперимента»

Пока не берем А/В-тестирование, а разберем «простой» пример, когда вы добавили еще один рекламный баннер себе на сайт и измерили показатели.

На него кликают, начали капать деньги.

Что стало с другими баннерами и их конверсией? Если вам не повезло, то, скорее всего, суммарный доход не изменился или вообще упал.

А теперь представьте, что вам повезло и доход вырос. Разве дело только в баннере? Может изменился трафик? Сработала сезонность или разовый вирусный эффект в соц.сетях? Пока вы тестируете, продукт живет и развивается, очень трудно найти «чистый» месяц, который был бы «без влияния» маркетинга, портящего эксперимент.

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

Как действовать в подобной ситуации? Следовать простому алгоритму:

1. Придумали гипотезу.
2. Внедрили изменение.
3. Измерили главные показатели через месяц (или другой период: день или квартал).
4. Стало лучше? Можно оставлять.
5. Стало хуже? Верните как было.
6. Повторите.
7. Go to 1.

Увидеть улучшение или ухудшение просто. Объяснить причину изменений и масштабировать ее — ой какое неблагодарное занятие.

2. Нужна крутая аналитика. Или аналитик

Мы в своем проекте помимо Google Analytics и Яндекс.Метрики еще использовали самописную аналитику и выгружали сырые данные в Excel для ручного подсчета. Как мне известно, крупные e-commerce проекты живут примерно так же (по крайней мере жили). Они измеряют все в нескольких системах, так как они считают по разному и дают разную погрешность. У одного и того же сайта данные посещений по ЯМ и GA могут сильно отличаться. Увы, если бы это было главной проблемой: системы аналитики не очень полезны, когда вам нужно одновременно уметь считать коммерческие и продуктовые показатели.

Может так получиться, что с новым баннером доход за месяц вырос. Только возвращаемость (или ретеншен) стал падать. Ядро аудитории стало больше «раздражаться». То есть, через несколько месяцев вы потеряете в трафике и, опять же, «на круг» заработаете меньше.

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

Естественные колебания показателей могут достигать 10%-20%, так что если вы поставили баннер и получили изменение прибыли на 5% — это ничего не значит. Вообще ничего.

Перекрасили кнопку в розовый? Конверсия выросла на 9%?
Ха-ха 😉

3. А/В-тестирование очень дорогое

А давайте одновременно показывать разные варианты дизайна разным людям, но из одинакового источника? Тогда мы не будем зависеть от изменчивости трафика, а также исключим сезонность и маркетинг.

Отличная идея.

Если продукт с историей, high-load, настроено кэширование, разные сервера для контента и еще много всяких радостей, то вряд ли этот проект изначально затачивался на разветление продкашена. То есть архитектурно, проект не готов к тесту. Это значит что если вы придете к backend-программисту и скажете:

— Коля, а давай мы на 8% аудитории будем показывать другую верстку страницы регистрации, причем они еще там должны регистрироваться. Да, поля другие. Да, еще надо, чтобы страница персонализировалась, если он вернется. А я уже говорил что статистику надо модифицировать? Ээ, чо я такого сказал, что ты кипятишься?!
Ваш первый А/В-тест будет полон технических сюрпризов и веселья, особенно если что-то отвалится и вы «перемешаете» аудиторию. Конечно, в идеальных проектах такого нет, но в реальности встречается постоянно.

Когда вы с этим справитесь и даже потестируете что-нибудь, вы поймете что небольшие изменения дают небольшой результат. То есть, если на кнопке сделать скругление краев и поменять цвет с синего на зеленый — большинство пользователей не заметят этого. Если вы хотите ощутимый результат — делайте «крупные» изменения. Было 12 полей ввода для регистрации, а осталось 4? Это существенно.

Главный вопрос в том, что если вы можете обойтись 4 полями, вместо 12… почему вы это еще не сделали? Разве вам нужно подтверждение А/В-тестом или мнением авторитетного UX-специалиста для правильного вывода в этой ситуации?

И даже если вы все равно решили сделать A/B тест… готовьтесь выложить минимум половину первоначальной стоимости страницы для подготовки второго, тестового, варианта.

А вы как думали? Еще не верите, что выхлоп очень сомнителен по сравнению с затратами?

4. Другие действия дают больше пользы.

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

Почему А/В-тесты так популярны?

Думаю, потому что крупные компании их используют и непроизвольно пиарят. Для них они необходимы, так как они уже попробовали все для своих продуктов и теперь вынуждены «выжимать камень» в поисках крупиц пользы. У них есть на это ресурсы, деньги и желание.

Например, Яндекс.Музыка использует eye-tracking (целый набор инструментов, который изучает куда смотрит глаз человека во время использования мобильного приложения). Да, штука полезная, когда у тебя есть бюджет. Не рекомендовать же теперь это всем?

А/В-тест легко продается некомпетентным людям. Можно что-то сделать и сказать в отчете, что «возвращаемость аудитории из камчатского региона выросла на 8%». Как это влияет на прибыль? Такой вопрос редко ставят. В общем, аналитики и проектировщики хотят есть свой хлеб 😉

Главный вывод про кнопки и интерфейсы

Делайте аккуратно, удобно и со вкусом. Этого будет достаточно. Если ваш продукт так себе и call-центр хамит клиентам — ни один интерфейс не исправит ситуацию.

Сделали нормальный дизайн, продумали сценарии использования, посидели над текстами, нарисовали приятную графику? Круто, вы уже достигли 96% эффективности!

Достичь оставшиеся 4% за счет интерфейсных улучшений — утопия. Не живите в утопии.

Получается, A/B-тесты — мертвая история?

Нет, конечно! Сама методология прекрасна, если вы работаете в более контролируемых условиях, например, во время тестирования контекстной рекламы или e-mail рассылок. Тексты, в принципе, легко тестировать, в отличии от дизайна. Лэндинги тоже хорошо поддаются экспериментам, но будьте внимательны с интерпретацией результатов 😉

Как у нас устроено A/Б-тестирование. Лекция Яндекса / Яндекс corporate blog / Habr

A/Б-тестирование на сервисах Яндекса проводится постоянно. «Раскатить на такую-то долю аудитории» и посмотреть на реакцию людей — настолько стандартная практика, что ни у кого в команде не возникает вопроса, зачем это нужно. А чтобы не было проблем с самим тестированием, у нас есть специальная инфраструктура для экспериментов. Подробности рассказывают разработчики Сергей Мыц и Данил Валгушев.

Сергей:
— Я попробую упрощенно описать задачу A/Б-тестирования. Есть абстрактная система с пользователями, в нее мы вносим какие-то изменения, и нужно уметь измерять в ней пользу. Пока все просто, но слишком абстрактно. Пример. Есть веб-сервис по сравнению пары фотографий котов. Пользователь должен выбрать наиболее понравившуюся фотографию. При этом он может выбрать не только левый или правый снимок, но и «против всех». Значит, мы подобрали картинки не очень хорошо. Наша задача — обоснованно улучшать сервис, доказывая это цифрами.

Как нам экспериментировать? Сперва нужно понять, что такое хорошо. Мы хотим улучшать систему. Нужно выбрать то, к чему стремиться, причем не обязательно в цифрах, а в том, что мы называем направлением к идеалу. Можно хотеть, чтобы пользователь как можно реже говорил, что мы вообще не нашли ничего хорошего. Чтобы было как можно меньше отказов. Также, возможно, хорошо, когда мы можем правильно предугадывать выбор пользователя. Тогда давайте стараться, чтобы левая картинка ему нравилась чаще. Еще можно хотеть, чтобы пользователь все дольше хотел пользоваться нашим сервисом. Вдруг мы потом захотим повесить рекламу, и чем больше он будет пользоваться сервисом, тем больше он увидит рекламы. И ему хорошо, потому что ему нравится сервис, и нам, потому что нам нравится реклама. Шутка.

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

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

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

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

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

Эксперимент — совокупность из нескольких выборок. Как правило, одна из них контрольная, и пользователи видят там наш сервис без экспериментов. Все остальные включают экспериментальные действия. Срез данных — вспомогательный аналитический инструмент. Чаще всего мы хотим посмотреть наши метрики, возможно, на какой-то ограниченной группе пользователей. Иногда нам интересно, как ведут себя пользователи в отдельно взятой стране. Иногда интересно, как мы меняем выдачу по коммерческим запросам, потому что с них приходят деньги. Интересно смотреть не на весь поток данных, а на отдельные срезы.

Надо научиться создавать и проводить эксперимент. В описании экспериментальной выборки надо как-то определить описание параметра, который будет включать этот эксперимент. Допустим, эксперимент будет сравнивать два алгоритма подбора картинок. Первый предпочитает котов по усатости, второй — по пушистости. Тогда в первой экспериментальной выборке может быть флаг isУсатый = true, во второй isПушистый = true.

Еще экспериментальная выборка будет включать то, на какой процент пользователей и, возможно, с какими ограничениями — например, в какой стране — мы хотим запускать наш эксперимент. Это все касается описания и изменения экспериментальной выборки. И нам хорошо бы уметь останавливать эксперименты и запускать их. Следим за здоровьем. Когда есть большая система, хорошо понимать, когда все ломается или когда в результате изменений что-то идет не так, как мы запланировали.

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

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

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

Данил:
— На самом деле нет. Меня зовут Данил Валгушев. Все непросто. Это связано с тем, что Яндекс — большая компания, и возникает множество интересных нюансов, о которых я хочу рассказать на конкретном примере.

У нас есть не только основной поиск. Есть поиск по картинкам и видео, почта, карты и много других сервисов.

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

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

Типичный эксперимент состоит из трех шагов. Менеджер или аналитик сначала проводит эксперимент на реальных пользователях и по завершении анализирует результаты и принимает решения.

К примеру, мы решили провести эксперимент и улучшить верстку результатов поиска. Мы должны создать заявку и заполнить все поля. Мы пишем, что критерии выкатки — улучшение основных интерфейсных метрик. Тип заявки — интерфейсы. Дальше создаем две выборки. Одна пустая, А, чистый продакшен. И выборка В, где есть некоторый флажок, например, goodInterface = true. Этот флажок потом через всю нашу инфраструктуру прокидывается до места назначения, до кода, который генерит интерфейс, и по этому флажку код срабатывает. Также в заявке мы говорим о целевых срезах, которые мы хотим обсчитывать в метриках, и отмечаем, на каких регионах, браузерах, платформах и на каком проценте мы хотим завести эксперимент.

Допустим, мы заполнили заявку. Оказывается, мы не можем просто так выкатить ее в продакшен. Мы должны сначала ее протестировать. Тестирование преследует две цели. Есть ручные тесты и автоматические. Ручные — это когда создатель эксперимента сам прощелкивает все, что ему интересно, весь нужный интерфейс, чтобы все работало корректно. Автоматические тесты направлены на то, чтобы избежать факапов, когда эксперимент выкатится в продакшен.

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

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

Когда заявка одобрена, мы должны попасть в продакшен. Здесь тоже возникает проблема: пользователи ограничены, а заявок много. Образуется очередь.

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

Допустим, мы попали в продакшен. Как же пользователи разбиваются на эксперименты? У нас есть некоторая конфигурация, которая фактически описывает правила. И мы пришли к тому, что эту конфигурацию удобно описывать в виде графа решений. В листьях графа находятся эксперименты, а в нодах — решения по параметрам запроса, которые включают в себя, например, идентификатор пользователя, текст запроса, адрес страницы, регион, юзер-агент, время.

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

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

Бывают более мелкие поломки, когда ломается один эксперимент. Здесь сложнее, это видно не сразу, необходимо строить графики по каждому эксперименту, по ключевым метрикам, таким как количество кликов, количество запросов. И есть система автоматического обнаружения аномалий, которая замечает, когда какой-то график начинает вести себя плохо. Есть еще система экстренного отключения, если что-то не так.

Как работает разбиение? Как разбить пользователей, чтобы они перемешались, но при этом каждый пользователь попадал в один и тот же эксперимент?

Простое решение — взять хэш от его идентификатора, и взять по модулю N. Мы получаем N возможных сходов и называем их слотами. Это разбиение мы обычно называем измерением.

Потом на слоты можно навесить эксперименты и алгоритмы. Но здесь возникла проблема. Допустим, перед нами работал эксперимент, в котором пользователям в одной выборке было хорошо, а в другой — чуть хуже. После отключения эксперимента пользователи привыкли и начали вести себя по-разному. И когда мы включаем свой, у нас возникает смещение, А и В находятся в неравных условиях.

Благодаря тому, что наш алгоритм — граф, мы можем сделать такой финт ушами: взять и еще раз перемешать пользователей перед тем, как они вновь попадут в выборку А и В. Тем самым обеспечим им одинаковые условия.

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

Когда измерения ведутся в разных ветках, они обычно имеют Salt1 и Salt2 — соль, чтобы они бились независимо и не коррелировали друг с другом.

Последняя проблема связана с тем, как собрать конфигурации. Важно вспомнить, что каждый эксперимент все-таки имеет набор ограничений: проценты, регионы, браузеры, платформы и т. д. Здесь приведен пример — четыре эксперимента, которые идут в разных регионы. Как же их разместить, допустим, на 10 слотах?

Если разместим так, то видим, что каждый эксперимент по чуть-чуть отъел от каждого слота и последний эксперимент не получился, потому что он пересекается со всеми тремя.

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

Вот мы провели эксперимент, он отработал, мы смотрим метрики. Обязательно смотрим обычные метрики: количество пользовательских запросов, кликов — чтобы понимать, сколько данных собралось. Еще одна стандартная метрика — доля некликнутых страниц, CTR. У нас много различных метрик, и приемка происходит не по кликам и запросам, а по синтетическим метрикам. Это отдельная тема, не для нашего доклада.

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

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


Сергей:
— Это некий обобщенный обзор инфраструктуры инструментов. Мы проговорили первые две темы: что можно делать с интерфейсом взаимодействия и как происходит разбиение. А какие проблемы возникают с логированием в реальном мире?

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

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

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

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

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

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

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

Так как у нас много экспериментов и метрик, их необходимо мониторить, и возникает другая проблема: когда много чисел, на них сложно посмотреть. Поэтому у нас есть инструмент для автоматического нахождения проблем. Все параметры всех метрик с экспериментов отправляются туда, и он с помощью алгоритмов анализа временных рядов определяет подозрительные точки, которые мы называем разладками. Ответственному потом уходит уведомление. У нас есть интерфейс просмотра метрик, где можно изучить данные по своему эксперименту за любой день по любому срезу, который вы заказали заранее. Еще иногда хочется исследовать эксперимент более детально, в процессе может прийти идея проверить что-то, хочется как-то повертеть данные. С этим поможет инструмент быстрого анализа по произвольным совокупностям указанных срезов.

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

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

Есть несколько групп людей на разных уровнях, которые следят за правильностью измерений. В первую очередь, это разработчики команды АБТ, куда входим мы с Данилом. Мы разрабатываем инфраструктуру экспериментов и инструменты анализа, а также разбираем возникающие проблемы. У нас есть понимание, что и как должно быть сделано, но мы больше уходим в инфраструктурную поддержку всего этого.

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

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

Тема обширная, многие вещи были показаны не очень глубоко. Спасибо.