Тест SMPP-шлюза занимает от дня до недели. Провайдер обычно выдаёт тестовый доступ, а вы прогоняете через него свои сообщения и смотрите, что получается. Проверять стоит три вещи: доходят ли SMS на номера разных мобильных операторов, держит ли канал пиковую скорость и насколько понятны отчёты по каждой рассылке. Ниже — чек-лист: что запросить до начала, какие сценарии прогнать и какие ошибки встречаются чаще всего.
Что запросить у провайдера до теста
Начните с тестовых учётных данных. Без них вы застрянете в переписке с менеджером уже на второй день, когда захочется перепроверить спорный случай.
- system_id и пароль для тестового подключения, IP-адрес и порт шлюза;
- режим подключения: transmitter, receiver или transceiver;
- лимит скорости на тестовом доступе и рабочий лимит после подключения;
- какие имена отправителя разрешены и как их согласовать;
- документация с описанием команд протокола и кодов ошибок;
- как считается сегмент: сколько символов влезает в кириллице и латинице.
Тестировать лучше на своих номерах, а не на абонентах провайдера. Абонент тогда видит реальный текст, реальное имя отправителя и настоящее время доставки. Заодно станет ясно, одинаково ли ведёт себя шлюз на номерах разных операторов.
Как понять, выдержит ли канал ваш объём
Сначала посчитайте, что именно нужно выдержать. Возьмите самый нагруженный час прошлого месяца и разделите число сообщений в нём на 60. Получится среднее в минуту, то есть нижняя граница. Верхняя важнее: рассылка по базе идёт пачкой, и шлюз получает сотни запросов почти одновременно.
Тестовый доступ часто урезан по скорости. Попросите поднять лимит на время теста, иначе вы измерите ограничение тарифа, а не канал. Отправляйте через тот же API или SMPP и тем же кодом, которым будете пользоваться в работе.
Смотрите не только на факт доставки, но и на разброс по времени. Если половина сообщений приходит в первую минуту, а остальные капают полчаса, при пиковой нагрузке часть клиентов получит код подтверждения с опозданием. Для транзакционных SMS это заметно, для массовых — терпимо.
Если вы смешиваете типы трафика — сервисные коды и рекламные рассылки, — уточните, нужны ли очереди на вашей стороне. У части провайдеров приоритет определяется автоматически, и писать под это код не нужно (по описанию сервиса SMSC). Как устроить локальную очередь перед шлюзом, если она всё-таки понадобится, разобрано в статье как настроить локальную очередь перед SMPP-шлюзом.
Что смотреть в статистике
Отчёты нужны не для красоты. По ним вы разбираете спорные случаи с клиентом и видите, на каком этапе теряются сообщения.
- время доставки по каждому сообщению и по кампании целиком;
- доля доставленных и список проблемных номеров;
- детализация статусов: принято шлюзом, передано оператору, доставлено абоненту;
- выгрузка в файл и уведомления о доставке на ваш сервер.
Проверяйте это на тесте, а не после подключения. Сравните свой лог отправки с отчётом в кабинете: статусы и отметки времени должны сходиться. Расхождения — повод задать вопрос до подписания договора (время доставки, доля доставленных, проблемные номера — по данным сервиса Notificore).
Если вы ещё выбираете способ интеграции, сравнение протокола и HTTP-интерфейса есть в материале SMPP или API-шлюзы: что выбрать малому бизнесу в Беларуси. Это влияет на то, какие отчёты вы вообще сможете получать.
Какие сценарии прогнать на тестовом доступе
| Сценарий | Что делаем | На что смотреть |
|---|---|---|
| Доставка | Отправить один текст на 5–10 своих номеров разных операторов | Доля доставленных, разброс по времени, подмена имени отправителя |
| Кириллица | Отправить сообщение кириллицей и латиницей | Сколько сегментов списалось, как текст выглядит у абонента |
| Пиковая скорость | Запустить пачку сообщений подряд | Растёт ли задержка, появляются ли отказы из-за перегрузки |
| Длинный текст | Отправить сообщение на несколько сегментов | Склеивается ли текст, не путается ли порядок частей |
| Сбои | Отправить на несуществующий номер, разорвать и восстановить соединение | Понятны ли коды ошибок, не появляются ли дубли |
| Отчётность | Сверить свой лог с кабинетом и выгрузкой | Сходятся ли статусы и время, приходит ли уведомление о доставке |
Если отправка идёт из учётной системы, отдельно проверьте сценарий отправки SMS из 1С через SMPP-шлюз — обмен данными между базой и шлюзом иногда даёт сюрпризы на стороне выгрузки, а не на стороне провайдера.
Типичные ошибки на тестовом доступе
- Тестируют на одном номере и одном операторе, а потом удивляются разнице в доставке.
- Смотрят только «дошло или нет» и не замеряют время доставки в час пик.
- Согласуют тестовый лимит скорости и не уточняют рабочий.
- Не проверяют поведение при обрыве соединения, а потом находят дубли в базе клиентов.
- Не сохраняют логи теста — при разборе спорной доставки нечем аргументировать.
- Путают статус «принято шлюзом» с «доставлено абоненту» и считают потери не там, где они есть.
Что зафиксировать до подписания договора
Перенесите результаты теста в договор. Рабочий лимит скорости, окно отправки в нерабочие часы, порядок связи при сбое и время реакции на обращение — эти четыре пункта закрывают большинство будущих споров. Если планируете сезонные пики, заранее посмотрите чек-лист перед сезоном пиковых нагрузок: инфраструктуру к ним готовят за месяцы, а не в день запуска.
3 шага, которые можно сделать на этой неделе:
- Запросить тестовый доступ и список параметров подключения: логин, порт, лимит, имена отправителя.
- Прогнать сценарии из таблицы на своих номерах и сохранить логи отправки.
- Сверить отчёты провайдера со своими данными и перенести лимиты и порядок связи при сбоях в договор.
