Push-уведомления для React Native и веба: платите за устройства, а не за сообщения

Сервис Espresso Notify предложил считать оплату за push-уведомления по числу активных устройств, а не по количеству отправленных сообщений. Разбираемся, что это значит на практике и какие подводные камни остаются.

Считать плату за каждое push-сообщение — значит наказывать разработчика за то, что он общается с пользователями: новая модель с оплатой за активное устройство делает счёт предсказуемым, но пока это скорее маркетинговый ход молодого сервиса, чем отраслевой стандарт.

На первый взгляд новость выглядит узко-разработческой: какая-то компания изменила модель оплаты для сервиса push-уведомлений. Но если подумать, речь идёт о вещи, которая касается каждого из нас напрямую. От того, сколько стоит отправить уведомление, зависит, как часто приложения будут дёргать ваш телефон. Когда каждое сообщение — это расход для разработчика, команда думает дважды, прежде чем прислать вам что-то. Когда оплата фиксированная, а сообщений можно отправить сколько угодно, стимулы меняются — и не всегда в лучшую для нас сторону.

О чём вообще речь

Push-уведомления — это те всплывающие плашки на экране блокировки: «ваш заказ передан курьеру», «вас упомянули в комментарии», «не забудьте про запись к врачу». Технически всё устроено так: приложение получает на вашем устройстве специальный адрес-токен, отправляет его на сервер разработчика, а тот через Apple, Google или браузерную службу шлёт вам сообщение.

Сервисов, которые занимаются доставкой таких сообщений, много: OneSignal, Firebase Cloud Messaging, Braze, Airship и другие. Каждый берёт деньги за эту посредническую работу, и почти все считают по одному из двух принципов: либо по числу отправленных сообщений, либо по числу месячных активных пользователей (MAU — Monthly Active Users, то есть людей, открывших приложение хотя бы раз за месяц).

Espresso Notify, чей SDK вышел для React Native и веба, предлагает третий вариант: платить за «активное устройство». Устройство считается активным, если вы открывали приложение за последние 30 дней. И неважно, получили вы за это время одно уведомление или пятьдесят — цена одна и та же. Первые 10 тысяч устройств бесплатны.

Почему старые схемы раздражают

Логика здесь понятна, и её стоит разобрать подробнее, потому что обе традиционные модели действительно имеют изъяны.

Оплата за сообщение бьёт по тем, кто чаще всего общается с пользователем. Банк, который присылает подтверждение каждой транзакции, платит больше календарного приложения, которое напоминает о встрече раз в неделю. То есть сервис дороже обходится тем, кто делает уведомления полезными, а не спамными. Справедливости ради замечу: у платы за сообщение есть и обратная сторона — она сдерживает поток мусора. Если каждое уведомление стоит денег, меньше соблазна слать рекламу пачками.

Оплата за месячных активных пользователей считает всех, кто заходил в приложение, даже если уведомления вы отключили или они вам просто не нужны. Получается, разработчик платит за людей, до которых на самом деле ничего не доносит.

Модель с активным устройством выглядит аккуратнее: число устройств примерно равно числу установок за последний месяц, это легко спрогнозировать. Не нужно гадать, вырастет ли вовлечённость и попадёте ли вы в следующий тарифный порог.

Что именно предлагает сервис

Кроме необычной тарификации, Espresso Notify собирает под одной крышей довольно стандартный, но полезный набор инструментов. Один дашборд, из которого кампания пишется один раз и уходит сразу на iOS, Android и в браузеры — не нужно собирать три отдельные рассылки. Есть сегменты аудитории по свойствам и поведению пользователя, а также отдельные «тестовые устройства», чтобы проверить уведомление на своих телефонах до общей отправки.

Отдельно стоит отметить аналитику доставки: для каждого отправления видно, дошло ли оно, открыли его или оно не прошло — с указанием причины сбоя. Распространённый случай — токен, который устройство больше не использует: человек удалил приложение или переустановил его, а старый адрес остался в базе. Без такой диагностики разработчик отправляет сообщения в пустоту и не понимает почему.

