Блок «A/B тест»
Блок делит входящих клиентов на несколько вариантов ветки в заданных пропорциях и отслеживает, какой из них лучше работает. Используйте его, когда хотите проверить гипотезу — например, какой текст приветствия, какая кнопка или какая последовательность сообщений даёт больше переходов вперёд.
Ключевая особенность: распределение детерминированное. Один и тот же клиент всегда попадает в один и тот же вариант (вычисляется по его ID), поэтому при повторном входе в воронку он не «перепрыгнет» в другую ветку и эксперимент остаётся чистым.
Когда использовать
- Сравнить два-три варианта одного сообщения (текст, кнопки, оффер)
- Протестировать разные сценарии после одной точки входа
- Раскатать новый шаг воронки на часть аудитории (например, 20%), оставив остальным старый
- Проверить гипотезу до того, как менять воронку для всех
Настройки
- Варианты — список вариантов (по умолчанию два: «Вариант A» и «Вариант B»). У каждого есть название и вес. Можно добавлять новые кнопкой «Добавить вариант» и удалять лишние (минимум всегда остаётся 2 варианта — кнопка удаления у первых двух недоступна).
- Вес варианта (%) — слайдер от 1 до 99. Задаёт долю клиентов, попадающих в этот вариант. При изменении одного веса остальные пересчитываются автоматически так, чтобы сумма стремилась к 100%. Индикатор «Итого» зелёный при 100% и янтарный при отклонении.
- Критерий победителя — по какому показателю сравнивать варианты: следующий клик по кнопке (по умолчанию) или завершение текущей воронки.
- Длительность теста (часы) — число от 1 до 720 (по умолчанию 24). Это окно, внутри которого действие клиента относится к варианту, и срок первой оценки результата.
Результаты собраны в проектном разделе «A/B тесты»: участники, конверсия вариантов, срок оценки, достоверность и лидер. Из настроек блока туда ведёт отдельная ссылка.
Как работает
- Для каждого клиента блок берёт его ID, считает по нему хэш и выбирает вариант пропорционально весам. Один клиент → всегда один и тот же вариант (детерминированно), повторный вход ничего не меняет.
- Выбор веток идёт по «ручкам» (sourceHandle): к выходу каждого варианта нужно протянуть свою стрелку. Если связь варианта найдена — управление уходит в неё. Если связи именно для этого варианта нет — блок уходит в первую исходящую стрелку (фолбэк), чтобы клиент не застрял.
- В момент назначения варианта блок отправляет в аналитику событие `ab_test_assigned` с ID варианта, блока и воронки. Клики по callback-кнопкам записываются как `button_click`, а достижение конечного блока — как `flow_complete`.
- Если у блока вообще нет вариантов — выбор не делается (блок ничего не вернёт). Поэтому хотя бы один вариант с весом обязателен.
- Лаборатория считает уникальных клиентов, применяет заданное окно атрибуции и сравнивает два лучших варианта двусторонним z-тестом пропорций. Победитель показывается только после срока, минимум при 20 участниках в каждом варианте и `p < 0.05`.
Пример
Вы хотите понять, какое приветствие приносит больше кликов.
1. Поставьте блок «A/B тест» сразу после старта воронки. 2. Оставьте два варианта: «Короткое» (вес 50) и «Длинное» (вес 50). 3. От ручки варианта A протяните стрелку к блоку «Сообщение» с коротким текстом, от ручки варианта B — к блоку с длинным текстом. 4. Выберите критерий «Клики на кнопки» и длительность 48 часов. 5. Запустите воронку. Каждый новый клиент стабильно попадёт в свой вариант, а результат появится в разделе «A/B тесты» после накопления ответов.
Частые ошибки
- Не протянули стрелку от варианта. Если у конкретного варианта нет исходящей связи, клиент уйдёт в первую попавшуюся стрелку блока — итоги теста будут искажены. Подключайте каждый вариант отдельно.
- Удалили все варианты. Без вариантов блок не делает выбор и фактически становится «тупиком». Всегда оставляйте минимум один (UI не даёт опуститься ниже двух).
- Ждёте, что один клиент попадёт в разные варианты. Распределение детерминированное по ID — повторный вход того же клиента всегда даёт тот же вариант. Это норма для чистоты эксперимента, а не баг.
- Рассчитываете, что блок сам остановит распределение. Лаборатория автоматически считает лидера, но runtime продолжает назначать варианты, пока вы сами не измените или не уберёте A/B-блок. Это защищает опубликованную логику от скрытого изменения.