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

Мониторинг эксперимента

Кроме того, что эксперимент надо правильно спроектировать, необходимо проконтролировать, что он проходит в соответствии с дизайном. Что это значит:

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

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

Проблему проще понять на конкретном примере, поэтому вновь обратимся к опыту одной онлайн-школы — как обычно, примеры вымышлены, совпадения случайны.

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

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

Система контроля соблюдения условий вашего эксперимента обязательно должна быть спроектирована до запуска эксперимента:

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

Посмотрите видео о том, как проводят A/B-тесты в операционных процессах Skyeng.

Проблема подглядывания

Думаю, что многим знакома ситуация, когда после запуска A/B-теста команда настолько переживает за результат, что не отводит свой взгляд от дашборда с ключевыми метриками. И в один прекрасный день мы, наконец, видим, что тестовая группа с ощутимым отрывом обходит контроль. Дрожащими руками мы вбиваем конверсии в калькулятор для проверки статзначимости результатов, видим заветный результат «Sample 2 is more successful» и радостно бежим раскатывать фичу на всех пользователей. Остановитесь!

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

Даже если вы тестируете два абсолютно идентичных варианта с корректной сплит-системой, разница между ними в процессе сбора наблюдений иногда может оказываться статзначимой — ведь мы проектируем эксперимент так, что зафиксировать разницу с нужной нам значимостью можно, лишь накопив полную выборку. Если же мы будем регулярно «подглядывать» за результатами и с готовностью принимать решение, то сильно снизим точность нашего теста. Подробнее эта проблема освещается в статье на GoPractice.

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