Push-уведомления 2026: FCM, APNs, Web Push, OneSignal

Push уведомления в 2026 году — это уже не «пищалка для скидок», а инфраструктурный канал для продукта: доставки OTP, статусов заказов, тревожных событий, реактивации и аккуратного маркетинга. В этом гайде разберём FCM, APNs, Web Push, OneSignal, Pushwoosh и SendPulse: где они работают, где ломаются, как внедрять SDK и какие ограничения учитывать в России.

Цены, лимиты, версии продуктов и зарплатные диапазоны в материале даны как ориентиры на момент публикации. Точные значения сверяйте по сайтам провайдеров и актуальным исследованиям рынка.

Что такое push в 2026 и где применяется

Канал, который живёт между продуктом и операционкой

Push — это сообщение, которое приходит пользователю через инфраструктуру платформы: APNs на iOS и macOS, FCM на Android и в части веб-сценариев, браузерные push-сервисы для Web Push. Приложение не обязано быть открытым: операционная система принимает событие, решает, можно ли его показать, и отдаёт его в центр уведомлений, на экран блокировки или в обработчик приложения.

В 2026 году push стоит воспринимать как транспорт с жёсткими правилами, а не как бесплатную рекламную трубу. Apple, Google и браузеры всё сильнее ограничивают шум: требуют явного согласия, режут фоновые сценарии, группируют уведомления, дают пользователю быстрый opt-out. Если продукт шлёт мусор, он теряет разрешение на канал быстрее, чем успевает нарисовать красивый retention-график.

Где push действительно нужен

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

• Transactional: OTP, чеки, статусы заказов, security alerts.
• Product: комментарии, назначения задач, завершение обработки файла.
• Marketing: персональные офферы, брошенная корзина, win-back.
• Media: breaking news, подборки, live-события.
• B2B: алерты мониторинга, SLA, согласования, инциденты.

Короткая карта технологий

Платформа	Базовая технология	Типичная интеграция	Ограничения
iOS, iPadOS, macOS	APNs	Нативный SDK, backend provider, token-based auth	4 КБ payload, строгие разрешения, фокус-режимы
Android с Google Services	FCM	Firebase SDK, HTTP v1 API, Admin SDK	4 КБ payload, зависимость от GMS
Web	Push API, Service Worker, VAPID	JS SDK или собственный backend	HTTPS, разрешение браузера, различия Safari/Chrome/Firefox
Мультиканал	OneSignal, Pushwoosh, SendPulse	SDK провайдера, сегменты, API	Стоимость, vendor lock-in, хранение данных

Push уведомления хороши там, где пользователь выигрывает время. Если сообщение не помогает принять решение или завершить действие, его лучше отправить в email, in-app inbox или вообще не отправлять.

Apple Push Notification Service (APNs)

Как устроен APNs

APNs — официальный шлюз Apple для удалённых уведомлений. Сервер продукта отправляет HTTP/2-запрос в Apple Push Notification service, указывает device token, topic приложения, тип уведомления и JSON payload. Apple принимает запрос, проверяет подпись и доставляет сообщение на устройство, если пользователь разрешил уведомления и устройство доступно.

Device token выдаётся конкретной установке приложения. Его нельзя считать вечным идентификатором: пользователь может переустановить приложение, восстановить устройство, изменить настройки. Поэтому backend должен уметь обновлять токены, деактивировать недействительные и не строить пользовательскую модель только на APNs token.

Payload, headers и типы уведомлений

Обычный payload APNs ограничен 4096 байтами, VoIP — 5120 байтами. Это не место для большого JSON с профилем пользователя. В payload кладут заголовок, тело, badge, sound, category, thread-id, небольшие custom keys и ссылку на объект в backend. Секреты, персональные документы и длинные тексты нужно загружать из API после открытия приложения.

• alert: видимое сообщение с title/body.
• badge: число на иконке приложения.
• sound: звук, включая кастомный, если он встроен в приложение.
• content-available: фоновое обновление без показа баннера.
• mutable-content: обработка через Notification Service Extension.
• thread-id: группировка сообщений в центре уведомлений.

С 2020-х Apple требует корректно указывать apns-push-type: alert, background, voip, liveactivity и другие типы. Неверный тип ухудшает доставку или приводит к отказу. Для авторизации лучше использовать token-based auth через ключ .p8, Team ID и Key ID: сертификаты всё ещё встречаются в легаси, но они менее удобны в ротации.

Практика для iOS-команд

