РАЗРАБОТКА

Как мы внедрили программу лояльности 1С‑Рарус в омниканальном ритейле: кейс с доработкой модуля

Главная
/
Блог

Максим Жуков

Сооснователь ecommerce-агентства KISLOROD

Чтобы покупатели возвращались, недостаточно просто запускать акции и бонусы — важно выстраивать системную работу с клиентом. В e-commerce за это отвечает LTV — показатель пожизненной ценности клиента. Чем выше LTV, тем стабильнее бизнес.

Один из рабочих способов поднять LTV — внедрить программу лояльности. Особенно если речь идет об омниканальном ритейле: здесь важно, чтобы скидки, история покупок и личный кабинет работали одинаково и на сайте, и в офлайн-магазине. Именно такую задачу мы решали в этом проекте.

Содержание

Почему не подошло типовое решение
Как работает сервис 1С-Рарус: архитектура и возможности
Как работает программа лояльности
Технические нюансы
Проектирование интеграции
Результаты

О проекте

Мы работали с российским представительством международного бренда спортивной одежды — название под NDA. У клиента были:

сеть розничных магазинов по всей стране;
интернет-магазин с высоким трафиком;
дисконтная программа, работавшая только в офлайне.

Цель проекта — объединить онлайн- и офлайн-аудиторию в единой системе лояльности. Один профиль, одна скидка, одна история покупок — доступные и в магазине, и на сайте. Управление — через единый интерфейс, с синхронизацией в реальном времени.

Почему не подошло типовое решение

На первый взгляд, задача казалась простой: подключить дисконтную программу из розничной сети к интернет-магазину. Но анализ показал — стандартной интеграции недостаточно, даже с типовым модулем от Рарус.

Устаревший сайт

Интернет-магазин был построен на Python-фреймворках, не поддерживающих нужные интеграции. Мы перенесли его на 1С-Битрикс, сохранив бизнес-логику и адаптировав дизайн под фирменный стиль.

2. Нестандартные бизнес-процессы

В программе лояльности были особые правила: уровни скидок, акции по событиям, условия активации, ограничения для аутлетов. Типовой модуль не позволял учесть всё это — потребовалась кастомизация.

3. Ограничения SDK и типового модуля

SDK и модуль для Битрикс:Управление сайтом работают только с базовой логикой. Они не поддерживают быструю регистрацию, гибкие идентификаторы товаров, расширенные поля пользователя и синхронизацию скидок и акций для сайта. Плюс — зависят от устаревших библиотек.

4. Ограничения по API и тестовой среде

Тестовая среда отсутствовала — доработки сразу внедрялись в прод. API возвращал ошибки вместо пустых ответов, а модуль не обрабатывал такие случаи. Онлайн-расчёт скидок замедлял сайт.

На первый взгляд, задача выглядела просто: подключить уже работающую дисконтную программу, которая использовалась в офлайн-магазинах, к интернет-магазину. Однако при анализе стало ясно — стандартная интеграция невозможна, даже с учетом готового модуля от Рарус.

Как работает сервис 1С-Рарус: архитектура и возможности

1С‑Рарус интегрируется с учетной системой 1С, сайтом, кассами, мобильным приложением и другими точками контакта. Это позволяет выстроить сквозную систему управления программой лояльности — с единым личным кабинетом и синхронизированными скидками во всех каналах.

Что мы реализовали в рамках проекта:

1. Клиентская база и профиль покупателя

Создали единую базу с ФИО, контактами, датой рождения, историей покупок и активности. Данные поступают с сайта и из розницы, хранятся в облаке и синхронизируются с системой лояльности.

2. История покупок

В личном кабинете отображаются заказы из онлайн- и офлайн-каналов. Чтобы снизить нагрузку на API, реализована асинхронная подгрузка через отдельную HL-таблицу.

3. Синхронизация онлайн и офлайн

Покупки и скидки действуют в обоих каналах. Обмен данными обеспечен через расширенный SDK и отдельный модуль.

4. Гибкая система скидок

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

5. Сегментация и рассылки (в перспективе)

Система поддерживает триггерные рассылки, поведенческую сегментацию и аналитику. Эти возможности были заложены в архитектуру, но запуск отложен. Подключаются внешние SMS-, e‑mail-, push- и мессенджер-каналы. По желанию — можно привлечь маркетолога от Рарус.

