Web push уведомления что это

Web push руководство: как добавить вебпуши в свою digital-стратегию и поднять отдачу от канала

Показываем, как работают вебпуши, какие задачи решают, в чем их отличие от других инструментов. Разбираем способы улучшить результаты web push.

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

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

Веб-пуши получают только те, кто на них подписался. Для подписки пользователь должен зайти на ваш сайт, увидеть диалоговое окно подписки и разрешить отправлять уведомления. Но в любой момент он может запретить вам это делать — например, если вы будете слишком часто отправлять уведомления.

✅ Веб-пуши по-разному отображаются на разных операционных системах и в разных браузерах — это нужно учитывать при их создании. Например, большой баннер, как в примере выше, будет отображаться в Chrome на ОС Windows, но не будет на MacOS. Поэтому в сервисах, с помощью которых можно отправлять веб-пуш уведомления, обычно есть режим предпросмотра.

✅ Веб-пуши отображаются поверх всех окон. Даже если пользователь свернул или закрыл браузер или открыл другое приложение поверх него — он увидит ваше сообщение.

✅ Пользователь не может пожаловаться на спам, но может запретить отправку уведомлений. Если он так сделает, вы уже не сможете «вернуть» пользователя, пока он не разблокирует вас вручную.

✅ Базу контактов нельзя импортировать, как это можно сделать, например, с email или СМС. Ваши подписчики — только те, кто разрешил присылать ему вебпуши, пока был на вашем сайте.

✅ Уведомления можно доставлять как на компьютеры, так и на мобильные устройства.

Мобильные пуши отправляются приложением, которое установлено на смартфоне или планшете. Мобильные пуши могут вести только внутрь приложения, веб-пуши — на любой адрес.

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

Вебпуши обычно используют как дополнительный канал к email — из-за скорости их доставки. Кроме этого у него есть и другие плюсы:

Высокий CTR. Статистика показывает, что кликабельность веб-пушей в 4 раза выше, чем у электронных писем: на 8,5% выше 2,4% CTR email. Здесь также играет роль персонализация. Если человек чувствует, что вы обращаетесь именно к нему, он с большей вероятностью нажмет на всплывашку.

Высокая скорость подписки. В среднем на веб-пуши подписываются в три раза быстрее, чем на электронные письма. Это может быть связано с тем, насколько прост процесс: одним кликом посетители могут согласиться на получение уведомлений, не предоставляя email или другую личную информацию. Чем меньше шагов, которые должен пройти человек для подписки на любой канал, тем меньше у него сомнений.

Текстово-графический формат. В отличие от СМС, вы можете добавить к сообщению баннер, изображение магазина и кнопки — что повышает его видимость.

Web PUSH Notifications быстро и просто

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

Информации по этой теме в интернете полно, но она фрагментирована, разбросана по разным ресурсам и перемешена с уведомлениями для мобильных устройств с примерами на Java, C++ и Python. Нас же, как веб-разработчиков, интересует JavaScript. В этой статье я постараюсь саккумулировать всю необходимую и полезную информацию.

Я думаю, вы уже знаете что такое push-уведомления, но я всё же напишу коротко о главном.

Пользователь, заходя на сайт, вытягивает (pull) с него данные. Это удобно и безопасно, но с развитием интернет ресурсов, появилась необходимость оперативно доставлять информацию пользователям не дожидаясь пока те сами сделают запрос. Так и появилась технология принудительной доставки (push) данных с сервера клиенту.

Push-уведомления работают только если у вас на сайте есть HTTPS.
Без валидного SSL сертификата запустить не получится. Так что если у вас еще нет поддержки HTTPS, то пришло время её сделать. Рекомендую воспользоваться Let’s Encrypt.
Для запуска на localhost нужно прибегать к хитростям. Я же тестировал скрипты на Github Pages.

Оглавление

Хорошие уведомления

Сразу хочу оговориться, что push-уведомления не для рекламных рассылок. Отправлять нужно только то, что действительно нужно конкретному пользователю и на что он действительно должен оперативно отреагировать.

