AI-персоналізація push-сповіщень у мобільному додатку

У новинного додатка з аудиторією 500 тис. користувачів CTR push-сповіщень спочатку був 2.1%. Після впровадження персоналізації на основі collaborative filtering та multi-armed bandit він виріс до 7–12% — у три з лишком рази. AI-персоналізація push-сповіщень покращує CTR у 3–5 разів у порівнянні зі стандартними розсилками. Зростання дала системна робота з поведінковими даними, а не магія. Наша команда реалізує AI-персоналізацію push-сповіщень під ключ: від збору подій до serving layer. Щоденно обробляється до 200 тис. подій, а latency рекомендацій не перевищує 50 мс.

Ми використовуємо перевірений стек: Swift 5.9 для iOS з async/await, Kotlin з Coroutines для Android, Flutter 3.x для кросплатформи. Серверна частина на Python 3.11 з бібліотеками Surprise (collaborative filtering), LightGBM (CTR prediction) та HuggingFace Transformers (текстові ембеддинги). Сховище подій — ClickHouse (для аналітики) та BigQuery (для ML-пайплайнів). Всі рішення витримують пікові навантаження до 10 тис. запитів на секунду. Ми гарантуємо зростання CTR після впровадження, а сертифіковані фахівці мають понад 7 років досвіду.

Які дані потрібні для персоналізації?

Без поведінкових даних персоналізація неможлива. Мінімальний набір подій:

• notification_received — показ сповіщення
• notification_opened — тап по сповіщенню
• notification_dismissed — смахування без відкриття
• content_viewed — перегляд контенту
• content_shared, content_saved, content_liked

Всі події логуються з фічами: категорія контенту, час доби, день тижня, тип пристрою, версія ОС, довжина заголовка. Для зберігання використовуємо ClickHouse або BigQuery — вони оптимізовані для аналітичних запитів. PostgreSQL не підійде при обсязі понад 10 млн подій на день.

Як AI обирає правильне сповіщення для кожного користувача?

Рівень 1: Collaborative filtering. Ідея: користувачі, схожі на вас, вже клікнули на це. Реалізація — Matrix Factorization (бібліотека Surprise або implicit). Модель навчається раз на добу на даних за останні 30 днів.

Рівень 2: Content-based filtering. Аналіз контенту, який користувач читав: витягуємо ключові слова та категорії через TF-IDF або sentence embeddings (модель all-MiniLM-L6-v2). При появі нового контенту рахуємо cosine similarity з історією користувача.

Рівень 3: CTR prediction. Бінарна класифікація — тапне чи ні для кожної пари користувач-контент. Використовуємо LightGBM або XGBoost на табличних фічах, CatBoost для категоріальних. Інференс займає десятки мілісекунд.

На практиці починаємо з рівня 1 (швидко та інтерпретовано), потім переходимо до рівня 3, коли накопичено 50–100 тис. подій.

Персоналізація тексту сповіщення

Одна новина — різні заголовки для різних сегментів. Не генерація через LLM при кожному відправленні (занадто повільно). Підхід:

1. Редактор створює 3–5 варіантів заголовка для одного контенту.
2. Multi-armed bandit (Thompson Sampling) обирає варіант для кожного користувача на основі його попереднього CTR зі схожими заголовками.
3. Через 24 години аналізуємо результат та виявляємо переможця.

LLM (через API) може генерувати варіанти в різних стилях, але редактор обирає.

Чому suppression такий важливий?

При кожному відправленні сервіс персоналізації:

1. Отримує список цільових користувачів.
2. Запитує recommendation score з feature store (Redis з pre-computed vectors).
3. Якщо score нижче порогу — сповіщення не відправляється (suppression).
4. Якщо вище — обирає персоналізований текст.
5. Логує рішення для навчання.

Feature store в Redis оновлюється нічним батчем та інкрементально. Suppression знижує opt-out rate та підвищує релевантність. У нашій практиці suppression знизив opt-out rate на 40% за 3 тижні.

A/B тестування та метрики

Обов'язковий A/B тест перед глобальним rollout: 10% користувачів отримують персоналізовані сповіщення, 90% — стандартні. Метрики через 2 тижні:

• CTR — основна метрика.
• Opt-out rate — чи знизився відсоток відписок.
• Session starts per notification.
• Revenue per notification.

Firebase A/B Testing + Remote Config покривають базові сценарії. Аналітика через Firebase push analytics та BigQuery push events.

Мобільний клієнт: що змінюється

Нічого. Push приходить через стандартний FCM, обробляється як зазвичай. Вся логіка серверна. Клієнт тільки відправляє події поведінки. Шифрування — через UNNotificationServiceExtension на iOS. Для mobile push personalization клієнтська частина не потребує змін.

Етапи впровадження

Зв'яжіться з нами, щоб обговорити деталі та отримати індивідуальний план. Замовте безкоштовний аудит — оцінимо можливості персоналізації для вашого додатка. Економія на рекламних витратах може сягати $1000 на місяць.

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

• Відсутність логування dismiss подій — модель не бачить негативний зворотний зв'язок.
• Використання PostgreSQL для аналітики — повільні запити при мільйонах подій.
• Запуск без A/B тесту — неможливо виміряти ефект.

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

• Аудит поточної системи сповіщень та аналітики.
• Проектування пайплайну даних.
• Розробка та навчання моделей (collaborative / content-based / CTR).
• Реалізація serving layer (feature store, suppression, multi-armed bandit).
• A/B тестування та аналіз метрик.
• Документація та навчання команди.
• Підтримка після запуску.

Наші компетенції

Понад 7 років досвіду в мобільній розробці, понад 50 проєктів з персоналізацією. Дотримуємося політик App Store та Google Play відповідно до Human Interface Guidelines. Ми пропонуємо push notification optimization, iOS personalized push та Android push personalization.

Оцініть можливості персоналізації для вашого додатка — замовте безкоштовний аудит.

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