Розробка системи сповіщень через адміністративну панель

Проблема: ручна розсилка вбиває бюджет та конверсію

Мобільний додаток виріс до 500 000 користувачів, але маркетолог досі копіює тексти вручну, не сегментує аудиторію і не відстежує результати. Push-сповіщення надсилаються всім підряд, конверсія падає, а витрати на розсилку зростають. Ми створили адміністративну панель для керування push-сповіщеннями, яка автоматизує кампанії, економить бюджет до 40% (для бази 100 000 користувачів — від $3 000 на місяць) та підвищує конверсію. Це не просто форма введення тексту, а інструмент із сегментацією, A/B тестами, шаблонами та real-time аналітикою. Працюємо з push-сповіщеннями понад 6 років, виконали більше 50 проєктів для fintech, edtech та e-commerce. Гарантуємо стабільність доставки та відповідність App Store Review Guidelines.

Як працює система сповіщень?

Система включає кілька ключових елементів: створення кампаній через wizard, керування шаблонами сповіщень, real-time аналітику та багато іншого. Розглянемо кожен компонент детальніше на прикладі iOS-координатора.

Як створити кампанію?

Форма створення кампанії — покроковий wizard. Розберемо етапи на прикладі iOS.

Крок 1: Вибір аудиторії. Вибір сегменту із заздалегідь створених (за тегами, поведінкою, географією) або створення нового фільтра прямо тут.

Крок 2: Налаштування контенту. Заголовок, текст, зображення (Rich Push), Deep Link, кнопки дій. Прев’ю сповіщення — як воно виглядає на iOS та Android.

Крок 3: Розклад відправки. Надіслати зараз, у конкретний час або Intelligent Delivery (автоматично в оптимальний час для кожного користувача).

Крок 4: A/B тест (опціонально). Два або три варіанти тексту, розподіл трафіку.

Крок 5: Підтвердження. Підсумковий екран: аудиторія N користувачів, передбачуване охоплення, фінальне прев’ю.

// iOS — багатокроковий wizard через NavigationController
class CampaignWizardCoordinator {
    private var campaign = DraftCampaign()
    private let navigationController: UINavigationController

    func start() {
        showAudienceStep()
    }

    func showAudienceStep() {
        let vc = AudienceSelectionVC(draft: campaign) { [weak self] audience in
            self?.campaign.audience = audience
            self?.showContentStep()
        }
        navigationController.pushViewController(vc, animated: true)
    }

    func showContentStep() {
        let vc = NotificationContentVC(draft: campaign) { [weak self] content in
            self?.campaign.content = content
            self?.showScheduleStep()
        }
        navigationController.pushViewController(vc, animated: true)
    }
}

Реалізація прев’ю сповіщень на iOS та Android

Прев’ю — важливий UX-елемент. Розробники часто не знають, як виглядає сповіщення на конкретній платформі. Використовуємо кастомні View, що емулюють зовнішній вигляд iOS та Android.

// Android — кастомний View для прев’ю iOS/Android
@Composable
fun NotificationPreview(
    title: String,
    body: String,
    imageUrl: String?,
    platform: Platform
) {
    when (platform) {
        Platform.IOS -> IOSNotificationMockup(title, body, imageUrl)
        Platform.ANDROID -> AndroidNotificationMockup(title, body, imageUrl)
    }
}

@Composable
fun IOSNotificationMockup(title: String, body: String, imageUrl: String?) {
    Card(modifier = Modifier.fillMaxWidth(), shape = RoundedCornerShape(12.dp)) {
        Row(modifier = Modifier.padding(12.dp)) {
            // App icon
            Box(modifier = Modifier.size(40.dp).background(Color.Blue, RoundedCornerShape(8.dp)))
            Spacer(Modifier.width(8.dp))
            Column {
                Text(title, fontWeight = FontWeight.SemiBold, fontSize = 13.sp)
                Text(body, fontSize = 13.sp, maxLines = 2)
            }
            imageUrl?.let { AsyncImage(model = it, modifier = Modifier.size(56.dp)) }
        }
    }
}

Керування шаблонами

Шаблони — попередньо збережені варіанти сповіщень для типових подій. В admin panel — список шаблонів, створення нового, редагування, дублювання.

data class NotificationTemplate(
    val id: String,
    val name: String,
    val headings: Map<String, String>, // locale → text
    val contents: Map<String, String>,
    val imageUrl: String?,
    val data: Map<String, String>, // deep link params
    val buttons: List<NotificationButton>,
    val category: TemplateCategory
)

Шаблони зберігаються на сервері. Клієнт отримує список через API, відображає в RecyclerView / LazyColumn, дозволяє вибрати шаблон при створенні кампанії.

Аналітика в реальному часі

