У новинного додатка з аудиторією 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 тис. подій.
| Рівень | Метод | Інструменти | Коли застосовувати |
|---|---|---|---|
| 1 | Collaborative filtering | Surprise, implicit | Швидкий старт, мало даних |
| 2 | Content-based | TF-IDF, sentence embeddings | Є текстовий контент |
| 3 | CTR prediction | LightGBM, XGBoost | Велика історія подій |
Персоналізація тексту сповіщення
Одна новина — різні заголовки для різних сегментів. Не генерація через LLM при кожному відправленні (занадто повільно). Підхід:
- Редактор створює 3–5 варіантів заголовка для одного контенту.
- Multi-armed bandit (Thompson Sampling) обирає варіант для кожного користувача на основі його попереднього CTR зі схожими заголовками.
- Через 24 години аналізуємо результат та виявляємо переможця.
LLM (через API) може генерувати варіанти в різних стилях, але редактор обирає.
Чому suppression такий важливий?
При кожному відправленні сервіс персоналізації:
- Отримує список цільових користувачів.
- Запитує recommendation score з feature store (Redis з pre-computed vectors).
- Якщо score нижче порогу — сповіщення не відправляється (suppression).
- Якщо вище — обирає персоналізований текст.
- Логує рішення для навчання.
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 клієнтська частина не потребує змін.
Етапи впровадження
| Етап | Тривалість | Результат |
|---|---|---|
| Аудит | 1 тиждень | Звіт по поточній системі |
| Налаштування аналітики | 1–2 тижні | Пайплайн подій |
| Розробка моделі | 2–4 тижні | Прототип з метриками |
| A/B тест | 2 тижні | Статистично значущий результат |
Зв'яжіться з нами, щоб обговорити деталі та отримати індивідуальний план. Замовте безкоштовний аудит — оцінимо можливості персоналізації для вашого додатка. Економія на рекламних витратах може сягати $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.
Оцініть можливості персоналізації для вашого додатка — замовте безкоштовний аудит.