Интеграция push-уведомлений через OneSignal
Самая частая история: приложение уже в production, бэкенд-команда отправляет уведомления напрямую через APNs/FCM, и это превращается в зоопарк — отдельный код для iOS, отдельный для Android, нет аналитики открытий, нет сегментов, ретраи написаны вручную. OneSignal решает весь этот стек единым API и SDK.
Что реально происходит при подключении SDK
OneSignal SDK инициализируется один раз в точке входа приложения. На Android — в Application.onCreate(), на iOS — в AppDelegate.didFinishLaunchingWithOptions.
// 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 SDK версии 5.x (актуальная на момент написания) перешёл на модульную архитектуру: OneSignal.User, OneSignal.Notifications, OneSignal.InAppMessages — отдельные неймспейсы. Это важно при обновлении с версии 3.x, где всё было плоским API. Миграция не тривиальная: sendTag заменился на OneSignal.User.addTag, setExternalUserId — на OneSignal.login.
Push Permission на iOS — отдельная тема. Apple не позволяет запрашивать разрешение повторно после отказа. Если пользователь нажал «Не разрешать» — единственный выход открыть Settings. Поэтому момент запроса критичен: не при первом открытии приложения, а на экране, где ценность уведомлений очевидна (например, после создания первого заказа или включения отслеживания).
Идентификация пользователей и теги
По умолчанию 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")
Теги — основа для сегментации в дальнейшем. Их стоит проектировать заранее, иначе потом придётся форсировать обновление приложения только ради добавления нового тега.
Отправка через 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, click rate, influenced opens (пользователь открыл приложение в течение 60 секунд после получения уведомления, без клика). Для e-commerce это важная метрика — уведомление сработало, но пользователь открыл приложение иначе.
Если нужна более глубокая аналитика — OneSignal интегрируется с Mixpanel, Amplitude через outcome events:
OneSignal.Session.addOutcome("purchase_completed")
OneSignal.Session.addOutcomeWithValue("purchase_amount", 149.99f)
Сроки
Базовая интеграция OneSignal SDK (iOS + Android или Flutter/RN), настройка APNs/FCM сертификатов, привязка external user ID, обработчик открытий — 3–5 рабочих дней. Если добавляется серверная логика отправки, настройка сегментов и шаблонов в OneSignal Dashboard — ещё 2–3 дня.