«Условие»: как работают контекстные фильтры в сценариях

В сценариях можно уточнить, по каким данным нужно сработать, с помощью фильтров в блоке 'Условие'.

В нем доступны разные сущности (контексты) в зависимости от того, что нужно проверить. Например, сценарий по снижению цены должен запускаться только при доступности продукта, а брошенная корзина — только после сессии с пополнением списка.

Контексты во всех сценарияхКонтексты во всех сценариях

Данные сущности доступны во всех сценариях.

По клиентуПо клиенту

Определяет, должен ли сценарий сработать по клиенту, который в него попал.

Используем контекст 'Клиенты'. Проверяем, что есть валидный email и подписка и не было рассылок за последние сутки.

По доступности промокода и По наличию продуктов в сегментеПо доступности промокода и По наличию продуктов в сегменте

Задают условия срабатывания вне зависимости от данных по клиенту.

Сегмент по продукту может быть любым (реалтаймовым, пересчитываемым, статическим).

Сценарий отработает, если в сегменте 'Новинки' есть хотя бы пять продуктов.

---

Пул может быть из любой кампании. Важно, чтобы он был запущен в работу.

Сценарий отработает, если в пуле 'Для акции 10%' есть хотя бы один доступный промокод.

Контексты по событиямКонтексты по событиям

События, которые запускают сценарии, имеют свои данные.
Например, если это заказ, — стоимость, купленные продукты, статус позиций и т.д.

Выбор события дает возможность фильтровать переданные в нем сущности с помощью специальных контекстов.

Рассмотрим, как с ними работать, на примере заказа и сессии.

По заказуПо заказу

Доступен в сценариях по событиям 'Новый заказ', 'Данные заказа изменены' и 'Статус заказа изменен'.

Задача: сценарий должен запускаться при доставке заказа стоимостью от 30 000.

Создаем сценарий по событию 'Статус заказа изменен' задаем условие:

Используем контекст 'Заказы'. Таким образом проверяем именно заказ, запустивший сценарий.

Отличие проверки по заказу от проверки по клиенту:

При использовании контекста 'Клиенты' задается условие, что у клиента есть нужные данные. При этом связи с событием нет:

Проверяется, что у клиента есть заказ от 30 000. Это может быть как заказ, который запустил сценарий, так и любой другой из истории. Для текущей задачи данный контекст не подходит.

По сессииПо сессии

Доступен в сценариях по событию 'Клиент покинул сайт или приложение'.

Задача: для создания брошенной корзины нужно проверить, что клиент во время сессии добавлял продукты в список.

Используем контекст 'Сессия'. Таким образом проверяем именно сессию, запустившую сценарий.

Отличие проверки по сессии от проверки по клиенту:

Задается условие, что у клиента есть в 'Корзине' продукты. При этом не обязательно, чтобы они были добавлены в данной сессии. Для текущей задачи данный контекст не подходит.

По переменным операцииПо переменным операции

Доступен в сценариях по событию ’Вызов операции’.

Логика сравнения такая же, как в мультиветках, но есть особенности по типам переменных.

• Целочисленные и десятичные числа

  Границы диапазонов включаются: «менее 3» — это 3 и меньше, «от 1 до 5» — это 1, 2, 3, 4, 5.

  Десятичные числа

  Десятичные числа должны полностью совпадать с заданным значением. При условии равно 7,77 значение 7,77221 уйдет в ветку «Нет». Контролируйте точность на стороне интеграции.

  Пример использования

  • Целочисленные. После доставки заказа операция передает в переменную nps_score оценку из NPS-опроса. В блоке условия настроены три ветки:

    • 3 и менее → письмо с извинением и просьбой поделиться, что пошло не так;
    • В диапазоне от 5 до 8 → письмо «Спасибо за оценку, будем стараться лучше»;
    • В диапазоне от 9 до 10 → письмо «Спасибо за высокую оценку, ценим и любим».

  • Десятичные. Клиент оформил заказ. Операция передает в переменную order_amount сумму покупки. В блоке условия настроены три ветки:

    • В диапазоне от 1000.00 до 4999.99 → письмо с подборкой сопутствующих товаров и промокодом;
    • Более 5000.00 → письмо с благодарностью и повышенным кешбэком на следующую покупку.

