RapidSoft - Решения - Платформа клиентских данных (CDP)

Платформа клиентских данных (CDP)

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

Запросить демонстрацию

Почему триггерный маркетинг упирается в ИТ

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

• События разложены по системам. Процессинг, сайт, приложение, контакт-центр, опросы, кассы. Профиль клиента собран, а его действия живут в разных таблицах и форматах, и лентой по клиенту их никто не видит.
• Каждый триггер — отдельный ETL-пакет. «После первой покупки начислить бонус», «если не оплатил за 30 минут — напомнить»: под каждое правило пишется свой пакет. Что он делает, знает автор. Изменение условия означает доработку и релиз.
• Моменты проходят между выгрузками. Первая покупка, брошенная корзина, признак оттока — клиент готов к действию сейчас, а кампания по сегменту стартует после ночной выгрузки. Почему сообщение не пришло, разбирают по логам.

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

Как это работает?

Профиль и события

Схемы событий

Сценарии и экземпляры

Сегменты и аудитории

Интеграции

Профиль и события

Единый профиль клиента и лента его событий

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

• Расширяемый состав атрибутов профиля, словари значений, обязательные и идентификационные поля
• Импорт событий из баз данных, Apache Kafka, RabbitMQ, через API и из файлов
• Лента событий клиента из его карточки: источник, тип, дата, исходный и расчётный контекст
• В расчётном контексте видно, какие механики акций сработали по событию и с каким результатом
• Объединение дублей клиентов, базы в десятки миллионов записей

Схемы событий

Схема каждого события проверяется на входе

Для пары «система-источник + тип события» задаётся схема в формате JSON Schema — отдельно для исходного и расчётного контекста. Схему не пишут руками: она генерируется из примера события и проверяется на другом примере в том же редакторе. Событие, не прошедшее проверку, отклоняется с понятной причиной, остальные события пакета обрабатываются.

• Визуальный редактор полей и режим JSON, переключение без потери данных
• Генерация схемы из примера события, проверка примера по схеме, экспорт и импорт
• Типы, обязательность, форматы, вложенные структуры и списки
• Индексные поля для быстрых выборок по событиям
• Схема как контракт с источником: изменилась структура события — видно сразу, а не через месяц по неверному расчёту

Сценарии и экземпляры

Сценарии в графовом редакторе и их экземпляры

Сценарий (customer journey) — граф на холсте: узлы и переходы между ними. Простейший сценарий — два узла и одно ребро: «по событию X выполнить действие Y», сложные добавляют ожидания, таймауты и ветвления. Каждое прохождение сценария клиентом — экземпляр со своей карточкой: текущий узел, статус, счётчики и лог обработанных событий.

• Шесть типов узлов: Вход, Ожидание события, Таймаут, Условие, Действие, Выход
• Ожидание с таймаутом и веткой «не дождались» — брошенная корзина и любой паттерн «событие не произошло за N»
• Счётчики и ветвление: «после третьей покупки», «когда сумма превысила N»
• Публикация с проверкой графа: недостижимые узлы и ошибки шаблонов показываются списком замечаний
• Карточка экземпляра: позиция на графе, статус, лог событий с указанием сработавшего перехода
• Повторное событие с тем же идентификатором — корректировка: счётчики пересчитываются, действия не отзываются

Сегменты и аудитории

Сегментация и целевые аудитории на всех данных

Группы и сегменты строятся по любым атрибутам профиля и событиям. Встроенные алгоритмы автоматической сегментации — RFM, CLV, жизненный цикл, структура корзины. Целевые аудитории для кампаний в модуле акций формируются из сегментов или по событию. Сценарии дополняют сегментные кампании реакцией на действия отдельного клиента.

• Конструктор условий с группировкой, логическими операторами и масками
• Автоматическая сегментация: RFM-анализ, CLV, жизненный цикл, структура покупок
• Целевые аудитории: открытые и закрытые, статические и динамические, по событию с opt-in и opt-out
• Сегмент как условие входа в сценарий, событие сценария как признак для сегмента
• Анализ поведения по покупкам, структуре чека, суммам и частоте

