Что такое ретриггер

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

Ретриггер – это повторное срабатывание условия, которое заново запускает автоматический сценарий или его часть. В маркетинге и CRM так называют повторный вход клиента в цепочку действий после нового подходящего события или выполнения заданных условий.

Клиент вернулся, а сценарий готов к этому?

Первый запуск обычно понятен: человек оставил заявку, система создала задачу. Вопросы появляются во второй раз. Тот же человек снова заполнил форму, вернулся на сайт или сделал новый заказ. Нужно повторить цепочку, продолжить прежнюю или ничего не делать? Ответ определяет бизнес-логика, а не само наличие технического события.

Слово «ретриггер» не обозначает единую кнопку во всех сервисах. Где-то говорят о повторном входе, где-то о повторном срабатывании триггера. Поэтому в техническом задании полезнее описывать событие, объект и разрешенный результат, чем ограничиваться фразой «настроить ретриггер». Знакомое слово не заменяет договоренности.

Один клиент может участвовать в нескольких разных заказах. Ограничение «только один запуск на человека» защитит от назойливости, но способно заблокировать законную обработку следующей покупки. Часто проверять нужно сочетание клиента и заказа, а для брошенной корзины – еще и конкретную корзину.

Три повтора, которые нельзя складывать в одну папку

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

В первом случае новое выполнение может быть полезно. Во втором повторное письмо или начисление бонусов обычно окажется дублем. В третьем важно повторить незавершенную операцию, не воспроизводя уже успешные действия. Иначе после восстановления связи клиент получит вторую благодарность, а бухгалтерия – первый повод для расследования.

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

Как задать условия повторного запуска

У правила должны быть границы. Укажите, что считается новым поводом, сколько времени проходит между запусками и допускается ли второй вход, пока первая цепочка еще работает. Отдельно определите, что произойдет после завершения сценария и после отказа на одном из шагов.

В условном магазине напоминание о корзине разрешено не чаще одного раза за двое суток для конкретного клиента. Перед отправкой система повторно проверяет, что корзина существует, покупка не завершена, а действующие правила коммуникации допускают сообщение. Значение «двое суток» здесь учебное: реальную паузу выбирают под продукт и поведение аудитории.

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

Откуда появляется бесконечный круг

Опасная конструкция выглядит невинно: изменение карточки запускает сценарий, а сценарий меняет ту же карточку. Если каждое изменение снова удовлетворяет стартовому условию, система начинает обслуживать собственную деятельность. Клиент в этой деловой переписке уже не требуется.

Один из способов защиты – запускать действие при переходе из одного состояния в другое, а не при любом сохранении записи. Еще один – проверять служебный признак уже выполненного шага. Такие признаки требуют аккуратности: если никогда не сбрасывать отметку, полезные повторные обращения перестанут обрабатываться.

Для интеграций с параллельными запросами недостаточно двух раздельных действий «проверить отметку» и «поставить отметку». Два обработчика могут одновременно увидеть, что события еще нет. Проверка и резервирование операции должны выполняться согласованно, например через уникальный ключ в хранилище.

Как проверить ретриггер до встречи с клиентами

1. Отправить одно новое событие и проверить результат
2. Повторить то же событие с тем же идентификатором
3. Отправить новое событие для того же клиента, но другого заказа
4. Проверить вход во время работающей цепочки и после ее завершения
5. Изменить состояние клиента во время ожидания: например, завершить покупку
6. Проверить сбой на середине цепочки и последующее восстановление

В журнале полезно видеть причину запуска или отказа, объект, идентификатор события и выполненные шаги. Запись «сценарий отработал» мало помогает, когда человек спрашивает, почему ему написали пять раз. Нужен ответ о конкретном повторе, а не свидетельство общей занятости программы.

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