Как работает программа лояльности

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

Сценарий регистрации

Покупатели могут присоединиться к программе:

в розничных магазинах через сотрудников;
в интернет-магазине — через форму регистрации или личный кабинет.

Условия программы

Система автоматически повышает уровень скидки при достижении порога. Кроме того, предусмотрена возможность временно назначать индивидуальные скидки вручную для всех карт — например:

увеличить скидку до 40% на время сезонной распродажи;
назначить персональную скидку 20% на день рождения клиента.

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

Дополнительные условия участия:

1. Скидки по дисконтной программе лояльности не суммируются с другими акциями и предложениями. Они действуют только в фирменных магазинах и интернет-магазине, но не распространяются на аутлеты.

2. Для присоединения к программе достаточно получить карту лояльности и зарегистрироваться по номеру телефона — в магазине или онлайн.

3. Чтобы скидка начала действовать, необходимо заполнить все обязательные поля анкеты в личном кабинете на сайте.

Сбор и работа с данными покупателей

Для участия в программе лояльности пользователь заполняет анкету участника, где указывает личные данные и подтверждает согласие на обработку информации. Клиент дает согласие на получение маркетинговых и информационных сообщений — по SMS, e-mail и другим каналам связи. Регистрация также была доступна через онлайн-форму на сайте самой платформы Рарус.

Хранение и обмен данными по программе лояльности

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

кассовое ПО розничной сети (РМК);
РМК партнеров по франшизе;
интернет-магазин (сайт).

Система лояльности объединяет эти каналы в единую базу.

Какие данные собираются

У каждого участника программы — владельца дисконтной карты — в системе хранятся:

ФИО и дата рождения;
контактные данные (телефон, e-mail);
история всех покупок (включая офлайн);
согласия на получение сообщений (e-mail, SMS, мессенджеры);
дата регистрации в программе;
номер карты и точка вручения;
уровень скидки и накоплений;
дополнительные параметры, нужные для персонализации или сегментации.

Что дают собранные данные

СУЛ помогала накапливать и использовать данные о покупателях для маркетинга и персонализации. Часть функций была заложена в архитектуру, но на момент внедрения не использовалась в полном объеме.

Потенциал работы с данными:

1. Сегментация клиентов

Возможность фильтровать участников программы по дате регистрации, объему покупок, категориям товаров и другим параметрам.

2. Создание аудиторий для рассылок

Система поддерживает выгрузку баз для рассылок по SMS и e-mail через внешних операторов — с учетом согласий и предпочтений клиента.

3. Триггерные сценарии (в перспективе)

Например, акция для клиентов, которые не покупали более года, или предложение для тех, кто недавно приобрел товары в категории «горнолыжная одежда».

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

Технические нюансы

Для интеграции с системой управления лояльностью от 1С-Рарус использовался открытый SDK — набор инструментов, с которым можно работать через Composer. В рамках проекта мы настраивали именно дисконтную модель, а не бонусную.

Сложности, с которыми столкнулись:

1. Ограничения SDK

SDK покрывает только ту часть API, которую использует типовой модуль.
Для реализации дополнительных сценариев мы расширяли SDK вручную, используя собственные классы и обходные решения. Архитектура была понятна, но технически «не поощряла» такие вмешательства — приходилось «хитрить».

2. Старые зависимости и Composer

При установке модуля через Composer возникали конфликты: часть библиотек использовала устаревшие версии. Проблемные зависимости пришлось искать и подключать вручную.

3. Отсутствие тестовой среды

Отдельной площадки для разработки не было — все работы велись прямо в боевой системе до запуска системы управления лояльностью.

4. Особенности работы API

API иногда возвращало ошибки, где по логике ожидался пустой ответ, например, при отсутствии данных. Это усложняло отладку.

5. Актуализация данных в реальном времени

Система управления лояльностью требует онлайн-запросов при каждом действии пользователя. Это снижало скорость сайта. Некоторые данные мы кешировали заранее, но скидки рассчитываются «на лету» через механизм скидочного правила — и их отложить нельзя.

Проектирование интеграции

Учитывая требования клиента, мы составили технический план интеграции системы с сайтом на 1С-Битрикс. Стандартный модуль не поддерживал ключевые функции, поэтому потребовалась кастомная доработка.

Ключевые задачи

