Как тестировать доставляемость SMS перед массовой рассылкой

Перед массовой SMS-рассылкой малому бизнесу в Беларуси стоит проверить не только текст, но и весь маршрут сообщения: API или SMPP-соединение, имя отправителя, статусы доставки и номера разных операторов. Такой тест помогает найти ошибки в интеграции, увидеть задержки и понять, какие сообщения операторская фильтрация принимает хуже. В статье разберём практический сценарий проверки, который можно выполнить до запуска основной кампании без сложной перестройки системы.

Что именно нужно проверить до рассылки?

Доставляемость складывается из нескольких этапов. Сначала ваша система формирует сообщение и передаёт его через API или SMPP-шлюз. Затем провайдер передаёт SMS оператору, оператор определяет маршрут, а телефон абонента возвращает статус. Сбой на любом участке изменит результат, поэтому одна тестовая отправка на один номер ничего не показывает.

Для проверки подготовьте небольшую тестовую группу. В неё включите номера разных мобильных сетей, несколько устройств и разные типы телефонов. Если бизнес работает с клиентами в Минске, Бресте, Гомеле или небольших населённых пунктах, полезно проверить номера абонентов из разных регионов. Такой подход показывает, связана ли проблема с маршрутом, сетью или конкретной настройкой телефона.

Зафиксируйте для каждого сообщения четыре момента:

• время отправки из вашей системы;
• время передачи сообщения шлюзу;
• статус доставки, который вернул провайдер;
• фактическое время получения SMS на телефоне.

Сравнение этих данных помогает отделить техническую задержку от недоставки. Если система получила положительный ответ на запрос, это ещё не подтверждает, что абонент прочитал сообщение: нужен финальный статус доставки, или DLR.

Как провести тест через API или SMPP?

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

Сначала отправьте сообщение на тестовый номер вручную. Затем повторите отправку через тот же API-метод или SMPP-сессию, который будет использовать рабочая система. Проверьте:

• корректность номера в международном формате;
• имя отправителя и его отображение на телефоне;
• кодировку кириллицы;
• длину текста и число сегментов;
• обработку ответа шлюза;
• приём DLR и связь статуса с конкретным сообщением.

При работе по SMPP отдельно проверьте состояние соединения. Сессия должна корректно устанавливать bind, поддерживать соединение и обрабатывать ответы шлюза. Ошибка в команде или тайм-аут легко превращаются в очередь сообщений, которые приложение считает отправленными, хотя шлюз их не принял. Для небольшого проекта полезно заранее описать повторную отправку и исключить бесконечные повторы одного SMS.

Практическая схема выглядит так: приложение создаёт уникальный идентификатор сообщения, отправляет SMS, сохраняет ответ шлюза, ждёт DLR и меняет итоговый статус только после получения результата. Если статус не пришёл за заданный интервал, запись попадает в отдельный список для проверки. Подход к обработке ошибок SMPP разобран в материале как автоматически обрабатывать ошибки SMPP и не терять SMS.

Как понять результаты тестовой отправки?

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

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

Как проверить текст и имя отправителя?

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

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

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

Какие ошибки чаще всего портят тест?

• Проверка одного номера вместо группы с разными сетями и устройствами.
• Оценка доставки только по ответу API без финального DLR.
• Тест короткого текста, хотя в рассылке планируется длинное сообщение с кириллицей и ссылкой.
• Повторная отправка без ограничения количества попыток.
• Смешение тестовых и рабочих номеров в одном отчёте.
• Запуск всей базы сразу после первого удачного SMS.

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