Блок «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-блок. Это защищает опубликованную логику от скрытого изменения.