Подписки на спортивные события: темы и системные разрешения

Системное разрешение — дорогой момент

Если попросить push-доступ при первом открытии без объяснения ценности, пользователь принимает решение вслепую. Лучше сначала предложить конкретную подписку: начало матча, изменение счёта, выбранная команда — и только затем запросить системное разрешение, когда намерение уже понятно.

Настройка пользователя и системное разрешение — два разных состояния

Backend хранит темы и quiet hours, но приложение отдельно знает системный permission. В UI эти состояния не смешиваются. Можно иметь сохранённую подписку при отключённом OS permission и показать способ включить доставку, не теряя выбор пользователя.

Слишком мелкие настройки превращаются в панель самолёта

Гранулярность нужна там, где типы уведомлений различаются по ценности и частоте. Не стоит выводить десятки технических toggle. Хорошая модель начинается с нескольких продуктовых intent и при необходимости раскрывает детали.

Тема — стабильный продуктовый идентификатор

Preference хранит domain topic, например event_start или score_change, а не название текущего push-template. Шаблоны можно менять без миграции пользовательских настроек. Dispatcher применяет quiet hours и дедупликацию после выбора topic.

Интерфейс обещает уведомление, которого система не может доставить

После изменения OS permission приложение синхронизирует device capability. Если token недействителен или permission off, настройки не должны показывать ложный «всё включено». Формулировка разделяет «вы подписаны» и «уведомления разрешены на этом устройстве».

Как не превратить настройки в длинную форму

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

Состояние preference и permission нужно хранить отдельно. Пользователь может хотеть уведомления, но запретить их на уровне ОС; интерфейс в этом случае должен объяснить, почему доставка невозможна, и сохранить его продуктовые предпочтения на случай повторного разрешения.

• Не запрашивать OS permission без предварительного контекста.
• Поддерживать quiet hours независимо от системного режима «Не беспокоить».
• Показывать состояние доставки, если permission был отозван вне приложения.

Как оценивать без натягивания метрик

Смотрят принятие системного запроса разрешения после конкретного intent, unsubscribe по topic, suppression reason и долю недоставки из-за device state. Эти данные помогают улучшать момент и содержание подписки; универсальная «хорошая цифра» здесь не нужна.

Системное разрешение появляется после понятного выбора

Если приложение просит push permission на первом экране, пользователь ещё не знает, зачем оно нужно. Гораздо сильнее работает сценарий, где человек сначала выбирает «напомнить о начале матча» или «сообщать об изменении счёта», а система объясняет, что для этого понадобится разрешение ОС.

NotificationPreferences хранит продуктовый выбор отдельно от OS permission. Поэтому отзыв разрешения в настройках телефона не стирает подписки: UI может показать, что темы сохранены, но доставка push сейчас отключена, и предложить понятный путь восстановления.

Quiet hours тоже лучше хранить как пользовательское правило, а не как локальный таймер устройства. Иначе смена телефона, timezone или серверная отправка легко нарушат обещанное поведение.