Кейс: как мы создали тестовый сервис для видеостриминга

Как работают A/B тесты

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

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

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

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

Как работает сервис

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

Бэкенд

Бэкенд проекта написан на Python, использован веб-фреймворк FastAPI. Для работы с базой и управления данными выбрали стандартный набор из SQLAlchemy и PostgreSQL.

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

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

Динамическая админка

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

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

Поэтому для фронтенда выбрали React — это современное решение, которое будет легко поддерживать в будущем. Сама же админка сверстана с помощью Bootstrap. В интерфейсе есть эксперименты (названия), эпохи (срок) и фильтры — атрибуты пользователя: пол, возраст, откуда пришел. Справа есть подсказка, какие поля уже заполнены.

Пересечения

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

Расширение экспериментов

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

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

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