Что такое каскад — и чем он не является
Каскад — это не набор каналов с очерёдностью попыток. Это управляемая последовательность, в которой каждый следующий шаг зависит от определённого условия, а вся цепочка имеет чёткое условие остановки. Без последнего элемента любой «каскад» — это параллельная отправка с задержкой, которая неизбежно приводит к дублям.
Правильное понимание каскада начинается с вопроса не «какие каналы подключить», а «при каком действии клиента задача коммуникации считается выполненной». Ответ на этот вопрос определяет всё остальное: порядок каналов, интервалы, условия перехода и условие остановки.
Событие как единица проектирования
Прежде чем выбирать каналы, нужно описать событие. Событие — это факт в системе или в жизни клиента: запрошен код авторизации, изменился статус заказа, приближается запись. Для каждого события нужно определить четыре параметра.
Кому нужно сообщить — конкретный получатель или сегмент, а не «всем клиентам».
Сколько времени событие сохраняет смысл — код авторизации: минуты. Статус заказа: часы. Напоминание о записи: до момента визита или отмены.
Какое действие клиента означает «задача выполнена» — ввод кода, подтверждение, оплата, просмотр уведомления.
Что делать, если событие устарело до завершения каскада — отменить цепочку без дополнительных отправок.
Почему технический статус не равен бизнес-результату
Одна из ключевых ошибок в каскадах — использовать технический статус доставки как единственный триггер перехода или остановки. Технический статус отвечает на вопрос «что произошло с попыткой отправки». Бизнес-статус — «выполнена ли задача коммуникации».
Для PUSH: сообщение передано в операционную систему — технический успех. Уведомление появилось на экране и было замечено клиентом — другой вопрос. Для SMS: статус доставки подтверждён — технический успех. Клиент прочитал и ввёл код — бизнес-результат.
Правило перехода к следующему каналу должно соответствовать задаче сценария. Для верификации переход может происходить при технической недоставке или короткой задержке — там скорость критична. Для сервисного статуса переход при отсутствии клика может быть избыточным: клиент мог увидеть уведомление, не совершив видимого действия.
Пять параметров рабочего каскада
Единый идентификатор события — связывает все попытки доставки к одному источнику. Без него SMS и PUSH — два независимых расхода, не связанных в единый сценарий.
Условие перехода — конкретный статус или событие: техническая недоставка, ошибка, отсутствие признака доступности канала, истечение интервала ожидания.
Интервал ожидания — определяется сроком жизни события, а не единой настройкой. Слишком короткий интервал создаёт дубли (статус первого канала не успел прийти). Слишком длинный — оставляет клиента без информации.
Условие остановки — бизнес-действие клиента (код введён, платёж совершён) или устаревание события (срок истёк, запись отменена). Лимит попыток как дополнительный предохранитель.
Порядок проверки доступности — если у системы есть данные о получателе (нет приложения, отключены уведомления), нет смысла пробовать недоступный канал первым. Это сокращает задержку и упрощает аналитику.
Контент: почему текст для SMS и PUSH не должен совпадать
У каналов разный формат, длина и способ отображения. SMS требует краткости: получатель должен понять, что произошло и что делать, за один взгляд. Важен лимит 70 символов кириллицы на сегмент — превышение увеличивает стоимость отправки. PUSH может включать диплинк в нужный раздел приложения.
При этом смысл сообщения должен быть единым по всей цепочке. Нельзя в SMS указать один срок действия кода, а в PUSH — другой. Нельзя предлагать в разных каналах разные действия. Перед запуском проверьте персональные подстановки, ссылки и время жизни кода — в рамках одного теста для всей цепочки, а не для каждого канала отдельно.
Как пилотировать: что смотреть
Каскады редко стоит внедрять сразу для всех сценариев. Правильный подход — выбрать один процесс с достаточным объёмом, понятным результатом и умеренными последствиями ошибки. Хороший первый кандидат: уведомление о статусе заказа или напоминание о записи.
На пилоте смотрите на цепочку целиком, а не только на долю сообщений, остановившихся на первом канале. Важные метрики: доля событий с дублями, доля событий, потребовавших резервного канала, доля событий, отменённых как неактуальные, и изменение числа обращений в поддержку по данному сценарию.
Если расходы по сценарию растут без роста числа событий — одно событие генерирует лишние отправки. Если доля завершённых событий ниже ожидаемой при хороших технических статусах — каскад останавливается по неверному условию.
Инфраструктура
Для управляемого каскада недостаточно доступа к нескольким каналам. Нужна интеграция с источником события — CRM, сайтом, приложением или внутренней системой. Нужна единая история попыток и статусов, привязанная к идентификатору события. Без этого нельзя видеть, что происходило с конкретным уведомлением, и нельзя отличить дубль от корректного резервного маршрута.
Автоматические каскады с единой аналитикой по каналам и интеграцией с CRM, сайтом и приложением поддерживает платформа i-digital direct. Практическая ценность — команда видит всю цепочку по конкретному событию и может корректировать условия без ручной сверки разных систем.
Итог
Каскадная рассылка — не технология доставки сообщений во что бы то ни стало. Это архитектурное решение о том, как система ведёт себя при недоставке и когда она останавливается. Чем точнее описаны событие, условия перехода и момент остановки, тем меньше дублей для клиента и тем прозрачнее расходы для бизнеса. Каскадные рассылки.
