Настройка сегментации push-уведомлений: iOS, Android, триггеры

Отправлять одно и то же уведомление всей базе — это не сегментация, а спам. CTR падает (некоторые клиенты теряли до 70% открытий за месяц), отписки растут, iOS начинает ограничивать доставку через Apple Push Notification throttling для приложений с низким engagement rate. Мы решаем эту задачу технически, а не маркетингово — проектируем схему тегов, интегрируем SDK, настраиваем триггеры. Гарантируем рост open rate на 25% и снижение числа жалоб вдвое.

Почему сегментация важна для доставляемости?

Apple и Google отслеживают поведение пользователей при push-уведомлениях. Если много отписок или пользователи не открывают уведомления — доставка начинает задерживаться. Например, для iOS действует rate limiting на уровне APNs. Сегментация — единственный способ сохранить высокую доставляемость. Без неё вы рискуете, что 30% уведомлений не дойдут вовсе.

Как работает сегментация на уровне SDK

Любая платформа рассылок (OneSignal, Firebase, Braze, Airship) строит сегменты на основе двух источников: атрибуты пользователя (теги, properties) и поведенческие данные (события, сессии, покупки).

На клиенте задача одна — корректно передавать данные:

// Android — после каждого значимого действия
OneSignal.User.addTag("subscription_tier", "premium")
OneSignal.User.addTag("last_active_days", "0")
OneSignal.User.addTag("preferred_category", "electronics")

// При изменении локации (с разрешения пользователя)
OneSignal.User.addTag("region", "UA-30")

// iOS — то же самое для тегов и событий
OneSignal.User.addTag("onboarding_completed", "true")
OneSignal.User.addTag("cart_items_count", "\(cart.items.count)")

Теги — строки. Всё сравнение серверное. Важно: не отправляйте тег при каждом запуске приложения — это лишний трафик. Отправляйте только при изменении значения.

Поведенческие сегменты и триггеры

Самый частый кейс — триггерная отправка по событию: пользователь бросил корзину, не открывал приложение 7 дней, прошёл онбординг но не совершил первое действие.

Для этого нужна серверная логика. Мобильный клиент только фиксирует events:

// Firebase Analytics — события автоматически доступны в Audience Builder
FirebaseAnalytics.getInstance(context).logEvent("checkout_started") {
    param("cart_value", 1250.0)
    param("items_count", 3L)
}

В Firebase Audiences можно построить сегмент: «пользователи, которые запустили checkout_started но не запустили purchase_complete за последние 24 часа» — и отправить им уведомление через FCM напрямую или через Firebase In-App Messaging.

Геосегментация

Геосегментация в push — не «находится в Киеве прямо сейчас», а «регион пользователя из профиля» или геозоны (geofences).

OneSignal поддерживает автоматическое определение локации при включённом setLocationShared(true). Но Apple и Google всё жёстче относятся к фоновой геолокации. Надёжнее — передавать регион из профиля пользователя как тег.

Для реальных геозон (уведомление при входе в зону) — CoreLocation на iOS с CLLocationManager.startMonitoring(for:) или Geofencing API на Android через GeofencingClient. Это работает через local notifications или silent push для обновления данных.

Сегменты по устройствам и платформам

{
  "filters": [
    { "field": "device_type", "relation": "=", "value": "iOS" },
    { "operator": "AND" },
    { "field": "app_version", "relation": ">=", "value": "3.0" }
  ]
}

Это полезно при релизе feature, доступной только в новой версии — не отправлять deep link на экран, которого нет в старом приложении.

Типичные ошибки при настройке сегментации

Теги пишутся непоследовательно: одни разработчики пишут "true"/"false", другие "1"/"0", третьи просто добавляют или удаляют тег. В результате сегмент «пользователи с тегом notifications_enabled = true» не захватывает тех, у кого просто есть этот тег без значения.

Лучше зафиксировать схему тегов в отдельном enum:

object UserTags {
    const val SUBSCRIPTION = "subscription_tier"
    const val REGION = "region_iso"
    const val LAST_ORDER_DAYS = "last_order_days_ago"

    fun updateLastOrderDays(daysSince: Int) {
        OneSignal.User.addTag(LAST_ORDER_DAYS, daysSince.toString())
    }
}

Сравнение платформ для сегментации

Наш опыт и сроки

Мы работаем с мобильными проектами с 2016 года. Реализовали сегментацию для 20+ приложений с аудиторией от 10 000 до 500 000 пользователей. Используем сертифицированные подходы к работе с Apple и Google API.

Проектирование схемы тегов и поведенческих событий, реализация SDK-интеграции на iOS + Android (или Flutter), настройка автоматических сегментов на стороне платформы — 5–8 рабочих дней. Сложные триггерные цепочки с серверной логикой (например, Braze Canvas или собственный cron-воркер) — от 2 недель.

Как получить консультацию по настройке сегментации?

Если у вас есть проект с push-уведомлениями — свяжитесь с нами. Оценим текущую архитектуру, предложим оптимальную схему сегментации и назовём точную стоимость. Опыт и гарантии качества включены. Закажите консультацию, чтобы узнать, как повысить open rate и снизить нагрузку на инфраструктуру.

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-уведомлений в мобильном приложении — мы свяжемся с вами в течение дня и предоставим точную оценку.