• Отправка уведомления об изменении статуса обращения пользователя в службу техподдержки;
• Отправка уведомления об изменении статуса заказа;
• Появление на складе товара, который ждал пользователь;
• Ответили на комментарий пользователя к статье;
• Новая задача в багтрекере со статусом Bug или Critical.

• Новые поступления на склад;
• Скидки и акции на товары;
• Новая статья на сайте;
• Ответили на комментарий пользователя к статье, который он написал год назад.

Плохие примеры тоже требуют уведомления, но на них не нужно реагировать оперативно. Эти уведомления можно отправить на почту. Вообще, все важные уведомления рекомендуется дублировать на почту, так-как push-уведомления могут не дойти до пользователя по разным, не зависящих от вас, причинам. Также важным фактором является актуальность события. Об этом я еще поговорю чуть позже. Рекомендую к прочтению:

Вернемся к нашим баранам. Так как же всё это работает? Для начала немного теории.

Теория

Среди непосвященных бытует мнение что push-уведомления это простая технология, не требующая для реализации особых ресурсов. В действительности же это целый пул технологий.

Для начала небольшая схема того как все это работает (анимированная схема):

1. Сервер отдает страницу пользователю;
2. Клиент подключается к серверу сообщений, регистрируется и получает ID;
3. Клиент отправляет полученный ID на сервер и сервер привязывает конкретного пользователя к конкретному устройству используя ID устройства;
4. Сервер отправляет сообщение клиенту через сервер сообщений используя полученный ранее ID.

К сожалению, мне не удалось выяснить кто и как создает ID устройства и как сервер сообщений привязывается к конкретному устройству. Я использовал сервер сообщений Firebase Cloud Messaging от Google и его библиотеку. К сожалению, я не смог выяснить можно ли его заменить на свой сервер и как это сделать.

Изначально для отправки сообщений использовали:
Cloud to Device Messaging

Потом его заменили на:
Google Cloud Messaging

А потом еще раз поменяли на:
Firebase Cloud Messaging

Интересно, что дальше.

Что же происходит на стороне клиента?

• JavaScript запрашивает у пользователя разрешение на показ уведомлений;
• Если пользователь одобрил, то подключаемся к серверу сообщений и получаем ID устройства;
• Отправляем идентификатор на наш сервер, чтобы мы идентифицировали пользователя;
• Инициализируем JavaScript воркер который будет работать в фоне, получать сообщения от сервера сообщений и показывать их пользователю;
• Подключаемся к серверу сообщений и ждем новых поступлений.

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

Это все выглядит очень сложно, но на сервере все не проще.

Сложности на серверной стороне

• Понятно, что идентификатор устройства, присылаемый пользователем, мы сохраняем в базу данных;
• Идентификатор устройства хорошо бы привязывать к пользователю, чтобы отправлять персонализированные сообщения;
• Стоит помнить, что пользователь у нас один, а устройств у него может быть несколько, также одним устройством могут пользоваться несколько пользователей;
• Отправка уведомлений пользователям не самая дешевая операция и поэтому событие, инициирующее отправку уведомления, нужно ставить в очередь на отправку;
• Только маленькие проекты с малым числом получателей могут позволить себе отправлять уведомления по событию, в течении того-же HTTP запроса;
• Так у нас появляется система очередей на RabbitMQ, Redis и т.д.;
• Появляются демоны/воркеры которые разбирают очередь и другие инструменты поддержки очередей;
• Для увеличения скорости отправки можно распараллелить процесс и разнести его на несколько нод.

Практика

Наконец-то, мы перешли к самому главному. Как я уже говорил ранее, в качестве сервера сообщений мы будем использовать Firebase Cloud Messaging, поэтому мы начинаем с регистрации и создания проекта на Firebase.

• Заходим на сайт;
• Регистрируемся;
• Жмём кнопку Create new project или Import Google project, если у вас уже есть проект;
• При создании указываем название проекта и страну;
• После создания проекта попадаем на его dashboard;
• В меню наводим на колесико рядом с Overview и выбираем Project settings;
• На открывшейся странице переходим во вкладку Cloud Messaging;
• Нас интересует Server key, который будет использоваться для отправки сообщений с сервера и Sender ID который будет использоваться для получения сообщений на стороне клиента.