Интеграции

Результат сценария уходит туда, где он нужен

Действие на узле формирует запись для канала доставки по шаблону с подстановкой данных профиля, события и счётчиков. Записи попадают в таблицу исходов, откуда их забирают ETL-процессы Системы лояльности и внешние интеграции. Один канал настраивается один раз и переиспользуется всеми сценариями.

• Система коммуникаций: рассылки, опросы, push и сообщения в приложении
• Модуль акций и бонусный процессинг: начисления, участие в акциях, статусы
• Внешние системы: HTTP-вызовы, публикация в Apache Kafka, произвольные ETL-потоки
• Шаблоны с подсветкой и автодополнением по полям профиля, события и счётчикам
• Статус доставки и число попыток по каждой записи в интерфейсе и через REST API

Примеры сценариев

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

• Приветственный бонус. Первая покупка новым клиентом — начисление бонуса. Если через 7 дней второй покупки нет — напоминание с предложением. Первая покупка → Клиент новый? → Начислить бонус → Ждать покупку 7 дней → Напоминание
• Опрос после обращения. Закрытие обращения в контакт-центре — приглашение в опрос. Ответа нет 3 дня — повторное приглашение. Несколько обращений одного клиента ведутся отдельно по ключу корреляции. Обращение закрыто → Приглашение в опрос → Ждать ответ 3 дня → Повтор или выход
• Брошенная корзина. Товар добавлен в корзину — ожидание оплаты 30 минут. Оплата не пришла — напоминание с составом корзины из данных события. Товар в корзине → Ждать оплату 30 минут → Напоминание с корзиной
• Накопительная механика. Счётчик покупок в категории. После третьей покупки — бонус или переход на следующий уровень программы, данные о сумме подставляются из счётчика. Покупка в категории → purchases +1 → purchases = 3? → Повысить уровень
• Негативный отзыв. Ответ на опрос с негативной тональностью и причиной «не перезвонили» — задача сотруднику контакт-центра. Повторного контакта нет 2 дня — эскалация руководителю. Негативный отзыв → Задача в контакт-центр → Ждать контакт 2 дня → Эскалация

Отзывы клиентов становятся событиями

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

Схема работы

Платформа принимает события от систем-источников, ведёт профиль клиента и отдаёт результаты сценариев в модули Системы лояльности и внешние системы. Всё в контуре заказчика.

Кто и что делает

Маркетинг настраивает сценарии и сегменты, ИТ подключает источники и каналы, служба безопасности контролирует доступ и аудит.

Данные под контролем

Платформа работает с персональными данными клиентов, поэтому требования служб ИТ и ИБ учтены в архитектуре.

• Развёртывание в контуре заказчика. Платформа устанавливается в инфраструктуре заказчика вместе с остальными модулями Системы лояльности. Внешние сервисы для хранения или обработки данных не используются.
• Единая авторизация. Сотрудники входят через модуль безопасности Системы лояльности. Роли и доступы управляются централизованно, отдельных учётных записей платформа не заводит.
• Проверка событий и защита от конфликтов. События проверяются по схеме при приёме. Схемы и сценарии защищены от одновременного редактирования: изменения фиксируются с автором и временем.
• Неизменяемые версии и аудит. Опубликованная версия сценария не меняется. По каждому экземпляру доступны лог событий и таблица исходов через интерфейс и REST API.
• Идемпотентность и корректировки. Повторное событие не создаёт повторного действия. Корректировка события пересчитывает счётчики и фиксируется в журнале.
• Языковая модель заказчика и открытые коннекторы. Языковая модель для разметки текста подключается через точку доступа заказчика: локальная, корпоративная или облачная по вашему договору. Какие поля получает модель, настраивается. Источники данных подключаются через открытую библиотеку EtlKit, которую развивает RapidSoft: базы данных, Kafka, RabbitMQ, файлы, REST.
• В развитии: ограничение частоты и переобработка. Лимиты на число входов клиента в сценарий за период и штатный механизм переобработки исторических событий.

