AI-оптимізація часу надсилання push-повідомлень

AI-оптимізація сповіщень: де ламається ручна логіка

Ручна логіка розсилки майже завжди виглядає однаково: розклад налаштовують один раз — «ранок буднього дня за часом головного офісу» — і далі всі сегменти отримують повідомлення за цим єдиним розкладом. Поки база локальна, схема працює.

Щойно в ній з'являються користувачі з кількох часових поясів, частина аудиторії починає отримувати пуші в незручні години.

Нічна доставка б'є по відгуку одразу з двох боків. Користувач прокидається до стосу накопичених сповіщень, читає їх поспіхом і змахує не дивлячись — повідомлення витрачено, а інтерес до застосунку знижено. Удень, навпаки, сповіщення приходить у розпал робочого дня і губиться серед інших.

Перше, що просідає, — частка відкриттів. У зведеному звіті цифра при цьому виглядає терпимо: сильні сегменти витягують середню, а за часовими поясами розбіжність вимірюється разами.

Помітити це вручну важко: щоб зловити момент, потрібно зіставити відгук за кожним сегментом, типом пристрою та типом повідомлення.

Далі ручна логіка перестає масштабуватися. Сегментів десятки, подій у застосунку сотні, у кожного користувача свій ритм — а розклад один на всіх.

Оптимізація часу відправлення потрібна саме для того, щоб момент доставки вибирався не за загальним правилом, а за поведінкою конкретної людини. Розбираємо, як це закривається.

Що дає адаптивний час доставки сповіщень

Адаптивний час доставки — це коли застосунок не розсилає всім в один момент, а підбирає вікно під конкретного користувача: за історією його відкриттів, часовим поясом і давністю останнього запуску.

Налаштування перераховується на свіжих даних, тому вікно зміщується разом зі зміною звичок, а не фіксується один раз при підключенні.

• Частка відкриттів. Відправлення в персональне вікно піднімає частку відкриттів проти розсилки «всім в один час» — ефект рахуємо на контрольній групі, щоб не сплутати із сезонністю.
• Частка переходів. Відкриття й перехід — різні метрики: сповіщення приходить вчасно, але веде на загальний екран, і переходів немає. Тому разом із часом підбираємо точку входу.
• Відписки від розсилки. Частина відписок — реакція на незручний момент, а не на зміст. Зсув вікна прибирає цей клас втрат без правки текстів.
• Відмови доставки. Недійсні адреси пристроїв вичищаються за розкладом: частка відмов доставки падає, а репутація відправника перед Firebase Cloud Messaging залишається чистою.
• Сегментація за активністю. Новачкам, ядру та «сплячим» потрібні різні вікна й різна частота: єдине налаштування дає перекіс — одним занадто часто, іншим занадто рідко.

Метрики фіксуємо до змін і порівнюємо на однакових періодах, інакше зростання відкриттів легко списати на сезон. Якщо відкриття зростають, а відписки йдуть угору — вікно підібрано агресивно, правило переглядається.

Способи підбору часу відправлення: порівняння режимів

Вибір режиму визначається двома речами: скільки накопичено даних про поведінку конкретного користувача і наскільки однорідна база за часовими поясами. Нижче — п'ять підходів, які трапляються в робочій експлуатації, з їхніми реальними межами.

На практиці гібридний режим збирають так: прогноз обслуговує сегменти з історією, правило за часовим поясом закриває залишок, а для критичних розсилок залишається ручне вікно з пріоритетом вище за автоматику.

Частка сегментів під прогнозом зростає в міру накопичення подій, і режим перемикається без переписування логіки відправлення.

Як ми впроваджуємо підбір часу відправлення: етапи робіт

Роботи йдуть від даних до моделі й від моделі — до вашої команди, без схеми «впровадили та пішли». Спочатку розбираємося, що взагалі є: які події надходять із клієнта, де губляться, як фіксуються відписки та відкриття, скільки історії накопичено за кожним сегментом.

Якщо даних мало або в них діри, підбір часу дасть нестабільний результат — це з'ясовується на першому етапі, а не після запуску.

