Как сравнить тарифы push-уведомлений для приложения: лимиты, цена и SLA

Какие параметры тарифа push-уведомлений сравнивать до расчёта бюджета

Тариф push-уведомлений кажется простым: есть база пользователей, есть отправки, есть цена в месяц. На практике итоговый счёт часто отличается от рекламной цены, потому что сервисы считают лимиты по-разному: по MAU, по количеству устройств, по числу отправленных сообщений, по API-вызовам, по сегментам или по объёму аналитики.

Перед сравнением тарифов зафиксируйте не «хотим отправлять пуши», а конкретный сценарий приложения.

Минимальный набор вводных:

• сколько активных пользователей в месяц: например, 10 000, 50 000 или 250 000 MAU;

• сколько устройств приходится на одного пользователя: одно устройство или несколько;

• сколько push-уведомлений отправляется одному пользователю в неделю;

• есть ли массовые рассылки, триггерные уведомления, транзакционные сообщения;

• нужны ли сегменты: город, язык, тариф пользователя, поведение в приложении;

• нужна ли A/B-проверка текста, времени отправки и deep link;

• сколько членов команды будет работать в панели;

• нужен ли API-доступ и webhooks;

• сколько месяцев должна храниться история кампаний и событий.

Если приложение отправляет только 2–3 сервисных уведомления в месяц, достаточно базового тарифа. Если push — часть удержания, продаж или операционной коммуникации, дешёвый тариф быстро упрётся в ограничения.

MAU, устройства и подписчики — это не одно и то же

Один из частых источников ошибки — смешивать MAU, токены устройств и подписчиков.

MAU — это активные пользователи за месяц. Токены устройств — технические идентификаторы для отправки push. У одного пользователя может быть смартфон, планшет и переустановленное приложение, из-за чего токенов будет больше, чем людей. Подписчики — это пользователи, которые разрешили уведомления.

Пример: у приложения 40 000 MAU, push разрешили 65%, то есть 26 000 пользователей. Но токенов может быть 31 000–35 000 из-за нескольких устройств и старых установок. Если тариф считает не MAU, а устройства, запас нужен минимум 15–25%.

Проверьте в условиях тарифа, что именно входит в лимит:

• активные пользователи;

• все зарегистрированные пользователи;

• устройства;

• push-токены;

• отправленные сообщения;

• доставленные сообщения;

• API-запросы;

• события аналитики.

Если поставщик не объясняет метод подсчёта, бюджет нельзя считать точным.

Массовые, триггерные и транзакционные уведомления

Не все push-уведомления одинаковы по ценности и требованиям к стабильности.

Массовые уведомления — это акции, новости, обновления. Их можно отправлять с задержкой, тестировать и дозировать. Триггерные уведомления завязаны на событие: пользователь бросил корзину, завершил регистрацию, не открыл приложение 7 дней. Транзакционные уведомления связаны с действием пользователя: подтверждение операции, статус заказа, вход в аккаунт, изменение настроек безопасности.

Для транзакционных push важны скорость и надёжность. Для маркетинговых — сегментация, аналитика, A/B-тесты и контроль частоты. Если сервис предлагает один общий тариф без разделения по сценариям, уточните, есть ли приоритетная очередь для критичных сообщений.

Что должно быть в тарифе без доплат

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

В тарифе для коммерческого приложения обычно нужны:

• REST API для отправки уведомлений;

• SDK для iOS и Android;

• поддержка Firebase Cloud Messaging и Apple Push Notification service;

• сегментация пользователей;

• персонализация текста;

• deep links;

• расписание отправки;

• локализация по языку;

• отчёты по отправке, доставке, открытиям;

• экспорт статистики;

• роли и права доступа для команды;

• журнал ошибок;

• техническая поддержка;

• документация и примеры интеграции.

Если часть этих функций доступна только на старших тарифах, сравнивайте именно тот уровень, который закрывает ваш сценарий, а не самый дешёвый пакет.

Таблица проверки

Эту таблицу удобно использовать при запросе коммерческого предложения. Для тиража или проекта запросите 3 сметы: базовую, оптимальную и срочную. В каждой отдельно отметьте сроки 3–7 дней для первичной интеграции или аудита, гарантию на выполненные настройки и стоимость переделки, если после теста выяснится, что формат событий, SDK или файлов интеграции не подходит.

Как посчитать реальную стоимость: MAU, отправки, сегменты, API и перерасход

Реальная стоимость push-сервиса считается не от красивой цены на сайте, а от нагрузки. Лучше собрать модель в таблице и прогнать минимум три сценария: текущий месяц, рост на 30% и пиковый месяц.

