Push-уведомление — это короткое сообщение, которое приходит на устройство пользователя вне приложения или сайта: всплывает на экране телефона или в углу браузера. Оно не требует, чтобы человек в этот момент был на сайте или держал приложение открытым. Ниже разберём, как устроена подписка и доставка push, чем web-push отличается от мобильных уведомлений, для каких задач их используют в маркетинге и удержании и где проходит граница их возможностей.
Что такое push-уведомления простыми словами
Push-уведомление (от английского push — «толкать») — это сообщение, которое сервис отправляет пользователю сам, без запроса с его стороны. В этом главное отличие push от обычной загрузки данных: не человек идёт за информацией, а информация приходит к нему.
Технически push состоит из короткого текста, чаще всего заголовка и одной-двух строк, иконки и ссылки, по которой человек попадает при нажатии. На телефоне уведомление появляется на экране блокировки или в шторке, в браузере — небольшим окном в углу экрана.
Ключевое условие push — предварительное разрешение. Пользователь должен сам согласиться получать уведомления: в браузере он нажимает «Разрешить» во всплывающем запросе, в мобильном приложении — соглашается на системный запрос при первом запуске или позже. Без этого согласия отправить push нельзя технически, а не только по правилам.
Push работает через посредника — сервис доставки уведомлений на стороне платформы. Сайт или приложение не отправляет сообщение напрямую на устройство: оно передаёт его в служебную систему браузера или операционной системы, а та уже доводит уведомление до конкретного устройства. Поэтому push доходят, даже когда сайт закрыт, а приложение свёрнуто.
Виды push-уведомлений
Push делятся на несколько типов, и разница между ними определяет и механику подписки, и сценарии применения. Смешивать их не стоит: web-push и мобильные уведомления живут по разным правилам.
Web-push в браузере
Web-push приходят от сайта и показываются браузером. Чтобы их получать, не нужно ставить приложение — достаточно разрешить уведомления при заходе на сайт. Работают они на десктопе и на Android; на iPhone web-push поддерживаются в Safari начиная с iOS 16.4, но только если сайт добавлен на домашний экран как веб-приложение.
За доставку web-push отвечает служебный скрипт сайта — service worker. Он работает в фоне в браузере и принимает уведомления, даже когда вкладка сайта закрыта. Именно поэтому web-push не требуют, чтобы человек оставался на сайте: сообщение примет service worker, а не открытая страница.
Обязательное условие web-push — защищённое соединение по протоколу HTTPS. На сайтах без него подписка на уведомления не работает. Это ограничение платформ, а не настройка сервиса рассылок.
У web-push есть и оборотная сторона охвата. Подписка привязана к конкретному браузеру на конкретном устройстве: человек, разрешивший уведомления в браузере на ноутбуке, не получит их на телефоне, пока не подпишется и там. Поддержка тоже неоднородна — правила показа и оформление запроса различаются от браузера к браузеру, а на iPhone web-push работают только через веб-приложение на домашнем экране. Планируя канал, эту разницу приходится учитывать: часть аудитории технически не сможет подписаться.
Мобильные push в приложениях
Мобильные push приходят от установленного приложения и показываются операционной системой телефона. Их получают только те, кто скачал приложение и разрешил уведомления. Возможностей у них больше: помимо текста и иконки, такое уведомление может содержать картинку, кнопки действий, значок на иконке приложения.
Доставку мобильных push обеспечивают платформенные сервисы: для Android это система push от Google, для iPhone — служба уведомлений Apple. Приложение регистрирует устройство в этой службе и получает уникальный идентификатор — токен, по которому потом адресуются сообщения.
У мобильных уведомлений богаче форматы. Помимо текста, push может нести картинку, кнопки быстрых действий («Оплатить», «Отложить»), значок-счётчик на иконке приложения. Нажатие ведёт не на общий экран, а сразу в нужное место приложения — этот приём называют диплинком (deep link). Например, уведомление о новом сообщении открывает конкретный чат, а не главный экран. Всё это делает мобильные push более гибким инструментом, чем короткое web-push окно в браузере.
Транзакционные и маркетинговые push
Отдельно уведомления делят не по устройству, а по назначению. Транзакционные push сообщают о событии: заказ собран, курьер выехал, платёж прошёл, пришло новое сообщение в чате. Маркетинговые push продвигают что-то: скидку, новинку, возвращение в брошенную корзину.
Разница между ними не косметическая. Транзакционные уведомления человек ждёт и почти не отключает — они полезны в моменте. Маркетинговые быстрее раздражают и чаще становятся причиной отписки, поэтому их частоту и уместность приходится контролировать куда строже.
Как работает push по шагам
Механику push удобно разобрать по шагам — от согласия пользователя до появления сообщения на экране. Весь путь проходит автоматически, но каждое звено обязательно.
Первый шаг — запрос разрешения. Сайт или приложение показывает системный запрос на отправку уведомлений. Пока человек не нажал «Разрешить», подписки нет.
Второй шаг — регистрация устройства. После согласия браузер или операционная система выдаёт уникальный идентификатор подписки — токен или endpoint. Это адрес, по которому конкретное устройство будет получать уведомления. Сайт или приложение сохраняет его у себя.
Третий шаг — отправка. Когда нужно доставить уведомление, сервис передаёт его не напрямую на телефон, а в push-службу платформы вместе с сохранённым идентификатором устройства.
Четвёртый шаг — доставка. Push-служба платформы находит нужное устройство и передаёт ему сообщение. Если устройство сейчас офлайн, уведомление какое-то время ждёт и приходит при следующем подключении к сети.
Пятый шаг — показ и клик. Уведомление всплывает на экране. Если человек нажимает на него, открывается заданная ссылка — страница сайта или нужный экран приложения. Если игнорирует, через время оно уходит в общий список уведомлений.
Важная деталь: идентификатор подписки не вечен. Пользователь может отозвать разрешение в настройках, переустановить приложение, сменить устройство. Тогда старый токен перестаёт работать, и push по нему не доходит. Поэтому базу подписчиков на push приходится поддерживать так же, как базу email: убирать «мёртвые» адреса.
Как получить согласие на push и не отпугнуть
Подписка на push держится на одном системном запросе, и от того, как вы его показываете, зависит вся дальнейшая работа канала. Отказ здесь почти необратим: если человек нажал «Блокировать», браузер запоминает это решение, и повторно спросить разрешение вы уже не сможете. Поэтому первый показ запроса стоит готовить особенно аккуратно.
Главная ошибка — показывать системный запрос сразу при заходе на сайт. Человек ещё не понял, чем полезен ресурс, а его уже просят на что-то согласиться. В такой момент большинство нажимает «Блокировать», и канал закрывается навсегда. Разумнее дождаться момента, когда польза очевидна: человек дочитал материал, положил товар в корзину, оформил заказ.
Помогает приём с предварительным запросом — так называемый двухшаговый opt-in. Сначала сайт показывает собственное окно, которое можно оформить и объяснить: «Хотите получать уведомления о статусе заказа?» И только если человек согласился в этом окне, запускается настоящий системный запрос браузера. Плюс подхода в том, что отказ в собственном окне ничего не блокирует — системный запрос ещё не был показан, и позже его можно вызвать снова.
Работает и объяснение ценности. Абстрактное «Разрешить уведомления» проигрывает конкретному «Сообщим, когда заказ приедет» или «Пришлём, когда товар снова появится». Человек соглашается не на уведомления вообще, а на понятную пользу.
Отдельно стоит подумать о том, что вы обещаете и что потом отправляете. Если при подписке речь шла о статусах заказов, а на устройство сыплются акции, человек чувствует подмену и отключает push. Согласие на push — это негласный договор об уместных сообщениях, и нарушать его дорого: вернуть отключившегося подписчика почти невозможно.
Чем push отличается от email и SMS
Push легко спутать с другими каналами прямого контакта — email и SMS. Все три доставляют короткое сообщение конкретному человеку, но работают по-разному, и это определяет их роли.
Главное отличие push от email — момент и форма. Push видно сразу, он всплывает поверх экрана и требует секундной реакции. Email лежит во «Входящих» и ждёт, пока человек откроет почту. Push короче и заметнее в моменте, email вместительнее и живёт дольше.
От SMS push отличается стоимостью и охватом. SMS доходит на любой телефон и платный за каждое сообщение. Push бесплатен в отправке, но доходит только до тех, кто подписался и не отключил уведомления. SMS шире по охвату, push — дешевле и без ограничения по длине текста.
Сравнить три канала удобно по нескольким параметрам.
| Параметр | Push | SMS | |
|---|---|---|---|
| Условие получения | подписка и разрешение | наличие адреса и согласие | наличие номера и согласие |
| Стоимость отправки | бесплатно | почти бесплатно | платно за сообщение |
| Объём сообщения | короткое | большое | короткое |
| Заметность в моменте | высокая | низкая | высокая |
| Срок жизни сообщения | короткий | долгий | средний |
| Отписка | одно действие в настройках | ссылка в письме | по запросу оператора |
Таблица показывает, что каналы не заменяют, а дополняют друг друга. Push хорош для мгновенной короткой реакции, email — для развёрнутого содержания, SMS — для гарантированного охвата в важных случаях. Многие компании используют их вместе, распределяя сообщения по каналам в зависимости от срочности и объёма.
Для бизнеса это означает, что push не стоит рассматривать как замену email-рассылке. Это отдельный инструмент с другими сильными сторонами: он выигрывает в скорости и заметности, но проигрывает в объёме и в том, как легко от него отписаться.
Для каких задач используют push
Push решают несколько типовых задач, и почти все они относятся к удержанию — возвращению человека, который уже знаком с продуктом. Привлекать новую аудиторию push не умеют: чтобы отправить уведомление, нужна подписка, а её даёт только тот, кто уже пришёл.
Первая задача — возврат в продукт. Push напоминает о недочитанной статье, незавершённом заказе, новом эпизоде или сообщении. Человек отвлёкся и ушёл, уведомление возвращает его обратно.
Вторая задача — сообщить о событии в реальном времени. Изменился статус заказа, появился ответ в переписке, началась трансляция — push доносит это быстрее любого другого канала, потому что не ждёт, пока человек откроет почту.
Третья задача — точечные акции и предложения. Скидка на товар, который человек смотрел, ограниченное по времени предложение, напоминание о брошенной корзине. Здесь push работает как быстрый триггер к покупке.
Четвёртая задача — реактивация. Тем, кто давно не заходил, push напоминает о себе. Но здесь легко перегнуть: человек, который потерял интерес, от навязчивых уведомлений просто отключит их совсем.
Push сильнее всего там, где важна скорость и где сообщение привязано к действию самого пользователя. Уведомление о статусе заказа полезно и почти не раздражает. Массовая рекламная рассылка «просто так» быстро приводит к отпискам, потому что не отвечает ни на какой запрос человека.
Отдельно стоит развести триггерные и запланированные push. Триггерное уведомление отправляется в ответ на событие: человек бросил корзину, товар подешевел, изменился статус заказа. Оно почти всегда уместно, потому что связано с конкретным действием. Запланированная рассылка уходит по расписанию всем сразу — например, анонс акции. Она полезнее, когда сегментирована: уведомление о скидке на категорию логично отправить тем, кто эту категорию смотрел, а не всей базе. Чем ближе push к реальному интересу конкретного человека, тем меньше он раздражает и тем выше отклик.
Пример работы push в связке с другими каналами
Чтобы механика стала нагляднее, разберём условный сценарий интернет-магазина. Это пример, а не кейс конкретной компании.
Человек добавил товар в корзину, но не оформил заказ и закрыл сайт. Через час ему приходит web-push: «Товар ждёт в корзине — оформите заказ». Уведомление короткое и приходит в момент, пока интерес ещё не остыл. Если человек нажимает — открывается страница оформления.
Если push не сработал и покупка не состоялась, через несколько часов подключается email с тем же напоминанием, но с картинкой товара и условиями доставки — тем, что не помещается в короткое уведомление. Push здесь взял на себя быструю первую попытку, email — более подробную вторую.
После покупки роль push меняется на транзакционную. «Заказ оформлен», «Заказ передан в доставку», «Курьер будет через час» — эти уведомления человек ждёт и почти никогда не отключает. Они не продают, а информируют, и именно поэтому не вызывают раздражения.
Сценарий показывает главное: push не работает в одиночку и не заменяет остальные каналы. Он берёт на себя быстрые, короткие, привязанные к событию сообщения, а развёрнутое содержание остаётся за email.
Какие показатели отслеживать
Эффективность push оценивают по нескольким метрикам, и одной цифры для этого мало. Каждая показывает свой участок пути от подписки до действия.
Показатель подписки (opt-in rate) — доля посетителей, которые согласились получать уведомления. Он показывает, насколько уместно и вовремя вы просите разрешение. Если запрос выскакивает сразу при заходе на сайт, до того как человек что-то понял, соглашаются немногие.
Доставляемость — доля отправленных уведомлений, которые дошли до устройств. Push не доходит, если подписка отозвана, приложение удалено или токен устарел. Растущая доля недоставленных — сигнал, что базу пора чистить.
Показатель кликов (CTR) — доля уведомлений, по которым человек нажал. Он говорит о том, насколько сообщение попадает в интерес: релевантный текст и уместный момент поднимают клики, массовая рассылка не в тему их снижает.
Показатель отписок — доля людей, отключивших уведомления после сообщения. Это самая честная метрика уместности. Если после рассылки заметно растут отписки, канал используют слишком навязчиво или не по делу.
Смотреть эти показатели нужно вместе. Высокий CTR при растущих отписках означает, что уведомления кликают, но постепенно от них устают. Один показатель без остальных легко вводит в заблуждение.
Отдельно стоит следить за временем отправки. Push приходит мгновенно, поэтому уведомление ночью раздражает сильнее, чем письмо, которое человек увидит утром. Многие сервисы позволяют учитывать часовой пояс подписчика и отправлять сообщения в приемлемое время. Здесь же помогает ограничение частоты — так называемый frequency capping: система не даёт отправить одному человеку больше заданного числа уведомлений за период, даже если под условия рассылки он попал несколько раз. Это защищает от ситуации, когда пользователь за день получает пять маркетинговых push и отключает их все.
Типичные ошибки при работе с push
Ошибки в push повторяются и быстро обесценивают канал: человек отключает уведомления один раз и навсегда. Разберём основные.
Первая ошибка — просить разрешение сразу при входе. Всплывающий запрос до того, как человек понял ценность сайта, чаще всего получает отказ. Разумнее просить разрешение после полезного действия, когда интерес уже есть, и объяснять, зачем нужны уведомления.
Вторая ошибка — слишком частые сообщения. Несколько маркетинговых push в день воспринимаются как навязчивость. В отличие от письма, которое молча лежит в почте, push вторгается на экран, поэтому порог терпения к нему ниже, а частоту приходится держать сдержанной.
Третья ошибка — рассылать всем одно и то же. Push без учёта интересов человека превращается в шум. Уведомление о брошенной корзине уместно тому, кто её оставил, но бессмысленно для остальных. Сегментация здесь важнее, чем в email, из-за той же повышенной заметности.
Четвёртая ошибка — неинформативный текст. Уведомление видно доли секунды, и если из него неясно, что внутри и зачем нажимать, человек его смахнёт. Заголовок должен сразу говорить о сути, а не интриговать.
Пятая ошибка — не чистить базу подписок. Устаревшие токены не приносят результата, но искажают статистику доставляемости. Отключившихся и недоступных подписчиков нужно убирать, как и неактивные адреса в email.
Ограничения push-уведомлений
У push есть границы, за которыми канал не работает, и понимать их важно, чтобы не ждать от него лишнего.
Первое ограничение — нужна подписка. Push нельзя отправить тому, кто не разрешил уведомления. Это делает канал инструментом удержания, а не привлечения: он работает только с теми, кто уже пришёл и согласился.
Второе ограничение — лёгкая отписка. Отключить уведомления можно одним движением в настройках, и вернуть человека потом почти невозможно — повторно запросить разрешение система обычно не даёт. Одна навязчивая рассылка способна закрыть канал для конкретного пользователя навсегда.
Третье ограничение — короткий формат. В push помещается несколько слов. Развёрнутое предложение, подробности, длинный текст туда не вложить — для этого нужен другой канал.
Четвёртое ограничение — зависимость от платформ. Доставку контролируют браузеры и операционные системы, и их правила меняются. Поддержка web-push на iPhone появилась только с iOS 16.4 и остаётся более ограниченной, чем на Android. Возможности канала заданы платформами, а не только вашим сервисом рассылок.
Поэтому push правильно считать быстрым дополнительным каналом, а не основным. Он силён в скорости и заметности, но узок по объёму и держится на согласии, которое человек может отозвать в любой момент.
Вывод
Push-уведомления — это короткие сообщения, которые сервис отправляет на устройство подписчика вне сайта или приложения, с его предварительного разрешения. Web-push приходят от сайта через service worker и требуют HTTPS, мобильные push — от установленного приложения через службы Google и Apple. Канал силён в скорости, заметности и бесплатной отправке, поэтому лучше всего работает на удержание: возврат в продукт, статусы заказов, точечные напоминания. Его границы — обязательная подписка, короткий формат и лёгкая отписка, из-за которой частоту и уместность уведомлений приходится держать под строгим контролем.