Уявіть: ви запускаєте push-кампанію о 10:00 понеділка, але половина користувачів живе в іншому часовому поясі, а третина вже в потоці задач. Одне сповіщення в правильний час для конкретного користувача ефективніше за десять в універсальний. Наша команда має 15+ років досвіду, реалізувала 20+ проектів і гарантує якість. За нашими даними, AI-оптимізація часу відправлення підвищує CTR у 2-3 рази. Типова економія маркетингового бюджету — 30-40%. Зв'яжіться з нами для аудиту вашої системи.
Чому універсальний час відправлення неефективний?
Користувачі відкривають сповіщення в різний час: ранкові перевірки, обідня перерва, вечірній відпочинок. Часові пояси та звички впливають на момент, коли push буде помічений. Відправлення в середній час призводить до втрати сповіщення. За даними Urban Airship, персоналізовані за часом сповіщення збільшують залученість на 25%. Економія маркетингового бюджету за рахунок підвищення CTR сягає 30–40%.
Для досягнення максимальної ефективності ми використовуємо AI оптимізацію сповіщень, персоналізацію сповіщень на основі machine learning сповіщення, аналіз LightGBM на часових рядах, frequency capping, push notification intelligence, відстеження CTR сповіщень, вирішення проблеми cold start сповіщення, сегментацію користувачів сповіщення, A/B тестування сповіщень та моніторинг через Grafana дашборд сповіщення.
Що таке оптимальний час відправлення насправді?
Задача: для кожного користувача передбачити, в який час доби він з найбільшою ймовірністю відкриє сповіщення. Це класична задача регресії або класифікації на часових рядах з історичними даними про відкриття.
Вхідні фічі моделі:
- Історія відкриттів сповіщень з 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, розподіл за годинами)
- Документація та навчання команди
Вартість впровадження розраховується після аналізу поточної системи та обсягу аудиторії. Замовте консультацію для точного пропозиції — зв'яжіться з нами, щоб обговорити ваш проект.