Логика узлов
Как проходит сценарий в исходном шаблоне
После старта бот отправляет сообщение "Колесо фортуны" и сообщает о шансе 40%. Затем узел randomSplit с параметром splitA 40 распределяет пользователей между двумя ветками. Это программное случайное ветвление, а не визуальная анимация. Если вы хотите показывать настоящее колесо в мини-приложении или на странице, такой интерфейс и связь с ботом нужно создавать отдельно.
В ветке выигрыша сначала отправляется сообщение о 50 бонусных баллах. Узел mathOperation прибавляет 50 к loyalty_balance и сохраняет результат обратно в loyalty_balance. Далее добавляется тег fortune_winner, а следующее сообщение выводит баланс через переменную {{loyalty_balance}}. Ветка заканчивается после этого сообщения. Вторая ветка отправляет сообщение о том, что попытка не принесла приз, ставит тег fortune_lost и завершается.
Схема не содержит проверки периода акции, лимита на попытки, наличия покупки или возраста участника. Она также не задаёт юридические правила розыгрыша, порядок выдачи физического приза и обработку спорных случаев. Если эти условия нужны вашему проекту, добавьте их до randomSplit и опишите человеческим языком в самом сообщении или на доступной странице правил.
- Укажите, кто может запустить сценарий и сколько раз.
- Согласуйте, что означает балл и где им можно пользоваться.
- Проверьте начальное значение loyalty_balance для нового пользователя.
- Разделите технический тег исхода и фактическую выдачу внешнего приза.
Пример диалога
Не только текст
Сначала задайте правила участия
До запуска сформулируйте правила без рекламных оборотов. Нужны дата и время действия, доступные пользователи, число попыток, вероятность или способ определения результата, вид приза и порядок обращения в поддержку. Если баллы сгорают, имеют ограничения по товарам или не совмещаются с другими скидками, это тоже лучше написать до участия. Человек должен видеть правила до того, как бот сообщит об исходе.
В исходном тексте указаны 40% шанса и 50 баллов. Эти цифры связаны с текущими узлами: splitA равен 40, а операция прибавляет 50. Меняйте их одновременно, иначе сообщение и фактическая логика разойдутся. Номинал одного балла, стоимость призов и названия партнёров не берите из примера как готовое условие. Это значения для замены после проверки вашей программы лояльности.
Продумайте поведение для повторного запуска. Простая схема каждый раз проходит через randomSplit, поэтому без дополнительной проверки человек может получать новую попытку при каждом попадании в поток. В зависимости от вашей политики можно поставить до игры тег, переменную даты или проверку другой бизнес-системы. В сиде этих ограничений нет, поэтому их нельзя считать уже включёнными.
Опишите условия
Составьте короткий список для пользователя и отдельный рабочий список для команды: кто участвует, что получает и куда обратиться при вопросе.
Синхронизируйте числа
Сверьте процент в сообщении с randomSplit, размер награды с mathOperation и текст о балансе с тем, как ваша система считает баллы.
Добавьте ограничение попыток
Если оно требуется, разместите проверку до случайного деления и подготовьте отдельное понятное сообщение для уже участвовавшего человека.
Математика сценария
Проверьте переменную бонусного баланса
Победная ветка не создаёт отдельный кошелёк: она выполняет действие loyalty_balance + 50 и записывает ответ в loyalty_balance. Для корректного результата эта переменная должна иметь ожидаемое числовое значение до игры. Решите, где оно создаётся для нового пользователя и как оно синхронизируется с покупками, возвратами и ручными корректировками. Это особенно важно, если баллы существуют ещё и во внешней учётной системе.
Шаблон показывает результат через {{loyalty_balance}} сразу после операции. Это удобно для объяснения пути, но перед запуском стоит пройти тестовый сценарий с нулевым и ненулевым балансом. Проверьте формат числа, правила округления и то, что сообщение не раскрывает лишние данные. Если переменная может быть пустой или содержать текст, обработайте это в своей логике до арифметического узла.
Тег fortune_winner уместен для последующей коммуникации о победителях, а fortune_lost — для технической сегментации ветки без выигрыша. Не используйте их как единственный финансовый журнал. Тег показывает, какой путь был выбран, но не заменяет подтверждение начисления там, где баланс ведётся вне сценария.
Тон общения
Сделайте оба исхода понятными
Сообщение о выигрыше должно называть, что добавлено, и где пользователь увидит баланс. Не обещайте скидку, подарок или доставку, если это не включено в правила. В примере побеждает участник, которому добавляют баллы, а не физический приз. Если у вас другая награда, измените и текст, и следующий шаг: например, выдачу промокода, запрос данных или передачу заявки оператору.
Сообщение без выигрыша не должно подталкивать к бесконечным попыткам, если вы их не разрешили. В сиде есть приглашение попробовать позже, но период и число попыток там не определены. Замените эту строку на вашу фактическую политику: укажите дату следующей попытки, условия нового участия или завершение акции. Не создавайте ложного ожидания гарантированных баллов за покупку, если такой процесс отсутствует.
В обоих сообщениях сохраните спокойный тон и доступный способ получить помощь. Для вопросов о балансе полезно указать команду поддержки либо кнопку, если она добавлена в ваш путь. Команда /support присутствует в других шаблонах, но не в этой схеме, поэтому не вставляйте её автоматически без настройки обработчика.
- Победное сообщение соответствует фактической награде и её условиям.
- Непобедная ветка не обещает возможность, которой нет в правилах.
- Текст не переносит из примера цены, сроки или названия партнёров.
- Путь к поддержке существует и проверен в вашем боте.
Финальная проверка
Пройдите сценарий до запуска
Проведите тестовый запуск по обеим веткам. Для победы проверьте порядок: сообщение, изменение loyalty_balance, тег fortune_winner и вывод баланса. Для другой ветки проверьте сообщение и тег fortune_lost. Убедитесь, что завершение каждой ветки не запускает неожиданную рассылку или повторный расчёт. Тестовая проверка пути не доказывает результаты акции, но помогает найти разрыв между узлами и текстом.
Если вы добавили ограничение повторов, пройдите поток второй раз тем же тестовым пользователем и посмотрите, что произойдёт. Если подключена внешняя программа лояльности, сверяйте запись в ней по безопасной тестовой процедуре. Не храните токены поставщика, адреса API или ключи в тексте сообщения и не оставляйте значения из демонстрационных настроек как рабочие секреты.
Сохраните версию правил и конфигурацию сценария на период акции. Когда меняются шанс, размер награды или условия участия, не редактируйте историю задним числом: зафиксируйте дату новой версии. Это упрощает ответы команде поддержки и разбор ситуаций, когда пользователь видел другую формулировку.