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

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

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

Ночная доставка бьёт по отклику сразу с двух сторон. Пользователь просыпается к стопке накопившихся уведомлений, читает их в спешке и смахивает не глядя — сообщение потрачено, а интерес к приложению снижен. Днём, наоборот, уведомление приходит в разгар рабочего дня и теряется среди других.

Первое, что проседает, — доля открытий. В сводном отчёте цифра при этом выглядит терпимо: сильные сегменты вытягивают среднюю, а по часовым поясам расхождение измеряется разами. Заметить это вручную тяжело: чтобы поймать момент, нужно сопоставить отклик по каждому сегменту, типу устройства и типу сообщения.

Дальше ручная логика перестаёт масштабироваться. Сегментов десятки, событий в приложении сотни, у каждого пользователя свой ритм — а расписание одно на всех. Оптимизация времени отправки нужна именно затем, чтобы момент доставки выбирался не по общему правилу, а по поведению конкретного человека. Разбираем, как это закрывается.

Что даёт адаптивное время доставки уведомлений

Адаптивное время доставки — это когда приложение не рассылает всем в один момент, а подбирает окно под конкретного пользователя: по истории его открытий, часовому поясу и давности последнего запуска. Настройка пересчитывается на свежих данных, поэтому окно смещается вместе с изменением привычек, а не фиксируется один раз при подключении.

• Доля открытий. Отправка в персональное окно поднимает долю открытий против рассылки «всем в одно время» — эффект считаем на контрольной группе, чтобы не спутать с сезонностью.
• Доля переходов. Открытие и переход — разные метрики: уведомление приходит вовремя, но ведёт в общий экран, и переходов нет. Поэтому вместе со временем подбираем точку входа.
• Отписки от рассылки. Часть отписок — реакция на неудобный момент, а не на содержание. Сдвиг окна убирает этот класс потерь без правки текстов.
• Отказы доставки. Недействительные адреса устройств вычищаются по расписанию: доля отказов доставки падает, а репутация отправителя перед Firebase Cloud Messaging остаётся чистой.
• Сегментация по активности. Новичкам, ядру и «спящим» нужны разные окна и разная частота: единая настройка даёт перекос — одним слишком часто, другим слишком редко.

Метрики фиксируем до изменений и сравниваем на одинаковых периодах, иначе рост открытий легко списать на сезон. Если открытия растут, а отписки идут вверх — окно подобрано агрессивно, правило пересматривается.

Способы подбора времени отправки: сравнение режимов

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

На практике гибридный режим собирают так: прогноз обслуживает сегменты с историей, правило по часовому поясу закрывает остаток, а для критичных рассылок остаётся ручное окно с приоритетом выше автоматики. Доля сегментов под прогнозом растёт по мере накопления событий, и режим переключается без переписывания логики отправки.

Как мы внедряем подбор времени отправки: этапы работ

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

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

Что остаётся у заказчика после внедрения

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

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

Эти артефакты — условие, при котором оптимизацию можно менять и выключать своими силами, не обращаясь к нам за каждой правкой.

Кейс: как выросла доля открытий без увеличения объёма рассылки

Приложение с несколькими сотнями тысяч активных пользователей отправляло пуши фиксированными волнами: маркетинговые — утром по времени офиса, сервисные — сразу по событию. В базе были люди из разных часовых поясов, поэтому часть сообщений приходила ночью или в часы, когда человек неделями не открывал приложение. Доля открытий держалась около 4–5%, а жалобы на неуместные сообщения росли быстрее, чем аудитория.

Мы добавили модель, которая считает персональное окно доставки для каждого: локальное время, историю входов, день недели, реакцию на прошлые сообщения. Отправка идёт через Braze, а расчёт окна живёт на нашей стороне — расписание пересобирается раз в сутки, поэтому задержки внешнего сервиса на него не влияют. Сегменты и число сообщений на пользователя остались прежними: менялся только момент отправки.

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

Что делать, если рассылка уже идёт по фиксированному графику?

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

Через несколько недель накапливается история, сопоставимая с текущей логикой: те же сегменты, события и типы уведомлений, только с дополнительным полем — рекомендованное окно и признак, по которому оно выбрано. Старые записи о доставке и открытиях не перезаписываем, а дописываем рядом, поэтому отчёты, выгрузки и дашборды продолжают строиться без изменений и прошлые периоды остаются сравнимыми.

Перевод на адаптив делаем долями: сначала 5–10% аудитории, приоритетно неактивные сегменты и тихие часы, где цена ошибки минимальна. Если метрики проседают, возврат — один переключатель на фиксированное расписание, состояние подписок и накопленная история при этом не теряются.

Сравнение держим на контрольной группе, которая остаётся на текущем графике. Смотрим долю открытий в первые часы после отправки, отписки и долю доставленных по сегментам, а не общую цифру по приложению. Если на каком-то сегменте адаптив проигрывает, для него оставляем фиксированное расписание: модель предлагает окно, но частотные ограничения и правила тихих часов остаются решающими.

Вопросы, которые задают инженеры до подключения

До подключения оптимизации отправки команда задаёт пять вопросов: хватает ли объёма данных, как учитываются часовые пояса, что с ночными ограничениями, кто отвечает за ошибку модели и как отделить эффект от сезонного роста активности.

Как учитываются часовые пояса?

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

Что с ночными ограничениями?

Тихие часы задаются политикой кампании и приоритетнее прогноза. Даже при высокой предсказанной вероятности открытия отправка в ночное окно блокируется, а уведомление переносится на утреннюю границу.

Кто отвечает за ошибку модели?

Каждая кампания идёт с контрольной группой и стоп-правилами по частоте, отпискам и падению открытий. Отклонение от прогноза выше порога останавливает рассылку автоматически, а порядок проверок фиксирует Регламент контроля качества доставки.

Как отделить эффект от сезонности активности?

Сравнение идёт не с прошлой неделей, а с контрольной группой, которая отправляет по фиксированному расписанию. Сезонные всплески подаются в модель отдельным признаком, поэтому прирост открытий не списывается на праздники.

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

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

Взамен вернёмся с планом: как собираются признаки, по какому правилу аудитория делится на группы, как выбирается момент отправки и как всё вернуть к фиксированному расписанию, если результат окажется хуже.

• Что нужно от вас: перечень сценариев и каналов, выгрузка истории отправок и реакций за сопоставимый период, ограничения по частоте и «тихим часам».
• Что подготовим взамен: схему признаков, черновые правила группировки аудитории и вариант контроля — часть сегментов остаётся на прежнем расписании для сравнения.
• Порядок этапов: разбор данных, настройка сбора событий, пилот на одном сценарии, расширение на остальные, регламент регулярного пересмотра правил.
• Сроки и отчётность: согласуем контрольные точки по этапам, на каждой — отчёт с замером открытий, переходов и отписок относительно контрольной группы.
• Точки возврата: фиксируем, при каких отклонениях метрик правило отключается и рассылка возвращается к прежнему расписанию.
• Кто участвует: с вашей стороны — владелец рассылок и тот, кто подтверждает сценарии; с нашей — инженер по данным и разработчик мобильного приложения.

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