Можно еще покопаться в настройках и поиграться с разделением прав доступа, но, в общем-то, работа с сайтом Firebase закончена.

Приступаем к написанию клиента

Начнем с того что создадим Service Worker для получения push-уведомлений.
Создаем файл firebase-messaging-sw.js с следующим содержимым.

• <SENDER_ID> — это Sender ID который мы получили после регистрации в Firebase.

Файл Service Worker-а должен называться именно firebase-messaging-sw.js и обязательно должен находиться в корне проекта, то есть доступен по адресу https://example.com/firebase-messaging-sw.js. Путь к этому файлу жестко прописан в библиотеке Firebase.

Написанного кода достаточно для того чтобы показывать уведомления. О дополнительных возможностях поговорим чуть позже. Теперь добавим библиотеку Firebase и скрипт подписки в наш шаблон страницы.

Добавляем на страницу кнопку для подписки на уведомления

Подписка на уведомления

Вот и все. Это весь код который требуется для получения push-уведомлений.

Отправка уведомлений с сервера

В общем виде отправка уведомления выглядит так:

• YOUR-SERVER-KEY — это Server key который мы получили при регистрации в Firebase;
• YOUR-TOKEN-ID — это ID устройства конкретного пользователя.

Все поля по порядку:

• notification — параметры уведомления;
• title — заголовок уведомления. Лимит 30 символов;
• body — текст уведомление. Лимит 120 символов;
• icon — иконка уведомления. Есть некоторые стандарты размеров иконок, но я использую 192×192. Иконки меньшего размера плохо смотрятся на мобильных устройствах;
• click_action — URL адрес страницы на которую перейдет пользователь кликнув по уведомлению;
• to — ID устройства получателя уведомления;
• Полный список параметров здесь.

Это пример отправки одного уведомления одному получателю. Можно отправить одно уведомление сразу нескольким получателям. Вплоть до 1000 получателей за раз.

Пример ответов от сервера сообщений:

Мы не привязаны к какому-то конкретному языку программирования и для простоты примера будем использовать PHP с расширением cURL. Скрипт отправки уведомления нужно запускать из консоли.

messaging.onMessage

Обработчик messaging.onMessage стоит отдельного упоминания, так как он относится как раз к категории подводных камней. В примерах от Firebase я не видел примера использование этого обработчика. О нем мне рассказал FluorescentHallucinogen, за что ему отдельное спасибо, но он не упомянул о некоторых особенностях его использования.

Что же это за обработчик и как он работает. Из документации мы знаем, что этот обработчик вызывается если мы получаем push-уведомление и находимся в этот момент на странице сайта с которого отправлено уведомление (желающие использовать нативное решение могут посмотреть пример реализации). Эта функциональность очень полезна тем, что мы можем отобразить уведомление на странице сделав красивую модалку или еще что-то. У меня такой необходимости нет, потому я просто отображу стандартное уведомление.

Вроде все просто, но есть подводный камень. Дело все в том что на мобильных устройствах запрещено использовать конструктор Notification. И для решения этой проблемы нужно использовать ServiceWorkerRegistration.showNotification() и обработчик в этом случае будет иметь виде:

Теперь уведомления работают и на мобильных устройствах. Казалось бы уже все, но нет. Не смотря на заверения некоторых, ServiceWorker не должен быть пустым. Мы же хотим, что бы по клику пользователь переходил на нужную нам страницу. Для этого нам нужно добавить обработчик клика по уведомлению в ServiceWorker.

Сохраняем параметры уведомления для доступа свойству click_action в ServiceWorker-е.

Обрабатываем клик по уведомлению в ServiceWorker-е.

TTL и дополнительный контроль над уведомлением

Важным свойством для уведомления может является время его актуальности. Это зависит от ваших бизнес процессов. По умолчанию время жизни уведомлений 4 недели. Это очень много для уведомлений такого характера. Например, уведомление «Ваша любимая передача начинается через 15 минут» актуально в течении 15 минут. После этого сообщение уже не актуально и показываться не должно. За контроль над временем жизни отвечает свойство time_to_live со значением от 0 до 2419200 секунд. Подробней читать в документации. Сообщение с указанным TTL будет иметь вид:

Сообщение вида «Ваша любимая передача начинается через 15 минут» актуально в течении 15 минут, но уже через минуту после отправки оно станет не корректным. Потому что передача начнется не через 15 минут, а уже через 14. Контролировать такие ситуации нужно на стороне клиента.

Для этого мы поменяем отправляемое с сервера сообщение:

Обратите внимание что поле notification поменялось на data . Теперь не будет вызываться обработчик по умолчанию Firebase и нам нужно самостоятельно сделать это. Добавим в конце файла firebase-messaging-sw.js следующие строки:

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

Заключение

А теперь поговорим о грустном. Не смотря на все прелести технологии, у неё есть ряд недостатков:

1. Самая главная проблема это, как всегда, поддержка в браузерах. Полноценная поддержка есть в Chrome, Firefox и Opera последних версий. IE, Safari, Opera Mini, UC Browser, Dolphin и прочая братия остаются за бортом. Но зато работает в мобильных версиях браузеров Chrome, Firefox и Opera.
2. Открытый сайт и работающий Service Worker не гарантируют доставку сообщения. Хотя уведомления могут дойти и при закрытом браузере.

Библиотека Firebase скрывает в себе много тайн и её исследование могло бы дать ответы на некоторые вопросы, но это уже выходит за рамки этой статьи.

Поиграться

Проект на GitHub Pages

Так как для запуска Service Worker-а нужен HTTPS, то самым простым решением было разместить проект на GitHub Pages, что я и сделал.

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

• Зайти на страницу;
• Нажать кнопку Register;
• Браузер запросит разрешение на показ уведомлений;
• Подтверждаем разрешение;
• На странице и в консоли браузера будет напечатан ID вашего устройства;
• Появится кнопка Delete Token для удаления существующего токена и повторной регистрации;
• Появится форма с параметрами уведомления которое можно отправить нажав на кнопку Send;
• Меняем параметры по усмотрению и получаем разные уведомления.

Можно отправить уведомление через любой инструмент для отправки HTTP запросов. Можно использовать сURL, я предпочитаю приложение Postman для Chrome.

Запрос такой же как и описанный ранее:

• YOUR-TOKEN-ID — это ID устройства который вы получили на странице приложения.

Вот и все. Получаем уведомление и радуемся жизни.

Ссылки

• Про PUSH

• Quickstart от Firebase

Updated at 2018-06-09

Обнаружились некоторые «особенности» в работе уведомлений.

Дубликаты уведомлений

Ко мне несколько раз обращались с вопросом: «Как исправить дублирующиеся уведомления?»

Проявляется эта проблема если открыть сайт отправляющий уведомления одновременно в нескольких вкладках. В этом случае Service Worker отправляет уведомление в обе вкладки и в обоих вкладках срабатывает метод messaging.onMessage. Наблюдать эту проблему можно на моем Demo проекте.

Что бы решить эту проблему, нужно в методе messaging.onMessage знать, что уведомление уже показывалось в другой вкладке. В качестве единого хранилища можно использовать localStorage , а идентифицировать уведомления по хеш сумме уведомления или присваивать уникальный id. Только стоит помнить, что localStorage не резиновый и id уже показанных уведомлений нужно подчищать через некоторое время.

Могу порекомендовать для этих целей библиотеку pamelafox/lscache.
Если у вас есть другой метод решения проблемы, напишите в комментариях.

Картинки в уведомлениях

Сегодня ко мне обратился пользователь CTterorist, заметивший, что не отображаются картинки (image) в уведомлениях.

Немножко потестировав, мне удалось разобраться. Не смотря на то, что поле image отправляется в Firebase, вместе с другими параметрами уведомления, но обратно от Firebase поле image не приходит. Решается проблема очень просто. Можно отправлять картунку в поле data , а в обработчике показа уведомления вытягивать картинку из data и вставлять ее на место в уведомление.

То есть, если вы отправите сообщение в таком виде, то Firebase потеряет картинку.

What is a Web Push Notification and how does it work?

