Реализация AI-оптимизации времени отправки уведомлений в мобильном приложении

Реализация AI-оптимизации времени отправки уведомлений в мобильном приложении

Маркетолог ставит рассылку на 10:00 понедельника — «деловое время, все уже проснулись». Половина аудитории в другом часовом поясе, треть просыпается в 7:00 и к 10:00 уже в потоке задач. Одно уведомление в правильное время для конкретного пользователя работает лучше, чем десять в «универсальное» время.

Что такое optimal send time на самом деле

Задача: для каждого пользователя предсказать, в какое время суток он с наибольшей вероятностью откроет уведомление. Это классическая задача регрессии/классификации на временных рядах с историческими данными об открытиях.

Входные фичи для модели:

• История открытий уведомлений с timestamp (последние 90 дней)
• День недели и час для каждого открытия
• Тип контента уведомления (транзакционное, маркетинговое, editorial)
• Часовой пояс устройства
• Время последней активности в приложении

Целевая переменная: вероятность открытия для каждого часового слота (24 слота × 7 дней = 168 бинарных классификаторов, или один мультиклассовый).

Архитектура решения

Минимальный вариант без ML: эвристика на основе агрегированной статистики. Для каждого пользователя строим гистограмму открытий по часам. Оптимальное время = час с максимальным числом открытий за последние 30 дней. Это работает, не требует ML-инфраструктуры, внедряется за 1–2 недели.

ML-вариант: модель на уровне сегментов или индивидуального пользователя.

Для сегментов (если мало данных на пользователя): кластеризация пользователей по паттернам активности через K-Means или DBSCAN. Кластеры типа «ранние пташки» (активны 6:00–9:00), «офисные» (12:00–13:00, 18:00–20:00), «ночные» (21:00–00:00). Каждый кластер получает своё оптимальное время отправки.

Для индивидуального предсказания: LightGBM с временными фичами. Обучение батчем раз в сутки, inference — в момент постановки задачи на отправку.

Когда пользователя мало данных (cold start)

Новый пользователь — нет истории открытий. Fallback-стратегия:

1. Первые 7 дней: отправляем в среднее оптимальное время для сегмента (определяем по часовому поясу, платформе, типу устройства)
2. 7–30 дней: переходим на индивидуальный паттерн как только накопилось 10+ событий
3. 30+ дней: полная индивидуальная оптимизация

Это реализуется через feature flag в feature store: user:{id}:send_time_model = "cohort" | "individual", обновляется автоматически при пересечении порогов.

Технический pipeline отправки

1. Маркетолог создаёт кампанию в CMS с параметром send_time = "optimal"
2. В момент запуска кампании вместо немедленной отправки задачи раскладываются в очередь с delayed timing
3. Для каждого пользователя: optimal_hour = get_optimal_send_time(user_id) → задача ставится в Bull Queue с delay до следующего оптимального слота (сегодня или завтра)
4. Воркер отправляет push в нужное время

Ограничение: «следующий оптимальный слот» может быть завтра. Для time-sensitive кампаний устанавливаем max_delay = 24h — если оптимальное время прошло сегодня, отправляем завтра; если и завтра нет — отправляем в следующее доступное окно в пределах недели.

Frequency capping

Смежная задача: не перегружать пользователя уведомлениями вне зависимости от оптимального времени. Лучшая практика — не более 2–3 маркетинговых уведомлений в неделю на пользователя.

Реализация через Redis: INCR user:{id}:push_count:{week} при каждой отправке, EXPIRE на конец недели. Перед постановкой задачи на отправку — проверка счётчика.

Комбинация optimal send time + frequency cap + relevance scoring (из AI-персонализации) — это полноценная push notification intelligence система.

Мониторинг и обратная связь

Метрики, которые нужно трекать постоянно:

• Lift в CTR по сравнению с baseline (случайное или фиксированное время)
• Распределение отправок по часам — не должно быть аномальных пиков
• Coverage: для скольких пользователей есть достаточно данных для индивидуального предсказания

Дашборд в Grafana или Metabase с ежедневным обновлением. Деградация модели (снижение CTR) — триггер для переобучения или ревизии фичей.

Сроки внедрения

Стоимость рассчитывается после анализа текущей системы уведомлений и объёма аудитории.