Прості сценарії

Запланований сценарійЗавершена покупкаКинута корзина

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

Для запланованих одноразових відправок ми можемо скористатись Запланованим Тригером (Schedule Trigger).

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

Note

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

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

Після налаштування умов сценарію (запланований тригер) та вибору шаблону, ми можемо приступати до запуску сценарію. Для цього потрібно натиснути кнопку “Зберегти” у правій верхній частині екрану, та перевести повзунок Статус сценарію у праве положення (повзунок буде позначений зеленим кольором із написом “Активний”).

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

У цьому випадку розберемо сценарій, який реагує на успішне оформлення замовлення, і відправляє клієнту повідомлення про це. Даний сценарій виглядає наступним чином:

Логіка сценарію складається із:

1. Trigger Event (тригер що прив'язаний до певної події, для прикладу оформлення замовлення, додавання товару у кошик, або звичайний перегляд товару).

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

3. Каналу комунікації. У нашому випадку повідомлення про успішну купівлю буде надходити на email, який є обов'язковим при здійсненні купівлі, тому клієнт гарантовано отримує повідомлення.

Як виглядають налаштування даного сценарію:

• Назва події: order_item_ivent - тобто наш тригер буде реагувати на подію, що повязана із товаром.

• Назва атрибуту події: order_status - перевірка на якому етапі знаходиться замовлення.

• Значення для порівняння і його оператор: completed - завершене замовлення на всіх його етапах (створення замовлення, заповнення даних, оплата). EQUAL - це перевірка значення completed (шукаємо конкретно completed (завершене) замовлення).

Якщо простими словами, то логіка даного тригеру наступна: якщо у нас є подія по одному з товарів (order_item_event), яка знаходиться на статусі (order_status) успішного завершення (completed), тоді запускається наступний ланцюжок у сценарії.

Тригер очікування: у нашому випадку було вирішено, що краще повідомити про успішну покупку клієнту на електронну пошту через 5 хвилин після здійснення замовлення.

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

• Email одержувача: пусте поле, адже система автоматично підставить пошту клієнта, для якого спрацює цей сценарій.

Note

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

• Налаштування частоти комунікації: в даному полі вибираємо один із раніше налаштованих (або стандартних) частот комунікації.

• Максимальна к-сть відправок клієнту та Впродовж: зазвичай дані значення підставляються як і обраній частоті комунікації у “Налаштування частоти комунікації”. Дані поля були впроваджені для того, щоб у разі тестування (коли ми хочемо відправити собі 5-10-15 тестових листів), не змінювати ці значення у основній частоті комунікації, і потім не змінювати їх ще раз, коли будемо відправляти лист клієнту.

Note

Налаштування Максимальна к-сть відправок клієнту та Впродовж мають значення лише в тому випадку, коли вони відрізняються від загальної частоти зв'язку, тому, як згадувалося раніше, ці поля ідеально підходять для тестування.

• Мінімальний час відправлення та Максимальний час відправлення - обмеження по локальному часі, в період якого буде відправлена комунікація.

Після налаштування сценарію та вибору шаблону, ми можемо приступати до запуску сценарію. Для цього потрібно натиснути кнопку “Зберегти” у правій верхній частині екрану, та перевести повзунок Статус сценарію у праве положення (повзунок буде позначений зеленим кольором із написом “Активний”).

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

Розберемо цей сценарій більш детально:

• Тригер який реагує на додавання будь-якого товару у корзину.

Назва події: “mobile_app_event” - тригер буде реагувати на подію, що відбулась у мобільному застосунку.

Назва атрибту події: “action - add” - у даному випадку додавання у корзину перевіряється за подією “action” потрапляння товару в корзину “add”

• Таймер очікування у 30 хв, щоб не сповіщати клієнта про незавершену покупку одразу ж після додавання товару у корзину.

• Condition split - перевірка на те, чи не була завершена покупка і додаткові дії з корзиною (для прикладу видалення товару з корзини).

Перевірку робимо по вкладці “Клієнту”, тобто подія для кожного індивідуального клієнта.

Назва події: “mobile_app_event” - подія у мобільному застосумку. “З моменту запуску сценарію” - реагує на момент першого тригеру додавання користувачем товару у корзину.

Назва атрибуту події та значення для порівняння - атрибут “action” у нашому випадку відповідає за будь-які дії повязані з корзиною. Значення для порівняння “remove” “purchase” i “add” відповідають за видалення з корзини (remove), завершення покупки (purchase) i додавання ще одного товару (add).

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

• Коли ми отримуємо результат “кинутої корзини” який пройшов перевірку у пункті №3, то ми відправляємо клієнту пуш сповіщення у його мобільний додаток, і нагадуємо йому про товар що він раніше додав у кошик.