Настройка акций для целевого обновляемого сегмента

Редактировал(а) Татьяна Брыкова 2026/02/04 09:17

В системе реализованы офферы, которые предлагаются контакту, если он попал в определенный целевой сегмент. Чаще всего это применимо для акций, направленных на привлечение оттока.

Сегмент в таком случае формируется, например,  из:

  • контактов, которые не совершали покупок в указанный период в определенном формате магазинов – магазин у дома, гипермаркет и т.п.
  • контакты, которые не совершали покупок в указанный период в онлайн или офлайн.

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

Рассмотрим пример настройки акции с оффером, по которому клиенту начисляются 100 бонусов за покупку товаров от 1000 руб. в одном чеке. Оффер доступен только контактам, которые не совершали покупок в течение месяца офлайн.

Для реализации такой механики осуществляется сквозной процесс передачи сегмента с контактами из модуля Campaign на ежедневной основе в модуль Loyalty для настройки оффера с фильтром по контактам из маркетингового списка (МС) и с правилом для поощрения.

В Campaign:

Формируется акция для ежедневного обновления и сохранения сегмента в маркетинговый список.  По интеграции МС из Campaign передается в лояльность, ежедневно пополняя его новыми контактами.
Акция в Campaign настраивается стандартным образом с дополнительным шагом «Сохранение списка». Подробнее с функционалом сохранение списка можно ознакомиться здесь. Для сегмента используются фильтры – дней после последней покупки (равно 30)  и формат магазина   - (онлайн/офлайн).

1769522873386-982.png

1769522888244-651.png

Для того, чтобы запустить акцию необходимо на стороне лояльности:

Настроить оффер и привязать к нему правило начисления с фильтром по чекам и по контактам. В фильтр по контактам добавить МС,  полученный из Campaign, указав в нем "Тип маркетингового списка" = "Пополняемый". 

Участники большого МС не отображаются в представлении Контакты самого МС в UI, но подсчитывается общее количество участников.

1770027995466-683.png

Настройка оффера:

1769522728932-693.png1769522754095-228.png

 Чтобы поощрение в рамках оффера было предоставлено контакту только 1 раз, в правиле необходимо настроить соответствующее ограничение.

 Настройка правила начисления с фильтрами и ограничениями:

1769522781927-306.png1769522814381-965.png1769522831704-757.png

Для реактивации и привлечения покупателей можно начислять подарочные бонусы определенным сегментам, используя функционал Manzana Loyalty, - Задания по расписанию (ЗПР). Например, начислять 100 бонусов тем, кто ничего не покупал в течение 30 дней.

Для этого в Loyalty  к ЗПР привязывается переданный из Campaign МС, но с типом «Перезаписываемый», чтобы в обновляемый список попадали только новые контакты, а старые удалялись. Важно: ЗПР должно быть активировано только после  привязки МС, иначе возникнет ошибка при выполнении ЗПР.

Шаги по запуску ЗПР с бонусным начислением:

1.Формирование акции в Campaign для ежедневного обновления и сохранения сегмента в перезаписываемый маркетинговый список.

1769522948142-967.png

2. Проставление в МС в Loyalty признака "Перезаписываемый" тип маркетингового списка.

1769522924168-559.png

3. Добавление в ЗПР фильтра по МС, который будет обновляться новыми контактами из Campaign и разово начислять бонусы каждому контакту. Важно: если в поле "Максимальное количество объектов" указать  значение меньше, чем в МС, то ЗПР не сработает.

1769522988369-250.png1769523009841-208.png1769523036922-888.png

Для контроля начислений по ЗПР предусмотрено дополнительное логирование, включаемое партнерской настройкой Loyalty.Scheduler.Log.ErrorContactFromMarketingList 
После завершения обработки ЗПР в технической таблице доступна следующая  информация:

  1. Количество контактов для начисления при запуске ЗПР.
  2. Количество контактов с успешным начислением.
  3. Идентификаторы контактов, которым не удалось выполнить начисление, для последующего разбора причин.

 Для распределенной системы логируется запуск на ноде, и в таблицу попадают контакты, принадлежащие серверу этой ноды.

Информация, записанная в таблицу, передается в CDP.