На прошлой неделе было много технической базы, на этой будет поменьше 🙂
А пока прервёмся на что-то попроще. Давай порассуждаем как вообще происходит запуск теста в команде. Рассмотрим пример компании, где тесты плюс-минус поставлены на поток.
✅ Всё начинается с идеи. Как я уже говорил, идеи приходят от команды или рождаются в процессе исследования продукта и поведения юзеров.
Чтобы идея превратилась в аналитический артефакт, с которым можно работать, её нужно задокументировать. Так она становится гипотезой. Для ведения документации, я обычно создаю отдельную ветку в confluence (скорее всего у тебя в команде он тоже есть).
✅ Далее, если нужно, ты идёшь к продакту и вы выдаёте задачу дизайнеру на разработку тестового варианта.
✅ Когда у тебя появляются картинки, ты идёшь в свою сплит-систему и создаёшь тест. В любой системе, кастомной или сторонней, обычно нужно завести ID теста/вариантов и описания вариантов.
✅ После этого нужно поставить задачу на разработку. В задаче нужно оставить ID теста и вариантов, продублировать описание вариантов, приложить картинки. Чем более полно ты опишешь задачу, тем больше вероятность получить то что заказывал.
✅ Когда тест запустят на стороне разработки, обязательно сверься с базой и убедись что всё летит как надо (скорее всего у тебя в БД есть таблица типа
ab_test, где хранятся данные по юзерам, тестам и вариантам). Для проверки, построй небольшой дашборд, в котором будут графики с распределением юзеров по вариантам, убедись что сплитовалка раскидывает юзеров равномерно (если это не Байесовские бандиты, конечно).
В общем-то это всё. Это один из самых частых флоу, который я встречал. Но он, естественно, не всегда такой и у тебя будут свои нюансы на каждом шаге. Иногда у твоей сплитовалки нет интерфейса и ты “заводишь” тест напрямую в задаче на разработку, иногда это сторонняя система со своими правилами.
Но т.к. АБ — это твоя территория, тебе и менеджерить весь процесс 🙂