Как настроить A/B-тест приветствия в Telegram-боте

Сценарий начинается с узла randomSplit с распределением 50/50. Одна половина пользователей попадает в вариант A, другая в вариант B. Такое деление нужно, чтобы не выбирать версию вручную и не смешивать аудиторию в одном запуске. Само по себе оно не измеряет клики, заказы или ответы: эти данные нужно связать с последующими узлами и отчётами вашего процесса.

В варианте A из сида стоит эмоциональное приветствие с одной callback-кнопкой "Что там?". В варианте B сообщение объясняет три направления: материалы, каталог и вопрос, поэтому у него три callback-кнопки. После отправки каждого сообщения шаблон добавляет отдельный тег: ab_welcome_variant_a или ab_welcome_variant_b. Затем обе ветки завершаются. Это важно учитывать при редактировании: кнопки в исходной схеме не продолжают путь сами по себе.

Сравнивайте не абстрактную "конверсию приветствия", а одно понятное действие. Например, можно добавить после callback отдельные ветки и смотреть, сколько людей дошли до заявки, просмотра материала или обращения в поддержку. Если у вариантов разные предложения и разное число кнопок, они проверяют сразу несколько вещей. Для чистого ответа лучше менять один элемент за раз: формулировку, порядок вариантов или объяснение пользы.

• Определите одно действие, которое будет считаться результатом теста.
• Сохраните одинаковый следующий шаг там, где сравнивается только текст.
• Дайте тегам понятные имена и не меняйте их в середине сбора данных.
• Проверьте, куда ведёт каждая callback-кнопка после ваших дополнений.

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

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

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

1. 01

   Сформулируйте вопрос теста

   Запишите, что сравниваете: один призыв, порядок разделов или подробность приветствия. Не объединяйте несколько изменений в одном варианте без необходимости.

2. 02

   Отредактируйте сообщения

   Замените черновой текст и кнопки на свои, сохранив понятную разницу между A и B. Убедитесь, что каждое обещанное действие существует в сценарии.

3. 03

   Продолжите путь после кнопок

   В исходном шаблоне после тега стоит конец ветки. Добавьте обработчики callback и следующие узлы, если кнопка должна открывать раздел, задавать вопрос или вести к форме.

Теги в схеме фиксируют назначенную ветку, а не качество ответа. Тег ab_welcome_variant_a появляется после сообщения A, тег ab_welcome_variant_b после сообщения B. Поэтому по ним можно собирать сегменты для дальнейшей работы и сопоставлять участника с версией приветствия. Не стоит читать наличие тега как согласие на рассылку или признак интереса: это просто техническая метка маршрута.

Если в боте есть дальнейшие этапы, добавьте отдельные метки для события, которое вы измеряете: например, нажатия конкретной кнопки или завершения формы. Тогда можно отличить того, кто увидел вариант, от того, кто сделал целевое действие. Названия меток должны быть стабильными, иначе сравнение периодов станет запутанным. Для следующего эксперимента удобнее создавать новые теги, а не переиспользовать старые с другим смыслом.

Перед запуском договоритесь, кто и где смотрит результат. Для небольшого проекта это может быть ручная выгрузка сегментов по тегам. Для связанного процесса понадобится передача события в вашу аналитику или CRM. Шаблон не устанавливает такие интеграции автоматически, поэтому их состав и доступы настраиваются отдельно.

Частая ошибка — поставить в варианте B больше полезных кнопок и затем объяснять разницу только стилем текста. В этом случае меняется и навигация. Другой риск — вести разные ветки к разным предложениям, разным условиям или к разному времени ответа менеджера. Тогда результат описывает весь путь, а не одно приветствие. Это допустимо для проверки двух готовых сценариев, но вопрос теста нужно назвать точнее.

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

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

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

Откройте обе ветки из randomSplit и прочитайте их как обычный пользователь. У варианта A должна быть одна понятная кнопка, у варианта B — три предложенных в сообщении направления или ваши осмысленные замены. После сообщений должны появляться соответствующие теги, а построенные вами продолжения не должны пересекать данные двух вариантов. Особое внимание уделите callback-кодам: это служебные значения, по которым сценарий различает нажатия.

Сделайте список того, что остаётся за пределами шаблона. К нему относятся содержимое разделов после кнопок, правила повторного показа, сбор метрик, сроки эксперимента и решение о победителе. Такая граница полезнее громкого названия: она позволяет не выдавать техническую заготовку за готовую методику исследования. Когда эти части описаны, шаблон можно использовать как аккуратный первый фрагмент сценария.

После завершения периода сохраните тексты A и B, условия распределения и выбранный критерий вместе с данными. Даже если вы решите оставить одну версию, история поможет понять, что именно менялось в следующем запуске. Не переносите итог на другую аудиторию автоматически: новый канал, другая услуга или сезон могут требовать отдельной проверки.