Введение: относитесь к доставляемости как к аптайму, а не как к показателю для отчётности

Большинство команд смотрят на доставляемость SMS раз в месяц, и видят при этом единственную цифру в процентах.

«Выглядит неплохо, у нас около 95%».

Тем временем:

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

К тому моменту, когда это кто-то замечает, вы уже:

Потеряли значительную сумму выручки из-за брошенных оформлений заказа или депозитов.
Подорвали доверие («Я не получил код, ваше приложение не работает»).
Научили операторов воспринимать ваш бренд как навязчивый или рискованный.

В нашей практике разбора сотен инцидентов с доставляемостью закономерность очевидна: команды, которые относятся к доставляемости как к надёжности эксплуатации (SRE), восстанавливаются быстро. Команды, которые считают это еженедельной формальной метрикой, оказываются захвачены врасплох.

В этом руководстве мы расскажем, как:

Выбрать правильные KPI (и игнорировать те, что вводят в заблуждение).
Разбивать данные по оператору, пулу отправителей, маршруту и кампании.
Построить дашборд и систему алертинга, которая выявляет проблемы на раннем этапе.
Использовать мониторинг, чтобы улучшать доставляемость, а не просто фиксировать её.

Раздел 1: ключевые KPI доставляемости SMS, которые действительно имеют значение

Вам не нужны 40 метрик. Вам нужен небольшой набор KPI, которые напрямую связаны с инцидентами и их устранением.

1. Доля доставленных сообщений (по оператору, пулу, кампании)

Определение:

Доля доставленных = сообщения с положительными квитанциями «доставлено» ÷ общее число попыток отправки

Лучшая практика:

Всегда разбивайте показатель по:
- Оператору (Verizon, AT&T, T-Mobile, международные операторы)
- Пулу отправителей / сетке номеров
- Кампании / потоку (OTP, промо, транзакционные)
- Стране / региону

Как выглядит «норма» (для правильно настроенного A2P в США):

Основные транзакционные потоки: 99%+
Промо с высоким объёмом: 98–99%+
Всё, что стабильно держится ниже 97–98%, требует расследования.

2. Доля жёстких сбоев (hard-fail) / уровень ошибок

Определение:

Процент сообщений с окончательными кодами сбоя:
- Недействительный номер
- Неизвестный абонент
- Постоянный отказ оператора

Почему это важно:

Рост жёстких сбоев часто означает:
- Плохую гигиену базы номеров.
- Блокировку на уровне оператора конкретных отправителей или контента.
- Истощённый или «выгоревший» пул номеров.

На что обращать внимание:

Резкие скачки у одного оператора.
Конкретные маршруты или пулы с устойчивым уровнем жёстких сбоев >1–2%.

3. Доля временных сбоев (soft-fail) / повторных попыток

Определение:

Временные сбои:
- Проблемы сети
- Перегрузка
- Ограничение скорости отправки / троттлинг

Почему это важно:

Высокий уровень временных сбоев означает, что вы слишком сильно нагружаете операторов или попадаете на перегруженные маршруты.
Показывает, работает ли ваша стратегия повторных попыток или просто «долбит» канал.

4. Индикаторы «неизвестно» / отфильтровано / «ложно доставлено»

Операторы не всегда возвращают код «отфильтровано». Некоторые:

Возвращают общие ошибки.
Заявляют «доставлено», хотя устройство ничего не получает (теневая фильтрация).

Косвенные показатели для мониторинга:

Падение поведения на следующих этапах (клики, входы в систему) при «нормальных» квитанциях.
Выборочные тесты: сид-номера на каждом операторе, которые вы логируете отдельно.
Резкое падение показателей по новым кампаниям, в то время как остальные стабильны.

5. Здоровье пула и сетки номеров

Если вы используете:

Burner Number Pools (пулы «горящих» номеров)
Private Pool Grids (приватные сетки пулов)
Или даже простые выделенные номера

…вам следует отслеживать по каждому пулу/сетке:

Долю доставленных сообщений
Долю жёстких сбоев
Долю жалоб / отписок
Количество сообщений в день на одного отправителя

Признаки здорового состояния:

Стабильные показатели во времени.
Ни один отправитель не превышает:
- >1% жёстких сбоев в окне 24 часа.
- >0,3–0,5% жалоб / отписок по промо.

Раздел 2: «куб доставляемости» — как сегментировать данные

Единая глобальная «доля доставленных» скрывает всё.

Вам нужен куб доставляемости:

Оператор (Verizon, AT&T, T-Mobile и т. д.)
Отправитель (пул, сетка, отдельный номер)
Маршрут / продукт (шлюз, регион)
Кампания / поток (OTP, промо, транзакционные)
Уровень риска контента (массовый, высокорискованный, SHAFT)

Пример разреза, который выявляет реальные проблемы

Verizon × Промо × Сетка A:
- Доля доставленных падает с 99,1% до 94,4% за 48 часов.
- Жёсткие и временные сбои немного растут.
- Остальные операторы стабильны.
Действие:
- Перенести промо с сетки A на сетку B для Verizon.
- Проверить недавние изменения контента и паттерны скорости отправки.
- Временно снизить объём до базового уровня + 20% на время теста.

