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