Тест, по определению, проверяет какую-то идею. По умному эта идея называется гипотезой.
📎Гипотезы могут появляться просто как идеи или их может приносить команда (продакты, проджекты или дизайнеры), но чаще гипотезы вытекают из твоих рисёрчей. Когда ты исследуешь какую-то проблему или анализируешь фичу, хорошим тоном считается в выводах описать идеи по решению проблемы или улучшению фичи. Вот эти идеи — уже гипотезы.
Кстати, генерирование гипотез по итогам рисёрча отличает хорошего аналитика от не. Новички, как правило, вообще не заморачиваются с выводами. Итак таблицы есть — заказчик разберётся (спойлер — не разберётся).
Когда гипотеза ясна, первым шагом в подготовке теста является документирование. В аналитическом сообществе мы называем этот артефакт дизайном теста (ДТ).
ДТ должен включать в себя несколько важных пунктов. Обычно, в новой компании я приучаю заказчиков заполнять свою часть ДТ, если гипотеза от них.
ДТ все заполняют по разному, кто как. Структура, которую я покажу здесь, моя авторская, я начинал её делать года 4 назад, она постепенно эволюционировала, и вот финальная версия на сегодня. Моим командам нравится, пользуйтесь и в своих 🙂
Эту часть заполняет заказчик гипотезы ⬇️
1️⃣ Гипотеза.
Тут мы описываем суть идеи, что хотим поменять и зачем.
2️⃣ Описание вариантов.
Что меняем в тестовом варианте. Иногда, в зависимости от твоей системы, нужно проставить id вариантов перед стартом, это ты уже потом в доку добавишь.
3️⃣ Чего ожидаем от теста.
Ожидаем больше заказов или хотим увеличить возвращаемость, повысить средний чек и т.д. Эта инфа тебе понадобится чуть дальше, при выборе метрик.
4️⃣ Ограничения.
Если есть, тут стоит указать. Проводим только на определённом гео или платформе и т.д.
#ABtest