Push-уведомления, которые не приводят к отписке

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

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

Момент запроса разрешения

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

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

import * as Notifications from "expo-notifications"

export async function askForPush(reason: "order_placed" | "price_alert") {
  const current = await Notifications.getPermissionsAsync()

  // Уже решили — второй раз системный диалог не показываем:
  // на iOS он просто не появится, а счётчик попытки сгорит
  if (current.status !== "undetermined") return current.status

  // Свой экран с объяснением показываем до системного запроса
  const agreed = await showPrePermissionSheet(reason)
  if (!agreed) return "deferred"

  const { status } = await Notifications.requestPermissionsAsync()
  return status
}

Чем различаются платформы

Каналы на Android — недооценённая возможность. Если развести уведомления по каналам «статус заказа», «скидки», «новости», пользователь отключит только раздражающий канал, а не приложение целиком. На iOS похожего механизма нет, поэтому типы уведомлений придётся заводить в своих настройках и уважать их на сервере.

Что отправлять

• Событие, которое пользователь ждёт: заказ собран, задача назначена, документ подписан
• Изменение по объекту, за которым он сам попросил следить: цена, статус, ответ в переписке
• Напоминание о незавершённом действии — не чаще одного раза на действие
• Регулярную сводку, если пользователь сам выбрал частоту

Всё остальное — рекламные рассылки «мы вас потеряли», акции без привязки к интересу, новости компании — работает против канала. Кратковременный подъём открытий такие уведомления дают, но за ними идёт волна отписок, после которой полезные сообщения о заказах доходят до меньшей аудитории.

Как считать эффект

Одного показателя открытий недостаточно: он растёт от агрессивных формулировок и ничего не говорит о вреде. Мы смотрим на четыре цифры в связке.

const LIMITS = {
  order: { perDay: 10 },     // транзакционные — почти без ограничений
  reminder: { perDay: 1 },
  marketing: { perWeek: 2 },
}

export async function canSend(userId: string, kind: keyof typeof LIMITS) {
  const prefs = await getPrefs(userId)
  if (!prefs.enabled[kind]) return false

  const limit = LIMITS[kind]
  const since = limit.perDay ? hoursAgo(24) : daysAgo(7)
  const sent = await countSent({ userId, kind, since })

  return sent < (limit.perDay ?? limit.perWeek)
}

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

Что мы делаем на проектах

1. 01Разделяем уведомления на транзакционные и маркетинговые с раздельными настройками
2. 02Просим разрешение после первого значимого действия, со своим экраном-объяснением
3. 03Заводим лимиты частоты на сервере и логируем каждую отправку
4. 04Складываем в аналитику отправку, доставку, открытие и отписку одним событием
5. 05Раз в месяц смотрим отписки по типам и отключаем то, что не окупается