Работа с A/B-тестами в крупной соцсети: подробно об A/B платформе Одноклассников
ОК — социальная сеть, которой ежемесячно пользуется более 36,5 млн уникальных пользователей из России. Наш продукт имеет сложную архитектуру, включает десятки сервисов и инструментов, которые мы постоянно совершенствуем и добавляем новые. Чтобы в процессе выкатки обновлений не появились сбои в работе этого механизма, а продуктовые цели были достигнуты, мы активно работаем с A/B-тестами.
Меня зовут Евгения Лушпина. Я продуктовый аналитик в ОК. В этой статье я расскажу об A/B платформе ОК, сценариях ее применения и поделюсь, как у нас устроен процесс анализа экспериментов.
A/B платформа Одноклассников
А/B-платформа Одноклассников — высокопроизводительный инструмент, которым пользуется 25 продуктовых команд. Ежедневно анализатор платформы рассчитывает около 110 экспериментов.
Сейчас анализ экспериментов развивается усилиями четырех команд.
Dev Tools. Занимается автоматизацией конфигурирования — делает более удобную конфигурацию анализа экспериментов, автоматизирует конфиги в зависимости от запросов разных продуктовых команд и дорабатывает интерфейс задач в Jira для более удобного конфигурирования.
Data Warehouse (DWH). Обеспечивает агрегаты данных для анализатора, их стабильность, помогает с нестандартными метриками, а также работает над документацией источников данных.
Data Platform. Отвечает за всю техническую часть, код анализатора и стабильность работы платформы.
Продуктовая аналитика. Отвечает за методологию, оценку качества работы анализатора, развивает культуру A/B-тестирования. Мы работаем с нашим анализатором как с продуктом — запрашиваем обратную связь у пользователей, обсуждаем необходимость изменений, оцениваем качество работы, проверяем влияние изменений на качество.
A/B-тесты в ОК состоят из четырех этапов:
Дизайн эксперимента. В дизайне обычно участвуют продуктовый менеджер, разработчик и минимально аналитик.
Запуск эксперимента. Запуск происходит в Jira. За него отвечает разработчик изменения — например, разработчик из продуктовой команды, ответственный аналитик или data scientist.
Расчет эксперимента. Расчёт эксперимента происходит автоматически через анализатор. Вручную рассчитываются только эксперименты, имеющие сложную логику раскатки.
Оценка результатов эксперимента. Результаты расчета приходят ежедневно в Jira ссылкой на дашборд. Аналитик интерпретирует полученные данные и вместе с менеджером обсуждает решение по эксперименту.
Шаг 1. Дизайн эксперимента
Выбор целевых метрик
Дизайн эксперимента начинается с выбора целевых метрик и определения потенциального эффекта, в том числе просчитываем возможное негативное влияние (например, снижение продуктовых показателей). На этом этапе мы определяем, что хотим проверить и как именно.
У нас метрики объединены в специфические агрегаты данных, которые мы называем провайдерами. Они имеют общую схему данных и содержат несколько метрик для анализа, объединенных общей логикой. В провайдерах данные хранятся до пользователя, например, с указанием ID зарегистрированного пользователя или ID устройства, если пользователь анонимен — используем только уникальные идентификаторы без персональных данных. У каждой продуктовой команды есть один или несколько провайдеров с метриками.
В каждый эксперимент добавляется несколько групп провайдеров:
Основной провайдер, который содержит kpi и наиболее критичные для нас метрики: все самые важные для ОК метрики, а также верхнеуровневые метрики по всем основным продуктам. Главные зоны риска рассчитываются по умолчанию.
Провайдер с техническими метриками платформы, который содержит данные для оценки технических проблем — сбоев, ошибок, скорости загрузки страницы.
Провайдер (ы) с целевыми метриками, которые продуктовые команды подбирают под конкретный эксперимент.
Провайдер (ы) с метриками других сервисов.
В нашей A/B-платформе разработчики могут гибко конфигурировать наборы провайдеров с учетом направлений экспериментов. Например, рекомендации друзей предлагаются пользователям через разные инструменты: нотификации, пуши, лента новостей, раздел дружб. В зависимости от того, меняются ли рекомендации или логика их получения в конкретном разделе, могут меняться и провайдеры. Разработчик последовательно добавляет необходимые метрики.
Чтобы исключить проблемы при работе с провайдерами, сделать процесс нативным и упростить онбординг, мы разработали и используем:
документацию по каждому провайдеру;
Wiki с группировкой провайдеров по продуктам;
Wiki с порядком заведения экспериментов в продуктовых командах;
автоматизированный список провайдеров и целевых метрик по направлениям изменений и продуктовым командам в Jira.
Потенциально на этапе выбора целевых метрик существует несколько рисков.
Потеря времени аналитика. Наши аналитики работают с большим количеством экспериментов параллельно с другими задачами продуктовой аналитики, поэтому детальная проработка целевых метрик в каждом эксперименте может сильно повлиять на нашу производительность.
Невключение новых метрик или метрик других проектов. При автоматизации выбора метрик есть риск допустить потерю актуальности метрик, а также не учесть негативный эффект на метрики других команд.
Технические ограничения. Всегда есть риски, связанные с техническими ограничениями. Например, невозможность внесения изменений после старта эксперимента или невозможность сравнения результатов на новых метриках со старыми экспериментами, если продуктовая команда пересмотрела подход к целевым метрикам.
Чтобы сократить подобные риски, мы выстроили процесс следующим образом.
Позволяем добавлять метрики на любой стадии эксперимента.
Можем создавать тестовые провайдеры через админку.
Можем создавать новые провайдеры через DWH.
Поддерживаем любые количественные метрики.
Добавляем метрики блоками.
Рассчитываем основные метрики по умолчанию в каждом эксперименте.
Выбор аудитории
Следующий этап дизайна эксперимента — выбор аудитории.
Наш анализатор позволяет просчитывать один эксперимент несколько раз и сужать аудиторию по своему усмотрению. По умолчанию эффект рассчитывается на всех пользователей. При этом мы можем:
использовать оценку на пользователях приложения старше указанной версии;
проводить пересчёт на новых пользователях в 1 клик;
использовать стандартные сегменты пользователей по активности и возрасту;
по запросу собирать кастомные списки пользователей, на которых необходимо посмотреть эффект.
Например, у нас был эксперимент, в ходе которого мы хотели изменить поведение пользователей после открытия определенного пуша. Отслеживали две целевые метрики:
отказы после открытия пуша bounce rate — в рамках гипотезы мы ожидали их снижения;
время в приложении timespent — этот показатель надеялись увеличить.
В результате расчета на весь портал (всех пользователей ОК) мы увидели только изменение bounce rate. После этого мы пересчитали результаты только по пользователям, которые открывали этот пуш и увидели еще и рост времени в ленте новостей.
В итоге у нас получилось два расчета.
Аудитория | Вся аудитория ОК | Пользователи, открывшие пуш |
Эффект | bounce [-1.9% ;-0.2%] | bounce [-8.4% ;-5.5%], timespent в ленте [1.2% ;3.4%] |
Таким образом, выбор аудитории для проведения экспериментов напрямую влияет на их результаты — достоверность и полноту.
Основные риски на этапе выбора аудитории связаны с техническими ограничениями:
ограниченный набор сегментов;
невозможность использовать анализатор для сравнения специфически набранных групп (на основе гео, кластеров, PSM);
другие ручные расчеты.
Чтобы исключить такие риски, мы в ОК реализовали ряд мер.
Предусмотрели для анализатора поддержку расчетов по выбранному списку пользователей, а также пересчет на любой стадии эксперимента.
Создали список стандартных сегментов для ограничения пользователей: новички, версии, возраст, активность.
Позволяем быстро создавать новые сегменты через админку. Так, по простым критериям можно создать список пользователей через sql like выражение на основе любого агрегата, а по сложным критериям можно записать подневный или общий список пользователей и дальше использовать его для фильтрации в анализаторе.
Написали функцию, которая позволяет преобразовывать id пользователя так, чтобы анализатор воспринимал их как тест и контроль. Это позволяет автоматически рассчитывать эффекты даже по сложным разделениям, которые нужны при расчете сетевого эффекта.
Шаг 2. Расчёт эксперимента
После конфигурирования (дизайна) эксперимента мы переходим к его расчету. При этом расчет происходит полностью на стороне анализатора и запускается на основе конфигурации таска в Jira.
Мы работаем с большим количеством экспериментов, поэтому важно, чтобы анализатор умел обрабатывать эксперименты разного профиля.
Основные условия расчета анализатором
У нас своя методика расчета эффектов. Так:
В каждом эксперименте участвует своя уникальная соль для разбиения на тест и контроль. С учетом этой соли мы можем разбить одну аудиторию на любое количество групп и попарно их сравнить. Например, провести A/B/C-тест.
Также есть фиксированные доли аудитории ОК, которые мы называем партиции. Партиция — остаток от деления ID пользователя (или любого другого неизменяемого уникального значения) на число. Мы можем комбинировать набор партиций, чтобы достичь необходимой доли от всей аудитории. Кроме того, партиции помогают планировать эксперименты, которые не должны пересекаться.
В оценке эффекта учитывается весь период от старта эксперимента, но расчет выполняется ежедневно.
Эффект оценивается на бакетах. Количество бакетов для каждого события подбирается отдельно. Мы учитываем количество пользователей с событием, чтобы сократить дисперсию в количестве пользователей между бакетами до нужного уровня.
В результатах выводим доверительные интервалы эффекта с несколькими уровнями значимости альфа: 5%, 1%, 0,1%.
Результаты анализа записываются в Hadoop и ClickHouse.
Эксперименты оцениваются в разрезе всех платформ по отдельности и синтетической платформы ALL, которая агрегирует данные со всех платформ и позволяет оценивать эффект на всю аудиторию ОК.
По умолчанию рассчитывается набор из семи метрик по каждому событию из провайдера:
уникальные пользователи;
количество;
деньги или длительность;
среднее количество на пользователя в день;
средние длительность или деньги на пользователя в день
среднее количество на пользователя за период;
средние длительность или деньги на пользователя за период.
Для оценки эффекта на уникальных пользователей мы считаем доверительные интервалы на основе T-теста с поправкой Уэлча, а для всех остальных метрик — на основе разницы медиан в соответствии с описанной методологией.
Кроме того, одним из основных свойств платформы, которые позволяют максимально автоматизировать процесс, является быстрота расчета. За время работы анализатора в нашем случае отвечает дата-платформа. Чтобы соблюдать сроки выполнения, у нас:
есть технический дашборд с отслеживанием работы анализатора;
существует правило готовности старых экспериментов к 11:00;
отслеживается взятие новой задачи в работу.
Среднее время работы анализатора зависит от объема данных:
на основе данных за неделю расчет в среднем занимает 5.1 минуты;
по данным за 2 недели — 6.3 минуты.
При этом на расчет экспериментов с данными за 7 дней в 95% случаев уходит не более 15 минут, а 95% экспериментов с данными за 14 дней рассчитываются менее чем за 26 минут.
Также мы обязательно проводим проверку эксперимента на значимость в контрольном периоде. Для этого мы используем А/А-тесты.
По дефолту мы оцениваем разницу между тестом и контролем на основе 2 недель до старта эксперимента, но, если нужно, меняем этот период. А/А-тест для нас выступает не только этапом проверки корректности разбиения на экспериментальные группы и зашумленности метрик, но и источником данных для оценки качества самого эффекта.
Мы оцениваем новизну — насколько эффект не только значимый, но и отличается от того, что было до старта эксперимента. Новизна — не одна метрика, а совокупность факторов, которые оценивает аналитик: устойчивость эффекта, время его начала, пересечение с периодом «до». Для оценки также используются подневные данные.
Например, в одном из наших экспериментов мы получили метрики с низким показателем новизны — формально А/А-тест прошел успешно, но эффект начался не одновременно со стартом эксперимента.
Расчет объема выборки и времени
Следующим шагом мы оцениваем достаточность объема выборки, рассчитываем его и определяем время проведения эксперимента.
Зачастую функционал раскатывается поэтапно на стандартные доли от всей аудитории — например, начиная с четверти аудитории ОК.
Время для конкретного эксперимента, как правило, не рассчитывается вручную, увеличение происходит через установленный период времени. По достаточности данных мы ориентируемся на пост-оценку анализатора.
Необходимый размер выборки для достижения абсолютного эффекта мы определяем математически, используя следующую формулу:
где,
2 — вариация;
d — целевой эффект в абсолютах;
Z/2 и Z — критические значения нормального распределения, соответствующие заданным ɑ и β.
Мы используем данные, агрегированные анализатором по бакетам, и на основе дисперсии и наблюдаемой разницы теста и контроля рассчитываем размер выборки для значимого эффекта. Если не хватает данных для значимости, экстраполяцией рассчитывается необходимое количество дополнительных дней. Для этого мы оцениваем, как менялась дисперсия по дням. По результатам такого прогноза мы можем понять, если эффект или метрика недостаточно стабильные, чтобы учитывать влияние эксперимента на них.
Стоит отметить, что иногда анализатор может выдать ошибку. Как правило, такое случается, если допущены ошибки в конфигурации или при выполнении расчета. При этом основная часть ошибок отрабатывается без запуска самого расчета анализатора и может быть получена очень быстро после старта — пользователь сразу получает объяснение, что нужно исправить в конфигурации. Для нетипичных ошибок или падений расчетов самого анализатора у нас есть чат и уведомления, которые сразу присылаются в Jira.
Как и в случае с дизайном, на этапе расчета эксперимента есть некоторые риски. Они связаны со стабильностью и скоростью работы платформы, полнотой покрытия всех потребностей экспериментов, необходимостью ручных пересчетов и дополнительного вовлечения аналитика. Чтобы уйти от этого и минимизировать технические риски, мы активно взаимодействуем с командой дата платформы, а также пересматриваем методологию оценки экспериментов, чтобы сократить ручные расчеты и обеспечить оценку всех экспериментов через платформу.
Шаг 3. Оценка результатов эксперимента
Последний этап работы с A/B-платформой — получение результатов эксперимента и подведение итогов.
Для сбора всех данных от анализатора и оценки полученных результатов мы используем дашборд в Grafana, который легко конфигурируется под наши задачи. Он не только показывает результаты конкретного эксперимента, но и является навигационной страницей, через которую можно перейти в документацию анализатора, детальнее почитать обо всех полях и фильтрах отчета, перейти в документацию по провайдерам, а также на отдельный дашборд с подневной динамикой по любой метрике.
У нашего дашборда четыре основных блока:
общая статистика по эксперименту;
значимые эффекты;
список метрик, по которым не хватило данных;
детальная информация по дефолтному списку метрик или по списку, который передается из конфига.
Здесь же в Grafana мы можем перейти по ссылке в таблице и посмотреть подневную статистику по конкретной метрике.
Для удобства все данные на дашборде мы можем отфильтровывать по множеству признаков, что позволяет находить более сильные эффекты и выделять влияние на конкретный продукт. Кроме того, мы считаем специфические метрики:
новизну, которая показывает пересечение с доверительным интервалом эффекта в А/А-тесте выше определенной границы;
прогнозное количество дней, через которое значимый эффект можно считать неслучайным;
долю дней из тестового периода, где эффект набрал значимость.
На основе устойчивости результатов из основного дашборда, а также прогнозного количества дней, мы фиксируем итоговый результат. При наличии признаков эффекта новизны, мы можем увеличить период, чтобы понять значение устойчивого эффекта. Иногда мы можем оставить контрольную часть, если не видим рисков для раскатки. При этом настройки анализатора позволяют рассчитывать эффект окном и оценить более долгосрочный результат.
На этапе оценки результатов есть несколько рисков и трудностей:
непрозрачность результатов и методологии;
необходимость оценки множества значимых эффектов;
сложность ориентирования в результатах.
В результате любой из рисков может привести к повышению нагрузки на аналитика, а также к снижению точности оценки результатов проводимых экспериментов.
Чтобы сократить риски, которые здесь возникают, мы:
используем дашборд, чтобы добавлять ссылки на документацию;
добавили большое количество фильтров;
применяем дополнительные метрики и подневные графики, чтобы выделять более сильные эффекты.
Вместо выводов
A/B-тесты — неотъемлемая часть развития ОК, в которую вовлечено большинство наших команд. От скорости и точности проведения тестов зависит то, как будет развиваться ОК, и какие продуктовые метрики мы будем получать.
Добиться высоких показателей объективности A/B-тестов даже в условиях их непрерывного потока нам помогает работа с A/B-платформой — инструментом, который автоматизирует рутинные операции и сводит к минимуму необходимость ручного вмешательства специалистов по ходу экспериментов. Именно A/B-платформа в сочетании с четко выстроенной структурой экспериментов, мерами исключения рисков на каждом этапе и синергией между задействованными командами гарантируют, что наши A/B-тесты учитывают все аспекты и позволяют делать аргументированные выводы с минимальной нагрузкой на аналитиков.