Imagine a time when users would visit your website to explore your products and services. Very few of them would actually convert and a large chunk of them dropped off over time. Businesses like yours had limited options, such as email or SMS to reach out and nudge users, and even this was only an option for those users who had shared their contact details. But this was way back in the 1990s and 2000s. Fast forward to 2012 when Google launched Chrome 42. This supported native web push notifications and revolutionized how brands and online publishers could communicate and engage with their users.

Businesses quickly jumped on the bandwagon of this new marketing channel and started realizing its true potential in achieving their key business goals. Over the next few weeks, we will be taking you through multiple aspects of web push notifications, dive deep into the critical aspects of using them and the value you can get out of using these notifications.

What is a web push notification?

Web push notifications are actionable messages that are sent to visitors’ devices via a website. These messages are highly contextual, timely and personalized and are best used to engage, re-engage and retain website visitors.

Web push notifications can be sent to your visitor’s desktop and mobile phone on their browsers — even when the user is not active on your website. You don’t even need email addresses or contact details to send a push notification. This makes it easy for businesses to reach out to their users to grab their attention and bring them back to their website.

Types of web push notification

• Desktop Web Push Notification: Send messages or alerts on a user’s desktop even when the users are not on your website.
• Mobile Web Push Notification: Send messages or alerts on a user’s mobile even when the users are not on your website.

Browsers that support web push notifications

While most devices and OS’s allow web push notifications, it is critical to know which devices, OS’s and browser versions do support this function. Here’s a list of devices that support and do not support web push notifications.

The anatomy of a Web Push Notification

A web push notification is made up of 6 integral elements that collectively determine its effectiveness.

Web Push Notification Layout for Chrome on Windows

• Title: The title is the first thing that a user sees and sets the context of the push notification. While the title is important, it is imperative that you keep an eye on the title length. To write web push notification titles, you need to harness the art of copywriting so that you can be precise, on point, attractive and short. Here are the character limits of web push notification as supported on various browsers:

• Description: The description is the actual message that will be sent to the user. It should be short and sweet, while clearly conveying the idea to the user that they should take immediate action. The recommended character limit is also 120 characters, however, browsers have not specified a maximum limit.
• Icon: Add brand icons to instill brand recall and authenticity to your notifications. If you do not add an icon, the user will see a default bell icon. Users get numerous push notifications, hence it is a good idea to add an icon to help differentiate you from the noise. The recommended dimensions for icons is 192×192 px.
• Website URL: This is the URL of the website that sent the push notification. The URL visible on the notification is always the domain from which the user allowed the opt-in
• Image: This is the graphical and visual aspect of the push notification. Using an image in your push notification has been proven to increase user actions and conversion rates. However, the decision of whether to use an image or just the text is entirely up to you.
• CTA: CTAs play a vital role in your push notification. They help you to derive the intent of the user whether they like or dislike the message based on the CTA they choose. It provides additional actions besides clicking the notification. However, CTAs can be only added on the Chrome platform and there is a maximum limit of 2.

Advantages of using web push notifications in your marketing arsenal

Web push notifications have been proven to be an effective marketing channel in all aspects as opposed to both email and SMS. Since it is a purely permission-based channel, you have the user’s consent to reach out to them with marketing messages. Here are a few advantages of using web push notifications:

• Send messages even when the user is not active: Your users’ don’t have to be online or on their desktop to receive push notifications. Then, when they launch the website, they’ll be able to see all the notifications that they’ve received.
• Don’t depend on having a mobile app: Web push notifications help you to stay connected with your mobile users without investing in developing and offering mobile apps. On most Android mobile phones users receive notifications in a similar fashion to in-app notifications. However, this is limited to Android device users only.
• Easy opt-in experience: Unlike opt-ins for various other marketing channels, web push notifications offer users a seamless opt-in experience with a single click — “allow”. They need not worry about sharing their personal data such as their name, email, phone number and can have peace of mind that this channel is GDPR compliant.
• Swift delivery: Web push notifications are instantly sent to the users without any delay in transmission. All messages are sent and received in real-time.
• Increased engagement: Since push notifications are sent in real-time, they incur higher engagement rates as compared to any other marketing channel. Targeted web push notifications help you to increase return visitors by sending them exciting offers and discounts. Based on the real-time engagement rate, you can also estimate and analyze the active time of your users.
• Higher conversion rates: Personalizing your messages and targeting a segmented audience not only offers your users a great user experience but also helps boost conversion rates. You can even improve your conversion rates by sending notifications when your users are most active and based on the actions they take on specific product pages.

