Push уведомления своими руками

Как настроить пуши на сайте, не потратив ни рубля — пошаговое руководство

Чёткая инструкция от Константина Юревича, сооснователя Driveback.

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

Руководство написано на базе одной из популярнейших систем по отправке пуш-уведомлений — OneSignal. Выбор пал на неё по двум причинам:

• полностью бесплатна;
• обладает необходимыми функциями по сегментации аудитории и автоматизации пушей.

Что нужно для начала работы:

• сайт с поддержкой HTTPS, на котором будем настраивать пуши;
• доступ к коду сайта, чтобы разместить в нём три статичных файла.

Шаг 1. Регистрация и настройка аккаунта

Регистрируем новый аккаунт в OneSignal. Подтверждаем email и логинимся в панели управления:

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

Замеряем пульс российского диджитал-консалтинга

Какие консалтинговые услуги востребованы на российском рынке, и как они меняют бизнес-процессы? Представляете компанию-заказчика диджитал-услуг?

Примите участие в исследовании Convergent, Ruward и Cossa!

Нажимаем Add a new app и указываем название сайта, на котором хотим настроить пуш-уведомления:

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

Отмечаем Web Push и нажимаем Next:

Выбираем тип настроек Typical Site. Ниже указываем имя сайта и его URL с HTTPS. Загружаем квадратную картинку с логотипом вашего сайта, нажав кнопку +UPLOAD. Она будет отображаться в качестве иконки будущих пуш-уведомлений.

Настройку My site is not fully HTTPS оставляем по умолчанию отключённой.

Если ваш сайт до сих пор не поддерживает HTTPS, прекращайте чтение руководства и займитесь настройкой HTTPS:-) Безопасность пользователей превыше всего.

Скроллим страницу вниз на один экран и переходим к настройке Prompt. Это диалог, который запрашивает у пользователя разрешение на подписку.

Выбираем ADD A PROMPT:

В появившемся окне выбираем тип диалога SLIDE PROMPT.

Активируем опцию Customize slide prompt text, чтобы активировать русский язык.

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

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

Переходим на следующий экран, где опционально можно настроить Welcome Notification — сообщение об успешной подписке.

Ничего не имею против Welcome Notification, но точно нужно деактивировать Open link when clicking welcome notification. Многие компании не просто ставят ссылки в такие сообщения, но и проставляют utm-метки: но это вредит атрибуции по last non-direct click.

Скроллим до конца страницы. Оставляем все опции по умолчанию и нажимаем Save.

Шаг 2. Установка на сайт

Теперь устанавливаем систему OneSignal на сайт.

Скачиваем файлы OneSignal SDK и загружаем их в корень сайта:

Файлов всего три:

• Manifest.json
• OneSignalSDKUpdaterWorker.js
• OneSignalSDKWorker.js

Самый простой способ поставить их в корень сайта — доверить эту работу программистам, а затем пройти по ссылкам и проверить. Домен заменить на собственный:

Если ссылки открываются и публично доступны, значит всё работает. После этого осталось добавить код инициализации OneSignal на все страницы сайта.

Сделать это можно разными способами. Рассмотрим некоторые из них.

Способ 1

Установить напрямую в код сайта, как показано на скриншоте:

Не рекомендую этот способ по двум причинам. Во-первых, в будущем надо будет часто менять конфигурацию, чтобы отправлять в OneSignal разные сегменты и настраивать автоматизацию.

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

Способ 2

Установить при помощи Google Tag Manager.

Использовать триггер All Pages, как показано на рисунке:

Способ 3

Подключить при помощи DigitalDataManager.

Для этого необходимо выбрать OneSignal в личном кабинете в списке интеграций:

Указать идентификатор App ID и сохранить:

Идентификатор App ID можно найти в JS-коде установки из пункта 1 или позже в специальном разделе панели управления:

Настройка для всех браузеров, кроме Safari, завершена.

Шаг 3. Настройка пуш-уведомлений для Safari

Настройка пуш-уведомлений для браузера Safari требует сделать дополнительный шаг. Заходим в Settings в панели OneSignal:

Окно настроек выглядит следующим образом.

В поле Site Name указываем название сайта.

В поле Site URL прописываем URL сайта с https. В нашем случае это demo.ddmanager.ru

Поле I’d like to upload my own.p12 certificate оставляем неактивным.

Поле I’d like to upload my own notification icons делаем активным и загружаем квадратную иконку сайта в разрешении 256×256.

Название сайта Site name и иконка будут отображаться в системных диалогов Safari:

Когда всё готово, нажимаем Save.

Шаг 4. Подписка на пуш-уведомления

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

Подписываемся на пуш-уведомления и возвращаемся в панель OneSignal, чтобы проверить, что подписки появились в разделе Users.

Заходим в Users → All Users:

Находим себя в списке подписчиков:

Следующим шагом добавляем себя в список тестировщиков, чтобы в будущем тестировать новые пуш-уведомления.