1. Лейблы на товарах

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

2. Идентификаторы торговых предложений

Для точной идентификации мы внедрили формат: #артикул#_#код_цвета#_#размер#. Идентификатор записывается в отдельное свойство и участвует в передаче данных и расчетах скидок.

3. Форма регистрации на сайте

Для подключения к программе в ЛК реализована форма с обязательными полями: ФИО, телефон, город (с кодом ФИАС), дата рождения. Данные передаются в систему лояльности при активации.

4. Вступление в программу через ЛК

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

5. Вывод дисконтного статуса

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

6. Регистрация новых участников из розницы

Сайт сверяет пользователей с базой системы и регистрирует новых, если совпадений нет. При этом автоматически отправляется e-mail и SMS с доступом в личный кабинет.

7. История покупок из офлайн-магазинов

В личном кабинете отображаются покупки, сделанные в розничном магазине. Реализовали через HL-таблицу с асинхронной подгрузкой и кешированием.

Техническое задание: что дорабатывали

Мы составили подробное ТЗ и реализовали кастомные решения — с учетом архитектуры клиента и особенностей бизнес-логики.

1. Идентификация товаров

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

#артикул#_#код цвета#_#размер#

Пример: 11254_721_40-43. Этот идентификатор хранится в отдельном свойстве и участвует в передаче данных, расчетах скидок и фильтрации.

2. Импорт пользователей из системы лояльности

Типовой модуль не умел загружать готовую базу клиентов. Мы реализовали:

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

После регистрации пользователю отправляются SMS и e-mail со ссылкой на личный кабинет. При быстрой регистрации в рознице обработка дублирующихся профилей и рассылка настроены через исключения.

3. Расширенная форма регистрации

Чтобы использовать форму не только для создания аккаунта, но и для активации в программе лояльности, мы добавили:

поле «Город» с автозаполнением и кодом ФИАС (нужно для сегментации);
подтверждаемую почту (передается отдельно после верификации);
галочку для согласия на рассылку (включена по умолчанию, но пользователь может ее снять).

4. Активация карты и сценарии подключения

Через форму: если данных хватает, карта активируется автоматически;
Через личный кабинет: при открытии ЛК отправляется запрос в СУЛ. Если данных недостаточно, пользователь видит подсказки;
При обычной регистрации на сайте: система проверяет наличие профиля по номеру телефона, подтягивает статус участия и предлагает активировать карту, если чего-то не хватает. Этот сценарий отличается от формы в личном кабинете: пользователь не заполняет форму для участия в программе отдельно — он просто регистрируется на сайте, например, при оформлении первого заказа.

5. Передача данных в СУЛ

Мы доработали модуль так, чтобы передавались все необходимые поля:

ФИО;
дата рождения;
номер телефона;
пол;
город с кодом ФИАС;
подтвержденная почта (отдельно);
согласие на рассылку.

6. Подтверждение участия

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

Вывод цен и работа корзины

Программа лояльности напрямую влияет на стоимость товаров, отображение скидок и расчёт финальной суммы в корзине. Мы адаптировали механику цен под новую логику:

в каталоге отображаются цены, указанные на сайте. Настроили вывод скидочных цен и акций путем синхронизации данных с СУЛ на фоне через стандартный функционал агентов, чтобы потенциальный покупатель видел ту стоимость, которую ему рассчитает СУЛ в корзине и чекауте;
в истории заказов — те, что приходят из СУЛ;
при оформлении заказа цены пересчитываются с учетом скидок из СУЛ — через модуль;
бесплатная доставка учитывает финальную сумму с уже примененной скидкой;
раньше на сайте не отображалась сумма или процент скидки в корзине — мы это добавили.

Общие доработки модуля

Модуль 1С‑Рарус не поддерживал авторизацию по SMS, поэтому мы адаптировали регистрацию, импорт и редактирование профилей: номер телефона теперь записывается в поле PERSONAL_PHONE, как требует система лояльности.

Также мы реализовали:

отображение заказов из розничных магазинов в истории покупок;
блокировку возвратов таких заказов через сайт — если товар вернули в рознице, статус обновляется на «возвращен» и блокирует повторную операцию.

Отдельные требования от поддержки СУЛ:

Пол, город, телефон

Город нужно сначала создать в справочнике СУЛ через API (POST /organization/city/add), а затем передавать его ID при добавлении пользователя.

