Если вы занимаетесь рассылкой веб-пушей или только планируете подключить этот канал, нужно остерегаться подводных камней. В этой статье раскрыты такие вопросы:
Как работает процесс запуска пушей:
1) Проблемы миграции из одного сервиса в другой;
2) Особенности запуска рассылок после переноса базы;
3) На что обратить внимание при выборе push-сервиса рассылок.
А также правильно собирать и хранить токены-контакты, чтобы не потерять их при смене сервиса рассылок.
Как работает процесс запуска пуш-уведомлений
Сначала разберём наших главных героев, участников процесса пуш-рассылки.
Со стороны клиента:
- Сам подписчик,
- Браузер + Service Worker.
Service Worker - скрипт, выполняемый браузером в фоновом режиме, вне контекста веб приложения. Таким образом, предоставляя функциональность, которая не требует прямого взаимодействия с пользователем или необходимости веб приложения быть активным в данный момент ( под активным - имеется в виду наличие загруженных/открытых страниц сайта). Сегодня они включают такие функции, как push-уведомления и фоновая синхронизация.
Узнать больше информации можно на сайте developers.google
Со стороны отправителя:
- Сервис-рассылки (пуш-сервисы),
- Сервис-провайдер.
В нашем случае сервис-провайдер - это Google Firebase Cloud Messaging (FCM). Платформа с разнообразной функциональностью, в том числе для работы с приложениями на iOS и Android.
Прим. Safari использует свой сервис для приема и доставки уведомлений. Мы рассматриваем пример только с FCM, который используется браузерами Chrome, Opera и Yandex.
Чтобы начать работать с Firebase, необходимо создать в нём проект. Вы можете использовать несколько проектов для поддержки нескольких разных приложений.
Путь клиента: от подписки до получения первого сообщения
В момент, когда пользователь заходит на сайт компании, ему показывается окошко с предложением подписаться на рассылку веб-пуш уведомлений.
Если посетитель кликает на кнопку подтверждения, то создается токен. В свою очередь токен передается в сервис рассылки, который отправляет уведомления через соответствующего провайдера.
При наличии нового уведомления срабатывает соответствующий обработчик Service Worker`a. Который отвечает за отображение полученного уведомления.
Есть 2 способа получения содержимого уведомлений:
- Напрямую от сервиса-провайдера.
- Через специальный API сервиса рассылок.
Когда вы нажимаете на кнопку Send у себя в аккаунте, на самом деле вы отправляете в Firebase запрос, что у вас есть сообщение для этого токена. Service Worker получает информацию об имеющемся сообщении, запрашивает контент сообщения у сервиса рассылки и отображает его подписчику.
Проблемы миграции
Главная проблема: Firebase-проект может принадлежать не вам, а сервису рассылки.
Некоторые компании регистрируют все токены на свой домен или на свой проект, который принадлежит только им. Однажды составив “брачный договор” с сервисом пуш-рассылки, при разрыве брака всё имущество, а именно токены, остаются у сервиса. И не потому что сервисы плохие, а потому что так у них технически устроено.
Даже если вы чудом получите собранные токены, другой сервис, на который вы хотите перейти, не будет иметь доступа к Firebase, через который раньше осуществлялась рассылка. Получается, сделать рассылку по этим токенам будет невозможно.
Для переноса базы:
- Проект всегда должен принадлежать вам!
Подробнее о том, как настроить Firebase проект >>
- Должна быть возможность получить список токенов, чтобы перенести его из одного сервиса рассылок в другой.
Узнать как перенести контакты >>
- Подписка должна происходить через домен клиента.
Что делать, если Firebase вам не принадлежит
Если вы оказались в этом неприятном положении, вы можете продолжать отправлять проморассылки через старый сервис, а новые токены собирать через другой.
Срок жизни токена в среднем составляет 3 месяца. Часто до 50% токенов теряют актуальность в течение месяца. Причины могут быть такие:
- Отключение в настройках браузера подписки,
- Смена устройства,
- Удаление Service Worker`a и т.д.
Таким образом, вы сможете полностью перейти на новый сервис рассылок максимум через три месяца. И чем раньше вы примете решение вернуть себе контроль над собственной контактной базой, тем лучше!
Особенное внимание в веб-пушах оказывайте с первого момента жизни. Например, запуская приветственную серию для web-пушей.
Если перенос прошёл успешно
Это ещё не значит, что дальше всё пойдёт как по маслу. Здесь тоже есть нюансы.
В новом сервисе рассылок вы создаете сообщение и нажимаете “Отправить”. В Firebase, который принадлежит вам, поступает сигнал о том, что у вас есть сообщение для токена. Service Worker принимает этот сигнал вторым способом, а именно - через API сервиса рассылок, то по привычке он пойдёт за контентом в предыдущий сервис рассылки. Так будет продолжаться пока не обновится скрипт.
Как же передавать контент из нового сервиса рассылок?
Вам нужно “обучить” Service Worker запрашивать контент сообщения не у старого, а у нового сервиса рассылок. Для этого существует 2 варианта:
- Подписчик должен снова зайти на сайт компании и Service Worker обновится автоматически. При условии, что прошло более суток с момента последней проверки наличия обновлений браузера.
Минус в том, что пользователи редко просто так заходят на сайт. Можно подписчикам отправить email-рассылку и у тех, кто перейдёт на сайт обновится Service Worker. Но опять же, это только часть подписчиков. - Вам нужно отправить пуш-рассылку. Тогда благодаря обновленному содержимому в Service Worker при получении следующего уведомления обработчик пойдет за контентом сообщения в новый сервис рассылки.
Минус в том, что в первый раз обработчик всё же обратится к старому сервису рассылок и подписчики получат не вашу красивую рассылку, а техническое уведомление.
На этот случай у некоторых сервисов рассылок есть нейтральное сообщение по умолчанию, которое выдается, если для токенов нет приготовленного сообщения, но запрос поступает.
Но всё же, лучше сразу правильно выстроить коммуникацию с клиентом и прежде всего правильно выбрать пуш-сервис.
На что обратить внимание при выборе сервиса рассылок пуш-уведомлений:
- Доступ к базе. Убедитесь, что Firebase будет принадлежать вам и есть ли у вас доступ ко всем токенам. Если компания не даёт возможности использовать ваш проект Firebase, вы не сможете выгрузить контакты и перенести их в другой сервис при необходимости.
- Возможности для пуш. Например, есть ли возможность задать срок жизни пуша, использовать кнопки СТА, большие картинки и т.д.
- Автоматизация. Можно ли использовать автоматизированные push, можно ли в них добавлять динамический контент. Например, запуская брошенные корзины/ просмотры/ приветственные цепочки.
- Сегментация. По каким параметрам можно настроить сегменты и возможно ли это сделать вообще в рамках используемого сервиса.
- Мультиканальность. Сможете ли вы использовать пуши в рамках мультиканальных и омниканальных сценариев.
- Хранение базы. Очень важный нюанс - чистится ли база. Например, вычисляются ли неактивные токены. Согласитесь, не совсем целесообразно платить за отправку тем контактам, которые уже давно не существуют.
- Статистика. Какие показатели закладываются в статистику после отправки, как можно работать с этими данными.
Именно поэтому в этом году мы так значительно дополнили и расширили возможности для отправки push-уведомлений. Чтобы наши пользователи не встретитесь с вышеперечисленными проблемами и не возникало вопросов с хранением базы.
По вопросам переноса базы в eSputnik или знакомства с возможностями системы - пишите нам на support@esputnik.com.
