{"id":14286,"url":"\/distributions\/14286\/click?bit=1&hash=d1e315456c2550b969eff5276b8894057db7c9f3635d69a38d108a0d3b909097","hash":"d1e315456c2550b969eff5276b8894057db7c9f3635d69a38d108a0d3b909097","title":"\u041f\u043e\u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u043d\u0430\u0434 \u043a\u0440\u0443\u043f\u043d\u0435\u0439\u0448\u0438\u043c\u0438 \u0418\u0422-\u043f\u0440\u043e\u0435\u043a\u0442\u0430\u043c\u0438 \u0441\u0442\u0440\u0430\u043d\u044b","buttonText":"","imageUuid":""}

Дизайн АБ тестов (продуктовая аналитика)

Поговорим про документацию АБ-тестов.

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

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

Будет полезно как новичкам в тестированиях, так и командам, у кого документация тестов в приоритетах где-то рядом с деплоем в пятницу вечером. Приятного прочтения!

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

Эту часть заполняет заказчик гипотезы:

  • Гипотеза. Тут мы описываем суть идеи, что хотим поменять и зачем.
  • Описание вариантов. Что меняем в тестовом варианте. Иногда, в зависимости от твоей системы, нужно проставить id вариантов перед стартом, это ты уже потом в доку добавишь.
  • Чего ожидаем от теста. Ожидаем больше заказов или хотим увеличить возвращаемость, повысить средний чек и т.д. Эта инфа тебе понадобится чуть дальше, при выборе метрик.
  • Ограничения. Если есть, тут стоит указать. Проводим только на определённом гео или платформе и т.д.

Дальше ты берёшь наработки заказчика и напильник, и начинаешь детализировать:

  • Ключевая метрика / ОЕС. Иногда это будет просто метрика, на которую тест должен повлиять сильнее всего. Конверсия в регу, в покупку, средний чек, общий доход и т.д. Иногда это целый ОЕС (overall evaluation criterion) -- взвешенная группа ключевых метрик.
  • Дополнительные метрики. Укажи пару-тройку дополнительных метрик, которые тоже нужно мониторить, но они чуть менее важны чем ключевая. Не перебарщивай с набором метрик, бери только важное, иначе утонешь в интерпретации.
  • Базовое значение ключевой метрики и её вариативность. Как базу обычно берут среднее, а в качестве меры вариативности -- стандартное отклонение. Не бери большой период, 2-4 недели истории будет достаточно. Нужно чтобы значения были свежими.
  • MDE (minimum detectable effect). Наши ожидаемые изменения ключевой метрики по итогам теста. Например, мы хотим провести тест на конверсию, мы верим в гипотезу, она разрывная. Наша конверсия обычно 5%, мы хотим поднять её тестом до 7%. Вот эта разница и есть MDE. Чем ниже MDE, тем дольше проводить тест, но тем выше вероятность получить стат. значимый результат. Если мы слишком завысим MDE, то тест будет быстрым, но менее мощным.
  • Валидация MDE. Я поклонник метода через сигмы — MDE не должен быть выше 2-3 стандартных отклонений, это снижает реалистичность, MDE ниже одного отклонения, возможно, слишком мал и тест может затянуться. Тут надо балансировать.
  • Рассчитываем выборку. У нас есть всё что нужно для расчёта размеров теста: базовая метрика и MDE. Доверительный уровень, мощность и направление указывай по ситуации.
  • Расчёт сроков теста. На основании рассчитанных объёмов выборки и средних показателей трафика можно прикинуть сроки проведения теста. Есть нюансы — тест не должен быть короче 1 полной недели, чтобы включить выходные. Если тест слишком долгий, попробуй увеличить MDE.
  • Добавление в трекинг. Если нужно, можно добавить новые ивенты в разметку, особенно когда тестируем новую фичу. Как минимум нужна индикация, что юзер увидел фичу. Ивенты на новой фиче ещё могут помочь понять воронку и прибавить ещё гипотез, даже если тест не даст положительных результатов. Например, можно будет понять ошибки в дизайне фичи, и перезапустить тест после их исправления.

Поделитесь своими идеями, примерами, как у вас ведется документация, мне правда интересно посмотреть как это реализовано в других командах.

Вообще, у меня есть ТГ канал про практическую продуктовую аналитику, в основном для новичков, которые прошли первые собесы, но понятия не имеют что дальше делать то. Заглядывайте на огонек :)

0
Комментарии
-3 комментариев
Раскрывать всегда