1. Аудит даних і поточної логіки. Звіряємо події у сховищі з тим, що реально надходить на пристрої, перевіряємо повноту історії, дублі та затримки. На виході — перелік прогалин і рішення, які з них закриваємо збором, а які обходимо.
2. Схема потоків подій. Фіксуємо, який сигнал де народжується, як доїжджає до розрахункового контуру і з якою затримкою повертається рішення. Схема узгоджується до коду — інакше навчання будується на даних, яких на момент відправлення ще немає.
3. Налаштування сегментів. Ділимо аудиторію за поведінкою та активністю, а не за грубими зрізами: у нового користувача і у сплячого різна динаміка відкриттів. Для рідкісних сегментів задаємо правила, щоб рішення не будувалося на кількох спостереженнях.
4. Навчання та калібрування. Модель обчислює переважне вікно відправлення для кожного отримувача, ми обмежуємо її частотою торкань, тихими годинами та вашими правилами.
5. Перевірка на частині трафіку. Вмикаємо підбір на частці аудиторії, решту залишаємо контрольною групою: порівнюємо частку відкриттів, час до відкриття та відписки. Розширюємо лише після стійкої переваги на горизонті кількох тижнів.
6. Передача та навчання команди. Віддаємо конфігурації, схему, регламент перенавчання та порядок відкату, проводимо розбір із вашими інженерами й маркетингом. Далі система живе на вашому боці — ми залишаємося на підтримці.

Що залишається у замовника після впровадження

Впровадження не закінчується запуском на реальних користувачах — замовник отримує набір артефактів, за якими систему можна експлуатувати, розвивати й за потреби відкотити без нас. Кожен пункт передаємо в репозиторій проєкту й розбираємо з вашою командою на передачі.

• Схема потоків. Діаграма шляху події: від дії користувача в застосунку до доставки та відкриття, з точками, де підключається вибір часу. Видно, де губляться події і який сервіс за що відповідає.
• Політики сегментації. Правила розбиття аудиторії за активністю, часовим поясом, історією відкриттів і частотою заходів. Зберігаються в конфігурації, а не в коді — сегмент змінюється без релізу застосунку.
• Правила частоти. Добові та тижневі ліміти відправлень на користувача, «тихі години», пріоритети між типами кампаній. Окремо описано, що робить система при конфлікті двох розсилок.
• Регламент контролю. Метрики та пороги: частка доставлених, відкриття, відписки, скарги, затримка відправлення. Зазначено, хто дивиться, з якою періодичністю і що робить при виході за межі.
• Документація. Опис логіки вибору часу, вхідних ознак, меж застосовності та відомих слабких місць — щоб робота не залежала від одного інженера.
• Порядок відкату. Покрокове повернення до фіксованого розкладу відправлення: перемикач, час реакції, перевірка результату. Відкат не потребує перезбирання застосунку.

Ці артефакти — умова, за якої оптимізацію можна змінювати й вимикати своїми силами, не звертаючись до нас за кожною правкою.

Кейс: як зросла частка відкриттів без збільшення обсягу розсилки

Застосунок із кількома сотнями тисяч активних користувачів надсилав пуші фіксованими хвилями: маркетингові — вранці за часом офісу, сервісні — одразу за подією.

У базі були люди з різних часових поясів, тому частина повідомлень приходила вночі або в години, коли людина тижнями не відкривала застосунок. Частка відкриттів трималася близько 4–5%, а скарги на недоречні повідомлення зростали швидше, ніж аудиторія.

Ми додали модель, яка обчислює персональне вікно доставки для кожного: локальний час, історію входів, день тижня, реакцію на минулі повідомлення.

Відправлення йде через Braze, а розрахунок вікна живе на нашому боці — розклад перезбирається раз на добу, тому затримки зовнішнього сервісу на нього не впливають. Сегменти та кількість повідомлень на користувача залишилися незмінними: змінювався лише момент відправлення.

Зростання не можна списати на сезонність: контрольна група на фіксованому розкладі показувала попередні цифри. Ефект тримається не сам по собі — вікно перераховується, а невдалі сценарії вимикаються.

Якщо модель починає розносити повідомлення на пізні години, обмежувач повертає їх у денний інтервал: частка відкриттів просідає незначно, зате нічних доставок не з'являється.

Що робити, якщо розсилка вже йде за фіксованим графіком?

