Перші кроки
Дані користувача
- Огляд адаптивного 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
Зміна системи
Документи
Інтеграція
Група блоків “Популярні”
Популярні — найчастіше використовувані блоки.
До групи входить п'ять блоків:
-
Кінець
-
Таймер
-
Задача
-
Умова
-
Точка перевірки
Блок “Кінець”
Рекомендуємо використовувати блок “Кінець” наприкінці сценарію та всіх його гілок. Додавання блоку допоможе візуально зрозуміти логіку сценарію та дії перед завершенням. Це особливо корисно, коли сценарій має розгалужену структуру та значну кількість інших блоків.
Блок “Таймер”
Блок “Задача”
Призначення цього блоку — вирішити одну із задач:
-
Створити контакт;
-
Оновити контакт;
-
Отримати контакт;
-
Підтвердити контакт;
-
Відправити обов'язковий (транзакційний) email;
-
Відправити транзакційне Viber повідомлення;
-
Відправити транзакційне SMS повідомлення;
-
Отримати замовлення;
-
Створити промокод;
-
Отримати промокод;
-
Запустити подію.
Вибрати потрібну задачу можна з випадаючого списку у меню праворуч.
Створити контакт
Задача використовується для створення контакту в системі. Якщо профіль з такою email-адресою вже існує, його буде оновлено. Якщо немає, буде створений новий контакт.
Важливо
Задача “Створити контакт” потрібна тільки для специфічних задач, коли дані передаються за API методом Generate event v2, і лише частину даних треба записати при створенні контакту. Наприклад, ви передали подію методом Generate event v2 для контакту, якого немає в системі. За допомогою цієї задачі ви матимете змогу створити контакт. Для всіх інших методів ця задача не потрібна.
Задача має три параметри:
-
Email — обов'язкове поле для задачі, якщо треба створити контакт за email.
-
Номер телефону — обов'язкове поле для задачі, якщо треба створити контакт за номером телефону.
-
JSON — у цьому полі прописується рядок або ставиться змінна, що містить рядок у форматі JSON, із даними для заповнення полів контакту (телефон, ім'я, прізвище, місто, додаткові поля). Якщо його не прописати, то залишиться тільки email. За необхідності зафіксувати ім'я, прізвище, дату народження тощо поле потрібно заповнити обов'язково.
В полі JSON ви можете вказати змінну contactJson. В такому випадку на REST API буде виконана валідація значень цього параметра. У разі передачі параметрів контакту з помилками в попередженні будуть вказані невалідні параметри, а також допустимі значення.
Приклад даних для поля json:
{"firstname":"...","lastname":"...","sms":"...","town":"...","profileInputs":
[{"profileInputId":10001,"value":"..."}]}
Де:
-
profileInputs — масив додаткових полів;
-
profileInputId — ID додаткового поля;
-
value — значення додаткового поля;
-
confirmed — статус email-адреси контакту (підтверджено/не підтверджено).
Важливо
Якщо ви бажаєте створити контакт непідтвердженим, до тіла запиту треба додати параметр "confirmed":false
У цьому випадку поле json матиме таку структуру:
{"firstname":"...","lastname":"...","sms":"...","town":"...","profileInputs":
[{"profileInputId":10001,"value":"..."}],"confirmed":false}
Якщо потрібно створити контакт із певним значенням поля типу “дата”, використовуйте формат такого вигляду: “YYYY-MM-DD”:
{"profileInputs": [{"profileInputId":10001,"value":"2023/11/06"}]}
Якщо потрібно створити контакт із певним значенням поля типу “дата з часом”, використовуйте формат такого вигляду: “YYYY-MM-DDThh:mm”:
{"profileInputs": [{"profileInputId":10001,"value":"2023/11/06 16:42"}]}
Оновити контакт
Задача використовується для оновлення інформації про контакт у системі, працює за принципом задачі “Створити контакт”. Єдина відмінність: якщо контакт уже є в системі, він оновиться, а якщо немає — система його не продублює, а просто пропустить.
Задача є актуальною, коли треба оновити дані контакту з події, переданої за API методом Generate event v2, або якщо в сценарії треба задавати фіксоване значення додаткового поля.
Задача має чотири параметри:
-
ID контакту – якщо ви хочете оновити контакт не по email, а за його ID в системі, необхідно прописати назву змінної або ціле число, в якій міститься ID контакту. Наприклад, ${contactId} або 123345.
-
Email – обов'язкове поле для задачі. Наприклад, ${emailAddress} або test@test.com. Якщо у вас у події інша назва змінної, необхідно вписати в поле саме цю назву. У наших системних подіях змінна зветься emailAddress. Системні події — це ті, що генеруються всередині самої системи (клік кнопки в листі, запуск регулярного сценарію за групою, форма підписки, реактивація за допомогою RFM-аналізу). Для них у поле треба вписати ${EmailAddress}.
-
Номер телефону – номер телефону контакту.
-
JSON – у цьому полі прописується рядок або ставиться змінна, що містить рядок у форматі JSON, із даними для заповнення полів контакту (телефон, ім'я, прізвище, місто, додаткові поля). Формат даних такий самий, як і для задачі “Створити контакт”, але параметр “confirmed” ігнорується.
Отримати контакт
Мета задачі — отримати дані про контакт і передати їх у лист або для блоку “Умови”. Наприклад, ми бажаємо відправляти лист з контактними даними щоразу, коли в базі з'являється новий підписник. Другий варіант — ми хочемо після реєстрації надіслати клієнтові його реєстраційні дані.
Задача працює таким чином:
-
У системі створюється (реєструється) подія, яка містить дані про контакт.
-
Задача витягує всі наявні дані щодо контакту, які зберігаються в базі.
-
Отримані дані передаються в email.
Задача має чотири параметри:
-
ID контакту — ID контакту в системі eSputnik.
-
Email — email-адреса контакту.
-
Номер телефону — номер телефону контакту.
-
Токен — мобільний токен контакту.
Параметри “ID контакту”, “Email”, “Номер телефону” та “Токен” використовуються для вибору способу ідентифікації контакту. Одне з цих полів має бути обов'язково заповнене відповідними даними.
Наприклад, якщо ви бажаєте ідентифікувати людину не за email, а за її ID в системі, ви прописуєте назву змінної, яка містить ID контакту. За замовчуванням у системі вона зветься ${contactId}.
У повідомленні можна використовувати такі змінні:
-
$!data.get ('firstName') — ім'я;
-
$!data.get ('lastName') — прізвище;
-
$!data.get ('email') — email-адреса;
-
$!data.get ('sms') — номер телефону;
-
$!data.get ('contactKey') — ключ контакту;
-
$!data.get ('id') — ID контакту в системі;
-
$!data.get ('createdDate') — дата створення;
-
$!data.get ('updatedDate') — дата останньої зміни контакту;
-
$!data.get ('confirmed') — статус email-адреси контакту (true — підтверджено, false — не підтверджено);
-
$!data.get ('fields'). get ('12345') — додаткові поля. Замість "12345" треба підставити ID додаткового поля.
Ви можете активувати прапорець “Шукати тільки ID контакту” для пошуку контакту лише за його ID.
Підтвердити контакт
Мета задачі — підтвердити email-адресу підписника і зробити його активним у системі, щоб йому надходили листи.
Наприклад: коли людина заповнює форму підписки, контакт потрапляє до eSputnik із непідтвердженим email і йому на пошту надходить повідомлення з проханням підтвердити підписку. Доки він не перейде за посиланням підтвердження, контакт не отримуватиме розсилки. Коли людина підтверджує підписку, запускається сценарій, спрацьовує задача “Підтвердити контакт” і вона стає активною в системі.
Задача має розширені параметри.
Докладніше про розширені параметри блоків сценаріїв >
Важливо
Під час пошуку контактів для задач “Створити контакт”, “Оновити контакт”, “Отримати контакт”, “Підтвердити контакт” застосовуються такі правила:
- ID контакту має найвищий пріоритет серед усіх параметрів.
- Якщо задано externalCustomerId, пошук контакту буде виконуватись за externalCustomerId.
- Якщо externalCustomerId не задано, пошук контакту буде виконуватись за email адресою або за номером телефону.
Відправити обов'язковий (транзакційний) email
Мета задачі — відправити email контактові не зважаючи на його статус у системі (підтверджений, непідтверджений, відписався, із позначкою “скаржився на спам”), окрім контактів із чорного списку.
Важливо
Використовуйте цей блок лише для найважливіших тригерних повідомлень. Задача ігнорує статус контакту, тому можливі скарги на спам, які надалі негативно позначаються на репутації відправника. Даний блок потрібен тільки для відправлення новому (ще непідтвердженому) підписникові листа з кнопкою підтвердження підписки, сповіщень про замовлення або зміну тарифного плану. В усіх інших випадках для відправлення листів використовуйте блок “Email” у групі блоків “Повідомлення” або блок “Email групі” у групі блоків “Повідомлення на групу”.
Задача має один базовий (обов'язковий для налаштування) параметр — "Повідомлення". У цьому полі виберіть заздалегідь створене повідомлення, яке буде надіслане користувачу. Також задача має розширені параметри.
Докладніше про розширені параметри блоків сценаріїв >
Відправити транзакційне Viber повідомлення
Мета задачі — відправити Viber повідомлення контактові не зважаючи на його статус у системі.
Задача має два базових параметра:
-
Повідомлення.
-
Термін активності повідомлення (TTL) — Встановіть період, після якого повідомлення не буде показано, якщо до цього воно не було доставлено користувачеві. За замовчуванням встановлено 1 день. Мінімальне значення — 2 хвилини, максимальне — 28 днів.
Крім того, задача містить розширені параметри.
Докладніше про розширені параметри блоків сценаріїв >
Відправити транзакційне SMS повідомлення
Мета задачі — відправити SMS повідомлення контактові не зважаючи на його статус у системі.
Задача має один базовий параметр, обов'язковий для налаштування, – “Повідомлення”. У цьому полі виберіть заздалегідь створене повідомлення, яке буде надіслане користувачу.
Окрім базовогу параметру, задача має розширені параметри.
Докладніше про розширені параметри блоків сценаріїв >
Отримати замовлення
Мета задачі — отримання даних із замовлення і їх передавання до листа. Наприклад, статус замовлення.
Блок застосовується лише у сценаріях, у яких події передаються API методом Add orders.
Щоб налаштувати параметри задачі “Отримати замовлення”, розгорніть список “Отримати замовлення по” і виберіть один з варіантів:
-
ID замовлення. Вибирайте цей варіант, коли хочете отримати дані замовлення за ID, який сформований нашою системою.
-
Зовнішній ID замовлення. Вибирайте цей варіант, коли хочете отримати дані замовлення за ID, який ви передаєте в нашу систему.
Не обов'язково заповнювати поле “ID замовлення/Зовнішній ID замовлення”. Задача автоматично отримує всі параметри з події.
Задача працює наступним чином:
-
Система отримує дані про замовлення.
-
Блок “Задача” отримує всі дані, які передаються із замовленням, і вставляє ці дані до повідомлення замість змінних.
Докладніше про роботу блоку “Задача” із замовленнями читайте у статті “Автоматизація роботи із замовленнями”.
Створити промокод
Мета задачі — згенерувати промокод і передати його до листа, що є наступним у ланцюжку. Параметри будуть зашифровані за вашим ключем алгоритмом, а при введенні такого промокоду на сайті його розшифрує зворотний алгоритм (детальніше).
Задача має чотири обов’язкові параметри:
-
Дні — вказується кількість днів до завершення терміну дії промокоду. Система їх додасть до поточного числа і отриману дату завершення терміну дії зашифрує в промокод. За замовчуванням у це поле ставиться параметр ${days}.
-
Тип — тип промокоду. У вас може бути 32 типи промокодів, які ви задаєте самі. Наприклад: промокод за підписку — надано type 0, до дня народження — type 1, реактивація — type 3 тощо. У змінній вказується число від 0 до 31, яке відповідає потрібному типу. За замовчуванням у це поле ставиться параметр ${type}.
-
Знижка — розмір знижки. Використовується для генерації промокоду, коли знижка надається у відсотках від суми замовлення. Це завжди двозначне число, тому знижки до 10% слід доповнити нулем попереду. Наприклад, указати 05 для підстановки до листа 5% дисконту. За замовчуванням у це поле ставиться параметр ${discount}.
-
Ключ — ключ шифрування. Можна залишити ключ, що використовується за замовчуванням. За замовчуванням у це поле ставиться параметр ${key}.
Після цього блоку в сценарії ставиться блок відправлення повідомлення (Email, SMS, Viber тощо).
У листі на місці промокоду треба використовувати змінну $!data.get ('promocode').
Отримати промокод
Задача підставляє черговий промокод з бази до листа. Детальніше про завантажувані промокоди.
Задача має три обов’язкові параметри:
-
Дні — кількість днів від поточної дати, протягом яких промокод має бути діючим;
-
Тип — заданий вами для сегментації тип промокоду;
-
Знижка — розмір знижки від 01 до 99.
Згідно з параметрами система відбиратиме промокоди із завантаженої бази. Принцип роботи розглянемо на прикладі. У параметрах зазначимо такі значення: дні — 10, тип — newyear, знижка — 25.
Це означає, що сценарій витягне з бази промокод зі знижкою 25%, якому надано тип newyear і термін дії якого є не меншим 10 днів. Якщо заданим умовам відповідають кілька промокодів, система сама вибере один із них.
Після блоку “Отримати промокод” у сценарії ставиться блок відправлення повідомлення.
У повідомленні в те місце, де має бути промокод, треба вписати змінну $!data.get ('promocode').
Запустити подію
Мета задачі — запустити якусь подію зі сценарію. Наприклад, щоб з одного сценарію ініціювати старт іншого. Для використання задачі треба заздалегідь створити тип події, яку ми плануємо запустити.
Задача має три параметри:
-
Подія — обов'язкове поле. У ньому треба вибрати тип події, що запускається.
-
Ключ унікальності — ключ події, яку ми хочемо запустити. Наприклад, тут може бути змінна, яка містить email. Якщо поле не заповнено, буде використовуватися ключ із події, яка запустила поточний сценарій.
-
Параметр — масив параметрів, які ми бажаємо передати до події, що запускається. Якщо поле не заповнено, будуть передані параметри з події, що запустила поточний сценарій.
Формат параметрів є таким:
[{"name":"paramName","value":"значення параметра"}]
Блок “Умова”
Задача блоку — перевірити, виконуються певні умови сценарію чи ні. Залежно від цього подальший перебіг сценарію розгалужується на дві окремі гілки: “Так” або “Ні”.
Блок має один вхід (блок “Старт”) і два виходи (“Кінець”): для гілки “Так” і для гілки “Ні”.
Блок “Умова” має сім задач:
-
Перевірити подію;
-
Змінна відповідає регулярному виразу;
-
Контакт підтверджений;
-
Контакт існує;
-
Перевірити параметр за датою/часом;
-
Перевірити, що поле контакту відповідає параметру події;
-
Перевірте поля списку чекбоксів.
Для вибору задачі використовуйте випадний список у меню справа.
Перевірити подію
Мета — перевірити, відбулася потрібна подія чи ні. Пошук подій здійснюється за ключами.
Умова має три параметри:
-
Ключ унікальності — ключ події, що перевіряється. Наприклад, ключами подій, що перевіряються, може бути email-адреса. Таким чином, у цьому полі необхідний параметр, що містить email-адресу. Це параметр із події, що запустила поточний сценарій. Якщо він має назву “emailAddress”, то в полі слід написати ${emailAddress}.
-
Подія — тип події, яку треба перевірити. Обов'язкове поле, без заповнення якого сценарій не працюватиме.
-
Період — у цьому полі можна задати час до старту сценарію, протягом якого потрібно враховувати подію, що сталася. За замовчуванням блок перевіряє події після активації сценарію.
Змінна відповідає регулярному виразу
Мета умови — перевірити певну змінну з події або отримані іншими блоками дані й відповідно до цього скоригувати подальший перебіг сценарію.
Наприклад, ми можемо перевірити, ким є наш користувач: чоловіком або жінкою, і надіслати їм різні повідомлення.
Умова має два параметри:
-
Назва — назва змінної, яку треба перевірити. Це може бути параметр із події. Якщо ж ми перевіряємо дані, отримані іншими блоками сценарію (наприклад, блок “Отримати контакт”), то слід вписати в поле системну змінну smartMessageJson.
-
Патерн — регулярний вираз, на відповідність якому ми перевіряємо дані. Наприклад: ми бажаємо перевірити, що параметр address із події містить текст “Київ”. У цьому випадку в полі “Патерн” прописуємо Київ.
Приклад роботи та повного налаштування такого блоку.
Контакт підтверджений
Мета умови — перевірити, чи підтверджений email контакту, і залежно від цього скоригувати подальший перебіг сценарію.
Наприклад, людина зареєструвалася на сайті або підписалася на вашу розсилку. Ви бажаєте надіслати їй привітальний лист.
У цьому випадку:
-
Контакт з'являється в базі eSputnik, але має статус непідтвердженого.
-
Людині відправляється лист із проханням підтвердити реєстрацію.
-
Умова перевіряє, підтвердила людина реєстрацію чи ні.
-
Якщо підтвердила, сценарій має перебіг за гілкою “Так” і відправляється привітальний лист.
-
Якщо ще не підтвердила реєстрацію, сценарій перебігає за гілкою “Ні”.
Умова має два параметри:
-
Email — email-адреса контакту.
-
ID контакту — ID контакту в системі.
За замовчуванням система перевіряє, підтверджений контакт чи ні, за email. У полі “Email” необхідно прописати назву змінної або email-адресу. Наприклад, ${emailAddress} або test@test.com.
Якщо ви бажаєте, щоб ідентифікація здійснювалася за ID контакту, треба в поле “ID контакту” вписати змінну ${contactId}.
Для умови “Контакт підтверджений” у будь-якому випадку має бути вказаний один із параметрів.
Контакт існує
Мета умови — перевірити, існує контакт чи ні, і відповідно до цього скоригувати подальший перебіг сценарію. Працює аналогічно умові “Контакт підтверджений”.
У цієї умови є три параметри:
-
Email — email-адреса контакту.
-
Номер телефону — номер телефону контакту
-
ID контакту — ID контакту в системі.
За замовчуванням система перевіряє, існує контакт чи ні, за email. Якщо ви бажаєте, щоб ідентифікація здійснювалася за ID контакту, треба в поле “ID контакту” вписати змінну ${contactId}. Для ідентифікації контакту за номером телефону вкажіть у полі “Номер телефону” зміну ${phoneNumber}.
Перевірити параметр за датою/часом
Мета умови — перевірити дату з параметра події.
При створенні сценарію враховується часовий пояс користувача, час буде збережено в UTC.
Наприклад, перевіряємо дату з часом 2020-07-30 13.00. Часовий пояс користувача - (GMT +3) Europe/Kyiv, відповідно, в подію буде передано “2020-07-30T13:00 + 03:00”.
Важливо
Звертайте увагу на часовий пояс та враховуйте перехід на зимовий/літній час.
Умова має такі параметри:
-
Параметр — Обов'язкове поле. За замовчуванням у це поле ставиться параметр ${parameter}. Значення параметра, яке передається в параметрі має бути згідно з форматом передачі дати - ISO 8601.
-
Дата — поле, де необхідно вибрати зі списку конкретну дату, дату з часом або діапазон дат з часом.
Вибір параметрів дати та/або часу
Щоб вибрати налаштування дати та/або часу:
-
Клікніть поле “Дата” та виберіть зі списку один з параметрів:
-
Дата;
-
Дата з часом;
-
Діапазон дат;
-
Діапазон часу;
-
Діапазон дат з часом;
-
Дата входить до періоду до;
-
Дата входить до періоду після;
-
Дата з часом більше посточного на.
-
Налаштуйте потрібні параметри дати й часу для вибраного параметра, як описано нижче.
Налаштування параметрів “Дата”
Коли ви вибираєте “Дата”, блок “Умова” перевіряє, чи збігається дата події з вибраною датою для цього параметра.
Натисніть на значок календаря та виберіть потрібну дату.
Корисна порада
Клікніть на стрілці, що вказує ліворуч або праворуч, щоб змінити місяць, або кликніть на назву місяця з роком, щоб перейти до вибору місяця чи року.
Налаштування параметрів “Дата з часом”
Коли ви вибираєте “Дата з часом”, блок “Умова” перевіряє, чи збігається дата події з вибраними датою та часом для цього параметра.
Щоб вибрати дату з часом:
-
Клікніть на значок календаря та виберіть потрібну дату у вікні вибору дати.
-
У вікні вибору годин та хвилин виберіть потрібні значення.
Налаштування параметрів “Діапазон дат”
Коли ви вибираєте “Діапазон дат”, блок “Умова” перевіряє, чи збігається дата події з вибраним діапазоном дат для цього параметра.
Щоб вибрати діапазон дат:
-
Кликніть дату зліва та виберіть початкову дату діапазону.
-
Кликніть дату справа та виберіть кінцеву дату діапазону.
Налаштування параметрів “Діапазону часу”
Коли ви вибираєте параметр “Діапазон часу”, блок “Умова” перевіряє, чи збігається діапазон часу події з вибраним діапазоном часу для цього параметра.
Щоб вибрати діапазон часу:
-
Клікніть час зліва та виберіть початковий час у вікні вибору часу.
-
Клікніть час справа та виберіть час завершення у вікні вибору часу.
Налаштування параметрів “Діапазон дат з часом”
Коли ви вибираєте “Діапазон дат з часом”, блок “Умова” перевіряє, чи відповідають діапазон дати й часу події вибраному діапазону дати й часу для цього параметра.
Щоб вибрати діапазон дати/часу:
-
Клікніть дату з часом зліва та виберіть початкову дату та час у вікні вибору.
-
Клікніть дату з часом справа та виберіть дату та час завершення у вікні вибору.
Налаштування параметрів “Дата входить до періоду до”
Коли ви вибираєте “Дата входить до періоду до”, блок “Умова” перевіряє, чи знаходиться дата події, отримана як параметр, в діапазоні дат до вибраної дати.
Щоб вибрати параметри для “Дата входить до періоду до”, клікніть на піктограмі календаря поруч із полем дати та оберіть дату.
Налаштування параметрів “Дата входить до періоду після”
Коли ви вибираєте “Дата входить до періоду після”, блок “Умова” перевіряє, чи знаходиться дата події, отримана як параметр, в діапазоні дат після вибраної дати.
Щоб вибрати параметри для “Дата входить до періоду після”, клікніть на піктограмі календаря поруч із полем дати та оберіть дату.
Важливо
Обрана дата для параметрів “Дата входить до періоду до”, “Дата входить до періоду після” не враховується в періоді.
Налаштування параметра “Дата з часом більше поточного на”
Коли ви вибираєте “Дата з часом більше поточного на”, блок “Умова” перевіряє, чи дата та час події, отримані як параметр, перевищують поточну дату та час на N хвилин/годин/днів.
Приклад:
Ви організуєте вебінар з датою та часом початку 2022-10-10 16:00.
Ви налаштували відправлення 3 повідомлень зареєстрованим учасникам: за 30, 10 і 5 хвилин до початку вебінару.
Дата та час реєстрації учасника - 2022-10-10 15:52 (поточна дата та час).
Блок “Умова” порівнює поточний час з часом із параметра події. В результаті порівняння:
-
Відправлення першого повідомлення скасовується, оскільки умова відправлення повідомлення (за 30 хв) не виконується.
-
Відправлення другого повідомлення скасовується, оскільки умова відправлення повідомлення (за 10 хв) не виконується.
-
Третє повідомлення буде відправлено згідно з розкладом, оскільки умова відправлення повідомлення (за 5 хв) виконується.
Щоб налаштувати умову “Дата та час більше поточного на”, введіть значення в поле дати/часу і виберіть його формат зі списку: хвилини, години або дні.
Перевірити, що поле контакту відповідає параметру події
Умова дозволяє перевірити відповідність поля контакту переданому значенню параметра події. Наприклад, ви хочете перевірити, чи місто підписника відповідає значенню міста, переданому в події. Якщо ні, можна далі встановити блок оновлення контакту.
Умова має два базових параметра:
-
Поле контакта — поле із картки контакту, відповідність якого потрібно перевірити. Можна вибрати зі списку або за допомогою пошуку в рядку. Порівнювати можна поля таких типів: текстове поле, текстова область, число, дробове число, випадаючий список.
-
Параметр — параметр події, на відповідність до якого перевіряємо поле контакту. Значення можна вказати як змінну ${parameter} (назва параметра у події, наприклад ${city}) – у цьому випадку порівнюється поле контакту, вказане у “Полі контакту”, зі значенням із зазначеного параметра у події. Також можна задати рядок у форматі 123abc (наприклад, Київ) – тоді відбувається порівняння поля контакту з конкретним значенням, вказаним у параметрі (тобто, чи дорівнює поле контакту 123abc?).
Також умова має розширені параматри.
Докладніше про розширені параметри блоків сценаріїв >
Якщо при порівнянні операція має бути чутливою до регістру, встановіть відповідний прапорець під цим полем.
Перевірте поля списку чекбоксів
Мета умови — перевірити наявність порожніх чи конкретних чекбоксів у картці контакту.
У списку чекбоксів відображаються чекбокси, створені у розділі “Додаткові поля”.
Доступні такі опції перевірки:
- Перевірити наявність порожніх полів в списку чекбоксів
- Перевірити наявність конкретних полів списку чекбоксів
- Перевірити наявність одного з конкретних полів списку чекбоксів
Блок “Точка перевірки”
Якщо у вас складний сценарій з розгалуженнями, ви можете розмістити цей блок у будь-якому місці та потім переглянути в історії запусків сценарію, чи пройшов він визначеним шляхом. Крім того, блок "Точка перевірки" підходить для зведення кількох гілок в одну. Не всі блоки дозволяють підключати до себе кілька гілок, але цей блок вирішує таку задачу
Назва — єдиний параметр блоку.