Перші кроки
Дані користувача
- Огляд адаптивного email-редактора
- Cтворення оформлення для листа
- Створення синхронізованих модулів
- Налаштування адаптивності
- Налаштування Smart-елементів
- Оформлення промовкладки для Gmail
- Додавання Ролловера
- Додавання анкорних посилань
- Бібліотека модулів
- Додавання таблиці до листа
- Додавання кастомних шрифтів
- Створення кнопки СТA
- Робота з блоком "Зображення"
- Використання ШІ в email-редакторі
Омніканальність
- SDK для мобільних застосунків
- Керування ключами доступу до мобільного SDK
- Підключення мобільного застосунку
- Створення та завантаження ключа Firebase
- Створення мобільних push-повідомлень
- Налаштування аналітики доставлень та кліків
- Планування мобільних push-повідомлень
- Налаштування універсальних посилань (deeplinks & Universal links)
- Надсилання тестових повідомлень із налагодження запитів
- Налаштування віджетів для сайту
- Виклик віджета
- Налаштування геоданих для правил виклику віджетів
- Збереження даних із віджетів у поля контактів
- Захист від роздратування
- Дії після заповнення форми
- Заміна системного сценарію Double Opt-In
- Розширення для тестування форм в Google Chrome
- Створення pop-up-форм за допомогою Google Tag Manager або WordPress
- Надсилання подій з віджетів eSputnik до Google Analytics
- A/B-тестування віджетів
Автоматизація
- Подвійне підтвердження підписки
- Вітальна серія
- Вітальна серія із сегментацією за категоріями
- Запуск сценарію після імпорту контактів
- Регулярний сценарій для групи
- Вітання з днем народження
- Привʼязка сценарію до кнопки
- Використання змінних із замовлення у сценарії
- Збір відгуків про замовлення
- Реактивація клієнтів та підписників
- Відправка розсилки непрочитавшим
- Налаштування додаткових розсилок
Персоналізація
- Підстановка промокоду з файлу
- Підстановка промокоду з використанням API
- Принципи генерації промокодів за допомогою PHP/JAVA
- Підстановка промокоду за допомогою персоналізації
- Завантаження промокодів для використання в сценарії
- Генерація промокодів у сценарії
- Відправлення промокоду за допомогою передпроцесора
- HTTP-запит для передачі промокоду з повідомлення до картки контакту
Аналітика
- Звіт щодо email-розсилки
- Звіт щодо SMS-розсилки
- Звіт щодо розсилки Web Push
- Звіт щодо Viber-розсилки
- Звіт щодо розсилки Mob Push
- Звіт щодо розсилки App Inbox
- Звіт зі взаємодії з віджетами
- Звіт щодо тригерної розсилки
- Звіт щодо AMP-розсилки
- Звіт щодо мультимовної розсилки
- Налаштування передачі UTM-міток
- Візуалізація доходу
- Відстеження ефективності розсилок у Google Analytics
Мультимовність
Відстеження подій та поведінки
- Відстеження активності на сайті за допомогою Generate event
- Валідація параметрів подій
- Відстеження активності клієнтів у мобільних застосунках
- Події для запуску тригерних розсилок
- Розгалуження сценарію в залежності від параметрів події
- Підстановка даних з подій в повідомлення
- Вебхуки для відстеження активності
Товарні рекомендації
API
- Інтеграція з API — найчастіші питання
- API-ключі
- Ресурси API для додавання контактів
- Використання API-ресурсу Generate event
- Передача замовлень API-ресурсом Generate event
- Отримання рекомендацій щодо API ресурсом Contact recommendations based on web tracking
- Використання API-ресурсу Send prepared message
Зміна системи
Документи
Інтеграція
Створення 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 |
|
Firefox |
|
У більшості ситуацій достатньо буде впевнитися, що у користувача браузер 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 повідомлення у вас є можливість не тільки привітати або подякувати клієнта рідною для нього мовою, але й персоналізувати повідомлення, а також виконати процедуру сегментації. (Див. вище)
Сценарій із кількома послідовними перевірками
Приклад сценарію, в якому визначається локалізація браузера і стать клієнта, наведено нижче:
У разі, якщо вдалося визначити тільки локалізацію, передбачено відправлення уніфікованого повідомлення, призначеного для обох гендерів. Оскільки на самому початку здійснюється перевірка на відповідність українській, а потім російській та англійській мовам, то якщо жоден із шуканих параметрів не відповідає, то відправляється уніфіковане повідомлення англійською мовою.