Створення Welcome-серии для web push

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

Створення привітальної серії для пуш-повідомлень

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

Крок 1. Створення повідомлення

1. Перейдіть до розділу “Повідомлення” → “Повідомлення” → ”Web Push”. Натисніть кнопку “Новий Web Push”.

2. Готуємо повідомлення, як показано в прикладі.

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

3. За потреби відправляємо собі тестове повідомлення, щоб упевнитися в коректності відображення.

4. Зберігаємо повідомлення кнопкою «Зберегти і вийти» і переходимо до підготовки сценарію для запуску привітальної серії.

Зберегти і вийти з редактора веб-пуш повідомлення

Крок 2. Створення сценарію для запуску привітальної серії

1. Перейдіть до розділу “Тригери” → Сценарії”. Натисніть кнопку “Новий Сценарій”.

Найпростіший сценарій, в якому після підписки на web-push повідомлення користувачеві буде надіслано повідомлення про успішну підписку, матиме такий вигляд:

Обов'язковими блоками будь-якого сценарію є блоки початок та кінець; ми додаємо їх, а між ними – блок push. Для блоку пуш у випадаючому списку вибираємо повідомлення, яке буде відправлене клієнтові після здійснення підписки. Після чого послідовно з'єднуємо блоки між собою.

2. Зберігаємо сценарій і переходимо до фінального налаштування – вибору умови запуску.

3. При здійсненні клієнтом підписки на web-push повідомлення до вашого акаунта надходить подія newWebpushSubscription, яку можна знайти в розділі Тригери – Історія подій.

Конкретно ця подія і має запускати підготовлений сценарій.

4. Відкриваємо вікно умов запуску сценарію і вибираємо подію newWebpushSubscription

5. Застосовуємо налаштування і запускаємо сценарій.

Запустивши сценарій, ви здійсните обробку подій про підписку на web-push повідомлення в найпростіший спосіб.

Розділення привітальної серії за мовою користувача

Розглянемо уважніше, які ще дані передаються до події newWebpushSubscription, крім push-токена:

• pushToken – токен користувача

• os – операційна система

• userAgent – браузер, який використовується

• userAgentVersion – версія браузера

• userAgentLang – локалізація браузера (мова користувача)

• ip – адреса, з якої здійснено підписку

• subscriptionPage – сторінка, на якій здійснено підписку

• appUid – ідентифікатор додатка (службове поле)

• contactId – ідентифікатор створюваного контакту

Ці дані певним чином дозволяють нам проаналізувати передані параметри і персоналізувати повідомлення.

Перш за все визначимося, якою мовою ми будемо комунікувати з користувачем. Нам знадобиться блок сценарію «Умова – змінна відповідає регулярному виразу» (цей блок треба буде додати до створюваного або оновлюваного сценарію), а також параметр userAgentLang.

Визначення локалізації здійснюється таким чином:

Оскільки велике зображення і кнопки в повідомленні підтримуються тільки браузером Chrome та його похідними, то можна відправити актуальне повідомлення, здійснивши перевірку параметра userAgent.

Перевірка здійснюється також блоком «Умова – змінна відповідає регулярному виразу» і набуває такого вигляду:

У більшості ситуацій достатньо буде впевнитися, що у користувача браузер Chrome. В іншому випадку сценарій піде гілкою «ні». Тож надалі можна буде використовувати повідомлення без великого банера, але натомість із текстовим контентом, для користувачів браузерів, відмінних від Chrome, які не підтримують великий банер та кнопки.

І останній пункт, але не менш важливий, ніж попередні – у параметрі subscriptionPage передається адреса сторінки, на якій здійснено підписку на web-push повідомлення. Це дозволяє нам робити висновки щодо сфери інтересів користувача і надає можливість розпочати діалог на актуальну тему.

Збирання підписників із кількох сайтів

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

Для цього треба підготувати кілька повідомлень; припустимо, підписники збираються з трьох різних ресурсів, тоді сценарій набуває такого вигляду:

У цьому сценарії перевірка також здійснюється блоком «Умова – змінна відповідає регулярному виразу»; так у першому блоці робиться перевірка належності підписника за полем subscriptionPage на предмет збігу фрагмента адреси сайту, де здійснена підписка (site_number_one), і в другому – site_number_two (не зовсім прозоро викладено думку в цьому абзаці)

Пошук фрагмента за частковим збігом у посиланні здійснюється записом шуканого рядка, взятого в «.*», наприклад, – .*site_number_one.* або .*site_number_two.*.

Сегментація

Після здійснення користувачем підписки його токен додається до розділу, де зберігаються всі токени, зібрані з одного домену. В межах одного акаунта можна здійснювати збирання підписників із кількох доменів та піддоменів. Але це не єдиний спосіб здійснювати фрагментацію токенів.

З огляду на те, що у події newWebpushSubscription передається такий параметр, як contactId, який у межах сценарію можна використовувати як ідентифікатор для додавання web-push токена до заздалегідь створеної групи. (незавершена думка)

Для цього в сценарій достатньо додати блок «Додати до групи».

Вибрати групу, а в поле ID контакту вказати змінну ${contactId}.

Таким чином, пізніше на етапі формування пуш-розсилки буде доступною можливість запланувати масове відправлення повідомлень не тільки за web-push контактами всього домену, але також окремим групам, сформованим за допомогою сценарію, як це відбувається під час планування email, viber або sms розсилки.

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

Приклад налаштування привітання

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

Цей спосіб придатний для ресурсів, де в посиланні можна однозначно ідентифікувати розділ, в якому здійснено підписку.

Сторінка, на яку підписався чоловік:

«https://example.com/men/verkhniaia-odezhda/palto/palto-muzhskoe-krutoe»

Сторінка, на яку підписалася жінка:

«https://example.com/women/platya/midi/plate-pod-zamsh»

Чи звернули ви увагу, що після адреси example.com йде ідентифікація статі men та women?

Скористаємося тим самим блоком «Умова – змінна відповідає регулярному виразу» і з'ясуємо стать клієнта:

Аналогічно в цьому самому посиланні можна визначити і категорію товару, яка зацікавила людину. Верхній одяг:

«.../men/verkhniaia-odezhda/...» зацікавив чоловіка, а сукні: «.../women/platya/...» – жінку.

Для цього послідовно додається ще один блок «змінна відповідає регулярному виразу», в полі name також вказуємо subscriptionPage, але в полі pattern вже зазначаємо «.*verkhniaia-odezhda.*» або «.**platya.*»

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

За необхідності після кожної такої перевірки контакт можна помістити до певної групи, додавши відповідний блок сценарію.

Таким чином, завдяки лише трьом параметрам у події про підписку на web-push повідомлення у вас є можливість не тільки привітати або подякувати клієнта рідною для нього мовою, але й персоналізувати повідомлення, а також виконати процедуру сегментації. (Повтор, див. вище)

Сценарій із кількома послідовними перевірками

Приклад сценарію, в якому визначається локалізація браузера і стать клієнта, наведено нижче:

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