Персоналізація push-сповіщень: динаміка, Intelligent Delivery, A/B

Як персоналізація push-сповіщень рятує CTR від падіння?

Уявіть: ви відправили push-сповіщення «Знижка 20% на все!» — CTR впав на 15%, відписки зросли вдвічі. Без персоналізації 80% сповіщень залишаються невідкритими, а кожна друга відписка відбувається після першого ж повідомлення. Справжня персоналізація — коли сповіщення містить ім'я, улюблену категорію та приходить у момент звичної активності. Такі сповіщення дають CTR у 1.5–2 рази вище, а конверсія сягає 25–35%. Ми вирішували подібні задачі для десятків мобільних проєктів: від інтернет-магазинів до fintech-додатків. Наприклад, для fintech-додатку ми підняли CTR з 8% до 22% за місяць, впровадивши динамічні змінні та Intelligent Delivery. Розберемо технічну реалізацію на стеку OneSignal, Firebase та Braze. Отримайте консультацію щодо вашого сценарію — ми допоможемо підібрати оптимальне рішення.

Як динамічні змінні вирішують проблему низького CTR?

Динамічні змінні в payload — основа персоналізації. OneSignal та Braze підтримують шаблони зі змінними, які сервер рендерить перед відправкою.

Приклад payload для OneSignal:

{
  "app_id": "YOUR_APP_ID",
  "include_aliases": { "external_id": ["user_88234"] },
  "headings": { "ru": "{{first_name}}, ваш улюблений товар подешевшав" },
  "contents": { "ru": "{{product_name}} тепер коштує {{new_price}} ₴ — на {{discount_percent}}% менше" },
  "data": { "product_id": "{{product_id}}", "screen": "product_detail" }
}

Значення змінних беруться з тегів користувача. Тег first_name встановлюється на клієнті:

OneSignal.User.addTag("first_name", user.firstName)
OneSignal.User.addTag("preferred_category", user.topCategory)

Персоналізація на основі поведінки

Це складніше — вимагає аналітичного шару на бекенді. Типова схема:

1. Клієнт логує події (перегляд товару, додавання до вішлисту).
2. Бекенд або ML-сервіс формує рекомендації по користувачу.
3. При відправці payload збагачується рекомендованим контентом.

Якщо власного движка немає — використовуємо Firebase Personalization або Braze Recommendations. Приклад логування на Kotlin:

firebaseAnalytics.logEvent(FirebaseAnalytics.Event.VIEW_ITEM) {
    param(FirebaseAnalytics.Param.ITEM_ID, product.id)
    param(FirebaseAnalytics.Param.ITEM_CATEGORY, product.category)
    param(FirebaseAnalytics.Param.PRICE, product.price)
}

Чому Intelligent Delivery — не розкіш, а необхідність?

OneSignal Intelligent Delivery та Braze Optimal Time відстежують патерни активності кожного користувача та відкладають доставку до періоду найбільшої ймовірності відкриття. Для одного — 8 ранку, для іншого — 23:00. Вмикається одним параметром: "delayed_option": "last-active". Більш точний варіант — "intelligent_delivery": true. За нашими даними, це збільшує CTR на 25–40% — найкращий результат серед усіх методів оптимізації часу. OneSignal Documentation on Intelligent Delivery

Як виконати A/B тестування push-сповіщень?

Без A/B не можна стверджувати, що персоналізація працює. OneSignal підтримує нативні спліт-тести: відправляється кілька варіантів (наприклад, два різні заголовки), і після набору статистики алгоритм автоматично показує переможця. Приклад:

{
  "name": "price_drop_ab_test",
  "messages": [
    {
      "variant_id": "A",
      "contents": { "ru": "{{product_name}} подешевшав на {{discount}}%" },
      "weight": 50
    },
    {
      "variant_id": "B",
      "contents": { "ru": "Знижка {{discount}}% на товар з вашого вішлисту" },
      "weight": 50
    }
  ]
}

Після тесту OneSignal показує CTR по кожному варіанту. Переможець впроваджується в шаблон.

Як налаштувати персоналізацію за 6 кроків

1. Інтегрувати SDK OneSignal (iOS/Android) або Firebase Cloud Messaging.
2. Налаштувати теги користувачів на клієнті: ім'я, категорія, останній візит.
3. Створити шаблони push зі змінними {{first_name}}, {{product_name}}.
4. Підключити Intelligent Delivery (OneSignal) або Optimal Time (Braze).
5. Запустити A/B тест з двома варіантами заголовка та автоматичним визначенням переможця.
6. Налаштувати відстеження конверсій через outcome events.

Порівняння методів персоналізації

Відстеження конверсій

CTR — проміжна метрика. Важливіше — чи виконав користувач цільову дію. Для цього потрібні outcome events:

OneSignal.Notifications.addClickListener { event ->
    val productId = event.notification.additionalData?.getString("product_id")
    OneSignal.Session.addOutcome("notification_click_to_product")
}

OneSignal.Session.addOutcomeWithValue("purchase_from_notification", orderValue.toFloat())

Це пов'язує конверсію з конкретним сповіщенням. У наших проєктах конверсія після кліку сягає 35%.

Порівняння платформ push-сповіщень

Типові помилки при персоналізації

Що входить в нашу роботу

• Аудит поточних сповіщень та метрик
• Налаштування динамічних шаблонів та інтеграція SDK
• Підключення Intelligent Delivery та A/B тестів
• Налаштування відстеження конверсій (outcome events)
• Документація з доставки та підтримка 2 тижні після запуску

Терміни та вартість

Реалізація базового набору (динамічні змінні, Intelligent Delivery, A/B тестування) — від 6 до 10 робочих днів. Якщо потрібен власний рекомендаційний шар на бекенді або інтеграція із зовнішньою ML-системою — терміни обговорюються окремо. Економія на витратах на сповіщення за рахунок підвищення CTR може сягати 30% при нашому підході. Вартість розраховується індивідуально під ваш проєкт.

Наш досвід: понад 5 років на ринку мобільної розробки, реалізували більше 50 проєктів з персоналізацією. Сертифіковані спеціалісти OneSignal та Firebase гарантують якість.

Замовте аудит ваших push-сповіщень — зв'яжіться з нами. Оцінимо проєкт безкоштовно та запропонуємо рішення. Отримайте консультацію щодо вашого сценарію — ми допоможемо підібрати оптимальне рішення.

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