Переходити можна без зупинки розсилки: адаптивний підбір часу — це надбудова над поточною логікою відправлення, а не її заміна. Поки сповіщення йдуть за фіксованим графіком, новий шар паралельно рахує, у яке вікно кожне з них потрапило б за адаптивного вибору. Такий тіньовий режим не впливає на отримувача й не потребує переписувати наявні сценарії.

Через кілька тижнів накопичується історія, зіставна з поточною логікою: ті самі сегменти, події та типи сповіщень, тільки з додатковим полем — рекомендоване вікно та ознака, за якою його вибрано.

Старі записи про доставки та відкриття не перезаписуємо, а дописуємо поряд, тому звіти, вивантаження й дашборди продовжують будуватися без змін, і минулі періоди залишаються зіставними.

Переведення на адаптив робимо частками: спочатку 5–10% аудиторії, пріоритетно неактивні сегменти та тихі години, де ціна помилки мінімальна. Якщо метрики просідають, повернення — один перемикач на фіксований розклад, стан підписок і накопичена історія при цьому не втрачаються.

Порівняння тримаємо на контрольній групі, яка залишається на поточному графіку. Дивимося частку відкриттів у перші години після відправлення, відписки та частку доставлених за сегментами, а не загальну цифру по застосунку.

Якщо на якомусь сегменті адаптив програє, для нього залишаємо фіксований розклад: модель пропонує вікно, але частотні обмеження та правила тихих годин залишаються вирішальними.

Питання, які задають інженери до підключення

До підключення оптимізації відправлення команда ставить п'ять питань: чи вистачає обсягу даних, як враховуються часові пояси, що з нічними обмеженнями, хто відповідає за помилку моделі та як відокремити ефект від сезонного зростання активності.

Як враховуються часові пояси?

Мітка часу зберігається в UTC, а вікно відправлення обчислюється в локальному часі отримувача. Перехід на літній час і переїзд користувача відстежуються за останнім відомим регіоном — інакше частина аудиторії отримує сповіщення вночі.

Що з нічними обмеженнями?

Тихі години задаються політикою кампанії та мають пріоритет над прогнозом. Навіть за високої передбаченої ймовірності відкриття відправлення в нічне вікно блокується, а сповіщення переноситься на ранкову межу.

Хто відповідає за помилку моделі?

Кожна кампанія йде з контрольною групою та стоп-правилами за частотою, відписками й падінням відкриттів. Відхилення від прогнозу вище порогу зупиняє розсилку автоматично, а порядок перевірок фіксує Регламент контролю якості доставки.

Як відокремити ефект від сезонності активності?

Порівняння йде не з минулим тижнем, а з контрольною групою, яка надсилає за фіксованим розкладом. Сезонні сплески подаються в модель окремою ознакою, тому приріст відкриттів не списується на свята.

Обговоримо задачу та повернемося з оцінкою й планом

Щоб запропонувати схему оптимізації часу відправлення, нам достатньо розуміти, які події ви вже фіксуєте: відправлення, відкриття, переходи та цільові дії, відписки.

На старті не потрібні продакшн-доступи й правки в коді — вистачить вивантаження за каналами та узгодженого списку сценаріїв, які готові віддавати під управління моделі.

Натомість повернемося з планом: як збираються ознаки, за яким правилом аудиторія ділиться на групи, як вибирається момент відправлення і як усе повернути до фіксованого розкладу, якщо результат виявиться гіршим.

• Що потрібно від вас: перелік сценаріїв і каналів, вивантаження історії відправлень і реакцій за зіставний період, обмеження за частотою та «тихими годинами».
• Що підготуємо натомість: схему ознак, чорнові правила групування аудиторії та варіант контролю — частина сегментів залишається на попередньому розкладі для порівняння.
• Порядок етапів: розбір даних, налаштування збору подій, пілот на одному сценарії, розширення на решту, регламент регулярного перегляду правил.
• Терміни та звітність: узгодимо контрольні точки за етапами, на кожній — звіт із вимірюванням відкриттів, переходів і відписок відносно контрольної групи.
• Точки повернення: фіксуємо, за яких відхилень метрик правило вимикається і розсилка повертається до попереднього розкладу.
• Хто бере участь: з вашого боку — власник розсилок і той, хто підтверджує сценарії; з нашого — інженер з даних і розробник мобільного застосунку.

Опишіть задачу та поточну схему відправлення — повернемося з оцінкою, планом робіт і порядком етапів.