Зачем программе лояльности платформа клиентских данных

Платформа клиентских данных, или CDP (customer data platform), — это класс систем, которые собирают данные о клиенте из всех точек контакта в единый профиль и делают этот профиль доступным для маркетинга: сегментации, персонализации, триггерных коммуникаций. Для программы лояльности такая платформа — естественное продолжение: у неё уже есть самый ценный источник событий, транзакции, и самый прямой способ повлиять на поведение клиента, вознаграждение.

Разница между CDP-платформой в составе Системы лояльности RapidSoft и облачными сервисами в том, где живут данные и что происходит после срабатывания сценария. Облачные CDP хорошо решают задачу рассылок для e-commerce, но требуют вынести клиентскую базу наружу и оплачивать её объём. Наша платформа разворачивается в инфраструктуре заказчика, а результат сценария не ограничивается сообщением: сценарий может начислить бонус, изменить участие в акции, передать данные во внутреннюю CRM.

Триггерные сценарии вместо ETL-пакетов

Триггерные рассылки и начисления в большинстве программ лояльности реализованы как индивидуальные ETL-пакеты. Это работает, пока сценариев немного и их автор в команде. Со временем пакеты накапливаются, условия в них расходятся с тем, что помнит маркетинг, а любое изменение требует разработки. Сценарии событий переносят эту логику в настраиваемый и версионируемый объект: граф с условиями, который маркетолог видит целиком, а система проверяет при публикации.

Схема события как контракт

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

Сегментация и сценарии — две стороны одной базы

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

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

Развитие продукта

Первый этап платформы работает. Дальше развиваем движок сценариев и аналитику по отзывам.

• Каналы доставки. Встроенные обработчики для Webhook, Apache Kafka и пользовательских ETL-потоков с политиками повторов, управление каналами из интерфейса.
• A/B-разветвление. Узел, который делит поток клиентов в заданных пропорциях, для проверки механик внутри сценария.
• Окна и накопительные паттерны. Скользящие и календарные окна счётчиков, паттерн «накопить N и выйти», табличные развилки для менеджеров.
• Отчёт о причинах. Сводный отчёт о причинах позитива и негатива по опросам и обращениям.

Вопросы и ответы

Чем платформа отличается от облачной CDP?

Платформа разворачивается в инфраструктуре заказчика вместе с Системой лояльности. Клиентские данные, схемы событий и движок сценариев не покидают контур. В профиле уже есть события процессинга и сработавшие механики акций, а результат сценария уходит в начисление, коммуникацию или внешнюю систему. Облачная CDP может оставаться каналом коммуникаций, а платформа — источником событий и правил программы.

Насколько быстро сценарий реагирует на событие?

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

Кто настраивает сценарии — маркетолог или разработчик?

Маркетолог или CRM-аналитик. Простейший сценарий — два узла и один переход: по событию выполнить действие. Условия собираются в том же редакторе, что и группы контактов, поля события выбираются из списка по его схеме. Разработка ETL-пакета под сценарий не требуется.

Что происходит, если событие пришло с ошибкой или повторно?

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

Куда уходит результат сценария?

Действие формирует запись по шаблону с данными профиля, события и счётчиков. Записи забирают ETL-процессы Системы лояльности и интеграции: Система коммуникаций для рассылок и опросов, модуль акций и процессинг для начислений, внешние системы через HTTP-вызовы и Kafka.

Нужна ли Система лояльности RapidSoft, чтобы использовать платформу?

Платформа — модуль Системы лояльности RapidSoft и поставляется в её составе. Действующим клиентам она доступна как расширение, новым — вместе с системой или её частью, в модульной поставке.

Есть ли анализ тональности отзывов?

Да. Свободный текст из опроса или обращения размечается языковой моделью: тональность, её сила и причины из вашего словаря. Результат становится событием в профиле клиента, по нему работают сценарии, сегменты и отчёты. Модель и точку доступа выбирает заказчик, разметка выполняется в течение минут после ответа.

Покажем платформу
на ваших сценариях

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

Оставить заявку