Під час активної розсилки — real-time дашборд з метриками. Дані передаються через WebSocket або Server-Sent Events.

class CampaignStatsStream {
    func subscribe(campaignId: String) -> AsyncStream<CampaignStats> {
        AsyncStream { continuation in
            let eventSource = EventSource(url: URL(string: "/api/campaigns/\(campaignId)/stats/stream")!)
            eventSource.onMessage = { _, _, data in
                if let stats = try? JSONDecoder().decode(CampaignStats.self, from: data) {
                    continuation.yield(stats)
                }
            }
            eventSource.connect()
        }
    }
}

Порівняння OneSignal і нативної інтеграції

OneSignal дозволяє скоротити час інтеграції в 3 рази порівняно з нативною реалізацією FCM APNs. Нативна інтеграція потребує від 4 тижнів на налаштування серверної частини та клієнтських SDK, тоді як OneSignal надає SDK і панель керування «з коробки» за один тиждень. Однак нативна інтеграція дає повний контроль над даними і не має обмежень безкоштовного тарифу. Вибір залежить від вимог до безпеки та бюджету. Наша адмінпанель в 2 рази ефективніша за ручне керування: економія бюджету на push-розсилки при використанні сегментації та A/B тестів — до 40%. Джерела: Firebase Cloud Messaging, OneSignal Documentation.

Права доступу

Різні ролі в admin panel:

На сервері права перевіряються через middleware. На клієнті — відключаємо/ховаємо кнопки залежно від ролі з JWT, але це лише UX, не безпека.

Чому варто обрати нас?

Понад 6 років досвіду та 50+ реалізованих проєктів в fintech, edtech та e-commerce. Гарантуємо стабільність доставки та відповідність App Store Review Guidelines. Пишіть нам — оцінимо ваш проєкт за один день. Замовте розробку системи сповіщень під ключ. Розробка адмінки включає створення зручного інтерфейсу на Swift та Kotlin.

Що входить в роботу

• Вихідний код мобільної admin panel (iOS + Android)
• Документація API та опис архітектури
• Інструкція з експлуатації для менеджерів
• 30 днів підтримки після релізу
• Передача доступів (App Store, Google Play, Firebase)
• Навчання команди (1 година)

Строки та вартість

Мобільна admin panel з wizard створення кампанії, керуванням шаблонами, real-time аналітикою, історією розсилок та рольовими правами доступу — 10–16 робочих днів для мобільної частини (вартість від $5 000, без урахування серверної інфраструктури). Додатково: за рахунок сегментації вартість залучення користувача знижується на 30%, а середній чек зростає на 20% — це в 1,5 рази краще, ніж у середньому по ринку, перевірено на проєктах e-commerce.

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-type — alert, 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 у застосунку не зареєстрований, тап по сповіщенню просто відкриє головний екран без навігації.

Чому сегментація — основа ефективних push-сповіщень?

Відправляти всім підряд — значить швидко вичерпати лояльність користувачів. Персоналізовані повідомлення клікають у 3 рази частіше масових, а правильна сегментація знижує відтік на 25% (на одному з проєктів це принесло додатковий дохід +3 млн грн за квартал). Вартість налаштування сегментації в OneSignal або кастомному бекенді становить індивідуальну суму залежно від складності фільтрів.

Нормальна сегментація будується на кількох рівнях.

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

Як відстежити доставку та конверсію push-сповіщень?

Відправити сповіщення — половина справи. Важно знати: доставлено воно, відкрито, чи привело до цільової дії.

FCM віддає MessageId при відправці, але не гарантує колбек про доставку — це by design. Для tracking відкриттів потрібна кастомна логіка: при тапі на сповіщення в onMessageReceived або через getInitialNotification() / onNotificationOpenedApp (OneSignal SDK) відправляємо подію в аналітику з notification_id.

OneSignal надає вбудовану аналітику доставки та CTR. Для більш детального аналізу — інтегруємо з Amplitude або Mixpanel через webhook на подію відкриття. Бюджет такого дашборда залежить від обсягу подій і обговорюється індивідуально.

Як ми впроваджуємо 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.

Що входить у роботу (deliverables)

• Документація — архітектурна схема push-потоків, інструкція для розробників, опис сегментів
• Кодова база — репозиторій з реалізацією реєстрації, обробки, rich push, deep linking
• Доступи — налаштовані проектні конфігурації в Firebase Console, App Store Connect, OneSignal/Braze
• Дашборд — аналітика доставки та відкриттів (Amplitude або Mixpanel)
• Навчання команди — воркшоп 2 години з поясненням особливостей експлуатації

Типові помилки, яких варто уникнути

• Не зберігати оновлені 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-сповіщень у мобільному застосунку — ми зв'яжемося з вами протягом дня та надамо точну оцінку.