Шаг 1. Посчитайте базу для уведомлений

Начните с MAU и доли пользователей, которые разрешили push.

Пример:

• MAU приложения: 80 000;

• разрешили уведомления: 60%;

• активная push-аудитория: 48 000;

• среднее число устройств на пользователя: 1,15;

• технических токенов: около 55 200.

Если тариф считает MAU, ориентир — 80 000. Если считает подписчиков — 48 000. Если считает устройства или токены — 55 200. Разница между этими вариантами может изменить тарифный уровень в 1,5–2 раза.

Шаг 2. Рассчитайте количество отправок

Формула простая:

Количество отправок в месяц = push-аудитория × среднее число уведомлений на пользователя.

Если 48 000 пользователей получают в среднем 8 push в месяц, это 384 000 отправок. Добавьте запас 20% на акции, повторные отправки, тесты и сезонные пики. Получится 460 800 отправок.

Если сервис берёт условно $0,50–$2 за 1 000 отправок сверх лимита, перерасход в 100 000 отправок будет стоить $50–$200. Если перерасход считается не за отправки, а за пользователей, итог может быть выше.

Шаг 3. Учтите сегменты и автоматизации

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

Проверьте:

• сколько сегментов можно создать;

• есть ли динамические сегменты;

• сколько условий можно использовать в одном сегменте;

• обновляются ли сегменты в реальном времени;

• есть ли лимит на пользовательские атрибуты;

• можно ли строить сегмент по событиям за 7, 30, 90 дней;

• оплачиваются ли автоматические сценарии отдельно.

Если команда планирует retention-кампании, тариф без нормальных сегментов приведёт к ручным выгрузкам и ошибкам.

Шаг 4. Проверьте API-вызовы и rate limits

Push-сервис может быть недорогим по отправкам, но ограниченным по API. Это критично для приложений, где уведомления создаются событиями в бэкенде: доставка, бронирование, запись, финансовая операция, изменение статуса.

Запросите у поставщика:

• лимит API-запросов в минуту;

• лимит API-запросов в сутки или месяц;

• политику повторных запросов при ошибках 429, 500, 503;

• наличие idempotency key, чтобы не отправить дубль;

• webhooks по статусам доставки и отказам;

• отдельную очередь для транзакционных сообщений.

Для небольшого приложения может хватить 60–300 запросов в минуту. Для продукта с массовыми событиями лучше закладывать 1 000+ запросов в минуту или отдельную схему пакетной отправки.

Шаг 5. Добавьте стоимость интеграции и сопровождения

Даже если сервис стоит недорого, подключение требует работы разработчиков. В смете должны быть не только лицензия и подписка, но и трудозатраты.

Обычно в проект входят:

• проверка документации;

• установка SDK;

• настройка FCM и APNs;

• обработка разрешений на уведомления;

• регистрация и обновление push-токенов;

• настройка пользовательских событий;

• тестовые отправки;

• проверка deep links;

• настройка ролей в панели;

• логирование ошибок;

• подготовка инструкции для команды.

Для простого приложения первичная интеграция может занять 3–7 рабочих дней. Если есть несколько платформ, сложная аналитика, собственный backend и миграция с другого сервиса, срок легко увеличивается до 2–4 недель.

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

Шаг 6. Сравните итоговую стоимость владения

Соберите все расходы за 12 месяцев:

• абонентская плата;

• перерасход по MAU или отправкам;

• платные функции старшего тарифа;

• стоимость API или событий аналитики;

• хранение истории;

• платная поддержка;

• интеграция;

• миграция;

• доработки после тестирования;

• обучение команды;

• возможный простой при сбоях.

Пример расчёта для приложения с 80 000 MAU:

В таком примере «дорогой» тариф оказывается дешевле по совокупной стоимости. Поэтому сравнение только по абонентской плате даёт неверное решение.

SLA, доставляемость и поддержка: что влияет на стабильность уведомлений

Push-уведомления зависят не только от выбранного сервиса. В цепочке есть приложение, backend, push-провайдер, платформы Apple и Google, сеть пользователя, настройки устройства и разрешения. Но хороший сервис должен показывать, на каком этапе произошла ошибка.

Что смотреть в SLA

SLA — это не маркетинговая фраза про надёжность, а условия доступности и ответственности.

Проверьте:

• процент доступности: 99,5%, 99,9%, 99,95%;

• что именно входит в доступность: API, панель, отправка, webhooks;

• как измеряется простой;

• какие исключения прописаны;

• есть ли компенсация при нарушении SLA;

• где публикуется статус сервиса;

• как быстро поставщик сообщает об инциденте.

