Push-уведомления: что это, как работают и когда раздражают

Что такое push-уведомления простыми словами

Пуш — короткое сообщение, которое появляется на экране устройства по инициативе сервера, а не человека. Человек ничего не открывал и не обновлял; сообщение пришло само — отсюда название «push», «толкать».

В документации web.dev пуш и уведомление описаны как две разные технологии, которые обычно работают вместе: пуш доставляет данные с сервера на устройство, уведомление показывает их человеку. Различие практическое. Доставка может пройти успешно, а уведомление не появится — например, если система устройства его приглушила.

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

Как работают push-уведомления: веб и мобильные

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

1. Человек даёт разрешение на уведомления.
2. Устройство регистрируется в службе платформы и получает уникальный адрес — токен или подписку.
3. Ваш сервер сохраняет этот адрес и привязывает к клиенту.
4. Когда нужно, сервер отправляет сообщение в службу, указав адрес.
5. Служба доставляет сообщение на устройство, система показывает уведомление.

Для сайта нужен активный сервис-воркер — по документации MDN, без него подписка на пуш невозможна. Для приложений сообщения идут через службы мобильных платформ; кроссплатформенные сервисы вроде Firebase Cloud Messaging позволяют отправлять сообщения на мобильные устройства и в браузеры из одной точки.

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

Разрешение — главный ресурс канала

Всё, что можно сделать с пушами, ограничено числом людей, давших разрешение, и их готовностью его не отзывать.

На мобильных платформах разрешение спрашивается явно. В документации Android сказано, что начиная с Android 13 (API 33) приложение обязано запросить разрешение POST_NOTIFICATIONS во время работы, а не получает его по умолчанию. В браузере ситуация та же: web.dev рекомендует вызывать запрос разрешения только в ответ на действие пользователя — например, нажатие кнопки в собственном предварительном окне.

Отсюда рабочий порядок:

1. Сначала показать собственную подсказку с понятной пользой: «Сообщим, когда заказ передадут курьеру».
2. Системный запрос вызывать только после согласия в подсказке.
3. Не спрашивать при первом входе: человек ещё не знает, зачем ему ваши уведомления.
4. Дать настройку тем: отключить рекламу, оставив статусы, лучше, чем потерять всё.

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

Когда пуш возвращает клиента, а когда раздражает

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

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

Метрики: доставляемость, CTR, отписки

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

Условный пример. Подписчиков на начало месяца — 20 000. Отправлено 20 000 пушей, доставлено 17 000: доставляемость 85 %, остальные адреса устарели — люди удалили приложение или очистили браузер. Переходов — 510, CTR 3 %. За месяц отозвали разрешение 400 человек — 2 % базы.

Читать эти числа нужно вместе. Падающая доставляемость — сигнал чистить устаревшие токены, иначе сообщения уходят в пустоту, а отчёт врёт. Растущий CTR при растущих отписках означает, что вы перешли на агрессивные поводы и проедаете базу. Как и в почте, часть переходов произошла бы и без пуша, поэтому выручку, приписанную каналу, проверяют сравнением с группой, которой сообщение не отправляли, — механика в материале об A/B-тестах.

Что писать в пуше и как часто отправлять

Уведомление читают за секунду, на экране блокировки, между другими уведомлениями. Отсюда требования к тексту, которые проверяются до отправки:

1. Предмет в первых словах. Заголовок обрезается системой, поэтому главное — в начале: «Заказ передан курьеру», а не «Отличные новости о вашем заказе». Длину черновика удобно сверять счётчиком символов с ограничением платформы.
2. Одно событие — одно уведомление. Три новости в одном пуше не прочитают ни одну.
3. Конкретика вместо оценки. Время, номер, сумма, название — то, что отличает это сообщение от рекламы.
4. Переход ведёт к сути. Нажатие открывает тот экран или ту страницу, о которой сообщение, а не главную; иначе человек ищет сам и в следующий раз не нажимает.
5. Отправка в подходящее время. Сообщение, пришедшее ночью по часовому поясу получателя, раздражает сильнее любого текста.

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

Отдельный вопрос — содержание, которого в пуше быть не должно: персональные данные, суммы задолженности, коды доступа, если экран блокировки показывает текст целиком. Уведомление видит не только адресат, но и тот, кто сидит рядом.

Пуши, письма и мессенджеры: что куда

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

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

Спорное место

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

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

Источники

1. Push API — MDN Web Docs
2. Push notifications overview — web.dev (Google)
3. Notification runtime permission — Android Developers
4. Firebase Cloud Messaging — Firebase (Google)