Метрики доставки SMS: DLR, latency и конверсия

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

Что означает DLR

Delivery Receipt — отчёт о состоянии сообщения, который коммуникационная платформа получает по цепочке доставки и возвращает клиентской системе. Конкретные коды отличаются у операторов и поставщиков, поэтому на уровне приложения полезно иметь собственную нормализованную модель.

Минимальные состояния:

created — бизнес-система создала сообщение;
accepted — платформа приняла запрос и выполнила первичную проверку;
submitted — сообщение передано следующему участнику маршрута;
delivered — получен финальный положительный отчёт;
failed — получен финальный отрицательный отчёт;
expired — срок доставки закончился;
unknown — финальный статус не получен в установленное время.

Статус accepted подтверждает обработку API-запроса, а не доставку абоненту. Даже delivered не доказывает, что человек прочитал сообщение или выполнил действие.

Какие временные отметки сохранять

Для диагностики нужен не только финальный статус. Храните несколько отметок времени с едиными правилами часов и часовых поясов:

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

Так можно отделить задержку внутри приложения от очереди, транспорта и сети доставки. Один общий показатель «время SMS» скрывает причину и затрудняет работу с инцидентами.

Базовые показатели

Delivery rate

Доля сообщений с финальным статусом delivered среди сообщений, принятых к отправке. Знаменатель нужно фиксировать явно: исключение технически отклонённых запросов может искусственно улучшить отчёт.

Delivery within target

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

Latency percentiles

Среднее время плохо показывает редкие, но болезненные задержки. Используйте P50 для типичного опыта, P95 для контроля основной массы и P99 для хвоста распределения. Процентили считают отдельно от создания до принятия, от принятия до DLR и для полного пути.

Failure rate

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

Conversion rate

Доля сообщений, после которых произошло целевое действие: введён OTP, подтверждён заказ, открыт нужный экран или завершена запись. Для рекламных сценариев измерение и правовые основания отличаются; технический DLR не заменяет продуктовую аналитику.

Как нормализовать коды ошибок

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

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

Справочник версионируют: значение кода и его трактовка могут различаться между подключениями. Не стоит автоматически считать все временные ошибки поводом для мгновенного повтора — это может создать дубли и дополнительную нагрузку.

Правильные разрезы отчётности

Общая цифра по всему трафику часто выглядит стабильной, пока один важный сегмент деградирует. Метрики следует уметь фильтровать по:

типу сообщения: OTP, сервисное, маркетинговое;
оператору и стране назначения;
маршруту или группе маршрутов;
имени отправителя и шаблону;
часу суток и дню недели;
приложению, клиенту или бизнес-процессу;
первичной и повторной отправке;
длине и числу SMS-сегментов.

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

Как связать DLR с бизнес-результатом

Используйте единый correlation ID от бизнес-события до сообщения и целевого действия. Это позволяет ответить на вопросы, которые не видны в операторском отчёте:

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

Для OTP полезно строить воронку: запрос → принято платформой → доставлено в TTL → начат ввод → успешная проверка. Архитектурные меры для такого сценария разобраны в статье про безопасную доставку OTP.

SLI, SLO и алерты для SMS

SLI должен измерять то, что важно получателю. Например: «доля OTP, доставленных не позднее 20 секунд после запроса» или «P95 полного времени доставки сервисных сообщений». Конкретная цель SLO выбирается по статистике, договорённостям с поставщиками и критичности процесса, а не копируется из чужого проекта.

Алерт полезен, когда связан с действием. Примеры:

delivery-within-target ниже порога в течение нескольких интервалов;
P95 резко вырос относительно обычного уровня;
увеличилась доля unknown или одной группы ошибок;
один оператор отклонился от остальных;
выросли повторы без роста успешных подтверждений;
очередь отправки стареет быстрее, чем обрабатывается.

Короткие всплески сглаживают окнами и минимальным объёмом выборки, иначе команда получит много ложных уведомлений на малом трафике.

Как сравнивать SMS-платформы

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

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

Чек-лист панели качества

Принятие платформой отделено от финальной доставки.
Есть доставка внутри целевого окна, а не только общий DLR.
Показаны P50, P95 и P99, а не только среднее.
Сырые ошибки сохранены и сопоставлены с нормализованными группами.
Первичные отправки отделены от повторов.
Трафик разделяется по сценарию, оператору, маршруту и шаблону.
Метрики связаны с целевым действием через correlation ID.
Персональные данные скрыты в агрегированных отчётах.
Правила алертов проверены на достаточном объёме данных.
Команда может найти конкретное сообщение по идентификатору без поиска по открытому номеру.

Практический вывод

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

QuickTel предоставляет интерфейс и API для корпоративных SMS. При подключении заранее согласуйте набор DLR, webhook, хранение истории, отчётность и правила резервирования, а затем проверяйте показатели на собственном трафике и целевых сценариях.

Доставляемость SMS: DLR, задержка и метрики качества