Как сделать админку для AB тестирования за 1 час

-

Зачем нужна админка

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

Как выглядит

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

В админке можно:

  • Посмотреть конфиг экспериментов (размеры выборок и параметры в каждой). На скриншоте 2 эксперимента.
  • Назначить конкретному пользователю произвольную выборку (удобно для тестирования) — делается через поле с плейсхолдером user id.
  • Удалить/добавить/отредактировать конфиг эксперимента. Об этом подробнее:

Добавление/редактирование для того, чтобы не заморачиваться с фронтендом, сделано через JSON. Вот пример конфига эксперимента который появляется в большом инпуте внизу в результате нажатия на Edit и сохраняется кнопкой Отправить в правом нижнем углу.

При желании можно сделать админку user-friendly и редактировать все привычным путем — накликивая, но я думаю что в этом случае уже лучше поискать что-то на гитхабе.

Как работает

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

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

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

В чем плюс разделения параметров и бакетов?

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

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

Теперь про new_users_only. Почти все метрики, особенно для молодых проектов, завязаны на первую сессию, день или неделю — коэффициенты в воронке, D2, D7 ретеншн и так далее. Это значит, что загонять в эксперименты всех пользователей не нужно, а нужно только новых. Можно это отфильтровать в аналитике при анализе эксперимента, но еще лучше — вообще не вводить в эксперимент старых пользователей, чтобы не ломать им привычки.

Альтернативы

  1. Есть Optimizely, но у него 2 недостатка. Первый — это удаленный сервер, и на каждую обработку запроса на ваш сервер придется тратить на 30–200 миллисекунд больше. Если в проекте уже есть пользователи, то этого не хочется. Второй недостаток — насколько я понял по лендингу, прямо в коде нужно завязываться на id и бакет эксперимента (то есть нет поддержки экспериментальных флагов).
  2. Думаю, можно найти что-то на гитхабе, но проще было написать.

Bonus track

Обворожительная тулза для быстрого анализа AB эксперимента, которая умеет делать так:

Использую ее каждый раз.

Удачных экспериментов вам!