Что делать, если вы решили сменить сервис рассылки веб-пушей, и как не ошибиться с выбором нового

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

Как работает процесс запуска пуш-уведомлений

Сначала разберём наших главных героев, участников процесса пуш-рассылки.

Со стороны клиента:

• Сам подписчик,
• Браузер + Service Worker.

Service Worker - скрипт, выполняемый браузером в фоновом режиме, вне контекста веб приложения. Таким образом, предоставляя функциональность, которая не требует прямого взаимодействия с пользователем или необходимости веб приложения быть активным в данный момент ( под активным - имеется в виду наличие загруженных/открытых страниц сайта). Сегодня они включают такие функции, как push-уведомления и фоновая синхронизация.

Узнать больше информации можно на сайте developers.google 

Со стороны отправителя:

• Сервис-рассылки (пуш-сервисы),
• Сервис-провайдер.

В нашем случае сервис-провайдер - это Google Firebase Cloud Messaging (FCM). Платформа с разнообразной функциональностью, в том числе для работы с приложениями на iOS и Android.

Прим. Safari использует свой сервис для приема и доставки уведомлений. Мы рассматриваем пример только с FCM, который  используется браузерами Chrome и Opera. 

Чтобы начать работать с Firebase, необходимо создать в нём проект. Вы можете использовать несколько проектов для поддержки нескольких разных приложений.

Путь клиента: от подписки до получения первого сообщения

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

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

При наличии нового уведомления срабатывает соответствующий обработчик Service Worker`a. Который отвечает за отображение полученного уведомления.

Есть 2 способа получения содержимого уведомлений:

1. Напрямую от сервиса-провайдера.
2. Через специальный API сервиса рассылок.

Когда вы нажимаете на кнопку Send у себя в аккаунте, на самом деле вы отправляете в Firebase запрос, что у вас есть сообщение для этого токена. Service Worker получает информацию об имеющемся сообщении, запрашивает контент сообщения у сервиса рассылки и отображает его подписчику.

Проблемы миграции

Главная проблема: Firebase-проект может принадлежать не вам, а сервису рассылки.  

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

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

Для переноса базы:

1. Проект всегда должен принадлежать вам!

Подробнее о том, как настроить Firebase проект >> 

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

Узнать как перенести контакты >> 

3. Подписка должна происходить через домен клиента.

Что делать, если Firebase вам не принадлежит

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

Срок жизни токена в среднем составляет 3 месяца. Часто до 50% токенов теряют актуальность в течение месяца. Причины могут быть такие:

• Отключение в настройках браузера подписки,

• Смена устройства,

• Удаление Service Worker`a и т.д. 

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

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

Если перенос прошёл успешно

Это ещё не значит, что дальше всё пойдёт как по маслу. Здесь тоже есть нюансы.

В новом сервисе рассылок вы создаете сообщение и нажимаете “Отправить”. В Firebase, который принадлежит вам, поступает сигнал о том, что у вас есть сообщение для токена. Service Worker принимает этот сигнал вторым способом, а именно - через API сервиса рассылок, то по привычке он пойдёт за контентом в предыдущий сервис рассылки. Так будет продолжаться пока не обновится скрипт.

Как же передавать контент из нового сервиса рассылок?

Вам нужно “обучить” Service Worker запрашивать контент сообщения не у старого, а у нового сервиса рассылок. Для этого существует 2 варианта:

1. Подписчик должен снова зайти на сайт компании и Service Worker обновится автоматически. При условии, что прошло более суток с момента последней проверки наличия обновлений браузера.
   Минус в том, что пользователи редко просто так заходят на сайт. Можно подписчикам отправить email-рассылку и у тех, кто перейдёт на сайт обновится Service Worker. Но опять же, это только часть подписчиков.

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

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

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

На что обратить внимание при выборе сервиса рассылок пуш-уведомлений:

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

2. Возможности для пуш. Например, есть ли возможность задать срок жизни пуша, использовать кнопки СТА, большие картинки и т.д.

3. Автоматизация. Можно ли использовать автоматизированные push, можно ли в них добавлять динамический контент. Например, запуская брошенные корзины/ просмотры/ приветственные цепочки.

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

5. Мультиканальность. Сможете ли вы использовать пуши в рамках мультиканальных и омниканальных сценариев.

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

7. Статистика. Какие показатели закладываются в статистику после отправки, как можно работать с этими данными.

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

Если нужна будет консультация по переносу базы в eSputnik или знакомство с возможностями системы - пишите нам на support@esputnik.com.

До новой встречи в нашем блоге!