Присваиваем имя «тестировщику»:

Видим, что все тестовые пользователи отображаются в разделе Users → Test Users:

Шаг 5. Отправка первого пуш-уведомления

Теперь главное — тестируем отправку первого пуш-уведомления.

Заходим в раздел Messages и нажимаем New Push:

В разделе Audience выбираем Send to Test Device(s) и отмечаем галочками тестовые подписки, которые настроили в предыдущем шаге:

Указываем заголовок и вводим текст сообщения:

Для браузера Google Chrome можно настроить разные картинки, иконки и кнопки.

Указываем URL перехода при клике на пуш с необходимым UTM-метками в поле Launch URL и нажимаем Confirm:

Подтверждаем отправку выбранному сегменту пользователей:

Барабанная дробь… И появляются пуш-уведомления.

В следующих частях расскажем, как:

• настраивать сегменты внутри OneSignal и передавать поведенческие данные с сайта;
• настраивать автоматизацию («Брошенная корзина», «Реактивация спящих» и подобное);
• настраивать сегментированный сбор подписок.

Источник

Внедряем кросс-платформенные пуш-уведомления: начало

Добрый день! Меня зовут Владимир Столяров, я бэкенд-разработчик в команде Клиентские коммуникации в ДомКлике. В этой статье я расскажу о том, как внедрить кросс-платформенные пуш-уведомления. Хотя про это уже написано немало, я бы хотел рассказать о некоторых нюансах, с которыми нам пришлось столкнуться в процессе внедрения. Для лучшего понимания происходящего также напишем с вами небольшое веб-приложение, способное принимать пуши.

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

Начнем с веб-пушей. Для их получения браузер подключается к своему пуш-серверу, идентифицируется и принимает уведомления в сервис-воркер (в нем срабатывает событие push ). Нюанс тут в том, что у каждого браузера пуш-сервис свой:

• У Firefox он называется Mozilla Push Service. Его исходный код и спецификация протокола открыты, чем мы позже воспользовались.
• У Chrome это Google Cloud Messaging (не Firebase Cloud Messaging, что можно увидеть по именам доменов в исходном коде), и так далее.