Без сегментации вы увидели бы только:

Глобальный показатель доставленных: 97,8% → 96,9% (пожимаем плечами).

С сегментацией вы видите:

Один конкретный узел в матрице «выгорает», в то время как остальные в норме.

Раздел 3: пороги алертов и что делать, когда они срабатывают

1. Алерты по доле доставленных, специфичные для оператора

Рекомендуемые пороги (подстраивайте под собственный базовый уровень):

Срабатывать, если доля доставленных у любого крупного оператора:
- Падает более чем на 2 пункта от 7-дневной медианы.
- Или опускается ниже 97% дольше, чем на 30–60 минут при активном трафике.

Регламент действий (runbook):

Убедитесь, что это не сбой в данных (дашборды, необработанные логи).
Проверьте:
- Недавние деплои (изменения контента, изменения маршрутизации).
- Запуск новых кампаний.
- Скачки объёма.
Меры по устранению:
- Временно снизить скорость отправки для этого оператора.
- Переключиться на альтернативный пул / сетку, если есть такая возможность.
- Приостановить новые рискованные кампании для этого оператора.

2. Алерты по здоровью пула / сетки

Срабатывание алерта при:

Превышении доли жёстких сбоев у любого пула или сетки 1–2% дольше 1 часа при значимом объёме.
Превышении доли жалоб / отписок 0,3–0,5% по промо.

Регламент действий:

Остановить отправку новых кампаний через этот пул / сетку.
Перенести часть трафика на более здоровые пулы.
Расследовать:
- Не смешали ли вы более рискованный контент с ранее «чистым» пулом?
- Не изменились ли политики оператора (например, новое правило по ключевым словам SHAFT)?

3. Алерты на теневую фильтрацию и «ложную доставку»

Поскольку явные коды ошибок не всегда видны:

Сравнивайте:
- Доставленные сообщения → ожидаемые конверсии (клики, входы в систему, использование OTP).
Срабатывание алерта при:
- Доставляемость остаётся «хорошей», но конверсия на следующих этапах резко падает для одного оператора или кампании.

Здесь критически важны:

Сид-номера для каждого оператора.
Периодические живые тесты (вручную и автоматически), которые проверяют реальность против отчётов о доставке.

Раздел 4: проектирование дашборда доставляемости SMS

Ваш дашборд не обязан быть «красивым». Он обязан быть полезным под давлением.

Макет 1: обзор для руководства

Верхнеуровневые виджеты:

Глобальная доля доставленных (за последние 24 часа, 7 дней)
Доля доставленных по операторам (Verizon, AT&T, T-Mobile, топ 3–5 международных)
% сообщений по:
- Транзакционные vs маркетинговые
- Массовые vs высокорискованные

Тренды:

Линейные графики:
- Доля доставленных по оператору во времени.
- Объём по оператору.

Используйте этот вид, чтобы ответить на вопрос: «У нас всё горит, да или нет?»

Макет 2: вид для эксплуатации / SRE

Таблицы и графики по разрезам:

Оператор × Пул × Кампания
Метрики здоровья пула (доставлено, жёсткие сбои, временные сбои, жалобы)

Примеры:

Тепловая карта: доля доставленных по операторам (столбцы) и пулам/сеткам (строки).
Таблица с сортировкой:
- «Показать пулы с наибольшей долей жёстких сбоев сегодня».

Используйте этот вид, когда срабатывает алерт.

Макет 3: аналитический / маркетинговый вид

Фокус на:

Эффективности кампаний:
- Доля доставленных vs CTR vs конверсия.
A/B-тестах:
- Варианты контента vs доставляемость.

Этот вид связывает доставляемость и выручку, облегчая обоснование инфраструктурных решений.

Раздел 5: диагностика типичных проблем по вашим метрикам

Сценарий 1: один оператор «проседает», остальные стабильны

Вероятные причины:

Фильтрация, специфичная для оператора, по:
- Паттерну контента.
- Домену URL.
- Репутации пула отправителей.

Что проверить:

Были ли недавние изменения контента или шаблона?
Используются ли новые URL? (например, изменился сервис сокращения ссылок)
Темп роста объёма: не подняли ли вы скорость слишком резко для этого оператора?

Сценарий 2: показатели падают сразу у всех операторов

Вероятные причины:

Глобальное изменение контента (например, более агрессивные промо).
Агрессивный рост объёма по всем направлениям сразу.
Изменение на уровне платформы (маршрутизация, логика пулов).

Что проверить:

Последние несколько деплоев.
Новые высокорискованные кампании.
Действительно ли соблюдаются контрольные механизмы (логика «горящих» номеров, лимиты по операторам).

Сценарий 3: метрики выглядят нормально, но в поддержку поступают жалобы «я не получил сообщение»

Вероятные причины:

Фильтрация на уровне устройства (папки со спамом).
Теневая фильтрация на уровне оператора с обманчивыми квитанциями о доставке.
Затронуты отдельные регионы (например, конкретные коды зон).

