Реализация 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 в команде.