На iOS нельзя полагаться на гарантированную доставку. Устройство может быть офлайн, пользователь может включить Focus, выключить уведомления для приложения или запретить preview на lock screen. Silent push особенно чувствителен к энергетическим политикам: если приложение злоупотребляет фоновыми обновлениями, система будет резать частоту.

Для продуктовой команды важны три решения. Первое — когда спрашивать permission. Лучший момент — после действия, где ценность очевидна: подписка на статус заказа, включение алертов по цене, настройка мониторинга. Второе — какие категории создать: reply, approve, decline, open ticket, track order. Третье — как обрабатывать deep link, чтобы пользователь попадал не «на главную», а в конкретный заказ, чат или инцидент.

Задача	Что использовать в APNs	Практическая норма
Новое сообщение	alert, thread-id, category	Группировать по чату, не слать каждую реакцию
Фоновое обновление	content-available	Только для короткой синхронизации
Картинка в уведомлении	mutable-content, extension	Держать медиа лёгким, до 300-800 КБ
Живой статус	Live Activities	Доставка, такси, спорт, таймеры

Firebase Cloud Messaging (FCM)

Роль FCM в Android-экосистеме

FCM — основной транспорт уведомлений для Android-приложений с Google Mobile Services. Он заменил старый GCM и стал частью Firebase. Через FCM отправляют как видимые notification messages, так и data messages, которые приложение обрабатывает самостоятельно. Для большинства команд это стандарт де-факто: SDK зрелый, документация подробная, есть Admin SDK для Node.js, Java, Python, Go и C#.

FCM работает не только с Android. Он может выступать обёрткой для iOS через APNs и для Web Push через webpush-конфигурацию. Но это не отменяет платформенных правил: на iOS всё равно действуют APNs headers, а в браузере — Service Worker, VAPID и permission model.

Notification messages и data messages

FCM payload обычно ограничен 4096 байтами. В Firebase Console для некоторых сценариев действует более жёсткий лимит на текст. Главное архитектурное различие — кто показывает уведомление. Notification message в фоне Android может отрисовать SDK. Data message попадает в код приложения, где команда сама решает: показать локальное уведомление, обновить кэш, сохранить событие или проигнорировать.

• Notification message: быстрее внедрить, удобно для маркетинга и простых кампаний.
• Data message: больше контроля, нужен для сложных deep links и business logic.
• Topic messaging: рассылка по темам вроде price_drop_ru или incident_p1.
• Condition: логика по нескольким topics, но её стоит держать простой.
• Collapse key: замена старого сообщения новым, например для статуса доставки.

FCM хранит ограниченное число collapsible-сообщений на устройство для разных collapse keys. На практике не стоит плодить десятки ключей. Для статуса заказа достаточно order_status_{id} на backend-уровне и аккуратной дедупликации, а не бесконечной очереди «заказ принят», «заказ почти принят», «мы всё ещё думаем».

Интеграция backend и Android SDK

Нормальная схема выглядит так: приложение получает registration token, отправляет его на backend вместе с user_id, platform, app_version, locale, timezone и consent flags. Backend хранит токены в отдельной таблице, умеет помечать их inactive после ошибок доставки и не смешивает их с постоянными пользовательскими идентификаторами.

Отправку лучше делать через FCM HTTP v1 API или Firebase Admin SDK. Legacy API давно не стоит закладывать в новые проекты. Для high-volume сервисов важны очереди: Kafka, RabbitMQ, SQS, Pub/Sub или хотя бы отдельный job worker. Push-отправка не должна висеть в request-response пути оформления заказа.

Сценарий	Рекомендация	Почему
OTP и безопасность	Data message + серверная проверка	Не доверять payload как источнику истины
Маркетинг	Notification message или провайдер	Быстрее сегменты, A/B, расписание
Статус заказа	Collapse key + TTL 5-60 минут	Старые статусы не нужны
Инциденты B2B	Data message + retry + audit log	Нужна трассировка доставки

Push уведомления через FCM просты на старте, но качество появляется только после нормальной модели токенов, TTL, collapse policy и обработки ошибок.

Web Push: VAPID и Push API

Что изменилось в вебе

Web Push в 2026 году уже не экзотика. Chrome, Edge, Firefox и Safari поддерживают Push API и Service Worker, а iOS/iPadOS с 16.4 открыли push для web apps, добавленных на домашний экран. Это важная оговорка: на мобильном Safari пользователь не всегда получает такой же поток, как в нативном приложении. Веб-подписка зависит от браузера, контекста установки и настроек уведомлений.

