Почему push-уведомления критичны для торгового бота?
Торговый бот закрыл позицию ночью — пользователь увидел уведомление утром. За это время цена ушла на 8%, и момент для реакции уже упущен. Мы решаем эту проблему: push-уведомления для торгового бота — не «приятная фича», а часть рабочего процесса трейдера. Задержка доставки в 10–20 минут — стандартное поведение для обычных push. Но для сделок это катастрофа: стоп-лосс сработал, а трейдер узнаёт об этом через час. FCM с приоритетом high доставляет уведомление в 3 раза быстрее normal. На iOS APNs с interruption-level: time-sensitive обходит режим «Не беспокоить» и Focus. Именно эта разница превращает бота из красивой игрушки в рабочий инструмент.
Согласно документации Firebase, high-priority уведомления доставляются с задержкой не более 5 секунд в 99% случаев.
Что здесь ломается чаще всего
Типичная проблема: бот работает на сервере, отправляет уведомление через FCM, но на Android с включённым battery optimization уведомление приходит с опозданием 10–20 минут. Причина — Doze Mode откладывает сетевые операции, FCM использует «normal priority» по умолчанию. Для финансовых уведомлений нужен явный "priority": "high" в FCM payload, тогда сообщение доставляется через high-priority channel и будит устройство.
На iOS похожая история с Background App Refresh — если пользователь отключил его для приложения, бэкграунд-fetch не сработает. Единственный надёжный способ — APNs push с content-available: 1 или interruption-level: time-sensitive. Мы настраиваем сертификаты и provisioning profile так, чтобы уведомления проходили в любом состоянии приложения.
Архитектура уведомлений для бота
Бот генерирует событие (открытие/закрытие сделки, срабатывание стоп-лосса, достижение тейк-профита) → серверный обработчик формирует payload → Firebase Admin SDK отправляет в FCM/APNs.
Минимальный payload для сделки:
{ "notification": { "title": "BTC/USDT ✅ Закрыто +2.3%", "body": "Buy 0.05 BTC @ 67,420 → Sell @ 68,980" }, "android": { "priority": "high" }, "apns": { "headers": { "apns-priority": "10" }, "payload": { "aps": { "interruption-level": "time-sensitive" } } }, "data": { "trade_id": "t_9182", "symbol": "BTCUSDT", "pnl": "2.31" } } data поле используется для deep link — тап открывает экран конкретной сделки с деталями. Мы реализуем Universal Links (iOS) и App Links (Android), чтобы переход работал даже если приложение свёрнуто.
Типы уведомлений и их приоритет
| Событие | Приоритет FCM | APNs interruption-level |
|---|---|---|
| Стоп-лосс сработал | high | time-sensitive |
| Тейк-профит | high | time-sensitive |
| Открытие позиции | high | active |
| Дневной отчёт | normal | passive |
| Ошибка подключения к бирже | high | time-sensitive |
Разделение важно: пользователь может разрешить «критические» уведомления даже в режиме «Не беспокоить» — это работает через iOS Focus Filters и Android notification channels с IMPORTANCE_HIGH. Для дневных отчётов используем normal priority — они не должны будить ночью.
Сравнение доставки на разных платформах
| Платформа | Механизм доставки | Типичная задержка | Приоритет по умолчанию |
|---|---|---|---|
| Android (FCM) | High-priority channel | 1–5 сек | normal → high |
| iOS (APNs) | Critical alert (time-sensitive) | 1–3 сек | passive → time-sensitive |
Технические требования для интеграции
- Серверная часть: Node.js, Python или любой язык с Firebase Admin SDK.
- Мобильное приложение: Flutter 3.x или React Native 0.70+.
- Наличие учетной записи Firebase и Apple Developer Program.
- Для Android: минимальный API 26. Для iOS: iOS 15+.
Клиентская часть
На Flutter реализуем через firebase_messaging пакет. Главное — правильно обработать три состояния: foreground, background, terminated. В terminated state уведомление обрабатывается через FirebaseMessaging.instance.getInitialMessage() при следующем старте приложения. На React Native — @react-native-firebase/messaging, логика та же.
Запрос разрешений делаем не при старте, а при первом действии, связанном с ботом — конверсия в разрешение на уведомления вырастает с 30% до 70%.
Как гарантировать доставку в Doze Mode?
На Android мы используем комбинацию: FCM high-priority + явное указание канала с IMPORTANCE_HIGH. Если устройство в глубоком Doze, уведомление всё равно доставляется, так как high-priority FCM имеет право на обход. Дополнительно можно добавить запрос на исключение из батарейной оптимизации — мы включаем это в работу, если требуется.
На iOS для background-пробуждения используем content-available: 1 и сертификат VoIP или push с apns-priority: 10. Важно: time-sensitive уведомления не блокируются Focus режимами, если пользователь не запретил их специально.
Процесс внедрения push-уведомлений
- Аналитика: изучаем архитектуру бота, определяем события для уведомлений.
- Проектирование: выбираем приоритеты, настраиваем каналы, готовим схемы deep link.
- Реализация: интеграция FCM/APNs, обработка состояний на клиенте, тестирование на реальных устройствах.
- Деплой: загрузка в App Store Connect / Google Play Console, настройка сертификатов.
- Мониторинг: логируем доставку, отслеживаем опоздания >1 минуты.
Что входит в работу
- Настройка Firebase проекта и сертификатов APNs.
- Реализация серверного API для отправки уведомлений.
- Код клиентской обработки (Flutter или React Native).
- Глубокие ссылки на экраны сделок.
- Документация по использованию и поддержке.
- Гарантия доставки 99% уведомлений в течение 5 секунд.
Сроки интеграции в готовое приложение: 3–7 дней при наличии серверной части бота. Стоимость рассчитывается индивидуально — напишите нам, чтобы оценить проект под ключ.
Экономия на упущенных сделках может достигать 15% от портфеля ежемесячно. Оцените свой проект — свяжитесь с нами. Получите консультацию — обсудим, как push-уведомления улучшат ваш торговый бот.







