Комплексні сценарії

Кинута корзинаДень народження

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

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

• Event attribute name - e.commerce.action - відстежує події з корзиною.
• Compersion value - add - відповідає за додавання товару у корзину.

Після цього у нас є очікування (у 90 хвилин на верхній гілці, і 15 хвилин на нижній гілці), щоб не турбувати клієнта одразу ж в момент коли він лише додав товар в корзину.

Після очікування робимо перевірку Conditional Split на те, чи були ще якісь події на сайті, або ж покупка товару. Ця перевірка відбувається по двох умова website_event та order_item_event і виглядають вони наступним чином:

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

Оскільки у нас плануються ще додаткові канали комунікації (viber та email), то дане Web Push сповіщення має обмеження на лише 1 показ один раз на 8 днів, щоб не турбувати надмірними сповіщеннями.

Верхня гілка має 2 Condition Split перевірки, у першій перевіряється додаткові дії та купівля (приклад налаштувань було представлено вище), а інша перевірка на наявність вказаної електронної адреси, адже саме в залежності від цього залежить наш наступний канал звязку:

Якщо у конкретного клієнта (Client вкладка) наявний атрибут email_cleaned, то ми відправляємо повідомлення на електронну пошту. Якщо ж атрибуту email_cleaned немає, це означає, що клієнт свою пошту не вказував, і відповідно ми відправляємо йому повідомлення у Viber.

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

У цьому прикладі ми розібрали більш складніший варіант сценарію, у якому використовуються декілька каналів зв'язку (web push, viber, email) а також декілька напрямків подій, що залежать від наявності вказаної електронної адреси тощо.

Розглянемо варіант сценарію, в якому тригер реагує на День Народження клієнта, спрацьовує завчасно (за 7 днів) і повідомляє клієнту у 2 різних канали комунікації (viber та email), що в честь дня народження клієнт може скористатись знижкою при купівлі товару. Сценарій виглядає наступним чином:

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

Налаштування SQL запиту виглядають так:

У SQL запиті - ми додаємо тригеру необхідну нам логіку, а в налаштуваннях спрацювання (колонка з права), ми встановлюємо, що тригер буде спрацьовувати кожного дня тижня об 13:00 за місцевим часом.

Після виявлення клієнта із днем народженням, за 7 днів до настання ми відправляємо клієнту сповіщення про знижку у Viber та Email.

Після відправки Viber комунікації, логіка даної гілки завершується, але після відправки Email комунікації, у нас є ще додаткове, очікування, перевірки на здійснення покупки, і повторні нагадування клієнту про знижку.

Після відправлення першої Email комунікації у нас є очікування у 4320 хвилини (72 години, або ж 3 дні), після чого запускається перевірки на те, чи зробив даний клієнт покупку за цей час. Перевірка (Conditional Split) виглядає наступним чином:

Логіка перевірки наступна:

• Для кожного клієнта індивідуально (вкладка Client) ми перевіряємо подію оформлення замовлення order_item_event

• Завершене замовлення на всіх етапах (заповнення даних, успішна оплата) ми можемо відслідкувати через атрибут order_status і безпосередньо статус “completed”, що означає повністю завершене замовлення.

• Через оператор порівняння “>= 1” ми перевіряємо чи було хоча би одне (або більше) успішне замовлення і якщо так - то сценарій на цьому завершується і клієнт скористався знижкою. Але якщо такого замовлення не було, то клієнту відправляється наступна Email комунікація із нагадуванням про знижку.

Після другої комунікації логіка повторюється, і у нас знову спрацьовує таймер очікування у 4320 хв (72 год або ж 3 дні), ще одна перевірка з аналогічними налаштуваннями що перевіряє чи було у клієнта хоча би одне успішне замовлення, і якщо такого не було, клієнту відправляється остання Email комунікація.

В загальному, за 7 днів до Дня Народження ми починаємо комунікацію з клієнтом, і пропонуємо йому знижку. За цей тиждень клієнт отримує комунікації як на Viber (один раз під час спрацювання тригеру), так і на Email (три рази протягом тижня до безпосереднього Дня Народження), тому за рахунок декількох каналів комунікації клієнт точно зможе дізнатись про доступну йому знижку.