Технически Web Push работает через несколько компонентов. Сайт регистрирует Service Worker, запрашивает permission, создаёт subscription через PushManager.subscribe(), сохраняет endpoint и ключи на backend. Сервер отправляет зашифрованное сообщение в push-сервис браузера. Браузер будит Service Worker, а тот вызывает self.registration.showNotification().

VAPID, HTTPS и ограничения

VAPID — механизм идентификации отправителя. Команда генерирует пару ключей, публичный ключ отдаёт клиенту при подписке, приватным подписывает отправку. Это не «логин пользователя», а доказательство для push-сервиса, что сообщение отправляет владелец подписки. Без HTTPS Web Push в нормальном продакшене не работает, исключение — локальная разработка на localhost.

• Service Worker: обязателен для приёма push-события.
• HTTPS: нужен для secure context.
• Permission: пользователь должен явно разрешить уведомления.
• VAPID keys: идентификация приложения-отправителя.
• Subscription endpoint: URL push-сервиса конкретного браузера.
• CSRF-защита: нужна при создании и удалении подписок.

Payload в Web Push лучше держать коротким: заголовок, текст, URL, идентификатор сущности. Большие данные загружаются по API. Также нужно помнить, что subscription может протухнуть или быть отозвана браузером. Backend должен спокойно обрабатывать 404/410 от push endpoint и удалять мёртвые подписки.

UX: когда спрашивать разрешение

Самая частая ошибка — показывать системный prompt на первом экране. Пользователь ещё не понял ценность сайта, а браузер уже спрашивает разрешение. После отказа вернуть пользователя сложнее: настройки спрятаны в браузере, а не в вашем интерфейсе.

Рабочая схема — предварительный soft prompt внутри сайта. Например: «Сообщать о снижении цены по этому товару?» или «Присылать алерты по инцидентам P1?» После клика показывается системное окно. Так opt-in обычно выше: для e-commerce и медиа реалистичный диапазон 5-20%, для B2B-инструментов с понятной пользой — 20-45%, для случайного трафика с SEO — часто ниже 5%.

Браузер/среда	Web Push	Комментарий
Chrome/Edge desktop	Да	Самый предсказуемый сценарий
Firefox desktop	Да	Хорошая поддержка, свои UX-детали
Safari macOS	Да	Нужно тестировать отдельно
iOS/iPadOS web app	Да, при условиях	Обычно через добавление на Home Screen

OneSignal, Pushwoosh, SendPulse

Зачем брать провайдера

OneSignal, Pushwoosh и SendPulse не заменяют APNs, FCM и Web Push физически. Они строят поверх них удобный слой: SDK, dashboard, сегменты, шаблоны, расписания, A/B-тесты, автоматизации, отчёты и API. Для команды без отдельной messaging-платформы это экономит 2-6 месяцев разработки.

Провайдер особенно полезен, когда каналов несколько: iOS, Android, web, email, SMS, WhatsApp или Telegram. Маркетологу нужен интерфейс, продукту — триггеры, разработчикам — API и webhook, юристам — понятное хранение согласий. Самописная система быстро превращается в отдельный продукт внутри продукта.

Сравнение платформ

Платформа	Сильные стороны	На что смотреть	Кому подходит
OneSignal	Мобильные и web push, сегменты, Journeys, A/B, API	Стоимость на росте базы, хранение данных, санкционные риски	SaaS, медиа, mobile-first продукты
Pushwoosh	Push, in-app, customer journeys, enterprise-функции	Цена, интеграция SDK, юридическая модель	Retail, fintech, крупные приложения
SendPulse	Web push, email, chatbot, CRM-сценарии	Глубина mobile SDK, отчёты, лимиты тарифов	SMB, e-commerce, контентные проекты
Свой backend	Контроль данных, гибкость, нет vendor lock-in	Разработка, поддержка, аналитика, deliverability	Банки, гос, high-load, строгий compliance

По стоимости рынок сильно различается. Маленький проект может уложиться в бесплатный или недорогой тариф, но при базе 100-500 тыс подписчиков и активных автоматизациях счёт легко уходит в сотни долларов в месяц. Enterprise-контракты часто считают индивидуально: объём отправок, MAU, каналы, SLA, SSO, выделенная поддержка.

Как выбирать без иллюзий

