АБ-тесты. Интеграция в процесс пилотирования. Что делать. База пилотов
Цикл постов про АБ-тестирование. Пост 5

Как мы разобрались раньше, при внедрении АБ-тестирования в процесс пилотирования полезно создать базу пилотов. Хорошая база позволяет не только снизить риск некорректного финального решения о дальнейшем развитии проекта (можем отслеживать пересечения пилотов: чтобы в пилотной группе тестировался только один проект, а в контрольной - ни одного), но и сильно систематизировать знания компании о пилотах. А последнее потом очень помогает подбить эффект от работы команды АБ-тестирования за год 😉, а также найти проблемы в работе с пилотами (как технические, так и бизнесовые).

Каковы компоненты идеальной базы пилотов?

На самом деле, мы наполовину уже ответили на этот вопрос в предыдущем посте цикла, описав поля для чек-листа заявки на дизайн пилота. Все эти сведения будут полезны для базы пилотов. Полезно также присвоить им метку design (сведения, известные на момент дизайна пилота).

К этим данным стоит добавить:

- Параметры пилота, полученные после осуществления дизайна: расчетные даты границ пилота и препилота, полученные ошибки 1-го и 2-го рода, минимально детектируемый эффект, на который рассчитан дизайн, ID объектов пилотной и контрольной группы.

- Результаты оценки эффекта пилота, рассчитанные после его окончания: итоговый эффект пилота (или его отсутствие😐), итоговые параметры пилота (даты пилота/препилота, ошибки, ID объектов). Для этих данных полезно проставить метку estimation (этап оценки эффекта пилота).

Так мы видим идеальную базу. Будем рады комментариям и дополнениям!

Предыдущие посты цикла тут.
Продолжение следует!

#tech #ab_testing