Перші кроки
Дані користувача
- Огляд адаптивного email-редактора
- Cтворення оформлення для листа
- Створення синхронізованих модулів
- Налаштування адаптивності
- Налаштування smart-контейнерів
- Оформлення промовкладки для Gmail
- Додавання Ролловера
- Додавання анкорних посилань
- Бібліотека модулів
- Додавання таблиці до листа
- Додавання кастомних шрифтів
- Створення кнопки СТA
- Робота з блоком "Зображення"
- Робота з блоком “Таймер"
- Використання ШІ в email-редакторі
- Підтримка месенджер-протоколів поштовими клієнтами та платформами
Омніканальність
- SDK для мобільних застосунків
- Керування ключами доступу до мобільного SDK
- Підключення мобільного застосунку
- Створення та завантаження ключа Firebase
- Створення мобільних push-повідомлень
- Налаштування аналітики доставлень та кліків
- Планування мобільних push-повідомлень
- Типи діплінків
- Надсилання тестових повідомлень із налагодження запитів
- Налаштування віджетів для сайту
- Гейміфікація віджетів
- Виклик віджета
- Налаштування геоданих для правил виклику віджетів
- Збереження даних із віджетів у поля контактів
- Захист від роздратування
- Дії після заповнення форми
- Заміна системного сценарію Double Opt-In
- Створення pop-up-форм за допомогою Google Tag Manager або WordPress
- Надсилання подій з віджетів eSputnik до Google Analytics
- A/B-тестування віджетів
- Збір контактних даних за допомогою форм запитів
Автоматизація
- Налаштування та редагування сценаріїв
- Налаштування умов запуску та зупинки сценарію
- Блок “Старт”
- Група блоків “Популярні”
- Група блоків “Повідомлення”
- Використання блока повідомлень “Одне з багатьох”
- Група блоків “Контакт”
- Група блоків "Умови"
- Група блоків “Інше”
- Група блоків “Повідомлення на групу”
- Група блоків “Час”
- Розширені параметри блоків сценаріїв
- Дозволений час відправлення
- Вебхуки в сценаріях
- Відстеження історії запусків сценарію
- Якщо сценарій не працює
- Подвійне підтвердження підписки
- Вітальна серія
- Вітальна серія із сегментацією за категоріями
- Запуск сценарію після імпорту контактів
- Регулярний сценарій для групи
- Вітання з днем народження
- Привʼязка сценарію до кнопки
- Використання змінних із замовлення у сценарії
- Збір відгуків про замовлення
- Реактивація клієнтів та підписників
- Відправка розсилки непрочитавшим
- Налаштування додаткових розсилок
- Відправлення нагадувань в заданий користувачем час
- А/B-тестування в сценаріях
Персоналізація
- Підстановка промокоду з файлу
- Підстановка промокоду з використанням API
- Принципи генерації промокодів за допомогою PHP/JAVA
- Підстановка промокоду за допомогою персоналізації
- Завантаження промокодів для використання в сценарії
- Генерація промокодів у сценарії
- Відправлення промокоду за допомогою передпроцесора
- HTTP-запит для передачі промокоду з повідомлення до картки контакту
Аналітика
- Звіт щодо email-розсилки
- Звіт щодо SMS-розсилки
- Звіт щодо розсилки Web Push
- Звіт щодо Viber-розсилки
- Звіт щодо розсилки Mob Push
- Звіт щодо розсилки App Inbox
- Звіт щодо Telegram-розсилки
- Звіт зі взаємодії з In-App
- Звіт зі взаємодії з віджетами
- Звіт щодо тригерної розсилки
- Звіт щодо AMP-розсилки
- Звіт щодо мультимовної розсилки
- Налаштування передачі UTM-міток
- Візуалізація доходу
- Відстеження ефективності кампаній у Google Analytics 4
- Статистика повідомлень
Мультимовність
Відстеження подій та поведінки
- Події для запуску тригерних розсилок
- Найменування користувацьких подій
- Валідація параметрів подій
- Відстеження активності на сайті за допомогою Generate event
- Підстановка даних з подій в повідомлення
- Розгалуження сценарію в залежності від параметрів події
- Відстеження активності клієнтів у мобільних застосунках
- Вебхуки для відстеження активності
- Аналітика подій
Товарні рекомендації
API
- Поширені питання: Інтеграція з API
- API-ключі
- Ресурси API для додавання контактів
- Використання API-ресурсу Generate event
- Передача замовлень API-ресурсом Generate event
- Отримання рекомендацій щодо API ресурсом Contact recommendations based on web tracking
- Використання API-ресурсу Send prepared message
Зміна системи
Документи
Інтеграція
Група блоків "Умови"
Блоки в групі “Умови” (крім блоку “Розбити”) перевіряють виконання контактом тієї чи іншої умови й розділяють сценарій на дві гілки (“Так” або “Ні”), однією з яких він перебігатиме залежно від відповіді.
До групи входить вісім блоків:
-
Умова
-
Розбити
-
Відправлено?
-
Доставлено?
-
Прочитав?
-
Перейшов?
-
Входить до групи?
-
Поточний день/час
Важливо
До блоку “Старт” не можна приєднувати блоки:
- Відправлено?
- Доставлено?
- Прочитав?
- Перейшов?
Умова
Розбити
Блок використовується для спліт-тестування повідомлень. Розбиває сценарій на дві гілки та довільно розділяє контакти між ними. За замовчуванням імовірність спрацьовування кожної гілки становить 50/50. Ви можете змінити це співвідношення, перетягнувши регулятор у налаштуваннях блоку вліво або вправо.
Наприклад, ви можете створити сценарій для тестування ефективності каналів комунікації або двох варіантів повідомлення в одному каналі, встановивши для них однаковий відсоток спрацьовування.
На рисунку вище показано сценарій для тестування каналів “Email” та “SMS”. Виходячи з цієї схеми, одна половина ваших підписників отримає email-повідомлення, а інша — sms-повідомлення. Подальший аналіз статистики за розсилками для цих каналів дозволить визначити, який із них спрацював краще.
Відправлено?
Блок “Відправлено?” використовується для того, щоб перевірити факт надсилання повідомлення або ланцюжка повідомлень, розміщених у сценарії перед цим блоком.
У прикладі вище — сценарій, в якому першим відправляється мобільний пуш з експериментальним алгоритмом рекомендацій. Якщо даних для формування таких рекомендацій немає, повідомлення не надсилається.
При цьому у мобільних пушів крім статусу “Доставлено” існує статус “В процесі”. Тобто між відправкою та доставкою може пройти досить тривалий час, тому перевірка “Доставлено” в цьому випадку не підходить.
Якщо в результаті перевірки виявиться, що перший пуш не було відправлено, сценарій надішле другий з універсальним алгоритмом рекомендацій.
Блок “Таймер” необхідний, щоб система встигла перевірити факт відправлення повідомлення. Рекомендований час у налаштуваннях таймера – 2 хвилини.
Доставлено?
Завдання даного блоку — перевірити, чи доставлене користувачеві повідомлення, і залежно від цього скоригувати подальший перебіг сценарію.
Тим, хто отримав ваше повідомлення, через день буде відправлено другий email, а решту підписників буде поміщено в групу “Невалідні email”. Таким чином, використання цього блоку допоможе вам визначити доцільність використання email як каналу комунікації та зменшити відсоток помилок при здійсненні подальших розсилок.
Прочитав?
Цей блок перевіряє, чи прочитав користувач повідомлення, і залежно від результату (Так/Ні) розділяє сценарій на дві гілки. Якщо, наприклад, користувач не прочитав ваш email протягом певного проміжку часу, ви можете протестувати іншу тему повідомлення, дослати Viber-повідомлення (див. скрін нижче) або SMS-повідомлення такого самого змісту. Це підвищить ваші шанси на отримання бажаного результату.
Перейшов?
За допомогою цього блоку ви можете перевірити, чи переходив користувач за посиланням з повідомлення, і задати альтернативні дії виходячи з результатів перевірки. Блок ураховує перехід за будь-яким посиланням у вашому повідомленні, окрім посилання на сторінку відписки. При цьому пам'ятайте, що ви не можете вибрати для перевірки якесь конкретне посилання.
На скріні показано приклад сценарію, де використана перевірка в такий спосіб. Тим, хто перейшов за посиланням, тобто потенційно зацікавився вашою пропозицією, відправляється наступний лист, у якому пропонується спеціальна знижка, або детальніше розкриваються переваги презентованого товару чи бренду. Для тих, хто не перейшов за посиланням у листі, сценарій завершується. Можливо, знадобляться інші аргументи або додаткові інструменти для роботи з цією групою.
Примітка
Блоки “Відправлено?”, “Доставлено?”, “Прочитав?”, “Перейшов?” перевіряють повідомлення в рамках одного сценарію та не враховують, чи була виконана аналогічна дія з повідомленням в рамках іншого сценарію.
Блоки “Відправлено?”, “Доставлено?”, “Прочитав?”, “Перейшов?” мають два альтернативні параметри, що враховують:
- Тільки останнє повідомлення. У цьому випадку перевіряється лише останнє повідомлення перед блоком. Якщо повідомлення відправлено (доставлено, прочитано, контакт перейшов за посиланням) сценарій продовжується одним шляхом, а якщо ні – іншим.
- Всі повідомлення. Перевіряються всі повідомлення у сценарії перед блоком. Якщо відправлені (доставлені, прочитані, контакт перейшов за посиланнями) всі повідомлення, сценарій продовжується по одній гілці, якщо відправлені не всі або жодного – по іншій.
Важливо
Перед блоками “Відправлено?”, “Доставлено?”, “Прочитав?” і “Перейшов?” рекомендовано додаткове використання блоку “Таймер”. Якщо цього не зробити, високою є ймовірність, що для більшості ваших підписників сценарій буде запущено гілкою “Ні”.
Це пов'язано з тим, що система миттєво перевіряє виконання умови, а оскільки користувач не в змозі миттєво відреагувати на вашу розсилку, достовірні дані для запуску гілкою “Так” відсутні.
Входить до групи?
Завдання цього блоку — визначити, входять ваші підписники до певної групи чи ні. Залежно від результатів ви можете продовжити сценарій одним або іншим шляхом.
Блок має один базовий (обов'язковий до налаштування) параметр – “Група”. У полі виберіть групу для перевірки входження контакту в цю групу.
У прикладі вище якщо підписники входять до групи “Валідні Email”, їм відправляється повідомлення на електронну пошту, якщо ж ні, — SMS.
Також блок має розширені параметри, які детально розглянуті в окремій статті.
Поточний день/час
Блок допомагає перевірити, чи відповідає момент спрацьовування поточної гілки сценарію певній даті, дню тижня або часу доби. Залежно від цього коригується подальший перебіг сценарію.
Умовами для розсилки ви можете вибрати один із таких параметрів:
-
у певні дні тижня (Пн-Нд);
-
у певну дату;
-
у певний час;
-
у певний час певної дати/дня тижня.
Встановлення певної дати виключає можливість вибору дня тижня. Задати значення дати або дня тижня та часу можна як разом, так і окремо. За замовчуванням опція перевірки часу неактивна.
Якщо час вибрано без вказівки дня, то заданий період часу перевірятиметься щодня.
Якщо вибрано день і час, час перевірятиметься у вказаний день.
Час перевіряється згідно з часовим поясом контакту. Це виключає неточності, пов'язані з переведенням годинника на зимовий/літній час.
Задані граничні значення потрапляють у перевірку. Якщо встановлено час 08:00 – 12:00 і на момент перевірки буде 12:00, то сценарій піде гілкою “Так”.
Активація опції “Використовувати часовий пояс контакту” дозволить вам відправляти повідомлення в певний час, враховуючи часовий пояс контакту.
Розглянемо роботу блоку. Наприклад, 05 квітня 2023 року о 19:00 у вас проходить вебінар, зареєструватися на який можна до самого початку трансляції. Ви бажаєте, щоб залежно від поточної дати та часу були відправлені різні версії email-повідомлень:
-
Email 1. За день до проведення заходу – “Чекаємо на вебінарі 5 квітня о 19:00”;
-
Email 2. У день проведення до 17:00 – “Вже сьогодні! До зустрічі о 19:00”;
-
Email 3. У день проведення після 17:00 – Старт зовсім скоро! Не пропустіть початок о 19:00”.
Хід сценарію з такими умовами буде наступним:
-
сценарій дійде до блоку “Поточний день/час” і перевірить, яка сьогодні дата (чи зараз 05.04.2023?);
-
якщо дата не відповідає вказаній у параметрі, сценарій піде гілкою “Ні” – відправиться Email 1;
-
якщо сьогодні 05.04.2023, сценарій піде гілкою “Так” та перевірить час доби;
-
якщо зараз не пізніше 17:00, відправиться Email 2;
-
якщо поточний час не відповідає заданому - отже, зараз пізніше, ніж 17:00, і в такому випадку відправиться Email 3.
Окрім цього, використовуючи ці ж самі умови, ви аналогічним чином можете не відправляти вашу розсилку:
-
В певні дні.
-
В певний час.
-
В певний час певних днів.
-
В певний час певного дня.