Хорошая новость для нас в том, что веб-пуши стандартизированы IETF (https://datatracker.ietf.org/wg/webpush/documents/), и поддерживать разные форматы API для каждого браузера как на клиенте, так и на сервере нам не придется.

Теперь рассмотрим устройства на базе Android. Здесь есть несколько вариантов:

• Если в системе установлены Google Apps, то можно воспользоваться Firebase Cloud Messaging.
• Если у вас устройство от Huawei без Google Apps, то можно использовать Huawei Push Kit.
• Можно написать собственный пуш-сервер или воспользоваться готовыми проектами, например, https://bubu1.eu/openpush/, благо открытость платформы позволяет.

Далее идет iOS. В отличие от Android, способ отправить уведомления на устройства Apple всего один — использовать Apple Push Notification service (APNs).

Может возникнуть логичный вопрос: неужели придется поддерживать всё это многообразие стандартов, API и прочего на серверной стороне? На самом деле, всё не так уж и плохо, так как Firebase Cloud Messaging, помимо отправки на Android, покрывает еще и веб-пуши и работает с APNs. Так мы пришли к следующей схеме: на устройства Huawei без Google Apps отправляем через Huawei Push Kit, в остальных случаях пользуемся Firebase Cloud Messaging.

Несмотря на многообразие стандартов и сервисов, схема работы будет примерно одинаковой:

1. Клиент подключается к пуш-серверу и получает уникальный идентификатор — токен.
2. Клиент отправляет токен серверу конкретного приложения, чтобы стать связаным с учетной записью пользователя.
3. Сервер приложений начинает по полученному токену отправлять пуши для конкретного пользователя.

Попробуем написать тестовое приложение

Для начала просто получим пуш-токен от Firebase и попробуем отправить пуш. Нужно зарегистрировать проект в консоли Firebase и получить конфигурацию для веб-приложения. Для корректного функционирования будет нужен локальный HTTP-сервер с передачей статики.

Сделаем страницу с одной кнопкой и необходимыми скриптами:

Также потребуется скрипт сервис-воркера. По умолчанию он подгружается автоматически по пути /firebase-messaging-sw.js . Для начала будем использовать готовый скрипт отсюда.

Открываем страницу, нажимаем на кнопку, разрешаем уведомления в браузере и копируем отображенный токен. Для удобства работы с API вручную можно создать долговременный ключ сервера (не сервисный аккаунт). Делаем простой запрос:

Тут есть важный момент, о котором можно забыть: пуш-токен никак не связан с пользователем приложения, он связан с конкретным получателем (т.е. с клиентской конфигурацией). На мобильных устройствах он связан с конкретной инсталляцией приложения.

Посмотрим, что нам приходит в браузер. В документации описан колбэк setBackgroundMessageHandler . Модифицируем сервис-воркер, добавив в конец файла код:

Открываем консоль сервис-воркера, снова отправляем пуш… и ничего не видим в консоли, хотя уведомление отобразилось. Почему же? Ответ в есть в документации:

Note: If you set notification fields in your message payload, your setBackgroundMessageHandler callback is not called, and instead the SDK displays a notification based on your payload.

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

Тем не менее, можно это обойти, обрабатывая входящие пуши вручную. Поменяем содержимое firebase-messaging-sw.js :

Здесь мы считываем полезную нагрузку в json и парсим ее в js-объект, который будет выведен в консоль, заодно показывая уведомление. Обратите внимание на waitUntil внутри обработчика: он нужен для того, чтобы сервис-воркер не завершил работу до окончания асинхронного вызова onPush .

Теперь добавим пользователей в наше приложение

Для удобства заведем новую страницу:

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

В бэкенд также добавлен код отправки пушей конкретному пользователю.

Базово мы обеспечиваем следующую функциональность:

• При входе пользователя запрашиваем разрешение на показ уведомлений, и при согласии получаем пуш-токен и отправляем его на сервер. Пуш-токен привязывается к пользователю с помощью сессионных/авторизационных кук.
• При выходе мы инвалидируем пуш-токен. При следующей попытке отправить его Firebase нам ответит ошибкой, что такой токен не существует, и мы удалим его из хранилища.
• При обновлении пуш-токена мы отправляем новый в хранилище. Старый токен мы удалим уже при следующей отправке пуша.

Опишу несколько важных моментов, на которые мы наткнулись уже на практике (они отражены в примере):

• Пуш-токены имеют ограниченный срок жизни, однако узнать его из самого токена, на первый взгляд, невозможно. Судя по коду firebase-js-sdk, этот срок чуть больше недели, так как колбэк на обновление токена onTokenRefresh вызывается раз в неделю.
• Разные пользователи могут прислать одинаковые пуш-токены. Такое возможно в случае, если запрос на инвалидацию в Firebase не прошел успешно. Для решения этой проблемы мы в данном случае меняем владельца токена.
• У пользователя может завершиться сессия без явного логаута. Т.е. пользователь больше не авторизован, однако уведомления продолжают поступать. Способ решения этой проблемы зависит от архитектуры приложения. Мы при отправке пуш-токена на сервер сохраняем идентификатор пользователя еще и локально, при каждой загрузке страницы сверяя его с ответом на запрос о текущем пользователе. Если значения различаются или пользователь не авторизован, то пуш-токен инвалидируется. Однако у такого подхода всё же есть один недостаток: инвалидация происходит только в случае загрузки страницы сайта.
• Сохраняйте платформу, с которой получен токен. Это поможет при дальнейшей кастомизации: например, добавить возможность ответа в чат прямо из пуша (в Android/iOS можно, в браузере — нет), кнопки и прочее.

И вот, грабли собраны, доработки выложены в прод. Пуши ходят… или не ходят? Самое время поговорить про

Надежность

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

Идея следующая: мы генерируем одноразовый токен подтверждения (в нашем случае это просто UUID) и отправляем его в пуше. Клиент при получении и показе пуша делает HTTP-запрос, в который включается присланный токен подтверждения. Немного дорабатываем бекенд и firebase-messaging-sw.js :

И если с вебом нам хватило такой простой доработки, то с мобильными устройствами всё несколько сложнее. Помните про замечание в документации о setBackgroundMessageHandler ? Так вот, дело в том, что в Firebase (да и в Huawei) есть не совсем очевидное (по API) разделение на, условно, информационные пуши (если есть поле notification ) и data-пуши. По задумке, информационные пуши никак не обрабатываются приложением и на их основе сразу формируется уведомление, а data-пуши попадают в специальный обработчик и дальше приложение решает, что делать.

Если при получении веб-пушей с ними можно работать до показа, отказавшись от firebase-js-sdk в сервис-воркере, то в Android так не получится. Поэтому для Android мы перенесли всю нужную информацию исключительно в data и перестали отправлять notification , что позволило нам реализовать подтверждение доставки.

Для APNs же достаточно просто выставить mutable-content в 1, и тогда при обработке пуша можно будет выполнять некоторый код, но с довольно серьезными ограничениями, хотя этого вполне достаточно для простого HTTP-запроса. Собственно, именно из-за ограничений iOS при подтверждении пуша не задействуется пользовательская сессия, а используются одноразовые токены.

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

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

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

• Android (исключая Huawei) — 40 %
• Web — 50 %
• iOS — 70 %

Для Huawei достаточное количество данных еще не накоплено. Следует сказать о том, что мы не предпринимали никаких действий по увеличению доли доставленных пушей, как это сделали, например, в Яндекс.Почте.

Итоговая архитектура получается примерно такой:

Полную версию проекта можно взять на GitHub.

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

Источник