Хабрахабр

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

Меня зовут Данила, я работаю в команде, которая развивает аналитическую инфраструктуру в Авито. Всем привет. Центральное место в этой инфраструктуре занимает А/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 выборка должна быть «поюзерной». Теперь возникает вопрос: как провести T-test и MW-test для Ratio-метрик?

Ответ: нужно разложить Ratio в ряд Тейлора до первого порядка в точке $(\left[X\right], {E}\left[Y\right])$:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MDE. 1. Minimum Detectable Effect

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

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

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть