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

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

Разбор стоит начинать с одного клиента и одного ожидаемого действия. Ниже — диагностический маршрут CRM Lab, который помогает последовательно отделить отсутствие входа от корректного ограничения отправки.

Зафиксируйте воспроизводимую ситуацию

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

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

Найдите событие у нужного клиента

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

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

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

Отделите триггер от условий маршрута

Узлы Now и Repeat начинают обработку по запуску или расписанию; On event реагирует на подходящее событие. Сами эти способы входа не заменяют условия отбора. Документация Bloomreach описывает условия как отдельные узлы, через которые клиент проходит после запуска. [1]

Для событийного сценария сопоставьте фактическую передачу события с его настройками. Наличие старой записи в истории нельзя считать доказательством, что нужный запуск состоялся. Для импорта отдельно проверяйте, было ли разрешено запускать событийные сценарии. Bloomreach предупреждает, что большой импорт с такими запусками может создавать нагрузку и задержки. [2]

Дальше пройдите узлы по порядку. Запишите для каждого условия значение, доступное на момент проверки, и ожидаемую ветку. Особенно внимательно проверьте отсутствие значения, окно времени и сочетания «И» и «ИЛИ». Формулировка «есть покупка и нет возврата» требует уточнить, относятся ли события к одному заказу.

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

Проверяйте отправку отдельно

Частотная политика ограничивает число коммуникаций за выбранный период. Поэтому клиент может подходить сценарию и при этом не получить очередное сообщение. Проверяйте политику именно у нужного действия, её область применения и предыдущие коммуникации клиента. [3]

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

Условный пример. В 10:00 клиент просмотрел товар, в 10:02 прошёл условие сценария, в 11:02 достиг email-узла. Лимит уже исчерпан двумя предыдущими письмами. Исправлять триггер в этой ситуации не нужно. Команде следует решить, соответствует ли приоритет сообщения коммуникационной политике, и затем повторно проверить весь маршрут.

Устраните причину и настройте наблюдение

Исправление проверяйте на паре профилей: один должен получить сообщение, второй — обоснованно не получить. Добавьте случай с повторным событием и с покупкой во время ожидания. Для спорного участка сохраните доказательство прохождения: доступный журнал, результат узла или отдельное диагностическое событие в тестовом контуре.

В обращение в поддержку включите идентификаторы, временную последовательность, версию и ожидаемый результат. Такой набор полезнее просьбы «посмотрите, почему не работает цепочка».

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

Источники

1. Bloomreach. Design tab: Scenario building and editing. Bloomreach Engagement Documentation. Проверено 23.09.2026.

2. Bloomreach. Troubleshoot scenarios. Bloomreach Engagement Documentation. Проверено 23.09.2026.

3. Bloomreach. Frequency policy. Bloomreach Engagement Documentation. Проверено 23.09.2026.