Бэк-енд А/В-платформы

Поговорим об архитектуре.

1. Оффтоп новости

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

• Во-первых, я вел курс по продуктовой аналитике в Ozon Masters, который теперь перекочевал в AI Masters от Института ИИ МГУ.
• Во-вторых, ровно в день начала курса начался известный внешнеполитический кризис, который сказался на моей мотивации.

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

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

2. Архитектура А/В-платформ

Client side

Порядка 10 лет назад эксперименты на фронтенде проводились с помощью подмены веб-страницы: грузилась интересующая страница, на ней исполнялся JavaScript, который читал группа клиента (контроль или таргет) и для тестовой группы рисовал нужную версию. Так работают WYSIWYG-редакторы, например Hubspot. Отсюда и главный плюс — для проведения эксперимента можно не привлекать разработчиков, а также делать деплой/релиз.

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

Одним способом избежать эту проблему — скрывать элемент страницы до тех пор пока не загрузится таргетная версия. Примеры такого подход: anti-flicker snippet в Google Optimize или синхронная установка VWO в tag-менеджере или в визуальном редакторе. Однако такая схема тормозит общую загрузку страницы и все еще влияет на результаты эксперимента.

Server Side

Поскольку сервера IT-компаний обычно работают быстрее чем клиентские устройства, поэтому придумали такие вещи как server side rendering. Суть его в том, что вместо исполнения JS на странице клиента, код построения исполняется на сервере и клиенту отдается уже готовая страница.

Идея оказалась полезной, поэтому появились server side трекинг (например, в GTM) и server side A/B, когда сплитование и (возможно) рендеринг происходит на сервере. Коммерческие инструменты (VWO, Google Optimize, Optimizely, ABTasty), а также большинство команд уже перешли на server-side эксперименты. Подробнее про то как это работает можно прочитать тут.

Кроме производительности server side позволяет решать проблемы:

• privacy (не отдавать личные данные пикселю TikTok)
• отслеживания пользователей с adblock’ерами
• не запускать на сайте сторонний код

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

Архитектура

Благодаря R.Kohavi (стр. 99) мы знаем, что есть несколько вариантов server side архитектур. Например, Optimizely использует подход с API для получения варианта пользователя в конкретном эксперименте.

И наоборот, Google и Bing используют параметризацию с конфигами без получения варианта как такового. Это позволяет не плодить отставание кода (не нужно выпиливать вилочный код if … else). Можно назначить дефолтные параметры, которые всегда использует нужный сервис, и запускать эксперименты без деплоя или вообще постоянно крутить на них многорукого бандита. Например, так можно тестировать проценты скидок, версии алгоритмов ранжирования/рекомендаций, различные цвета всевозможных веб-элементов и тд.

Мы в Ozon используем именно последний вариант архитектуры. С ним возникает проблема синхронизации конфигов в сотнях микросервисов. Например, в А/В-тесте маркетинговой кампании помимо использования акционного движка нам необходимо отправлять коммуникацию + отрисовывать что-то на фронте (в client-side архитектуре запуск таких комплексных тестов невозможен).

Собственно к чему это я? Наш глава разработки А/В-платформы написал прекрасную статью о том, как в Ozon пришли к такой архитектуре, о решении проблемы синхронизации и о том, как держать огромный RPS. В ней также есть инсайты о том сколько А/В мы проводим через платформу и примеры наших экспериментов. Читайте и комментируйте!