Выбор провайдера стоит начинать не с красивого dashboard, а с матрицы требований. Где хранятся данные? Можно ли удалить пользователя по запросу? Есть ли экспорт событий? Как работает SDK на старых Android? Поддерживаются ли deep links, rich media, локализация, quiet hours, frequency capping? Есть ли российские способы оплаты и договорные документы, если бухгалтерия живёт в реальном мире?

• Проверьте SDK на iOS, Android, web и в React Native/Flutter, если они есть в стеке.
• Сделайте тест на 1000-5000 реальных подписчиков, а не только на трёх телефонах команды.
• Сравните задержку доставки: transactional push должен приходить за секунды, не минуты.
• Проверьте экспорт сырых событий: sent, delivered, opened, failed, unsubscribed.
• Оцените выход: как забрать токены, сегменты и историю согласий при миграции.

Push уведомления через SaaS-провайдера ускоряют запуск, но не отменяют архитектурную ответственность. Если провайдер упал, сменил тариф или перестал принимать оплату, продукт всё равно должен доставлять критичные сообщения.

Российские проблемы: Google Services, обходы

Где именно болит

Главная российская проблема не в том, что push «запрещён». Проблема в зависимости от иностранных платформ, способов оплаты, SDK, аккаунтов разработчика и устройств без Google Mobile Services. На Android часть аудитории использует Huawei, Honor и другие сборки без GMS. На таких устройствах FCM может не работать или работать непредсказуемо, если приложение собрано только под Google-экосистему.

Вторая зона риска — доступность SaaS-провайдеров: договоры, оплата картами, обработка персональных данных, поддержка русскоязычных команд, юридические ограничения. Третья — магазины приложений. Если продукт распространяется через RuStore, AppGallery или прямую APK-дистрибуцию, push-стратегия должна учитывать это до релиза, а не после отзывов «уведомления не приходят».

Технические варианты

Для Android без GMS чаще всего смотрят в сторону Huawei Push Kit, RuStore Push или собственного fallback через периодическую синхронизацию. Собственный постоянный socket для массового consumer-приложения почти всегда дорог: батарея, NAT, фоновые ограничения, поддержка разных прошивок. Для B2B-терминалов или корпоративных устройств такой путь возможен, но это уже отдельная инфраструктура.

• FCM: основной вариант для Android с Google Services.
• Huawei Push Kit: нужен для устройств Huawei/Honor без GMS.
• RuStore Push: вариант для проектов, ориентированных на российскую Android-дистрибуцию.
• Web Push: полезен для PWA и личных кабинетов, но зависит от браузера.
• SMS/email/in-app inbox: резерв для критичных сценариев.

Для критичных событий стоит проектировать multi-channel routing. Например: push отправляется первым, через 15-60 секунд при отсутствии открытия уходит email, для security-событий или финансовых операций — SMS или звонок по отдельным правилам. Это дороже, зато не превращает push в единственную точку отказа.

Юридическая и операционная реальность

Если аудитория в России, проверьте, где хранятся токены, пользовательские атрибуты и события. Push token сам по себе может не выглядеть как паспортные данные, но в связке с user_id, телефоном, email, устройством и поведением он становится частью профиля пользователя. Для ФЗ-152 это уже зона персональных данных.

Обходы в стиле «поставьте VPN, и всё заработает» не годятся для продукта. Пользователь не обязан чинить вашу архитектуру. Нормальный план включает тестовую матрицу устройств: iPhone, Android с GMS, Huawei без GMS, Chrome desktop, Safari macOS, iOS web app. Для российского массового рынка разумный минимум — 12-20 устройств и 3-5 регионов тестирования, включая мобильные сети разных операторов.

Push уведомления в РФ требуют не героизма, а скучной инженерной предусмотрительности: несколько транспортов, нормальные fallback-каналы и честное тестирование на устройствах, которые реально есть у пользователей.

Сегментация и персонализация

От массовой рассылки к событиям

Сегментация начинается не с пола и возраста, а с контекста. Что пользователь делал? Где остановился? Какой у него тариф? Когда он последний раз открывал приложение? На каком языке читает интерфейс? В каком часовом поясе живёт? Ответы на эти вопросы дают больше, чем абстрактный сегмент «мужчины 25-34».

В 2026 году хорошие push-кампании строятся на событиях: cart_abandoned, trial_day_3, invoice_failed, price_drop, incident_created. Каждое событие имеет payload, timestamp и правила отправки. Маркетинговый текст — последний слой, не первый.

Рабочие признаки сегментации

