Разработка Telegram-бота для массовых рассылок в мобильном приложении

Почему массовая рассылка через Telegram требует очереди задач?

Мы получаем много запросов на интеграцию Telegram-бота для рассылок. Open rate таких сообщений достигает 70–90% — против 20–25% у email. Но прямая отправка 50 000 сообщений за раз гарантированно приводит к бану: Telegram отвечает ошибкой 429 Too Many Requests. Правильная реализация требует учёта rate limits и очереди задач. Мы предлагаем готовое решение под ключ, учитывающее все нюансы Telegram Bot API.

В этой статье вы узнаете, как построить отказоустойчивую систему рассылок, избежать бана и обеспечить доставку 99% сообщений. Мы поделимся архитектурными решениями, которые используем в коммерческих проектах.

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

Многие разработчики пытаются обойти ограничения через мультиаккаунты или увеличение интервала. Это неэффективно: мультиаккаунты нарушают правила Telegram, а увеличение интервала растягивает рассылку на часы. Наш подход использует официальные возможности API и гарантирует соблюдение лимитов без риска бана.

Как Telegram ограничивает частоту сообщений?

Telegram разрешает отправлять максимум 30 сообщений в секунду для обычного бота и не более 20 сообщений в минуту в один чат. При превышении API возвращает 429 Too Many Requests с полем retry_after. Согласно документации Telegram Bot API, эти лимиты жёсткие.

50 000 получателей = минимум ~28 минут чистой отправки при правильном rate limiting. Реализация через простой цикл for с sendMessage упадёт на первой же крупной рассылке.

Правильный подход: очередь задач (Bull + Redis или RabbitMQ). Каждое сообщение — отдельная задача в очереди, воркер обрабатывает их с контролируемой скоростью (25 задач/сек с экспоненциальным backoff при 429).

Как организовать очередь задач для массовой рассылки?

Серверная часть: Node.js + Bull Queue + Redis. Администратор через мобильное приложение создаёт рассылку (текст, медиа, сегмент аудитории) → задача попадает в очередь → воркер отправляет с нужной скоростью → статус рассылки обновляется в реальном времени. Такой подход гарантирует, что бот не превысит лимиты и не будет забанен.

Мобильное приложение — панель управления: создание рассылки с rich text редактором, выбор сегментов аудитории, планирование по времени, просмотр статистики (отправлено/доставлено/ошибки).

Сегменты аудитории хранятся в PostgreSQL: теги, активность за последние N дней, язык интерфейса. SQL-запрос формирует список chat_id для конкретного сегмента прямо перед отправкой.

Как настроить очередь задач: пошаговая инструкция

1. Установите Redis и запустите сервер.
2. Создайте очередь в Node.js с помощью Bull: const Queue = require('bull'); const messageQueue = new Queue('notifications', { redis: { port: 6379 } });
3. Добавьте в очередь задачу при получении команды от админа: messageQueue.add({ chatId, text });
4. Настройте воркер с ограничением скорости: 25 задач в секунду, с повтором при ошибке 429 через 5 секунд.
5. Запустите несколько воркеров для параллельной обработки.

Сравнение: очередь задач против цикла for

Очередь с backoff в 10 раз надёжнее прямого цикла for — при 50 000 получателей она снижает число ошибок 429 до нуля. Цикл for блокирует бота, очередь же адаптируется к лимитам.

Push-уведомления для администратора

Отметим: когда рассылка завершена или возникла ошибка (например, бот временно заблокирован), приложение должно уведомить администратора. Используем FCM push:

• "Рассылка #42 завершена: 48 231 / 50 000 доставлено" — тип normal
• "Ошибка: бот заблокирован пользователями (>30%)" — тип high

На клиенте (Flutter) используем flutter_local_notifications для foreground, firebase_messaging для background/terminated.

Аналитика и поддержание чистоты базы

Базовая метрика — delivery rate. Telegram не возвращает факт прочтения (нет read receipts для bot messages в личных чатах), но возвращает ошибки: 403 Forbidden — пользователь заблокировал бота, 400 Bad Request: chat not found — пользователь удалил аккаунт.

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

Что входит в работу

Сравнение подходов к очередям

const Queue = require('bull');
const messageQueue = new Queue('notifications', { redis: { port: 6379 } });

messageQueue.process(async (job) => {
  try {
    await bot.sendMessage(job.data.chatId, job.data.text);
  } catch (error) {
    if (error.response && error.response.statusCode === 429) {
      const retryAfter = error.response.body.retry_after;
      await job.retry({ delay: retryAfter * 1000 });
    }
  }
});

Ориентировочные сроки

Полная система (сервер + мобильное приложение) — от 3 до 5 недель. Интеграция модуля в существующий бот и приложение — от 1 до 2 недель. Стоимость рассчитывается индивидуально после оценки объёма работ.

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

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-уведомлений в мобильном приложении — мы свяжемся с вами в течение дня и предоставим точную оценку.