Інтеграція push-сповіщень через OneSignal
Типова ситуація: додаток уже в production, backend-команда відправляє сповіщення безпосередньо через APNs/FCM, і це перетворюється на зоопарк — окремий код для iOS, окремий для Android, немає аналітики відкриттів, немає сегментів, retries написані вручну. 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 дні.