IOSOR База знань
DLR другий місяць: коли частка Unknown стає звичкою
Аналіз ризиків хронічного статусу Unknown на другому місяці роботи та методи покращення прозорості доставки.
На другому місяці масштабування SMS-операцій важливо переглянути ставлення до метрик, які раніше вважалися допустимими. Якщо на початку високий відсоток статусів «Unknown» сприймався як похибка інтеграції, то тепер це операційний ризик. На відміну від Пілотний тиждень DLR: чесність статусів після перших живих відправок, де закладається фундамент довіри, другий місяць вимагає відсутності «сірих зон» у звітності для забезпечення стабільного ROI.
Від первинного аналізу до системної стабільності доставки
Протягом першого місяця увага зазвичай зосереджена на Тиждень рахунків за DLR: невістка частка не є доставкою для звірки білінгу. На другому місяці пріоритетом стає технічна досконалість. Постійний статус «Unknown» свідчить про розрив у передачі сигналу від кінцевого оператора до вашого вебхука. Якщо понад 3% трафіку залишається без чіткого статусу, ви втрачаєте контроль над якістю маршрутів, що критично для OTP та транзакційних повідомлень.
Чому статус Unknown не має ставати нормою
Звичка ігнорувати «Unknown» створює технічний борг. За цим статусом часто ховаються події не доставлено, відхилено, прострочено, які не були коректно оброблені мережею. Для white-label сервісу це критично: неможливість пояснити клієнту долю 20% його повідомлень у кампанії 10DLC на другому місяці співпраці підриває репутацію. Ви повинні розглядати такі показники як сигнал до негайної зупинки та аудиту.
Технічна інтеграція вебхуків та JIT-активація номерів
Щоб позбутися статусу «Unknown», перевірте стабільність вашого HB (heartbeat) для вебхуків. IOSOR використовує модель JIT (Just-In-Time) для призначення номерів: вони виділяються з препейд-холду саме в момент потреби. Це запобігає використанню «сплячих» номерів, які часто дають помилкові статуси. Якщо ваша система не встигає підтвердити отримання DLR, IOSOR може позначити транзакцію як невідому. Оптимізуйте обробку вхідних даних для роботи з великими пакетами SMS.
Поріг масштабування та софт-рев'ю на рівні 1 000 USD
Зі зростанням обсягів посилюється контроль за якістю трафіку. IOSOR працює за моделлю передплати з мінімальним порогом 20 USD. Коли ваш щомісячний оборот наближається до 1 000 USD, платформа автоматично ініціює софт-рев'ю показників доставки. Висока частка «Unknown» на цьому етапі може свідчити про неактуальність бази або проблеми з контентом. Цей процес допомагає захистити ваш аккаунт перед переходом на рівень Enterprise.
Таблиця відповідності статусів DLR та якості трафіку
| Статус | Цільовий показник | Операційна дія |
|---|---|---|
| Delivered | > 92% | Оптимізація витрат |
| Unknown | < 2% | Перевірка латентності вебхука |
| Rejected | < 1% | Валідація бази через HLR |
| Expired | < 3% | Коригування TTL повідомлень |
| Undelivered | < 2% | Аналіз фільтрації контенту |
Почніть роботу з IOSOR
На другому місяці вважайте стоячу частку Unknown звичкою, не погодою. Назвіть власника щотижневого полювання. Експортуйте повторювані коридори й закривайте кожен клас Unknown, замість жити з відсотком. Це не стоп інциденту, не передрук рахунку і не хвіртка очистки тижня відновлення.
Підсумок IOSOR
Unknown другого місяця — звичка, яку полюють щотижня, не маршрут, з яким миряться.
Робіть: призначте полювання, закривайте Unknown клас за класом, не дайте відсотку стати нормою.
Не робіть: казати «так цей маршрут» чи чекати наступного тижня інциденту.
Чи був матеріал корисним?
Пов’язані гіди
- Порівняння показників доставки для коротких та toll-free номерів
Аналіз ефективності доставки повідомлень між короткими номерами та toll-free маршрутами у white-label CPaaS із фокусом на фільтрацію та DLR.
- Базові метрики deliverability на пілоті нового маршруту
Проводьте детальні тести доставки, аналізуйте показники мереж та формуйте базові метрики перед масштабуванням white-label трафіку на нових маршрутах.
- Аудит показників доставки та очищення черг після обслуговування мережі
Покроковий технічний посібник для платформних менеджерів щодо перевірки здоров'я маршрутів та безпечного скидання затриманихвіт DLR після технічних робіт.