The way forward

In this blog post, we talked about the basics of web push notifications, anatomy, importance and the advantages of using them. In our next blog series, we’ll tap into the aspects of user opt-ins and why they are important. So stay tuned!

Web Push уведомления: особенности и достоинства

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

В статье разобрались, в чем преимущества этого канала, как работает и как его использовать с наибольшей пользой для бизнеса.

Как работают Web Push рассылки

Web Push (web push notifications) — это всплывающие в окне браузера сообщения от брендов, медиа, сервисов и других проектов.

Если провести параллель с социальными сетями, то email-рассылка — это привлекательно оформленная запись во ВКонтакте, а Web Push — твит. Его просто и быстро оформить и также легко получить.

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

Web Push рассылают через специальный легкий протокол, встроенный в браузеры. Для идентификации пользователя вместо email или номера телефона используется уникальный токен, который создает браузер подписчика. После этого браузер будет принимать из сети только те уведомления Web Push, которые предназначены именно ему.

Кому и зачем нужны Web Push

Web Push могут использовать любые компании, у которых есть сайт, независимо от масштабов, ниши, объема целевой аудитории и количества трафика.

Через этот канал можно решать разные маркетинговые задачи:

• рассказывать про акции и скидки
• увеличивать продажи
• «догонять» пользователей, которые ничего не купили
• бороться с брошенными корзинами
• анонсировать статьи и приводить трафик в блог

Например, компании, которые ведут корпоративный блог, предлагают читателям подписаться на Web Push о новых статьях. Подписчики видят в браузере сообщение, как только новый материал вышел, и идут читать. Чем больше собранная база, тем больше у блога постоянных читателей. С помощью Web Push компании вовлекают их в контент и прогревают до покупки.

Интернет-магазины предлагают посетителям сайта подписаться на уведомления о самых выгодных акциях или новых поступлениях. А сервисы управления проектами через этот канал рассылают сообщения о новых событиях: изменении статусов задач, комментариях, просроченных делах, действиях коллег.

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

Особенности, плюсы и минусы Web Push уведомлений

Web Push — короткие сообщения без сложного форматирования. В отличие от email-рассылок:

• В Web Push не получится уместить много текста. Вся информация ждет пользователя на сайте или лендинге, а задача пуша — мотивировать его перейти на эту страницу.
• Весь дизайн Web Push сводится к добавлению иконки и иногда иллюстрации.
• База подписчиков Web Push анонимна — нет адреса, телефона и какой-либо еще информации о пользователях.
• Для запуска Web Push рассылки достаточно двух коротких строк текста. Лимит символов в разных браузерах отличается, но чтобы уведомление корректно отображалось у всех пользователей, стоит ориентироваться на 100–125 знаков.

Главные преимущества Web Push — простота и анонимность. Поскольку людям не надо нигде оставлять свои контакты, согласиться на такую рассылку проще, чем на email или смс. Для запуска не нужны ни длинный текст, ни дизайн, ни верстка, поэтому на рассылку Web Push требуется гораздо меньше времени и других ресурсов.

Маркетолог может самостоятельно генерировать поток уведомлений, которые будут привлекать подписчиков на сайт компании. Кроме того, на Web Push почти не влияют блокировщики рекламы.

Есть у Web Push и недостатки, о которых нужно знать, чтобы использовать их эффективно:

• Уведомления привязываются к конкретному браузеру, так что рассыльщик не знает о получателе ничего, кроме безликого токена. Если человек поменяет или переустановит браузер, подписки исчезнут. Более того, два браузера на разных компьютерах не могут принимать общие уведомления, даже если они связаны общим сетевым аккаунтом. Если пользователь подписался на уведомления с домашнего компьютера, на рабочем он их не получит.
• Web Push анонимны, поэтому их не получится так детально персонализировать, как email-рассылки. Вы легко можете настроить индивидуальные email-рассылку с подтверждением заказа или поздравлением с днём рождения, но браузерные уведомления пока так не умеют.

