Чому масова розсилка через 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 або кастомному бекенді становить індивідуальну суму залежно від складності фільтрів.

Нормальна сегментація будується на кількох рівнях.

Теми — для широких категорій: «нові акції», «оновлення статусу замовлення». Користувач підписується через 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 на подію відкриття. Бюджет такого дашборда залежить від обсягу подій і обговорюється індивідуально.

Як ми впроваджуємо 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.

Що входить у роботу (deliverables)

• Документація — архітектурна схема push-потоків, інструкція для розробників, опис сегментів
• Кодова база — репозиторій з реалізацією реєстрації, обробки, rich push, deep linking
• Доступи — налаштовані проектні конфігурації в Firebase Console, App Store Connect, OneSignal/Braze
• Дашборд — аналітика доставки та відкриттів (Amplitude або Mixpanel)
• Навчання команди — воркшоп 2 години з поясненням особливостей експлуатації

Типові помилки, яких варто уникнути

• Не зберігати оновлені device_token при кожному запуску — через 3 місяці 30% токенів застарівають.
• Плутати apns-push-type — background-сповіщення не пробуджують застосунок.
• Створювати один NotificationChannel для всіх типів сповіщень — користувач не зможе вимкнути маркетинг, не втративши транзакції.
• Завантажувати медіа в rich push по HTTP — ATS блокує запит на iOS.
• Не перевіряти deep link у таргетингу — переходи йдуть на головний екран.

Терміни та вартість

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

Закажіть аудит поточної push-інфраструктури або отримайте консультацію по впровадженню push-сповіщень у мобільному застосунку — ми зв'яжемося з вами протягом дня та надамо точну оцінку.