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

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

Новостний додаток відправляє одне й те ж сповіщення «Головні новини дня» всім 500K користувачам одночасно о 08:00. CTR — 2.1%. Після сегментації за інтересами той же контент з персоналізованими заголовками дає 7–12% CTR. AI-персоналізація — це робота з даними поведінки користувача, а не «розумний алгоритм» у вакуумі.

Дані як фундамент персоналізації

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

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

Ці події логуються з feature-набором: категорія контенту, час доби, день тижня, тип пристрою, версія OS, довжина заголовка.

Зберігання: ClickHouse або BigQuery — оптимізовані для аналітичних запитів за колонками. PostgreSQL для оперативних даних не підходить при обсязі >10M подій на день.

Моделі персоналізації: від простого до складного

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

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

Рівень 3: CTR prediction. Бінарна класифікація «тапне/не тапне» для кожної пари (користувач, контент). Модель: LightGBM або XGBoost на табличних фічах + CatBoost для категоріальних змінних (категорія, день тижня). Інференс швидкий — десятки мілісекунд на запит.

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

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

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

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

Для автоматичної генерації варіантів — LLM (GPT-4o або Claude через API) створює 5 варіантів заголовка в різних стилях (нейтральний, кліцбейт, запитання, статистика, цитата). Редактор вибирає з запропонованих, не пише сам.

Serving layer: як це працює при відправці

При кожній відправці сповіщення (event-triggered або scheduled) сервіс персоналізації:

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

Feature store — Redis з хешами: user:{id}:features → {category_prefs: "...", avg_open_rate: 0.08, ...}. Обновляється ночевим батчем та інкрементально при значимих подіях.

Suppression — ключовий інструмент. Краще не відправити, ніж відправити нерелевантне та отримати unsubscribe. Поріг suppression підбирається емпірично (A/B тест).

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

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

• CTR — основна метрика
• Notification opt-out rate — знизився ли відсоток відписок
• Session starts per notification — скільки сесій генерує сповіщення
• Revenue per notification — для e-commerce

Firebase A/B Testing + Remote Config покриває базові сценарії. Для продвинутого статистичного аналізу — власний фреймворк або Statsig/Eppo.

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

З точки зору клієнта — ніщо. Push приходить через стандартний FCM, обробляється як звичайно. Вся логіка персоналізації — серверна. Клієнт тільки відправляє події поведінки.

Шифрування payload при необхідності — через UNNotificationServiceExtension (iOS) розшифровує дані прямо на пристрої перед показом.

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

1. Аудит існуючої системи сповіщень та логування подій
2. Настройка аналітичного сховища (ClickHouse / BigQuery)
3. Розробка пайплайну збору подій (мобільний SDK → сервер → сховище)
4. Навчання першої моделі (collaborative filtering), A/B тест
5. Feature store та serving layer
6. Ітерація на більш складні моделі за результатами тестів

Терміни: мінімальна персоналізація (сегментація + bandit) — 4–6 тижнів. Повний ML-пайплайн — 12–16 тижнів, потребує data engineer + ML engineer в команді.