Привет, Хабр!

Меня зовут Максим Шевченко и последние два года я занимаюсь развитием платформы экспериментов в Okko, одном из ведущих онлайн-кинотеатров в России. Наша команда разрабатывает инструменты, которые позволяют продуктовым командам самостоятельно проводить А/В тесты и анализировать их результаты. Мы отвечаем за весь цикл экспериментов – от помощи в дизайне и выдаче пользователям разного опыта до предоставления рекомендаций по принятию решений.

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

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

Зрелость А/В платформ

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

В ней авторы выделили 4 этапа зрелости, грубо можно разделить компании по частоте запусков экспериментов:

• на этапе Crawl компания проводит эксперимент раз в месяц (примерно 10 экспериментов в год);

• на этапе Walk – раз в неделю (примерно 50 экспериментов в год);

• на этапе Run – ежедневно (примерно 250 экспериментов в год);

• на этапе Fly – более 1000 экспериментов в год.

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

На мой взгляд, организацию процесса на коленке, предлагаемого в рамках данной статьи, может подойти компаниям, находящимся на этапах Crawl, Walk и, возможно, ранних стадиях Run.

Точка отсчета

До создания отдельной команды платформы экспериментов процесс проведения экспериментов практически отсутствовал. Один человек (привет, Влад?) в полуручном режиме поддерживал таблицу в Confluence.

Эта таблица содержала минимальную информацию о проводимых тестах:

• название эксперимента, включающую платформу, на которой был запущен эксперимент;

• основные даты эксперимента – запуск, остановка, прерывания;

• ссылку на задачу в Jira.

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

Однако такой подход имел ряд серьезных недостатков:

• Неструктурированная информация: Если когда-нибудь потребуется провести мета-анализ наших экспериментов, это будет крайне затруднительно.

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

• Неформализованный процесс: Исполнитель и автор задачи часто один и тот же человек. Непонятно, кто ответственный за эксперимент, и к какому продукту он принадлежит.

Кроме этого, мы также сталкивались с другими проблемами:

• Затраты времени аналитиков: Продуктовые аналитики тратили значительную часть времени на анализ экспериментов.

• Отсутствие автоматических пайплайнов: Дашборды и эффекты в основном рассчитывались вручную.

• Децентрализованная методология расчета эффектов: Каждая продуктовая команда использовала разные статистические критерии для оценки эффектов. 

• Недостатки сервиса сплитования трафика: Сплиттер не был покрыт продуктовыми метриками качества.

• И другие проблемы

Так как в рамках данной статьи мы говорим про процессы А/В-тестирования, то  сосредоточимся на решении проблем первого блока.

Структурируем данные

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

1. Описание эксперимента

   1. Название эксперимента

   2. Даты начала и окончания эксперимента

   3. Продуктовая команда

   4. Краткое описание проделанных изменений

   5. Гипотеза, которую хотим проверить

   6. Ссылки на документацию, дизайн, связанные задачи

2. Сегменты пользователей, на которые влияет эксперимент

   1. Девайс-сегменты, например, платформа iOS

   2. Пользовательские сегменты, например, пользователи с подпиской

3. Описание групп

   1. Название группы

   2. Описание

   3. Процент

4. Метрики

   1. Целевые 

   2. Guardrail

   3. Критерий принятия решения

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

• Использование в аналитике: Наличие такой информации в аналитическом хранилище позволит оценивать эффективность групп эксперимента,  использовать данные для мониторинга состояния эксперимента и обеспечивать детерминированность результатов А/В-теста.

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

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

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

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

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

Информация об экспериментах в аналитическом хранилище

Еще одно серьезное преимущество Jira – удобное API для парсинга данных. Написав несколько простых скриптов, которые можно легко обернуть в DAG AirFlow, мы без проблем получаем всю информацию об экспериментах в структурированном и нормализованном виде. Эта таблица активно используется в наших пайплайнах. С помощью нее и других таблиц мы рассчитываем дашборды, считаем эффекты и оцениваем метрики здоровья сплитования. Также таблица используется группой мониторинга при исследовании инцидентов в работе приложения – неожиданное количество ошибок, с которыми сталкиваются пользователи могло быть вызвано запуском нового эксперимента.

Жизненный цикл эксперимента

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

Если мы спросим продуктового аналитика, сколько длился А/B-тест, то, скорее всего, получим ответ 7 или 14 дней, подразумевая, что в это время наши клиенты получали разный опыт. Однако реальная продолжительность процесса значительно больше: 

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

• Затем менеджер принимает решение на основе выводов аналитика, что может занять еще один день. 

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

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

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

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

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

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

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

• Запланирован. Иногда из-за пересечений с другими экспериментами запуск откладывается. В этом статусе карточка ждет своего часа для перехода в следующий статус.

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

• Анализ. По завершении эксперимента тикет перемещается в этот статус. На данном этапе аналитики платформы экспериментов применяют статистический аппарат и выносят рекомендуемое решение.

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

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

• Архив. Здесь оказываются все закрытые эксперименты. В зависимости от успешности проведения эксперимента они могут попадать либо в статус resolved – эксперимент прошел весь цикл, либо в статус closed – эксперимент пришлось экстренно выключить из-за найденных проблем. 

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

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

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

Итак, для каждого эксперимента мы имеем собственный тикет в Jira, который может находиться в разных статусах. Очень удобно нанести все наши эксперименты на одну доску в Jira – для этого мы воспользовались классической kanban-доской. В качестве swimline на этой доске решили использовать значения поля «Команда», чтобы каждая продуктовая команда могла видеть все свои эксперименты. Ещё для этой доски мы добавили фильтры на карточки. Например, мы можем отфильтровать все эксперименты, которые начинаются на этой неделе. 

Уведомления

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

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

Финальным решением для нас стал отдельный канал в Mattermost – #experiments. При создании нового эксперимента автоматически отправляется сообщение в этот канал. Сообщение содержит минимальную информацию об эксперименте и упоминает ответственных. Все обсуждения экспериментов ведутся в тредах к этому сообщению.

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

Таким образом, мы получили единое структурированное место для общения по конкретным экспериментам.  

Календарь экспериментов

Когда в продуктовых командах стало достаточно много экспериментов, стало сложно их планировать. Каждый продукт решал задачу по-своему: кто-то описывал эксперименты на собственных страничках в Confluence, кто-то рисовал диаграммы Ганта в Miro.

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

Выводы

Прежде чем переходить к выводам, хочется поднять один важный вопрос. Нужен ли все-таки отдельный сайт для управления всеми экспериментами компании или можно обойтись «подручными средствами»?

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

Однако будет честно упомянуть и о недостатках такого подхода.

• Инструменты для А/В-тестирования должны упрощать жизнь продуктовым командам, поэтому важно делать их максимально удобными. Стоит помнить, что Jira не предназначена для работы с экспериментами, поэтому сложно интегрировать в нее специфичные фичи.

• При большом количестве экспериментов процесс их организации усложняется и Jira может не удовлетворять нашим требованиям.

• Иногда довольно сложно собирать информацию из Jira. Например, трудно восстановить состояние эксперимента на конкретную дату в прошлом.

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

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

Насколько удобен процесс А/В тестирования в вашей компании? Какие методы и подходы вы нашли наиболее эффективными? Делитесь мнениями в комментариях.

Если вам интересно, как устроен сервис нашего сплитования пользователей, рекомендую ознакомиться с циклом статей – раз, два и три.