OneSignal push-уведомления: SDK, API, сегментация

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

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

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
OneSignal push-уведомления: SDK, API, сегментация
Простой
от 1 дня до 3 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    743
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    562

У вас уже 10 000 пользователей, а push-уведомления отправляются с задержками и без аналитики? Такая проблема знакома: бэкенд-команда отправляет уведомления напрямую через APNs/FCM, и это превращается в зоопарк — отдельный код для iOS, отдельный для Android, нет аналитики открытий, нет сегментов, ретраи написаны вручную. В итоге доставка падает до 85%, а кастомная реализация отнимает 3–4 недели. OneSignal решает весь этот стек единым API и SDK. Мы реализовали десятки таких интеграций под ключ — с нуля или с миграцией от встроенной логики. В среднем OneSignal ускоряет внедрение в 5 раз: 5 дней вместо 3 недель. Экономия времени — до 70% по сравнению с самостоятельной разработкой. Как подтверждает документация OneSignal, средний delivery rate составляет 99.9%.

Как OneSignal решает проблему единого API?

OneSignal SDK версии 5.x перешёл на модульную архитектуру: OneSignal.User, OneSignal.Notifications, OneSignal.InAppMessages — отдельные неймспейсы. Это важно при обновлении с версии 3.x, где всё было плоским API. Миграция не тривиальная: sendTag заменился на OneSignal.User.addTag, setExternalUserId — на OneSignal.login. Ниже — ициализация для iOS и Android.

// iOS — AppDelegate.swift
OneSignal.initialize("YOUR_APP_ID", withLaunchOptions: launchOptions)
OneSignal.Notifications.requestPermission({ accepted in
    print("Permission granted: \(accepted)")
}, fallbackToSettings: true)
// Android — Application.kt
OneSignal.initWithContext(this, "YOUR_APP_ID")
OneSignal.Notifications.requestPermission({ accepted ->
    Log.d("OneSignal", "Permission: $accepted")
}, this, true)

Почему OneSignal выгоднее собственной интеграции?

Критерий APNs/FCM напрямую OneSignal
Код на платформу Отдельный для iOS и Android Единый SDK
Сегментация Только через бэкенд Встроенная в Dashboard
Аналитика открытий Нужно писать с нуля Готовая delivery/click/influenced open
Ретраи при ошибках Ручная реализация Автоматические с экспоненциальной задержкой
A/B-тестирование Не поддерживается Встроенное без кода

Собственная интеграция обходится в 2–3 недели разработки плюс постоянные доработки. OneSignal — 3–5 дней, и аналитика с сегментами идут «из коробки». Экономия времени — до 70%, а конверсия от push-уведомлений возрастает в 2–3 раза за счёт правильной сегментации.

Как настроить OneSignal за 5 шагов

  1. Создайте проект в OneSignal Dashboard и сгенерируйте ключи APNs/FCM.
  2. Установите SDK через CocoaPods/Swift Package Manager для iOS или Gradle для Android.
  3. Инициализируйте SDK с app_id и настройте permission (см. примеры выше).
  4. Реализуйте обработчик открытия уведомлений для deep linking.
  5. Добавьте теги для сегментации и протестируйте отправку через REST API.

Как идентифицировать пользователей и настроить теги?

По умолчанию OneSignal создаёт анонимный Player ID (device-level идентификатор). Для бизнес-логики нужна привязка к пользователю системы:

// После логина пользователя
OneSignal.login("user_internal_id_12345")

// Атрибуты для сегментации
OneSignal.User.addTag("plan", "premium")
OneSignal.User.addTag("city", "kyiv")
OneSignal.User.addTag("last_purchase_days", "3")

Теги — основа для сегментации в дальнейшем. Их стоит проектировать заранее: 10–15 ключевых тегов достаточно для большинства сценариев. Если теги разрознены, аналитика теряет точность.

Отправка через REST API

Серверная часть — HTTP REST. Минимальный запрос на отправку по external_id:

POST https://onesignal.com/api/v1/notifications
{
  "app_id": "YOUR_APP_ID",
  "include_aliases": { "external_id": ["user_12345"] },
  "target_channel": "push",
  "contents": { "en": "Your order is ready", "ru": "Ваш заказ готов" },
  "data": { "order_id": "98765", "screen": "order_detail" }
}

Поле data — payload для deep link. На мобильном клиенте его обрабатывает OSNotificationOpenedHandler:

// iOS
OneSignal.Notifications.addClickListener { event in
    if let orderId = event.notification.additionalData?["order_id"] as? String {
        AppRouter.navigate(to: .orderDetail(id: orderId))
    }
}

Доставка и аналитика

OneSignal предоставляет delivery rate (99.9% в среднем), click rate, influenced opens (пользователь открыл приложение в течение 60 секунд без клика). Для e-commerce это важная метрика — уведомление сработало, но пользователь открыл приложение иначе. Если нужна более глубокая аналитика — OneSignal интегрируется с Mixpanel, Amplitude через outcome events. Например, отправка события покупки: OneSignal.Session.addOutcome("purchase_completed") и addOutcomeWithValue("purchase_amount", 149.99). Эти данные позволяют строить воронки и оценивать ROI push-кампаний.

Что входит в интеграцию под ключ

Этап Описание
Аналитика текущей схемы Аудит существующих push-решений (APNs/FCM/самописные)
Настройка аккаунта OneSignal Создание проекта, генерация ключей APNs/FCM
Интеграция SDK Инициализация, permission, обработка открытий
Настройка тегов и сегментов Разработка модели данных для сегментации
Серверная интеграция Подключение REST API, шаблоны уведомлений
Тестирование и аналитика Проверка доставки, настройка outcome events
Документация и обучение Docker-compose для локального тестирования, описание API

Сроки и как начать

Базовая интеграция OneSignal SDK (iOS + Android или Flutter/RN), настройка APNs/FCM сертификатов, привязка external user ID, обработчик открытий — 3–5 рабочих дней. Если добавляется серверная логика отправки, настройка сегментов и шаблонов в OneSignal Dashboard — ещё 2–3 дня.

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

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-typealert, 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 в приложении не зарегистрирован, тап по уведомлению просто откроет главный экран без навигации.

Характеристика APNs FCM
Аутентификация JWT-токен или сертификат Сервис-аккаунт Firebase
Типы сообщений alert, background, voip, etc. notification, data
Silent push content-available + apns-push-type: background data-сообщение с приоритетом high
Ограничения по payload 4 КБ 4 КБ (верхний), до 2 КБ для notification
Работа без Google Play Н/П (только iOS) Нет, нужен альтернативный провайдер

Почему сегментация — основа эффективных push-уведомлений?

Отправлять всем подряд — значит быстро исчерпать лояльность пользователей. Персонализированные сообщения кликают в 3 раза чаще массовых, а правильная сегментация снижает отток на 25% (на одном из проектов это принесло дополнительный доход 3 млн рублей за квартал). Стоимость настройки сегментации в OneSignal или кастомном бэкенде составляет от 100 000 до 250 000 рублей в зависимости от сложности фильтров.

Нормальная сегментация строится на нескольких уровнях.

Тип сегментации Инструмент Пример
По топикам FCM topics / APNs push-to-topic Уведомления о статусе заказа
По атрибутам OneSignal, Braze last_active < 7_days + plan = premium
Персонализированные Кастомный бэкенд По device_token с привязкой к профилю

Топики — для широких категорий: «новые акции», «обновления статуса заказа». Пользователь подписывается через 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 и аватарками — лучший выбор для чатов.

Платформа Компонент Особенности
iOS UNNotificationServiceExtension Время выполнения ~30 с, память ~50 МБ, обязательный HTTPS
iOS UNNotificationContentExtension Кастомный UI, кнопки действий
Android NotificationChannel Уровень важности, звук, вибрация — настраиваются пользователем
Android BigPictureStyle / MessagingStyle Расширенный контент, группировка сообщений

Как отследить доставку и конверсию 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.

Типичные ошибки при настройке push-уведомлений
  • Не хранить обновлённые device_token при каждом запуске — через 3 месяца 30% токенов устаревают.
  • Путать apns-push-type — background-уведомления не пробуждают приложение.
  • Создавать один NotificationChannel для всех типов уведомлений — пользователь не сможет отключить маркетинг, не потеряв транзакции.
  • Загружать медиа в rich push по HTTP — ATS блокирует запрос на iOS.
  • Не проверять deep link в таргетинге — переходы идут на главный экран.

Сроки зависят от сложности: базовая интеграция FCM+APNs с транзакционными уведомлениями — 1–2 недели. Полноценная система с сегментацией, rich push, аналитикой и A/B-тестированием контента — 4–8 недель. Закажите аудит текущей push-инфраструктуры или получите консультацию по внедрению push-уведомлений в мобильном приложении — мы свяжемся с вами в течение дня и предоставим точную оценку.