Разница между 99,5% и 99,9% выглядит небольшой, но в месяц это разные допуски простоя. 99,9% — примерно до 43 минут недоступности в месяц, 99,5% — более 3 часов. Для маркетинговых push это может быть терпимо, для транзакционных — уже риск.

Какие метрики доставки должны быть в отчётах

Минимальный отчёт «отправлено» почти бесполезен. Он не показывает, получил ли пользователь уведомление и что случилось после отправки.

Нужны отдельные статусы:

• created — уведомление создано;

• queued — поставлено в очередь;

• sent — отправлено в инфраструктуру доставки;

• delivered — доставлено на устройство, если платформа отдаёт такой статус;

• opened — пользователь открыл уведомление;

• failed — отправка завершилась ошибкой;

• unsubscribed или permission denied — пользователь запретил уведомления;

• expired token — токен устарел;

• invalid token — токен некорректен.

Для продуктовой команды важны CTR, open rate, delivery rate, unsubscribe rate и доля ошибок по платформам. Если после рассылки на 100 000 пользователей открытий всего 1 000, нужно понимать: текст слабый, время выбрано неверно, сегмент не тот или уведомления не доставились.

Почему доставляемость нельзя обещать как 100%

Ни один сервис не может честно гарантировать 100% доставку push на устройства. На результат влияют:

• пользователь отключил уведомления;

• устройство без сети;

• включён режим энергосбережения;

• приложение давно не открывали;

• токен устарел;

• payload превышает допустимый размер;

• ошибка в сертификатах APNs;

• сбой в FCM или APNs;

• пользователь удалил приложение;

• система ограничила фоновые процессы.

Поэтому правильный вопрос к поставщику — не «гарантируете ли 100% доставку», а «какие статусы и ошибки вы покажете, чтобы мы могли найти проблему».

Поддержка: что должно быть прописано

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

Проверьте:

• канал поддержки: чат, email, тикет-система, телефон;

• часы работы: 8/5, 12/5, 24/7;

• время реакции по критичным инцидентам;

• время реакции по обычным вопросам;

• кто имеет право создавать тикеты;

• есть ли выделенный инженер;

• входят ли консультации по интеграции;

• оплачиваются ли разборы ошибок отдельно.

Для продакшен-приложения нормальный ориентир: реакция на критичный инцидент в течение 1–4 часов, на обычный вопрос — до 1 рабочего дня. Если поддержка отвечает «по возможности», это не SLA.

Документы, которые стоит запросить

До оплаты запросите не только счёт, но и комплект документов.

Минимальный список:

• договор или оферта;

• SLA;

• техническое описание API;

• документация SDK;

• соглашение об обработке данных или DPA, если передаются пользовательские данные;

• политика хранения и удаления данных;

• описание ролей доступа;

• порядок резервного копирования;

• регламент поддержки;

• акт выполненных работ, если есть интеграция или настройка.

Если поставщик подключает сервис «по договорённости в чате», без ТЗ и документов, при сбое будет сложно доказать, что именно должно было работать.

Когда дешёвый тариф push-уведомлений не подходит приложению

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

Много транзакционных уведомлений

Если приложение отправляет уведомления о статусах операций, входах, подтверждениях, бронированиях или изменениях в аккаунте, нужен стабильный API, понятные очереди, мониторинг и поддержка. Тариф без SLA и логов ошибок может сорвать критичную коммуникацию.

Особенно опасно, если транзакционные и маркетинговые push идут через одну очередь без приоритета. Массовая рассылка может задержать важные сервисные сообщения.

Быстро растёт база пользователей

Если сегодня у приложения 20 000 MAU, а через 3 месяца планируется 100 000 MAU, тариф «до 25 000 пользователей» может быть ловушкой. Переход на следующий уровень иногда стоит не на 20–30% дороже, а в 2–4 раза.

Попросите расчёт сразу для трёх уровней:

• текущая нагрузка;

• рост на 50%;

• рост в 3 раза.

Так видно, где у сервиса резкий ценовой порог.

Нужна точная сегментация

Если push используется для удержания, возврата и продаж, без сегментов сервис быстро перестанет подходить. Отправлять всем одно и то же — значит повышать отписки и снижать доверие к уведомлениям.

Дешёвый тариф может ограничивать:

• количество сегментов;

• количество атрибутов;

• обновление сегментов;

• импорт событий;

• частотные ограничения;

• персонализацию;

• автоматические цепочки.

Если команда не может отделить новых пользователей от платящих, активных от уснувших, iOS от Android, сравнение тарифа нужно пересмотреть.

Нет нормальной аналитики