Впрочем, эти недостатки компенсируются тем, что сообщения сразу привлекают внимание пользователя в окне браузера и обычно имеют высокий CTR.

Как запустить Web Push рассылку

Чтобы настроить рассылку Web Push, нужно собрать базу и запустить отправку самих сообщений. Все это можно сделать с помощью сервиса рассылок. Чаще всего для отправки уведомлений = используют те же инструменты, что и для email-маркетинга. Например, рассылать такие уведомления умеет платформа Sendsay. Расскажем о технических особенностях на его примере.

Шаг 1. Запускаем сбор базы

Чтобы в браузере пользователя всплывало окно подписки на Web Push, на сайт нужно установить два скрипта.

1. Авторизуйтесь в личном кабинете Sendsay, перейдите в раздел «Подписчики» на вкладку Web Push и нажмите «Подключить сайт».

2. Введите ссылку и кликните «Добавить сайт»..

3. Установите код скрипта для Web Push на страницах сайта, с которых нужно предлагать посетителям подписку.

4. Скачайте и добавьте в корень сайта файл с именем sendsay_push_sw.js..

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

Также настроить функционал подписки на Web Push можно через Google Tag Manager. Для этого на сайте должен быть заранее установлен код GTM. В этом случае привлекать программиста не потребуется — справится маркетолог.

• Создайте в Google Tag Manager новый тег
• Кликните по полю «Конфигурация тега» и выберите тип «Пользовательский HTML»
• В открывшемся окне вставьте код скрипта, скопированный из личного кабинета Sendsay
• Кликните по полю «Триггеры» и выберите событие, по которому будет срабатывать скрипт. Для подписки на Web Push подходящий вариант — «Просмотр страницы»
• Нажмите «Сохранить» в правом верхнем углу

Шаг 2. Отправляем Web Push

Чтобы запустить рассылку уведомлений, перейдите в раздел «Рассылки» → «Web Push» → «Создать выпуск».

Настройте сообщение, заполнив поля:

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

Как сделать Web Push эффективным каналом коммуникации

Разработайте стратегию. Учитывая особенности Web Push, подумайте, как использовать их для достижения целей бизнеса. Пропишите задачи, план действий и KPI, по которым будете оценивать эффективность.

Развивайте омниканальность. Web Push должны быть встроены в общую систему маркетинговых коммуникаций с клиентом. Планируйте рассылки уведомлений так, чтобы они продолжали и дополняли общение в других каналах — email, мессенджерах, SMS.

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

Не отправляйте часто. Всплывающие в окне браузера сообщения сразу привлекают внимание пользователя. Когда они приходят слишком часто, это раздражает и люди отписываются. Через Web Push стоит отправлять только самые важные уведомления: сообщения о глобальных изменениях, интересный контент и масштабные акции. Для регулярных контентных рассылок, персонализированных подборок товаров и ситуативных коммуникаций лучше использовать более нейтральный канал, например, email-рассылку.

Поработайте над текстом. В коротком формате важно писать емко и лаконично, чтобы вмещать максимум смысла в ограниченное количество символов. И не забывайте про пользу и призыв к действию — так кликабельность Web Push будет выше.

Сегментируйте базу. Возможностей для персонализации здесь меньше, чем в email-рассылках. Но вы можете, например, собирать в отдельные сегменты пользователей, подписавшихся на рассылку в разделах сайта для B2B и B2C.

Как и с любым маркетинговым каналом, чтобы Web Push работали и приносили бизнесу пользу, важно тщательно отслеживать показатели и оптимизировать стратегию. Экспериментируйте с темами и частотой рассылок, чтобы найти варианты, которые будут оптимальны по количеству трафика и отписок.

Кроме того, мы делимся полезной информацией в сфере digital-маркетинга в нашем телеграм-канале, при подписке на который дарим книгу «Email-маркетинг для бизнеса». Подробнее о том, как ее получить, рассказали в закрепленном сообщении канала.