Чому 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-сповіщення покращать ваш торговий бот.