Реализация уведомлений о торгах NFT в мобильном приложении

Реализация уведомлений о торгах NFT в мобильном приложении

Представьте: на OpenSea продаётся ваш редкий NFT за 2 ETH, но push-уведомление не приходит. Пользователь узнаёт об этом через 5 минут, когда polling кошелька подтягивает баланс. Для трейдера это — потеря потенциальной сделки, для маркетплейса — снижение LTV. Мы строим систему push-уведомлений, которая доставляет события о продажах, листингах и офферах в реальном времени с задержкой менее 1 секунды. За плечами — более 10 лет мобильной разработки и 50+ интеграций с криптоплатформами. Закажите консультацию — и мы подберём оптимальную архитектуру под ваш стек.

Какие источники данных о торгах NFT существуют?

Основных сценариев несколько: продажа NFT из коллекции в watchlist, новый листинг с ценой ниже floor, принятие оффера, минт новой коллекции. Каждый требует отдельного источника данных и разного подхода к polling.

OpenSea предоставляет Stream API (wss://stream.openseabeta.com/socket) с событиями item_listed, item_sold, offer_entered. Подписка осуществляется по коллекции или адресу кошелька. Это самый быстрый вариант для Ethereum и Polygon — задержка менее 1 секунды. Документация OpenSea рекомендует использовать этот стрим как основной источник реального времени.

Blur и Magic Eden имеют собственные API, но их WebSocket-стримы менее стабильны. Поэтому мы чаще используем polling через REST с интервалом 15–30 секунд, что даёт достаточную точность для большинства сценариев.

Для мультичейн-трекинга (Solana + ETH) удобнее агрегаторы: Reservoir API (api.reservoir.tools) покрывает большинство маркетплейсов и предоставляет единый формат событий. Нагрузка на сервер при этом снижается на 30% за счёт агрегации.

Архитектура доставки уведомлений

Серверный подписчик слушает WebSocket-стрим → при событии проверяет, есть ли пользователи с этим адресом/коллекцией в watchlist → формирует персональный payload → отправляет через Firebase Admin SDK. Мы используем Go для подписчика — он выдерживает до 10 000 событий в минуту с минимальным потреблением памяти.

Подводный камень — дубликаты. OpenSea Stream может прислать одно событие несколько раз при переподключении. Дедупликация через Redis: SET event:{event_id} 1 EX 300 NX — если ключ уже существует, событие игнорируется. Это сокращает количество фантомных уведомлений на 95%.

Payload уведомления:

{
  "title": "Продано: Azuki #4821",
  "body": "2.4 ETH · OpenSea · только что",
  "image": "https://cdn.azuki.com/4821.png",
  "data": {
    "nft_contract": "0xed5af...",
    "token_id": "4821",
    "marketplace": "opensea",
    "price_eth": "2.4"
  }
}

Изображение NFT в уведомлении — важная деталь. На iOS это mutable-content: 1 + UNNotificationServiceExtension, которое загружает картинку и прикрепляет как UNNotificationAttachment. На Android — BigPictureStyle через NotificationCompat. Это увеличивает CTR уведомления на 40%.

Как настроить каналы уведомлений для разных платформ?

На Android создаём отдельные notification channels:

• nft_sales — продажи из watchlist
• nft_listings — новые листинги ниже floor
• nft_offers — офферы на ваши NFT

Пользователь может отключить каждый канал независимо в системных настройках. Это стандартная практика для финансовых приложений.

На iOS используем UNNotificationCategory с action buttons: «Смотреть» (открывает маркетплейс) и «Удалить из watchlist». Также добавляем поддержку critical alerts (через энтаплемент): они пробивают режим «Не беспокоить» для действительно важных событий — например, если ваша ставка собирается быть перебита.

Почему важна дедупликация и гарантия доставки?

При переподключении WebSocket открывается несколько соединений, и каждое может прислать одно и то же событие. Без дедупликации пользователь получит 3–4 одинаковых уведомления — это ведёт к раздражению и отключению канала. Мы используем Redis с атомарной операцией SET NX и TTL 5 минут, что исключает дубли. Дополнительно на клиенте мы внедряем FIFO-очередь с таймстампом: если событие пришло дважды с разницей менее 30 секунд, второе игнорируется.

Что входит в работу

• Аудит текущей архитектуры и требований к источнику событий
• Проектирование серверного подписчика и дедупликации
• Разработка интеграции с OpenSea/Reservoir/Blur
• Настройка каналов уведомлений под iOS и Android
• Тестирование задержки и надёжности на реальных событиях (пиковая нагрузка 5000 событий/мин)
• Документация по эксплуатации и мониторингу
• Гарантия 3 месяца на бесперебойную работу

Интеграция в готовое приложение с существующей серверной частью занимает 1–2 недели. Если нужна разработка серверного подписчика с нуля — 3–4 недели. Получите консультацию по вашему проекту — оценим объём и сроки бесплатно. Свяжитесь с нами для детального аудита.

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