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

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

Мобильное приложение выросло до 500 000 пользователей, но маркетолог по-прежнему копирует тексты вручную, не сегментирует аудиторию и не отслеживает результаты. Push-уведомления отправляются всем подряд, конверсия падает, а затраты на рассылку растут. Мы создали административную панель для управления push-уведомлениями, которая автоматизирует кампании, экономит бюджет до 40% и повышает конверсию. Это не просто форма ввода текста, а инструмент с сегментацией, A/B тестами, шаблонами и real-time аналитикой. Работаем с push-уведомлениями более 6 лет, выполнили более 50 проектов для fintech, edtech и e-commerce. Гарантируем стабильность доставки и соответствие App Store Review Guidelines.

Архитектура системы

Admin Panel (мобильное приложение)
       ↓
Campaign API (бэкенд)
       ↓
Queue (RabbitMQ / Redis)
       ↓
Push Worker (отправка через FCM / APNs / OneSignal)
       ↓
Webhook Handler (статусы доставки)
       ↓
Analytics DB (клики, открытия, конверсии)

Как устроена система уведомлений через административную панель?

Система включает в себя несколько ключевых элементов: создание кампаний через 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 и панель управления «из коробки» за одну неделю. Однако нативная интеграция даёт полный контроль над данными и не имеет ограничений бесплатного тарифа. Выбор зависит от требований к безопасности и бюджету. Экономия бюджета на push-рассылки при использовании сегментации и A/B тестов — до 40%.

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

Разные роли в admin panel:

На сервере права проверяются через middleware. На клиенте — отключаем/скрываем кнопки по role из JWT, но это только UX, не безопасность.

Почему стоит выбрать нас?

Работаем с push-уведомлениями более 6 лет. Выполнили более 50 проектов для fintech, edtech и e-commerce. Гарантируем стабильность доставки и соответствие App Store Review Guidelines. Свяжитесь с нами, чтобы оценить ваш проект за один день. Закажите разработку системы уведомлений с гарантией стабильности.

Что входит в работу

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

Сроки

Мобильная admin panel с wizard создания кампании, управлением шаблонами, real-time аналитикой, историей рассылок и ролевыми правами доступа — 10–16 рабочих дней для мобильной части (без учёта серверной инфраструктуры очереди и worker'ов).

Дополнительно: за счёт сегментации стоимость привлечения пользователя снижается на 30%, а средний чек вырастает на 20% — проверено на проектах 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 или кастомном бэкенде составляет от 100 000 до 250 000 рублей в зависимости от сложности фильтров.

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

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

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