Для автоматических сообщений — например, «ваш пароль изменён» — есть REST API с ключами идемпотентности. Это технический термин, который проще всего объяснить бытовым примером: если запрос с сообщением «с вами связался курьер» по какой-то причине не прошёл и система отправила его повторно, вы не получите две одинаковые пушки. Сообщение не задублируется.

Есть и ограничители, которые призваны защитить нас, пользователей, от перегруза: «тихие часы» — уведомления не приходят ночью, и частотные лимиты — сколько сообщений человек может получить за период. Плюс сценарии («journeys») и A/B-тесты для рассылок посложнее, чем одно сообщение.

Как это ставят на проект

Для React Native SDK выходит в npm под именем @espresso-notify/react-native. Установка сводится к одной команде:

npx @espresso-notify/react-native@latest setup

Мастер настройки сам читает package.json и подстраивается под проект. Если это Expo (нужен SDK 53 или новее), он ставит нужные пакеты и добавляет конфигурационный плагин. Если это «голый» React Native CLI (версия 0.79 или новее) — устанавливает Firebase-пакеты и пакеты уведомлений, прописывает строки в Podfile, Gradle и AppDelegate, а потом перечисляет, что осталось сделать руками: например, положить файлы Firebase. Веб-версия push-уведомлений описана в тех же документах отдельным руководством.

Звучит гладко, но здесь важно отделить обещания от реальности. Любая автоматическая настройка выглядит лучше в демо, чем на живом проекте с кучей своих зависимостей. Обещание «одна команда — и всё работает» — классический маркетинговый приём разработческих сервисов; на деле почти всегда остаётся ручная возня с ключами, сертификатами и разрешениями. Впрочем, перечисление того, что мастер не делает за вас, — признак честной документации, а не обмана.

Что стоит помнить, прежде чем довериться

Первое и главное: Espresso Notify — очень молодой сервис. Аккаунт на площадке DEV Community, где был опубликован анонс, создан 29 октября 2026 года, то есть в тот же день, что и сам пост. Это буквально первая публичная презентация проекта. Отсутствие отзывов, кейсов и истории работы — не повод списывать сервис со счетов, но и повод для полного доверия тоже нет.

Второе: сам текст анонса отмечен как «AI-assisted», то есть написан при участии искусственного интеллекта. Для рекламного поста это нормально, но сигнал к тому, что формулировки стоит проверять сами.

Третье: в анонсе нет цен за платные тарифы. Бесплатные 10 тысяч устройств — щедрый стартовый порог, но что будет дальше — 11-го тысячного устройства, неизвестно. Для стартапа это критично: если проект взлетит, отсутствие понятного прайса может ударить по бюджету сильнее, чем привычная модель оплаты за сообщения.

И наконец, четвёртое: сама идея «безлимитных» сообщений за фиксированную плату таит риск. Сервисы, которым платят не за отправку, могут быть менее заинтересованы в том, чтобы ограничивать поток уведомлений. Отсюда и «тихие часы», и частотные лимиты в списке функций — но как хорошо они работают на практике, покажет только время.

Что в итоге

Модель оплаты за активное устройство — здравая мысль, которая делает расходы на уведомления предсказуемыми и не наказывает разработчика за живое общение с аудиторией. Для команд на React Native и Expo, уставших собирать доставку push-сообщений по кусочкам, появление ещё одного «всё в одном» сервиса — приятная новость.

Но до настоящей конкуренции с OneSignal или Firebase новичку пока далеко: нет ни репутации, ни открытых тарифов, ни подтверждённой надёжности. Попробовать на бесплатном лимите, потестировать на своём проекте и только потом решать — разумный путь. Хорошая новость для нас как пользователей тут простая: чем больше подобных сервисов с честной аналитикой доставки и ограничителями частоты, тем меньше шансов, что ваш телефон будет звенеть без причины.