IOSOR

IOSOR База знаний

Исключения в кампаниях: пропущенные сообщения не являются сбоями в балансе

Разбор механизмов предварительной фильтрации в CPaaS: влияние исключений на резервирование баланса, финансовый учет и точность метрик.

Исключения в кампаниях: пропущенные сообщения не являются сбоями в балансе.

Принципы предварительной проверки исключений в массовых рассылках

При выполнении массовых SMS-кампаний по динамическим базам клиентов управление отписавшимися абонентами является технической и нормативной необходимостью. Когда конечный получатель отправляет ключевое слово STOP, его номер в формате E.164 заносится в локальную базу исключений. Во время последующих запусков кампания проверяет каждый целевой номер по этой базе перед отправкой сетевых пакетов операторам.

Различие статусов SKIPPED и FAILED в финансовом реестре

Частой причиной ошибок при сверке кампаний является объединение пропущенных сообщений с сетевыми сбоями доставки. Сетевой сбой происходит после отправки сообщения на маршрут, тогда как статус SKIPPED присваивается до любого взаимодействия с сетью. Когда сообщение не доходит из-за перегрузки сети, ошибок маршрутизации SMSC или недоступности абонента, статус DLR фиксирует ошибку, и предварительное резервирование превращается в фактическое списание. Напротив, запись SKIPPED означает, что система корректно отфильтровала номер до отправки.

Резервирование средств в предоплаченных кошельках и логика исполнения

В платформах с предоплатной архитектурой запуск кампании инициирует временную блокировку средств на балансе. Если кампания содержит 10,000 номеров, система рассчитывает сумму блокировки только для валидных адресатов. Если 1,000 номеров находятся в списке исключений, платформа сразу исключает их из расчета. Рассмотрим пример с базовой стоимостью USD 20 за 1,000 сообщений. Если пользователь запускает 50,000 сообщений с предполагаемой суммой USD 1,000, но 5,000 номеров находятся в списке исключений, биллинг корректно удержит только USD 900.

Журналы аудита и мониторинг на всех уровнях платформы

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

Экспорт операционных данных для корпоративного финансового учета

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

Начните с IOSOR

Откройте консоль IOSOR и проверьте настройки пре-флайт фильтрации перед запуском рассылки. Перейдите в раздел интеграции шлюза и настройте вебхуки для раздельной обработки статусов SKIPPED и FAILED. Убедитесь, что финансовый движок снимает временные удержания средств сразу после исключения заблокированных номеров.

Итог IOSOR

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

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

Был ли материал полезен?

Связанные гайды