У новостного приложения с аудиторией 500 тыс. пользователей CTR push-уведомлений изначально был 2.1%. После внедрения персонализации на базе collaborative filtering и multi-armed bandit он вырос до 7–12% — в три с лишним раза. Рост дала системная работа с поведенческими данными, а не магия. Наша команда реализует 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 тыс. запросов в секунду.
Какие данные нужны для персонализации?
Без поведенческих данных персонализация невозможна. Минимальный набор событий:
-
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 покрывают базовые сценарии.
Мобильный клиент: что меняется
Ничего. Push приходит через стандартный FCM, обрабатывается как обычно. Вся логика серверная. Клиент только отправляет события поведения. Шифрование — через UNNotificationServiceExtension на iOS.
Этапы внедрения
| Этап | Длительность | Результат |
|---|---|---|
| Аудит | 1 неделя | Отчет по текущей системе |
| Настройка аналитики | 1–2 недели | Пайплайн событий |
| Разработка модели | 2–4 недели | Прототип с метриками |
| A/B тест | 2 недели | Статистически значимый результат |
Свяжитесь с нами, чтобы обсудить детали и получить индивидуальный план. Закажите бесплатный аудит — оценим возможности персонализации для вашего приложения.
Типичные ошибки при внедрении персонализации
- Отсутствие логирования 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.
Оцените возможности персонализации для вашего приложения — закажите бесплатный аудит.