• Поведение: просмотры, покупки, клики, незавершённые действия.
• Жизненный цикл: новый пользователь, trial, активный, спящий, churn risk.
• Ценность: LTV, средний чек, тариф, частота заказов.
• Контекст: город, часовой пояс, язык, устройство, версия приложения.
• Предпочтения: категории, избранное, подписки на темы.
• Разрешения: какие типы уведомлений пользователь включил или выключил.

Персонализация не обязана быть пугающей. «Ваш заказ №1842 передан курьеру» нормально. «Мы видели, что вы 7 минут смотрели красные кроссовки в 23:41» — уже сомнительно. Граница проходит там, где полезность превращается в ощущение слежки.

Frequency capping и quiet hours

Главный убийца канала — частота. Для consumer-продуктов безопасный диапазон маркетинговых push часто лежит в пределах 2-5 сообщений в неделю на пользователя. Для медиа с breaking news может быть больше, но только если пользователь сам выбрал темы. Для B2B-алертов частота зависит от критичности: P1-инцидент можно отправить ночью, дайджест задач — нет.

Тип сообщения	Частота	Комментарий
Security alert	Без жёсткого лимита	Только реальные события безопасности
Статус заказа	3-8 на заказ	С collapse для промежуточных статусов
Маркетинг	2-5 в неделю	С учётом реакции пользователя
Дайджест	1-3 в неделю	Лучше в выбранное пользователем время

Push уведомления должны иметь настройки внутри продукта: темы, частота, quiet hours, критичные алерты отдельно от маркетинга. Один общий тумблер «всё или ничего» почти всегда ведёт к полному отказу.

Метрики: CTR, conversions, opt-out

Что измерять на самом деле

Open rate и CTR полезны, но сами по себе мало говорят о бизнесе. Пользователь мог открыть push случайно, закрыть приложение через секунду и больше не вернуться. Поэтому метрики нужно связывать с целью: оплаченный заказ, завершённая регистрация, прочитанный инцидент, продлённая подписка, снижение обращений в поддержку.

Базовая воронка выглядит так: eligible audience, sent, accepted by provider, delivered, displayed, opened, converted, unsubscribed. Не все платформы одинаково точно отдают delivered и displayed. APNs, FCM и браузеры имеют ограничения по видимости доставки, поэтому analytics layer продукта должен фиксировать client-side события: notification received, notification opened, deep link resolved, target action completed.

Ориентиры по цифрам

Сценарий	Открытия/CTR	Конверсия	Риск opt-out
OTP/security	40-80%	Высокая, зависит от процесса	Низкий
Статус заказа	20-60%	Средняя	Низкий
Брошенная корзина	5-20%	1-8%	Средний
Массовая акция	2-10%	0,2-3%	Высокий
B2B-инцидент	30-70%	Зависит от SLA	Низкий при точной настройке

Эти диапазоны не универсальный закон, а стартовая линейка. У банка, маркетплейса, DevOps-платформы и медиа разные ожидания. Важнее сравнивать кампании внутри одного продукта: сегмент A против сегмента B, текст A против текста B, отправка в 10:00 против 19:00.

Как не обмануть себя аналитикой

Первое правило — задавать контрольную группу. Если всем пользователям отправили скидку и продажи выросли на 12%, это ещё не значит, что push сработал. Возможно, был payday, сезонный спрос или баннер на главной. Holdout-группа 5-10% помогает оценить инкрементальный эффект.

Второе правило — считать отказы. Если кампания принесла 300 заказов и 5000 opt-out, это плохая кампания. Для зрелого продукта opt-out после одной рассылки выше 0,2-0,5% по активной базе уже повод смотреть на текст, частоту и сегмент. Для холодной web-базы цифры могут быть хуже, но это не делает их нормальными.

• Считайте conversion window: 30 минут, 24 часа, 7 дней — в зависимости от сценария.
• Разделяйте direct open и influenced conversion.
• Отдельно смотрите uninstall rate после массовых кампаний.
• Логируйте provider errors и invalid tokens.
• Связывайте кампании с revenue, retention и support metrics.

GDPR, ФЗ-152 и согласие пользователя

Согласие — не формальность

Push-канал требует технического и юридического согласия. Техническое — permission в iOS, Android или браузере. Юридическое — основание для обработки данных и отправки сообщений. Для сервисных уведомлений основание может отличаться от маркетинговых. Статус заказа и рекламная акция — не одно и то же.

