Реалізація 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 з часовими фічами. Обучення батчем раз на день, інференс — у момент постановки завдання на відправку.
Холодний старт: мало даних користувача
Новий користувач — нема історії відкриттів. Fallback-стратегія:
- Перші 7 днів: відправляємо в середнє оптимальне час для сегменту (визначаємо за часовим поясом, платформою, типом пристрою)
- 7–30 днів: переходимо на індивідуальний паттерн як тільки накопилось 10+ подій
- 30+ днів: повна індивідуальна оптимізація
Це реалізується через feature flag у feature store: user:{id}:send_time_model = "cohort" | "individual", обновляється автоматично при перетину порогів.
Технічний пайплайн відправки
- Маркетолог створює кампанію в CMS з параметром
send_time = "optimal" - У момент запуску кампанії замість немедленної відправки завдання раскладаються у чергу з delayed timing
- Для кожного користувача:
optimal_hour = get_optimal_send_time(user_id)→ завдання ставиться в Bull Queue з затримкою до наступного оптимального слота (сьогодні або завтра) - Воркер відправляє 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) — тригер для переобучення або ревізії фічей.
Терміни впровадження
| Варіант | Опис | Термін |
|---|---|---|
| Евристика | Гістограма за історією + Bull Queue | 1–2 тижні |
| ML-сегменти | Кластеризація + оптимальне час кластера | 3–5 тижнів |
| Індивідуальна ML | LightGBM per-user + feature store + A/B | 8–12 тижнів |
Вартість розраховується після аналізу поточної системи сповіщень та обсягу аудиторії.