Что проверить:

Тесты на сид-устройствах для каждого оператора.
Разбивку по регионам / кодам зон.
Наличие чувствительных ключевых слов или паттернов.

Раздел 6: как мониторинг доставляемости меняет ваши инфраструктурные решения

Когда вы видите:

Какие пулы деградируют быстрее всего
Какие операторы наиболее чувствительны
Как контент и объём влияют на результат

…становится очевидным, почему инфраструктура имеет значение.

Команды, которые переходят на:

Private Pool Grids (100+ мультиоператорных SIM-карт на сетку)
Алгоритмы сопоставления с оператором (Verizon → Verizon, AT&T → AT&T)
Burner Number Pools с автоматическим выводом из эксплуатации

…могут использовать свои дашборды, чтобы:

Проактивно ротировать и охлаждать отправителей.
Проводить A/B-тесты стратегий маршрутизации, а не только контента.
Создавать индивидуальные регламенты для каждого оператора вместо универсальных решений.

Мы регулярно наблюдаем:

На 40–60% меньше инцидентов после внедрения нормального мониторинга и маршрутизации на основе сеток.
Более быстрый RCA (анализ корневых причин), потому что логи и метрики согласуются между собой.
Более конструктивные разговоры о рисках с комплаенс- и юридическими отделами («вот точно как мы контролируем злоупотребления и отслеживаем жалобы»).

FAQ: метрики и дашборды доставляемости SMS

1. Что считается «хорошей» глобальной долей доставленных?

Для здоровой, правильно построенной программы:

Транзакционные потоки: 99%+
Маркетинг с высоким объёмом: 98–99%

Всё, что ниже 97–98% по основным потокам, — тревожный сигнал.

2. Как часто нужно проверять доставляемость?

Дашборды: ежедневно (или чаще во время запусков).
Алерты: в режиме реального времени при значительных падениях.
Глубокий разбор: еженедельно или ежемесячно с анализом тренда.

3. Действительно ли нужны данные по каждому оператору отдельно?

Да. Большинство серьёзных инцидентов привязаны к конкретному оператору. Без разреза по операторам вы действуете вслепую.

4. А если у меня небольшие объёмы отправки? Не избыточно ли всё это?

Если вы:

Отправляете небольшой объём.
Работаете в низкорискованных вертикалях.
Не получаете критически важную для бизнеса выручку через SMS.

…вы можете обойтись более простым мониторингом. Но в тот момент, когда SMS становится основным источником выручки, вы захотите, чтобы всё это уже было настроено.

5. С чего начать, если мой текущий провайдер не предоставляет нормальные метрики?

Варианты:

Выгружать CDR / логи и строить собственную агрегацию.
Использовать вебхуки, чтобы логировать DLR в собственное хранилище данных.
Рассмотреть шлюз, который изначально предоставляет данные на уровне оператора.

6. Как это связано с регистрацией A2P 10DLC?

Соответствие требованиям 10DLC влияет на:

Допустимый объём отправки.
Уровень проверок.
Штрафы за злоупотребления.

Мониторинг даёт обратную связь, которая показывает:

Соответствует ли поведение ваших кампаний ожиданиям операторов.
Не приближаетесь ли вы к превышению порога.

7. Может ли мониторинг исправить плохой контент или отсутствие согласия?

Нет. Он может только показать:

Насколько плохо обстоят дела.
Где именно проблема.

Вам всё равно нужны чистый opt-in, понятные сообщения и соблюдение местного законодательства.

8. Как обнаружить спам-фильтрацию на уровне устройства?

Размещайте сид-устройства у разных операторов и на разных платформах (iOS/Android).
Сопоставляйте квитанции «доставлено» с реальными подтверждениями устройств и фактическим поведением.

9. Как сюда вписывается приватность?

Шлюз, ориентированный на приватность, должен:

Минимизировать хранение персональных данных (PII).
Предлагать понятные средства управления сроками хранения данных.
При этом всё равно предоставлять агрегированные метрики, не раскрывая чувствительный контент.

10. Нужен ли отдельный инженер по доставляемости?

Не обязательно. Но вам точно нужны:

Чёткая зона ответственности (конкретный человек, который отвечает за это).
Регламенты (runbooks) и дашборды, понятные даже неспециалистам во время инцидента.

Заключение: сделайте доставляемость наблюдаемой, прежде чем она станет дорогой проблемой

Невозможно исправить то, что вы не видите.

Базовый дашборд доставляемости и настройка алертинга позволяют:

Выявлять проблемы конкретных операторов до того, как они превратятся в катастрофу.
Доказать ROI от улучшения инфраструктуры (сопоставление с оператором, приватные сетки).
Превратить SMS из «чёрного ящика» в управляемую с операционной точки зрения систему.

Если SMS напрямую связаны с выручкой, относитесь к этому как к задаче SRE:

Оснащайте систему инструментами мониторинга.
Настраивайте алерты.
Стройте вокруг этого регламенты действий.

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