# Настройте частоту, а не увеличивайте объём

- **Канонический URL:** https://playbook.affpartners.io/ru/practices/push-frequency/index.html
- **Markdown-версия:** https://playbook.affpartners.io/ru/practices/push-frequency/index.md
- **Раздел:** Push-уведомления
- **Время:** 75 минут на первую настройку

Пользователь видит все сообщения как один поток, даже если их отправляют разные команды. Соберите общий календарь и задайте правила, которые защищают человека от повторов и конкурирующих push.

## Результат

Одностраничная политика частоты: типы сообщений, приоритеты, общий лимит, паузы, исключения и владелец контроля.

## У пользователя один лимит внимания на все команды

Команды коммуникаций, продукта и поддержки могут считать свои сообщения полезными, но человек получает их в одну ленту. Частотная политика решает, сколько сообщений допустимо, какое важнее и когда следующий push нужно отменить.

## Что понадобится

- **Общий список:** Все сервисные, продуктовые и контентные сообщения, которые могут прийти одному пользователю за семь дней.
- **История:** Журнал отправок на уровне тестовых профилей или выборка реальных пользователей с датой, сценарием и результатом.
- **Владелец:** Один человек, который согласует конфликты между командами и регулярно проверяет отписки и жалобы.

## Термины простыми словами

- **Push-уведомление — Короткое сообщение от приложения вне его интерфейса:** Определение: Появляется на устройстве и может вернуть пользователя к конкретному полезному действию. Отправляется только при наличии разрешения. Пример: Сообщение о новом материале в сохранённой теме открывает этот материал по deep link.
- **Сегмент — Группа пользователей с общим поведением:** Определение: Сегмент объединяет людей по платформе, стране, интересу или действию, чтобы не отправлять всем одно сообщение. Пример: Пользователи Android, которые начали, но не завершили регистрацию за последние 24 часа.
- **Событие аналитики — Запись о конкретном действии пользователя:** Определение: Приложение отправляет событие в аналитику, когда пользователь открыл экран, нажал кнопку или завершил действие. Пример: registration_started и registration_completed позволяют увидеть, сколько людей бросили регистрацию.

## Когда применять

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

## Где увидеть реальную нагрузку

Не складывайте только запланированные кампании. Учитывайте автоматические триггеры и сервисные статусы, которые запускаются событиями.

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

## Настройте безопасную частоту

1. **Соберите все сценарии.** Запишите ручные кампании, автоматические триггеры и сервисные статусы. Для каждого укажите максимальную частоту на одного человека.
   - **Где сделать:** В общем календаре коммуникаций.
   - **Пример:** Верификация — до 2 напоминаний; новый материал — 2 в неделю; общий обзор — 1 в неделю.
2. **Разделите по пользовательской важности.** Сервисный статус и безопасность выше контентного повода. Внутренняя бизнес-цель не должна автоматически повышать приоритет.
   - **Где сделать:** В колонке приоритета политики.
   - **Пример:** Статус операции отправляется, а общий обзор в тот же день отменяется.
3. **Задайте общий лимит.** Ограничьте суммарное число необязательных сообщений и минимальную паузу между ними. Лимит действует поверх правил отдельных команд.
   - **Где сделать:** В настройках коммуникационной платформы.
   - **Пример:** Не более одного необязательного push за 24 часа и трёх за семь дней.
4. **Добавьте взаимные исключения.** После полезного действия, недавнего визита или похожего сообщения человек должен выйти из конкурирующих сценариев.
   - **Где сделать:** В условиях сегментов перед отправкой.
   - **Пример:** Завершил урок → исключить напоминание; получил личный разбор → исключить общий обзор на 24 часа.
5. **Проверяйте самые нагруженные профили.** Раз в неделю смотрите не только среднее, но и пользователей с максимальным числом сообщений. Именно там правила чаще всего конфликтуют.
   - **Где сделать:** В отчёте по сообщениям на пользователя.
   - **Пример:** Среднее — 1,8 push, но 4% пользователей получили 7+; найдено пересечение двух триггеров.

## Примеры из практики

- **Сервисный статус отменяет общий контент:** Пользователь получил важный статус операции. Общий обзор в тот же день отменяется, а следующий необязательный push возможен только через 24 часа.
- **Среднее скрывало перегруженную группу:** Средняя нагрузка была 1,8 push в неделю, но 4% пользователей получали 7+. После взаимных исключений общий лимит соблюдается и повторные жалобы снижаются.

## Готовый артефакт: Политика частоты на одну страницу

Правила должны применяться перед каждой отправкой, а не оставаться рекомендацией в документе.

| Тип | Приоритет | Лимит | Пауза и исключения |
| --- | --- | --- | --- |
| Безопасность и статус | 1 · обязательный | По событию | Не блокируется промо-лимитом |
| Незавершённое действие | 2 · полезный | 1 на сценарий | Отмена после завершения |
| Личный интерес | 3 · полезный | До 2 в неделю | Пауза 24 часа после другого push |
| Общий контент | 4 · необязательный | 1 в неделю | Не отправлять недавно активным |
| Все необязательные | Общий лимит | Не более 3 в неделю | Не более 1 за 24 часа |

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

## Ограничения и безопасность: Не компенсируйте слабый сценарий частотой

Если сообщение не даёт повода вернуться, повторная отправка не сделает его полезнее. Сначала исправьте причину, текст или маршрут.

## Чек-лист частоты

Политика готова только тогда, когда правила можно проверить на конкретном профиле пользователя.

- [ ] В одном списке есть ручные, триггерные и сервисные сообщения всех команд.
- [ ] У сообщений назначен приоритет по пользе для пользователя.
- [ ] Есть общий лимит и минимальная пауза между необязательными push.
- [ ] Завершившие действие, недавно активные и получившие похожее сообщение исключаются.
- [ ] Назначен владелец еженедельной проверки нагрузки, отписок и жалоб.

## Как понять, что частота стала безопаснее

- **Нагрузка:** Снижается доля пользователей, которые получают больше общего лимита за день и неделю.
- **Доверие:** Отключения уведомлений и жалобы не растут при сохранении полезных сценариев.
- **Польза:** Целевые действия на одно сообщение сохраняются или растут после удаления конкурирующих отправок.

## Главное правило

При конфликте двух сценариев отправляйте тот, у которого выше ценность для пользователя, а не выше внутренняя бизнес-цель.

---

- [HTML-версия](https://playbook.affpartners.io/ru/practices/push-frequency/index.html)
- [Все практики](https://playbook.affpartners.io/ru/)