В России нужно учитывать ФЗ-152 о персональных данных, требования к политике обработки, локализации баз в применимых случаях и передачу данных третьим лицам. В ЕС и для пользователей из ЕС включается GDPR: lawful basis, data minimization, right to access, erasure, withdrawal of consent. Если провайдер push хранит user attributes, события и сегменты, он становится частью цепочки обработки данных.

Что хранить и как объяснять

Минимальный набор: user_id, push token или subscription endpoint, platform, app version, locale, timezone, consent status, timestamp согласия, источник согласия, категории уведомлений. Для маркетинга нужно отдельно хранить согласие на рекламные сообщения и возможность отказаться без удаления аккаунта.

• Разделяйте сервисные и маркетинговые уведомления.
• Не кладите чувствительные данные в payload.
• Показывайте понятные настройки внутри приложения.
• Фиксируйте дату, версию текста согласия и источник opt-in.
• Удаляйте или анонимизируйте токены при удалении аккаунта.
• Проверяйте договоры с OneSignal, Pushwoosh, SendPulse и другими обработчиками.

Практический подход для продукта

Хорошая настройка выглядит так: пользователь может отдельно включить «статусы заказов», «безопасность», «скидки», «новости продукта», «дайджест». Критичные security-сообщения можно оставить частью сервиса, но рекламные рассылки должны выключаться легко. В идеале — за 2 клика, без письма в поддержку.

Текст permission prompt должен быть конкретным. Не «Разрешите нам отправлять уведомления», а «Сообщать о статусе доставки и изменении времени курьера». Для web лучше сначала показать собственный экран выбора категорий, затем системный prompt. Для мобильных приложений — объяснить ценность до вызова системного диалога.

Риск	Плохая практика	Нормальная практика
Маркетинг без согласия	Все токены попадают в промо-сегмент	Отдельный opt-in и история согласия
Утечка данных	Паспортные или медицинские данные в payload	Только ID события и загрузка из API
Vendor risk	Нет договора и DPA	Проверка провайдера и условий обработки

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

Чек-лист внедрения push в 2026

Архитектура

1. Опишите сценарии: transactional, product, marketing, security, digest.
2. Разделите платформы: iOS/APNs, Android/FCM, Android без GMS, Web Push.
3. Выберите подход: свой backend, OneSignal, Pushwoosh, SendPulse или гибрид.
4. Спроектируйте таблицу токенов: user_id, token, platform, status, consent, timestamps.
5. Добавьте очередь отправки и retry policy, не отправляйте push из синхронного API-запроса.
6. Задайте TTL, collapse keys и дедупликацию для повторяющихся событий.
7. Подготовьте fallback: email, SMS, in-app inbox, webhook.

Клиентские приложения и web

1. Запрашивайте permission после демонстрации пользы, а не на первом экране.
2. Обновляйте токены при смене, переустановке и logout/login.
3. Обрабатывайте foreground, background и killed state отдельно.
4. Настройте deep links до конкретного объекта: заказ, чат, задача, инцидент.
5. Для Web Push проверьте Service Worker, HTTPS, VAPID и отписку.
6. Для iOS проверьте Focus, Notification Summary, badges, categories и rich media.
7. Для Android проверьте notification channels, importance, permissions и OEM-прошивки.

Маркетинг, аналитика и compliance

1. Разделите сервисные и рекламные сообщения в настройках пользователя.
2. Добавьте frequency capping: общий лимит, лимит по категории, quiet hours.
3. Собирайте события sent, failed, received, opened, converted, unsubscribed.
4. Используйте holdout-группы 5-10% для оценки реального эффекта.
5. Проверяйте opt-out и uninstall после каждой крупной кампании.
6. Храните timestamp согласия, источник и версию текста.
7. Проводите тесты на реальных устройствах в РФ: GMS, без GMS, iOS, web.

Перед запуском сделайте нагрузочный прогон. Для базы 100 тыс подписчиков отправка не должна превращаться в 100 тыс синхронных HTTP-запросов из одного процесса. Нормальная схема — батчи, rate limits, backoff, idempotency key и логирование provider response. Для transactional-сценариев держите p95 задержки: 1-5 секунд хорошо, 10-30 секунд терпимо, минуты уже заметны пользователю.

Push уведомления в зрелом продукте — это маленькая messaging-платформа: транспорт, согласия, сегменты, шаблоны, аналитика, ретраи и юридический контур. Запустить баннер можно за день. Сделать канал, который не раздражает и приносит деньги, обычно занимает 4-12 недель.

FAQ о Push уведомления

Следите за обновлениями itech-news.ru — мы держим эту страницу актуальной.