Создание эксперимента

На этом шаге вы создаёте эксперимент в интерфейсе Trisigma: формализуете гипотезу, задаёте правила распределения трафика и критерии успеха.

Полное описание параметров - в разделе Создание эксперимента на основе трафика.

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

При создании эксперимента в Trisigma нужно заполнить три блока:

1. Гипотеза - описание того, какое изменение и почему должно привести к росту конкретного показателя.
2. Варианты - контрольная (Control) и тестовая (Test) группы пользователей.
3. Метрики - набор показателей, по которым вы оцениваете результат.

Планирование длительности

Чтобы заранее посчитать объём трафика и длительность эксперимента, используйте Калькулятор MDE. Он показывает минимальную разницу в метриках, которую вы сможете зафиксировать при заданных параметрах ещё до запуска теста.

Кейс для примера интеграции (Заведение эксперимента)

Сквозной кейс из вступления: команда продукта проверяет, влияет ли цвет кнопки «Добавить в корзину» на количество кликов. Дальше - как завести этот эксперимент в интерфейсе Trisigma.

Форма из 5 шагов. Ниже - три ключевых:

Шаг 1. Обязательная информация

Указываем название эксперимента, описание и команду. Дальше - параметры сплита:

• Тег сервиса - средство группировки экспериментов: сплиттер вернёт приложению только те эксперименты, которые привязаны к запрошенному тегу. В нашем кейсе тег один - default, к нему привязываем эксперимент. Подробнее - в статье Что такое tag.
• Строковый идентификатор - уникальное имя эксперимента, по которому код приложения ищет его в ответе сплиттера. Латинские буквы, цифры и подчёркивания. Для нашего кейса задаём blue_button_test.
• Группы эксперимента - варианты, между которыми разделяется трафик. Заводим две: control (серая кнопка, отмечена контрольной) и test (синяя кнопка).

Оба значения - тег и строковый идентификатор - передайте разработчику: они понадобятся ему на шаге Подключение сплиттера. По тегу разработчик запрашивает у сплиттера активные эксперименты (getFeaturesByTag), по строковому идентификатору (он же experimentLabel в ответе) находит в ответе именно этот эксперимент и решает, какой вариант показать пользователю.

Шаг 2. Дизайн эксперимента

Самая важная часть шага - Разметка пользователей. Она определяет, кто попадает в эксперимент и чьи действия влияют на метрики.

Тип разметки - один из двух:

• Разметка по событию - триггер попадания в эксперимент - событие Exposure (пользователь увидел тестовую функциональность, и код приложения отправил exposeManyV2). В метрики попадают только пользователи с Is Exposed = True - те, кто реально столкнулся с тестом. Подходит для онлайн-экспериментов в продукте: любой посетитель может попасть в группу, а критерий участия - факт показа.
• Разметка списком - в эксперимент входят все пользователи из выбранных списков, вне зависимости от того, столкнулись они с тестовой функциональностью или нет. Сами списки заводятся в интерфейсе Trisigma - см. Списки участников. Подходит для рассылок, push-уведомлений и сценариев, где «кому показать» известно заранее.

В нашем кейсе разделение пользователей происходит по факту захода на страницу с кнопкой - заранее списка пользователей нет, триггер участия = «увидел кнопку» = Exposure. Поэтому выбираем Разметка по событию.

Домен - продуктовый scope, в рамках которого работает эксперимент. У вас на платформе настроен свой домен или несколько - выбираете подходящий из списка. В нашем кейсе - Trisigma.

Тип участника - кто считается участником эксперимента. Из коробки доступны User ID (авторизованный пользователь) и Visitor ID (анонимный посетитель). В этом списке можно завести свои типы (participant types) под специфику продукта - например, Session ID, Device ID, Order ID - и пользоваться ими дальше. В нашем кейсе - User ID, потому что в таблице кликов есть user_id.

Слой - механизм изоляции конфликтующих экспериментов. Если на той же кнопке параллельно тестируется ещё что-то (например, текст или размер), эксперименты на одном слое не пересекаются по пользователям и не искажают метрики друг друга. В нашем простом кейсе слой не нужен - оставляем пустым. Подробнее - в Концепция слоев.

Полное описание разметки и связанных понятий - в статье Участники эксперимента.

Дальше в шаге настраиваем равное распределение трафика: 50% на каждую группу.

Шаг 3. Метрики

В этом шаге задаём, что и как будем измерять.

Гипотеза - направление ожидаемого эффекта. Три варианта:

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

Значение Is Exposed при принятии решения - оставляем True. На этой настройке отчёт строится по пользователям, которые получили Exposure - то есть реально столкнулись с тестом.

Длительность эксперимента и Объём трафика - две связанные настройки. Чтобы их подобрать, используем Калькулятор MDE (ссылка в правом верхнем углу). Он считает минимальный обнаружимый эффект для метрики и говорит, сколько времени и какой процент трафика нужны для теста с заданной чувствительностью. В нашем кейсе берём 100% трафика, длительность - по результату калькулятора.

Целевые метрики - те, по которым меряем основную гипотезу:

• Метрика - users_clicked (та, что мы описали на шаге Настройка метрик).
• Разрез - total (без разбиения; для среза по платформе, региону или другой dimension выбирают соответствующий разрез).
• Ожид. эффект - можно оставить пустым или указать ожидаемое изменение в % (используется калькулятором MDE).

Целевых метрик можно добавить несколько через кнопку «+ Добавить». Если в эксперименте нужен сразу большой набор метрик с заранее заданными настройками - удобнее подключить Список метрик: один объект на платформе, объединяющий N метрик.

Ниже в форме - Контр-метрики: показатели, ухудшение которых блокирует раскатку (например, время загрузки страницы). В нашем простом кейсе контр-метрики не задаём.

Это основные настройки эксперимента. Следующий шаг формы - параметры отчёта; для нашего кейса там менять ничего не нужно, переходим дальше.

Эксперимент создан и готов к запуску. Следующий шаг - подключить сплиттер в коде, чтобы он распределял пользователей по группам и отдавал нужный вариант интерфейса: Подключение сплиттера.