Push-уведомления для сайта и приложения: когда они полезны клиенту

Что push-уведомление добавляет сайту?

Стоит ли просить посетителя разрешить уведомления, если он только открыл каталог? Push-уведомления сайта — сообщения, которые сайт может отправлять подписавшемуся пользователю через поддерживаемый браузер и системную службу уведомлений. Их задача — сообщить о событии, к которому человеку полезно вернуться.

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

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

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

Браузерные и мобильные push: охват совпадает?

Мобильные push-уведомления не обязательно принадлежат отдельному приложению из магазина приложений. Сайт тоже может использовать Web Push на поддерживаемом устройстве. Но возможности компьютера и телефона различаются.

В материале WebKit о Web Push на iOS и iPadOS поддержка с версии 16.4 описана для веб-приложений, добавленных на домашний экран. Запрос разрешения вызывается прямым действием пользователя, например нажатием кнопки подписки. Поэтому фраза «подключим push на все телефоны» слишком расплывчата для задания: на приёмке нужно показать реальный путь покупателя, включая добавление веб-приложения, доступность запроса и появление сообщения на устройстве, которое использует заметная часть вашей аудитории. Добавление на экран требует отдельного действия.

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

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

Отдельное мобильное приложение стоит создавать ради задач всего продукта: польза дополнительной кнопки подписки должна оправдывать затраты на разработку. Для магазина с редкими повторными покупками дополнительное действие установки может оказаться существеннее ожидаемой пользы одного уведомления.

Что предложить посетителю вместо «разрешите уведомления»?

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

MDN рекомендует запрашивать разрешение на системные уведомления в ответ на действие пользователя. Для выбранного товара это можно сделать после нажатия кнопки «Сообщить о поступлении», предварительно объяснив, что сообщение придёт в уведомления устройства. Так покупатель связывает системное окно с собственным запросом, а команда может отдельно увидеть отказ от конкретного предложения и техническую невозможность подписки, не смешивая эти ситуации в общем числе закрытых окон.

Пример связанной пары сообщений

Предложение на странице: «Сейчас размера нет. Сообщить в уведомлениях устройства, когда он поступит?» Уведомление после появления: «Нужный размер снова доступен. Откройте карточку и посмотрите условия заказа». Это образец формулировки. Слова о наличии отправляют после подтверждения остатка, а переход ведёт в нужную карточку.

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

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

Что входит в подключение и за что платить?

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

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

Для уведомлений используется защищённое соединение HTTPS, что отдельно указано в документации Notifications API. Если сайт ещё работает с ошибками сертификата, сначала приводят в порядок эту основу. Подключать рассылку к нестабильной странице покупки неудобно: команда будет одновременно разбирать сообщения и доступность самого магазина.

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

На приёмке полезны сценарии отказа и истёкшей подписки. Исполнитель показывает, как система прекращает бесполезные попытки отправки и не принимает отсутствие доставки за отсутствие спроса на товар.

Когда push удобнее письма или СМС?

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

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

Я бы не подключал несколько каналов одновременно к первому тесту поступления. Сначала стоит увидеть, получает ли подписчик обещанное сообщение и продолжает ли покупку, иначе команда не сможет объяснить, какое обращение помогло вернуться, а какое просто повторило уже прочитанную информацию.

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

Как понять, что уведомления помогают?

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

В отчёте отдельно сохраняют предложение подписки, выданное разрешение, созданную подписку, попытку отправки и доступные события доставки или взаимодействия. Состав доступных сведений зависит от решения. Затем анализируют переход на товар и дальнейшее действие, потому что отсутствие покупки может объясняться исчезнувшим остатком, неудобным оформлением или тем, что человек уже приобрёл товар в другом месте, и одна общая доля кликов не различит эти причины. Знаменатель показателя тоже нужно назвать.

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

Перед расширением ответьте по своему сценарию: человек понимает, на что подписывается? Нужный товар действительно доступен после перехода? Поддерживаемые устройства испытаны? Отказ и завершение подписки обработаны? Расход на подключение и сопровождение сопоставлен с полезными действиями? Эти ответы дают руководителю основу для продолжения или остановки теста.

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