Представьте: вы запускаете push-кампанию в 10:00 понедельника, но половина пользователей живёт в другом часовом поясе, а треть уже в потоке задач. Одно уведомление в правильное время для конкретного пользователя эффективнее десяти в универсальное. Наша команда реализовала подобные решения для 20+ приложений — свяжитесь с нами для аудита вашей системы.
Почему универсальное время отправки неэффективно?
Пользователи открывают уведомления в разное время: утренние проверки, обеденный перерыв, вечерний досуг. Часовые пояса и привычки влияют на момент, когда push будет замечен. Отправка в среднее время приводит к потере уведомления. По данным Urban Airship, персонализированные по времени уведомления увеличивают вовлечённость на 25%. Экономия маркетингового бюджета за счёт повышения CTR достигает 30–40%.
Что такое оптимальное время отправки на самом деле?
Задача: для каждого пользователя предсказать, в какое время суток он с наибольшей вероятностью откроет уведомление. Это классическая задача регрессии или классификации на временных рядах с историческими данными об открытиях.
Входные фичи модели:
- История открытий уведомлений с timestamp (последние 90 дней)
- День недели и час для каждого события
- Тип контента (транзакционное, маркетинговое, редакционное)
- Часовой пояс устройства
- Время последней активности в приложении
Целевая переменная: вероятность открытия для каждого часового слота (24 слота × 7 дней = 168 бинарных классификаторов или один мультиклассовый).
Архитектура решения: от эвристики до ML
Минимальный вариант без ML: эвристика на основе агрегированной статистики. Для каждого пользователя строим гистограмму открытий по часам. Оптимальное время = час с максимальным числом открытий за последние 30 дней. Внедряется за 1–2 недели, работает без ML-инфраструктуры.
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-стратегию:
Таблица стратегий
| Фаза | Стратегия | Условие |
|---|---|---|
| 0–7 дней | Среднее для сегмента | Нет данных |
| 7–30 дней | Индивидуальный паттерн | 10+ событий |
| 30+ дней | Полная индивидуальная | Достаточная история |
Это реализуется через feature flag в feature store: user:{id}:send_time_model = "cohort" | "individual", обновляется автоматически при пересечении порогов.
Технический pipeline отправки
- Маркетолог создаёт кампанию в CMS с параметром
send_time = "optimal". - В момент запуска задачи раскладываются в очередь с delayed timing.
- Для каждого пользователя:
optimal_hour = get_optimal_send_time(user_id)→ задача ставится в Bull Queue с delay до следующего оптимального слота (сегодня или завтра). - Воркер отправляет push в нужное время.
Для time-sensitive кампаний устанавливаем max_delay = 24h — если оптимальное время прошло сегодня, отправляем завтра; если и завтра нет — отправляем в следующее доступное окно в пределах недели.
Frequency capping и метрики
Не перегружайте пользователя уведомлениями вне зависимости от оптимального времени. Лучшая практика — не более 2–3 маркетинговых push в неделю на пользователя. Реализация через Redis: INCR user:{id}:push_count:{week} при каждой отправке, EXPIRE на конец недели. Перед отправкой — проверка счётчика.
Комбинация optimal send time + frequency cap + relevance scoring — это полноценная push notification intelligence система. Трекайте метрики: lift в CTR, распределение отправок по часам, coverage пользователей с достаточными данными. Дашборд в Grafana или Metabase с ежедневным обновлением. Деградация модели — триггер для переобучения.
Варианты внедрения
| Вариант | Описание | Срок |
|---|---|---|
| Эвристика | Гистограмма + Bull Queue | 1–2 недели |
| ML-сегменты | Кластеризация + время кластера | 3–5 недель |
| Индивидуальная ML | LightGBM per-user + feature store + A/B | 8–12 недель |
Что входит в работу
- Аудит текущей системы уведомлений и сбор требований
- Выбор модели (эвристика, сегментная ML, индивидуальная ML) и её реализация
- Интеграция с вашей кодовой базой (Swift, Kotlin, Flutter, React Native)
- Настройка pipeline отправки (Bull Queue, schedule)
- Реализация frequency capping и A/B-теста
- Развёртывание модели (feature store, batch prediction)
- Дашборд мониторинга (CTR, coverage, распределение по часам)
- Документация и обучение команды
Стоимость внедрения рассчитывается после анализа текущей системы и объёма аудитории. Закажите консультацию для точного предложения — свяжитесь с нами, чтобы обсудить ваш проект.