Авторизация по номеру

Настроили поиск пользователей по PHONE_NUMBER — это основной идентификатор для входа по SMS.

Передача подтвержденной почты

E-mail отправляется в СУЛ только после подтверждения. Это решение мы реализовали через отслеживание статуса в профиле.

Возвраты и статусы

Покупка уходит в СУЛ только после перехода заказа в финальный статус — F (Доставлено). Если заказ отменяется, возврат с сайта убирается. Все возвраты происходят только через 1С.

Отображение акций на сайте

Помимо доработок модуля, мы обновили дизайн отображения акций:

сделали визуальные лейблы;
добавили описание условий;
реализовали переключение по размерам и категориям.

Внедрение программы лояльности 1С-Рарус | KISLOROD

Интеграция 1С‑Рарус с Битрикс

Чтобы обеспечить стабильную работу системы лояльности на новом сайте, мы расширили SDK под проектные задачи и адаптировали модуль под архитектуру клиента. Все доработки выполнили в пространстве имен проекта — без вмешательства в ядро платформы. Это позволило сохранить обновляемость и независимость решения.

Интеграция модуля: что дорабатывали

Чтобы модуль лояльности корректно работал в e‑commerce-среде, мы переработали ключевые механизмы обмена данными и отображения информации на сайте.

Работа с API

Запросы к системе лояльности выполняются синхронно — все ответы приходят в реальном времени с серверов 1C-Rarus. Это замедляло отклик сайта, особенно при оформлении заказов. Мы вынесли часть запросов (например, обновление истории покупок) в фоновый режим и переработали мини-корзину: теперь она загружается не в шапке, а при переходе на страницу корзины. Это снизило нагрузку и ускорило загрузку сайта.

Идентификация товаров

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

Отображение акций и лейблов у товаров

Мы настроили связку между сегментами из СУЛ и товарами на сайте: каждый сегмент формирует страницу акции, а также управляет лейблами и отображением условий в каталоге и карточке товара.

Что сделали:

Настроили синхронизацию акций между СУЛ и сайтом. Новые акции появляются неактивными и требуют проверки, удалённые — убираются автоматически.
Добавили свойство ACTIONS, в которое записываются все активные акции для товара. При следующем обновлении неактуальные значения затираются.
Реализовали визуальные лейблы и описания условий акций в карточке товара. Если предложение участвует в нескольких акциях — показываются все.
Сделали названия акций кликабельными — они ведут на страницы с акционным ассортиментом.
Реализовали динамическое обновление лейблов при смене размера или цвета в карточке.

Чтобы акции выглядели как полноценные разделы каталога, мы создали для них псевдоразделы и подключили их к смарт-фильтру. Доработали стандартные компоненты Bitrix и реализовали кастомную логику подсчета товаров в фильтре.

Кастомизация фасетного индекса

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

Проблема:

Акции в системе лояльности — это не физические разделы каталога. По умолчанию Bitrix не умеет корректно фильтровать товары вне структуры реальных разделов, особенно если используется «нулевой» раздел.

Как решили:

создали фантомные разделы с ID, совпадающим с ID акции;
из фасета «нулевого» раздела отобрали нужные товары — те, что участвуют в конкретной акции;
для них добавили дубли записей в индекс, указав ID фантомного раздела;
настроили агента, который отслеживает изменения и обновляет индекс только при необходимости.

Особенности реализации:

свойство ACTIONS сделали фильтруемым;
учитывали, что в фасете значение свойства = удвоенный ID;
настроили точный подсчет товаров внутри псевдоразделов и вывод только доступных к покупке позиций.

В результате фильтр работает стабильно и предсказуемо — как с обычными разделами каталога.

Регистрация, активация и обновление данных в СУЛ

Главный идентификатор пользователя — номер телефона (поле PHONE_NUMBER). С его помощью происходит регистрация и авторизация в системе лояльности.

Как работает передача данных:

данные отправляются в СУЛ при создании или обновлении пользователя — если он еще не существует в системе;
мы расширили логику: в нужных сценариях блокируем автоматическую отправку, либо вызываем обновление вручную через API БУС;
Подтвержденная почта и согласие на рассылки передаются отдельно — только если пользователь действительно подтвердил email или подписку на сайте.

Работа с городом:

