IOSOR

IOSOR База знань

Виключення у кампаніях: пропущені повідомлення не є збоями в балансі

Як CPaaS-платформи обробляють попередні виключення без впливу на резервування балансу, метрики доставки та фінансову звітність.

Виключення у кампаніях: пропущені повідомлення не є збоями в балансі.

Механізми попередньої перевірки виключень у масових розсилках

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

Відмінність статусів SKIPPED та FAILED у фінансовому реєстрі

Частою причиною помилок під час звірки кампаній є об'єднання пропущених повідомлень із мережевими збоями доставки. Мережевий збій відбувається після відправки повідомлення на маршрут, тоді як статус SKIPPED присвоюється до будь-якої взаємодії з мережею. Коли повідомлення не доходить через перевантаження мережі, помилки маршрутизації SMSC або недоступність абонента, статус DLR фіксує помилку, і попереднє резервування перетворюється на фактичне списання.

Резервування коштів у передплачених гаманцях та логіка виконання

У платформах із передплатною архітектурою запуск кампанії ініціює тимчасове блокування коштів на балансі. Якщо кампанія містить 10,000 номерів, система розраховує суму блокування тільки для валідних адресатів. Якщо 1,000 номерів перебувають у списку виключень, платформа одразу виключає їх із розрахунку. Розглянемо приклад із базовою вартістю USD 20 за 1,000 повідомлень.

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

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

Експорт операційних даних для корпоративного фінансового обліку

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

Почніть з IOSOR

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

Підсумок IOSOR

Ця стаття доводить, що статус SKIPPED фіксується ще до взаємодії з шлюзами, тому він не створює платних транзакцій і не повинен списувати кошти з рахунку. Чітке розмежування локальних відхилень та мережевих помилок DLR забезпечує повну прозорість білінгу та усуває розбіжності між логами систем і підсумковими інвойсами.

Робіть: налаштовуйте роздільну обробку статусів у вебхуках та фінансових експортах для точної звірки реальних витрат на кампанії. Не робіть: не об'єднуйте пропущені через списки придушення номери з помилками доставки, щоб не викривляти показники конверсії та фінансову звітність.

Чи був матеріал корисним?

Пов’язані гіди