Без аналитики push превращаются в шум. Команда видит только факт отправки, но не понимает, что сработало.

Тариф не подходит, если в нём нет:

• открытия уведомлений;

• статистики по платформам;

• ошибок доставки;

• динамики отписок;

• воронки после клика;

• экспорта данных;

• хранения истории хотя бы 90 дней.

Для продуктовых решений лучше иметь историю 6–12 месяцев, чтобы сравнивать сезоны, релизы и изменения коммуникации.

Есть риск миграции

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

Что может пойти не так:

• старый сервис не отдаёт экспорт токенов;

• часть токенов устарела;

• форматы payload отличаются;

• deep links работают иначе;

• SDK конфликтует с текущей аналитикой;

• нет тестового стенда;

• команда не знает, какие события реально используются;

• после миграции падает open rate, но нет диагностики.

Типовые риски: нет ТЗ, размытые сроки, устные правки, скрытая стоимость дополнительных работ, неподходящий формат файлов или отсутствие поддержки после запуска. Чтобы снизить риск, до миграции сделайте тест на небольшой аудитории: например, 5–10% пользователей или один внутренний сегмент.

Нет запаса на переделки

Даже при хорошем ТЗ после теста могут появиться доработки: изменить payload, добавить атрибуты, исправить обработку deep link, разделить маркетинговые и транзакционные уведомления, донастроить роли, добавить события аналитики.

В смете заранее укажите:

• сколько итераций правок входит в стоимость;

• срок реакции на правки;

• стоимость часа доработки;

• что считается ошибкой исполнителя;

• что считается новым требованием;

• действует ли гарантия после запуска;

• сколько дней длится гарантийный период.

Если этого нет, дешёвое подключение может стать дороже нормального тарифа с сопровождением.

Что важнее при выборе тарифа: цена за месяц или лимит MAU?

Важнее итоговая стоимость при вашей нагрузке. Тариф за $99 может стать дороже тарифа за $299, если в первом платные сегменты, дорогой перерасход, нет аналитики и поддержки.

Какой запас по лимитам закладывать?

Обычно закладывают 20–30% к текущему MAU и отправкам. Если приложение растёт быстро или есть сезонные пики, считайте отдельный сценарий с ростом в 2–3 раза.

Нужно ли платить за push, если FCM и APNs бесплатные?

FCM и APNs обеспечивают инфраструктуру доставки на платформы, но не закрывают весь продуктовый слой: сегменты, аналитику, сценарии, роли, отчёты, A/B-тесты, поддержку, мониторинг и удобную панель управления.

Что считать нормальным SLA для push-сервиса?

Для рабочего приложения ориентируйтесь на 99,9% и выше. Для критичных транзакционных уведомлений дополнительно проверяйте приоритетные очереди, статус-страницу, поддержку 24/7 и регламент инцидентов.

Можно ли доверять показателю доставляемости 100%?

Нет. Push зависит от устройства, разрешений, сети, токенов, платформ Apple и Google. Надёжный сервис не обещает абсолютную доставку, а показывает статусы и причины ошибок.

Какие документы запросить у поставщика?

Запросите договор или оферту, SLA, документацию API и SDK, DPA или соглашение об обработке данных, регламент поддержки, политику хранения данных и смету на интеграцию, если поставщик участвует в настройке.

Сколько времени занимает подключение push-сервиса?

Простая интеграция обычно занимает 3–7 рабочих дней. Если есть миграция, несколько платформ, сложные события, аналитика и проверка deep links, срок может увеличиться до 2–4 недель.

Что опаснее всего в дешёвом тарифе?

Самые частые проблемы — скрытый перерасход, отсутствие SLA, слабая аналитика, ограничения API, нет поддержки после запуска и платные функции, которые нужны уже в первый месяц.

Как проверить тариф до оплаты?

Попросите тестовый доступ, документацию, пример отчёта, описание лимитов и расчёт на ваших цифрах. Затем сделайте пилот: один сегмент, несколько типов уведомлений, проверка доставки, ошибок, открытий и реакции поддержки.

Нужны ли A/B-тесты в push-сервисе?

Если push используются для удержания, продаж или возврата пользователей — да. Без A/B-тестов команда не сможет проверить текст, время отправки, сегмент и частоту. Для чисто сервисных уведомлений это менее критично.

Что включить в ТЗ на внедрение?

Укажите платформы, события, пользовательские атрибуты, типы уведомлений, форматы payload, deep links, роли доступа, отчёты, SLA, тестовые сценарии, сроки, гарантию, порядок правок и стоимость переделок.

Как понять, что тариф уже стал мал?

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