город в СУЛ хранится как справочник;
перед передачей данных мы проверяем, существует ли город в системе. Если нет — создаем его через POST /organization/city/add, затем передаем city_id с остальными полями.

Расширение DTO:

В API СУЛ не хватало нужных полей для передачи пользовательских данных.
Мы дополнили объект Users вручную — добавили все недостающие атрибуты, чтобы соблюсти структуру и не нарушить архитектуру модуля.

Активация после быстрой регистрации:

В стандартной логике быстрая регистрация, например, в рознице создает профиль без активации скидки.
мы доработали сценарий: сайт проверяет наличие необходимых данных, инициирует активацию при оформлении заказа или заполнении профиля.
если данных достаточно — карта активируется. Если чего-то не хватает — пользователю показывается список недостающих полей.

Так мы обеспечили корректную регистрацию, гарантированную активацию карты и передачу всех нужных атрибутов в СУЛ.

Вступление в программу и отображение статуса

Если пользователь еще не участвует в программе, в личном кабинете он видит приглашение присоединиться. После активации или подтверждения профиля — предложение скрывается, а на его месте отображается текущий дисконтный статус: процент скидки и накоплений.

Для отображения информации мы разработали отдельный компонент sale.bonus.status, использующий возможности SDK и API-документации. Он запрашивает статус напрямую из системы лояльности и показывает его в интерфейсе личного кабинета.

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

История покупок из розничных магазинов

Чтобы в личном кабинете отображались не только онлайн-заказы, но и покупки из розничной сети, мы внедрили отдельную механику.

Реализовать офлайн-покупки как полноценные заказы сайта было бы технически сложно и рискованно — из-за возможных дублирований и конфликтов статусов. Поэтому мы храним эти данные отдельно, в HL-таблице, и отображаем их параллельно с интернет-заказами.

Как работает механизм:

при открытии истории заказов система асинхронно загружает розничные транзакции из СУЛ;
старые записи в HL-таблице обновляются, данные объединяются с онлайн-покупками;
итоговая выборка кэшируется на 60 минут для стабильной загрузки и минимальной нагрузки;
данные подаются через кастомный компонент sale.personal.order.history.list.

Оффлайн-покупки распознаются по заранее заданному ID магазина. Так мы избегаем путаницы при объединении источников и обеспечиваем корректную пагинацию.

Корзина и передача заказов в СУЛ

Чтобы начислять скидки и учитывать покупки в системе лояльности, важно корректно передавать данные из корзины и заказов на сайт в СУЛ.

Мы адаптировали механику корзины под бизнес-логику клиента. При оформлении или редактировании заказа информация передается в СУЛ, где заказ фиксируется как покупка. Передача происходит только при переходе в финальный статус — например, «Доставлено».

Что было доработано:

исправили баг, из-за которого заказ мог отправляться в СУЛ дважды;
отключили возвраты с сайта — они инициируются только из 1С, как предусмотрено системой;
переработали отображение скидок в корзине: теперь пользователь видит сумму и процент сразу, без дополнительных действий;
учли, что бесплатная доставка рассчитывается уже после применения скидки — ее сумма влияет на итог.

Такой подход позволяет точно отображать цены, избегать ошибок при расчёте и соблюдать правила начисления лояльности.

Результаты

Реализация проекта потребовала комплексного подхода — от переноса сайта до глубокой кастомизации модуля лояльности. Итак, кратко о ключевых задачах, которые мы решили, и результатах, которые получил клиент.

Что мы сделали:

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

Интеграция 1C-Rarus в омниканальную архитектуру требует точной настройки, внимания к деталям и понимания бизнес-процессов. Команда KISLOROD адаптировала типовое решение под реальные задачи ритейла: учли особенности скидок, обеспечили стабильную работу корзины, синхронизировали онлайн и офлайн, переработали модуль без вмешательства в ядро.

Такой подход помогает бизнесу быстрее внедрять лояльность, лучше понимать клиентов и увереннее расти. Если вам нужна команда, которая умеет внедрять сложные решения и говорить с бизнесом на одном языке — готовы обсудить ваш проект.

Получайте полезный контент от KISLOROD в любом из мессенджеров

При переходе в одну из указанных социальных сетей вы автоматически даете согласие на обработку персональных данных и согласие на получение рекламной рассылки. Подробнее об обработке данных в Политике конфиденциальности.