Що робити, якщо ви вирішили змінити сервіс розсилки веб-пушів, і як не помилитися з вибором нового

Якщо ви займаєтеся розсилкою веб-пушів або тільки плануєте підключити цей канал, слід остерігатися підводних каменів, які чатують на вас.

Як працює процес запуску пуш-повідомлень

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

З боку клієнта:

• Власне підписник,
• Браузер + Service Worker.

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

Дізнатися більше можна на сайті developers.google 

З боку відправника:

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

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

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

Щоб розпочати роботу з Firebase, треба створити в ньому проект. Ви можете використовувати кілька проектів для підтримки кількох різних додатків.

Шлях клієнта: від підписки до отримання першого повідомлення

У той момент, коли користувач заходить на сайт компанії, йому показують віконце з пропозицією підписатися на розсилку веб-пуш повідомлень.

Якщо відвідувач клікає кнопку підтвердження, то створюється токен. У свою чергу токен передається до сервісу розсилки, який відправляє повідомлення через відповідного провайдера.

За наявності нового повідомлення спрацьовує відповідний обробник Service Worker`a, який відповідає за відображення отриманого повідомлення.

Існують два способи отримання контенту повідомлень:

1. Безпосередньо від сервісу-провайдера.
2. Через спеціальний API сервісу розсилок.

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

Проблеми міграції

Основна проблема: Firebase-проект може належати не вам, а сервісу розсилки.

Деякі компанії реєструють усі токени на свій домен або проект, який належить тільки їм. Одного разу уклавши "шлюбний договір" із сервісом пуш-розсилки, при розірванні шлюбу все майно, а саме токени, залишає собі сервіс. І не через те, що сервіси погані, а тому що так у них технічно обумовлено.

Навіть якщо ви якимось дивом отримаєте зібрані токени, інший сервіс, на який ви бажаєте перейти, не матиме доступу до Firebase, через який раніше здійснювалася розсилка. Виходить, що зробити розсилку за цими токенами буде неможливо.

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

1. Проект завжди має належати вам!

Детальніше про те, як налаштувати Firebase проект >>

2. Має бути можливість отримання списку токенів, щоб перенести його з одного сервісу розсилок до іншого.

Дізнатися, як перенести контакти >>

3. Підписка має здійснюватися через домен клієнта.

Що робити, якщо Firebase вам не належить

Якщо ви опинилися в такій неприємній ситуації, ви можете продовжувати відправлення проморозсилок через старий сервіс, а нові токени збирати через інший.

Термін життя токена в середньому становить три місяці. До 50% токенів часто втрачають актуальність протягом місяця. Причини можуть бути такими:

• Відключення підписки в налаштуваннях браузера,

• Зміна пристрою,

• Видалення Service Worker`a та ін.

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

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

Якщо перенесення здійснено успішно

Це ще не означає, що далі все піде без перешкод. Тут теж є нюанси.

У новому сервісі розсилок ви створюєте повідомлення та натискаєте "Відправити". До Firebase, який належить вам, надходить сигнал про те, що у вас є повідомлення для токена. Service Worker приймає цей сигнал другим способом, а саме через API сервісу розсилок — отже, як зазвичай, він піде за контентом у попередній сервіс розсилки. Так триватиме, доки не оновиться скрипт.

Тож як передавати контент із нового сервісу розсилок?

Вам треба "навчити" Service Worker запитувати контент повідомлення не в старого, а в нового сервісу розсилок. Для цього є два варіанти:

1. Абонент має знову зайти на сайт компанії, і Service Worker оновиться автоматично за умови, що минуло більше доби з моменту останньої перевірки наявності оновлень браузера. Недолік у тому, що користувачі нечасто заходять на сайт просто так. Можна відправити підписникам email-розсилку, і в тих, хто перейде на сайт, оновиться Service Worker. Але знову ж таки це лише частина підписників.

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

На цей випадок у деяких сервісів розсилок є нейтральне повідомлення за замовчуванням, яке надсилається, якщо для токенів немає підготованого повідомлення, але запит надходить.

Утім краще одразу правильно побудувати комунікацію з клієнтом і перш за все вдало обрати пуш-сервіс.

На що звернути увагу при виборі сервісу розсилок пуш-повідомлень:

1. Доступ до бази. Переконайтеся, що Firebase належатиме вам, і з’ясуйте, чи є у вас доступ до всіх токенів. Якщо компанія не дає можливості використовувати ваш проект Firebase, ви не зможете вивантажити контакти і перенести їх до іншого сервісу за необхідності.

2. Можливості для пуш. Наприклад, чи є можливість призначити термін життя пуша, використовувати кнопки СТА, великі картинки тощо.

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

4. Сегментація. За якими параметрами можна налаштувати сегменти і чи можливо це взагалі зробити в межах використовуваного сервісу.

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

6. Зберігання бази. Дуже важливий нюанс — чи очищується база. Наприклад, чи виявляються неактивні токени. Погодьтеся, не дуже доцільно платити за відправлення тим контактам, які вже давно не існують.

7. Статистика. Які показники закладаються в статистику після відправлення і як можна працювати з цими даними.

Саме з цих міркувань цього року ми так суттєво доповнили й розширили можливості для відправлення push-повідомлень. Щоб наші користувачі не стикалися з вищезазначеними проблемами і не мали проблем зі зберіганням бази.

Якщо знадобиться консультація щодо перенесення бази в eSputnik або ознайомлення з можливостями системи — пишіть нам на support@esputnik.com.

До нових зустрічей у нашому блозі!