• Дата / Дата и время UTC

  Значения типа «Дата и время UTC» хранятся в формате UTC и при сравнении переводятся в часовой пояс проекта.

  • «В диапазоне» — правая и левая границы включаются. Например, при условии «наступит через 3–7 дней» клиент с датой ровно через 3 или ровно через 7 дней попадет в ветку «Да».
  • «Более N» / «Менее N» — граница не включаются. Например, при условии «наступит более чем через 3 дня» клиент с датой ровно через 3 дня попадет в ветку «Нет».
  • «Сегодня» срабатывает при совпадении с текущим календарным днем в часовом поясе проекта.
  Пример использования

  Дата и время UTC. Курьер опаздывает с доставкой. Операция передает в переменную arrival_time ожидаемое время прибытия курьера. В блоке условия настроены три ветки:

  • Наступит через 15–30 минут → письмо с извинением, компенсация не предусмотрена;
  • Наступит через 31–60 минут → письмо со скидкой 10% на следующий заказ;
  • Наступит более чем через 1 час → письмо с промокодом на 1000 рублей.

• Строковый и Перечисление

  Сравниваются на точное совпадение значения.

  Пример использования

  Открывается новый пункт выдачи заказов. Операция передает в переменную city_district город и район. В блоке условия настроены две ветки:

  • Значение равно «СПб Выборгский район» → письмо с подборкой новых точек выдачи в Выборгском районе;
  • Значение равно «Омск» → письмо с подборкой новых точек выдачи в Омске и т.д.

• Логический

  Принимают «Да» или «Нет».

  Пример использования

  Клиент оформляет подписку. Операция передает в переменную is_premium признак премиум-подписки. В блоке условия настроены две ветки:

  • Значение равно «Да» → письмо с приветствием и описанием премиум-возможностей.
  • Значение равно «Нет» → письмо с предложением перейти на премиум со скидкой.

Другие сущностиДругие сущности

По тому же принципу работают и остальные контексты.

Фильтры и события, в которых они доступны:

• по сессии (Клиент покинул сайт или приложение)
• по заказу (Новый заказ, Данные заказа изменены, Статус заказа изменен)
• по позиции заказа (Продукт в заказе доставлен, Продукт в заказе оплачен)
• по действию (Новый заказ, Данные заказа изменены, Статус заказа изменен, Просмотренный продукт изменился, Выдано действие связанное с продуктом, Клиент изменил email, Клиент изменил мобильный телефон, Баланс клиента стал отрицательным, Бонусные баллы стали доступны, Статус дисконтной карты изменен, Дисконтная карта заменена)
• по продукту в списке (Продукт в списке продуктов изменился, Список продуктов изменился)
• по продукту просмотра (Просмотренный продукт изменился)
• по продукту (Продукт в заказе доставлен, Продукт в заказе оплачен, Продукт в списке продуктов изменился, Список продуктов изменился, Просмотренный продукт изменился, Предпочитаемый продукт изменился, Выдано действие связанное с продуктом)
• по промокоду (Выдан промокод, Клиент применил промокод, Использован реферальный промокод клиента)
• по изменению баланса (Баланс клиента стал отрицательным, Бонусные баллы стали доступны)
• по информации о дисконтной карте (Статус дисконтной карты изменен)
• по переменным операции (Вызов операции)

Как собирать фильтры по разным контекстамКак собирать фильтры по разным контекстам

Сценарии с несколькими контекстамиСценарии с несколькими контекстами

Часто в механиках нужно задать условия по разным сущностям.

Задача: при регистрации на онлайн-курс по истории до начала учебного года клиенты получают бонус.

Создаем сценарий по событию 'Выдано действие связанное с продуктом' и проверяем две сущности:

• действие (когда была регистрация):

• продукт (передан ли нужный предмет):

В каком порядке ставить блокиВ каком порядке ставить блоки

В большинстве случаев это не имеет значения. Но если сценарий обрабатывает большие объемы событий (несколько миллионов в течение часа) и есть задача снизить нагрузку на проекте, то лучше ставить первыми блоки, которые откинут максимум ненужных событий.

Как можно и нельзя проверять клиентаКак можно и нельзя проверять клиента

Не стоит задавать условия по клиенту через другие контексты. В новых сценариях такой возможности уже нет.

Вместо такой настройки:

Разделите условия на отдельные блоки:

• по изменению баланса:

• и по клиенту: