Интеграция SMS-рассылки в мобильное приложение

Представьте: ваш бэкенд отправляет 10 000 SMS синхронно через HTTP. Каждый запрос длится 100–500 мс, сервер зависает на минуты, лимит Twilio (1 SMS/сек на обычном номере) превышается за несколько секунд, и половина сообщений уходит в ошибку 429. Бюджет потерян, пользователи недовольны. Мы видели такие сценарии десятки раз.

Недавно к нам пришёл проект с аудиторией 500 000 пользователей в России и СНГ. Клиент использовал Twilio, платя $0.08 за сообщение вместо $0.02 у локального провайдера. После миграции на SMSC и настройки очереди с лимитом 30 msg/s мы сократили расходы на 60% и устранили потери сообщений. На одном проекте мы снизили стоимость сообщения с $0.07 до $0.02, что сэкономило клиенту более $2000 в месяц.

Решение — асинхронная очередь с throttling и грамотный выбор шлюза. Ниже разберём архитектуру, которая выдержит нагрузку и не сожжёт бюджет.

За 7 лет мы интегрировали SMS-рассылку в 30+ мобильных приложений — от стартапов до enterprise-проектов с миллионными аудиториями. Наш опыт показывает: 80% проблем с доставкой связаны с неправильной настройкой rate limiting и выбором шлюза не по географии.

Какой шлюз выбрать?

Сравним популярные варианты:

Типичные лимиты шлюзов по скорости:

Если ваша аудитория в России и СНГ — SMSC или аналоги. Для международных проектов — Twilio или Infobip. Мы помогаем выбрать оптимальный вариант под бюджет и требования.

const Queue = require('bull');
const smsQueue = new Queue('sms', 'redis://localhost:6379');

smsQueue.process(5, async (job) => {
  const { to, body } = job.data;
  await twilio.messages.create({ to, from, body });
  await delay(1000 / 5); // 5 msg/sec
});

Как избежать rate limiting?

Rate limiting — главная проблема bulk-рассылок. Нарушение лимитов ведёт к блокировке и потере сообщений. Правильная архитектура: очередь задач (например, RabbitMQ или Redis + BullMQ) и воркеры с throttling. Каждый воркер забирает задачу, отправляет SMS, ждёт интервал, затем следующую. Для ускорения запускают несколько воркеров параллельно, контролируя общий throughput.

Почему нельзя отправлять SMS синхронно?

Попытка отправить 10 000 SMS в одном цикле HTTP-запросов приводит к:

• Блокировке бэкенда на время всех запросов (каждый занимает 100-500 мс).
• Превышению лимита шлюза — часть запросов вернёт ошибку 429.
• Отсутствию повторных попыток при сбое сети.

Очередь решает все три проблемы: запросы неблокирующие, лимиты соблюдаются, неудачные задачи автоматически повторяются. Rate limiting — механизм, который стоит учитывать на этапе проектирования.

Что входит в работу по интеграции?

1. Анализ требований: аудит текущего приложения, выбор шлюза, расчёт бюджета.
2. Серверная часть: проектирование очереди (RabbitMQ / Redis), реализация воркеров с throttling, настройка webhook для статусов.
3. Мобильный клиент: форма составления сообщения (со счётчиком символов), выбор сегмента получателей, отслеживание прогресса через WebSocket/SSE.
4. Тестирование: нагрузочное тестирование до 50 000 сообщений, проверка rate limiting.
5. Документация: описание API, схемы, руководство по эксплуатации.
6. Поддержка: гарантия 3 месяца, консультации.

Результат — надёжная система рассылки, готовая к масштабированию.

Как отслеживать статусы доставки?

Twilio отправляет webhook на ваш эндпоинт при каждом изменении статуса: queued → sending → sent → delivered или undelivered/failed. Бэкенд агрегирует эти статусы, мобильный клиент запрашивает сводку через эндпоинт:

GET /admin/sms/jobs/{jobId}/stats
→ { "total": 5000, "sent": 4823, "delivered": 4601, "failed": 177 }

Если шлюз не поддерживает webhook (как SMSC на дешёвых тарифах), бэкенд опрашивает статусы по расписанию.

Типичные ошибки при интеграции SMS-рассылки

• Игнорирование rate limiting — приводит к блокировке и потере сообщений.
• Выбор шлюза только по цене — дешёвый шлюз может не иметь webhook-статусов, что усложняет отслеживание.
• Синхронная отправка — зависание бэкенда и превышение лимитов.
• Отсутствие повторных попыток — потеря сообщений при временных сбоях.

Сроки и стоимость

Интеграция шлюза (Twilio или SMSC), реализация очереди, мобильный UI с счётчиком, выбор сегмента и отслеживание прогресса — от 5 до 8 рабочих дней. Стоимость рассчитывается индивидуально в зависимости от сложности и выбранного шлюза. Получите консультацию нашего инженера — он подберёт шлюз под ваш бюджет и нагрузку. Свяжитесь с нами для оценки вашего проекта — мы предложим оптимальное решение под ключ.

Push-уведомления в мобильном приложении: APNs, FCM, сегментация, rich push

Мы внедрили push-уведомления в мобильном приложении для 50+ проектов — от стартапов до enterprise с аудиторией 10M+ пользователей. Нерелевантное или технически сломанное уведомление хуже его отсутствия: пользователь отключает push или удаляет приложение. Согласно отчёту Localytics, отказ от push-разрешений на iOS достигает 40% в первую неделю — причина почти всегда в нерелевантности, а не в механике. Уже через 2 недели после внедрения качественной сегментации конверсия открытия вырастает на 25–30%. Свяжитесь с нами для аудита текущей реализации — мы оценим проект и предложим оптимальный стек за один день.

Как работает инфраструктура: APNs и FCM

APNs — единственный канал доставки на iOS. Всё остальное (OneSignal, Braze, Airship) — обёртки поверх него. APNs принимает запрос по HTTP/2, аутентификация через JWT-токен (p8-ключ) или сертификат. JWT предпочтительнее: один ключ для всех приложений в аккаунте, не истекает ежегодно в отличие от сертификата. Подробнее — на Wikipedia.

Критический момент: APNs различает apns-push-type — alert, background, voip, complication, fileprovider, mdm. Неправильно указанный тип на iOS 13+ приводит к тому, что background-уведомление не разбудит приложение. Видели проекты, где content-available: 1 отправляли без apns-push-type: background — приложение не получало silent push на части устройств, и команда месяц искала «баг в приложении».

FCM на Android работает через Google Play Services. Для устройств без GMS (Huawei, часть китайского рынка) нужен Huawei Push Kit или прямой WebSocket — отдельная задача. FCM поддерживает data-сообщения (обрабатываются в onMessageReceived) и notification-сообщения (система отображает автоматически, если приложение в фоне). Смешивать их нужно осторожно: если в notification-блоке есть click_action, а deep link в приложении не зарегистрирован, тап по уведомлению просто откроет главный экран без навигации.

Почему сегментация — основа эффективных push-уведомлений?

Отправлять всем подряд — значит быстро исчерпать лояльность пользователей. Персонализированные сообщения кликают в 3 раза чаще массовых, а правильная сегментация снижает отток на 25% (на одном из проектов это принесло дополнительный доход 3 млн рублей за квартал). Стоимость настройки сегментации в OneSignal или кастомном бэкенде составляет от 100 000 до 250 000 рублей в зависимости от сложности фильтров.

Нормальная сегментация строится на нескольких уровнях.

Топики — для широких категорий: «новые акции», «обновления статуса заказа». Пользователь подписывается через FirebaseMessaging.getInstance().subscribeToTopic("orders"). Просто, но нет гибкой фильтрации.

Сегменты по атрибутам — через OneSignal, Braze или кастомный бэкенд. Храним в профиле пользователя: язык, тип устройства, последняя активность, LTV-сегмент. Уведомление уходит только тем, у кого last_active < 7_days и plan = premium. OneSignal позволяет строить такие фильтры в интерфейсе без кода.

Персонализированные — по конкретному device_token. Важно хранить токены правильно: токен обновляется при переустановке приложения, при восстановлении из бэкапа на новый телефон, при сбросе настроек. На iOS используем UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, сохраняем на бэкенд при каждом запуске, не только при первом. Иначе через 3 месяца 30% токенов в базе устаревшие.

Что такое rich push и как он повышает конверсию?

Стандартное уведомление с заголовком и текстом кликают реже, чем rich push с картинкой и кнопками действий — в 3 раза. Но реализация rich push — отдельная работа на каждой платформе.

На iOS rich content требует UNNotificationServiceExtension (для модификации payload) и UNNotificationContentExtension (кастомный UI). Расширение запускается в отдельном процессе с ограниченным временем и памятью. Если расширение падает или превышает таймаут, система показывает оригинальный payload без медиа. Типичная ошибка — пытаться загрузить изображение по HTTP (не HTTPS): ATS заблокирует запрос, расширение молча завершится, пользователь увидит уведомление без картинки.

На Android с API 26+ уведомления привязаны к NotificationChannel. Если канал создан с IMPORTANCE_LOW, звук и вибрация недоступны. Разные типы уведомлений (транзакционные, маркетинговые) должны быть в разных каналах, чтобы пользователь мог отключить маркетинг, не теряя уведомлений о заказах. BigPictureStyle, MessagingStyle, InboxStyle — шаблоны для расширенных уведомлений. MessagingStyle с Person и аватарками — лучший выбор для чатов.

Как отследить доставку и конверсию push-уведомлений?

Отправить уведомление — полдела. Важно знать: доставлено ли оно, открыто ли, привело ли к целевому действию.

FCM отдаёт MessageId при отправке, но не гарантирует коллбэк о доставке — это by design. Для tracking открытий нужна кастомная логика: при тапе на уведомление в onMessageReceived или через getInitialNotification() / onNotificationOpenedApp (OneSignal SDK) отправляем событие в аналитику с notification_id.

OneSignal предоставляет встроенную аналитику доставки и CTR. Для более детального анализа — интегрируем с Amplitude или Mixpanel через webhook на событие открытия. Бюджет такого дашборда составляет от 50 000 до 150 000 рублей в зависимости от объёма событий.

Как мы внедряем push-уведомления: типовой процесс

1. Аудит текущей реализации — проверяем хранение токенов, обработку обновлений, типы уведомлений.
2. Проектирование архитектуры — выбираем транспорт (FCM + APNs), слой сегментации (OneSignal/Braze/кастом), способ персонализации.
3. Реализация — пишем код регистрации, обработки входящих, rich push, deep linking.
4. Тестирование — отправляем тестовые кампании, проверяем доставку на разных устройствах, симуляторах, регионах.
5. Мониторинг и аналитика — настраиваем дашборд, события открытия и конверсий.
6. Документация и обучение — передаём команде материалы по эксплуатации.

Типичный стек: FCM + APNs на транспортном уровне, OneSignal или Firebase Notifications Composer для сегментации, кастомный бэкенд для персонализированных событийных уведомлений. Для крупных приложений с >1M пользователей OneSignal имеет ценовые ограничения — тогда используем Braze или собственную реализацию на AWS SNS.

Сроки зависят от сложности: базовая интеграция FCM+APNs с транзакционными уведомлениями — 1–2 недели. Полноценная система с сегментацией, rich push, аналитикой и A/B-тестированием контента — 4–8 недель. Закажите аудит текущей push-инфраструктуры или получите консультацию по внедрению push-уведомлений в мобильном приложении — мы свяжемся с вами в течение дня и предоставим точную оценку.