Мобільний додаток Whale Alerts із затримкою менше секунди

Як побудувати систему Whale Alerts із затримкою менше секунди

Велика транзакція на $50 млн пройшла в мережі — користувач дізнався про це через 40 хвилин, вже після того, як ринок відреагував. Така затримка робить трекер марним. Ми вирішуємо це завдання: будуємо архітектуру сповіщень із затримкою менше секунди, щоб користувач отримував сигнал раніше за конкурентів. Проблема посилюється тим, що блокчейн-дані надходять нерівномірно: в години високої активності (наприклад, під час великих рухів біткоїна) навантаження на канали зростає. Без оптимізації доставки сповіщення можуть губитися або затримуватися. Наш підхід базується на прямому підключенні до WebSocket-стрімів провідних бірж та блокчейн-експлорерів, минаючи проміжні сервери.

Як мобільний додаток Whale Alerts обробляє великі транзакції?

Отримайте таке ж рішення для вашого проекту. Зв'яжіться з нами для оцінки. Архітектура будується на трьох компонентах: серверний воркер, канал доставки та клієнтська логіка. Воркер підписується на стріми даних, при виявленні транзакції вище порогу (наприклад, >500 BTC або >$1M) відправляє payload через FCM (Android) і APNs (iOS). Клієнт отримує сповіщення у фоні та відображає його.

Звідки беруться дані і чому це складніше, ніж здається

Більшість команд починають з публічного API Whale Alert (api.whale-alert.io) або аналогів — Glassnode, Nansen, CryptoQuant. Проблема не в отриманні даних, а в тому, що їх потрібно доставити до пристрою раніше, ніж це зробить конкурент.

Класична схема: мобільний клієнт polling кожні 30 секунд. Це вбиває батарею, перевантажує сервер і все одно дає затримку 15–30 секунд. На Android це ще й конфліктує з Doze Mode — WorkManager відкладає завдання, коли екран вимкнено.

Робоча схема виглядає інакше:

• Серверний воркер підписується на WebSocket-стрім (wss://stream.binance.com, wss://ws.blockchain.info/inv) або polling з частотою 5–10 секунд
• При виявленні транзакції вище порогу (наприклад, >500 BTC або >$1M) воркер формує payload і відправляє через FCM (Android) і APNs (iOS) одночасно
• Клієнт отримує сповіщення у фоні, відображає його через UNUserNotificationCenter (iOS) або NotificationCompat.Builder (Android)

На iOS важливо правильно налаштувати apns-priority: 10 для термінових сповіщень — інакше APNs може буферизувати доставку до наступного wake-up пристрою. Для цього потрібен entitlement com.apple.developer.usernotifications.time-sensitive. Цей флаг гарантує негайну доставку. Статистика показує, що 95% таких сповіщень доставляються менш ніж за 1 секунду, а uptime серверної частини досягає 99.9%.

Як забезпечити доставку сповіщень у реальному часі?

Ключовий елемент — прямий канал без проксі. Для iOS використовуємо APNs через HTTP/2 напряму (бібліотека node-apn або @parse/node-apn) — це швидше, ніж через FCM-проксі. Різниця в затримці невелика, але при високому навантаженні (>10K пристроїв) прямий APNs стабільніший.

Стек сервера: Node.js воркер + Redis Pub/Sub для розподілу завдань між кількома інстансами + Firebase Admin SDK для відправки.

Payload сповіщення містить мінімум даних — тільки те, що потрібно для відображення та deep link:

{
  "title": "🐋 BTC: 1,200 BTC → Binance",
  "body": "$72.4M · 2 хвилини тому",
  "data": {
    "tx_hash": "a1b2c3...",
    "chain": "bitcoin",
    "amount_usd": 72400000
  }
}

Deep link відкриває екран детальної транзакції через Universal Links (iOS) або App Links (Android).

Чому фільтрація на клієнті критична?

Користувач не хоче отримувати сповіщення про кожну транзакцію на $500K — він налаштовує пороги. Типовий набір фільтрів:

Ці налаштування зберігаються на сервері та прив'язані до FCM-топіку або до індивідуального токена. Перший варіант простіший для розсилки, другий — гнучкіший для персоналізації. На практиці використовуємо гібридну схему: топіки для загальних порогових подій (whale_btc_1m) та індивідуальні токени для watchlist-адрес.

На стороні додатку фільтри реалізуємо через UNNotificationServiceExtension (iOS) — розширення перехоплює сповіщення до показу і може його відхилити або модифікувати на основі локальних налаштувань. На Android аналогічно через FirebaseMessagingService.onMessageReceived() з ручним викликом або пропуском NotificationManager.

Моніторинг доставки

Firebase Console показує тільки базову статистику. Для production важливо відстежувати:

• Delivery rate — відсоток успішно доставлених сповіщень (FCM Analytics)
• Time-to-deliver — час від виявлення події до отримання на пристрої
• Open rate — скільки користувачів натиснули

Для time-to-deliver використовуємо власну метрику: сервер пише timestamp відправки в payload, клієнт логує timestamp отримання і відправляє дельту в аналітику (Mixpanel або власний ClickHouse).

Що входить в роботу

При замовленні ви отримуєте:

• Архітектурну документацію (схема взаємодії, вибір стеку)
• Інтеграцію з джерелами даних (узгодження API)
• Налаштування push-сповіщень (FCM + APNs)
• Клієнтську частину (iOS/Android) з фільтрацією та deep linking
• Моніторинг та алертинг
• Доступ до вихідного коду та репозиторію
• Інструкції з розгортання та підтримки

Етапи роботи

1. Аудит джерел даних — вибір API, оцінка затримки та надійності стрімів
2. Архітектура серверного воркера — polling/WebSocket, обробка дублів, rate limiting
3. Налаштування FCM + APNs, отримання сертифікатів/ключів
4. Реалізація клієнтської частини — запит дозволів, обробка токенів, deep linking
5. Система фільтрів користувача — UI налаштувань, синхронізація з сервером
6. Тестування на реальних пристроях (Doze Mode, Background App Refresh)
7. Моніторинг та алертинг

Терміни: від 2 тижнів для базової інтеграції (готовий бекенд + один стрім даних) до 5–6 тижнів при розробці з нуля з кастомними фільтрами та підтримкою 5+ блокчейнів. Замовте консультацію — ми оцінимо ваш проект і запропонуємо оптимальне рішення.

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-сповіщень у мобільному застосунку — ми зв'яжемося з вами протягом дня та надамо точну оцінку.