Настройка CDP (Customer Data Platform) для 1С-Битрикс

Настройка CDP (Customer Data Platform) для 1С-Битрикс

Если маркетолог не может ответить, сколько покупателей купили товар из категории «Электроника» дважды за последние 90 дней, — данные о клиентах есть, но CDP нет. Информация разбросана: сессии в Битрикс, заказы в 1С, обращения в Битрикс24 CRM, события в Яндекс.Метрике. CDP собирает это в единый профиль клиента и делает данные пригодными для сегментации и персонализации.

Что входит в интеграцию CDP с Битрикс

Настройка CDP для сайта на 1С-Битрикс решает три задачи: сбор данных из всех точек контакта, объединение профилей (один человек — один профиль, несмотря на разные устройства и каналы), активация — использование данных для персонализации и рассылок.

Источники данных для Битрикс-проекта:

• Сайт: события браузера (просмотры, клики, добавления в корзину) — через JavaScript SDK CDP
• Заказы: данные из модуля sale — через вебхуки или агент Битрикс
• Профили: данные пользователей из b_user, b_sale_order_user — через API CDP
• CRM Битрикс24: сделки, контакты — через REST API Битрикс24
• Email-рассылки: открытия, клики из ESP (UniSender, SendPulse) — через вебхуки ESP

Схема подключения

Большинство CDP-систем (Segment, mParticle, Mindbox, Retail Rocket) предоставляют JavaScript SDK и server-side SDK. Для Битрикс-проекта:

Frontend-трекинг — скрипт CDP подключается через шаблон сайта в header.php (или через GTM):

analytics.track('Product Viewed', {
    product_id: '{{ ELEMENT_ID }}',
    name: '{{ ELEMENT_NAME }}',
    price: {{ PRICE }},
    category: '{{ SECTION_NAME }}'
});
analytics.track('Order Completed', {
    order_id: '{{ ORDER_ID }}',
    total: {{ ORDER_TOTAL }},
    products: [...]
});

Server-side события — критичные события (оформление заказа, регистрация) дублируются с сервера, чтобы не потерять данные при блокировке скриптов. Отправка из Битрикс через обработчик события:

AddEventHandler('sale', 'OnSaleOrderSaved', 'sendOrderToCDP');

function sendOrderToCDP($event) {
    $order = $event->getParameter('ENTITY');
    $http  = new \Bitrix\Main\Web\HttpClient();
    $http->post('https://cdp-api.example.com/v1/track', json_encode([
        'event'      => 'order_completed',
        'userId'     => $order->getUserId(),
        'properties' => ['order_id' => $order->getId(), 'total' => $order->getPrice()],
    ]));
}

Объединение профилей: техническая сложность

Главная инженерная задача CDP — идентификация. Пользователь зашёл анонимно с телефона, добавил в корзину, ушёл. Через день открыл письмо из рассылки, кликнул по ссылке, оформил заказ с десктопа. Это один человек, но три разных identifier: anonymous_id браузера, email из рассылки, user_id после авторизации.

CDP решает это через identify call при авторизации:

// после успешного логина
analytics.identify('{{ USER_ID }}', {
    email: '{{ USER_EMAIL }}',
    name: '{{ USER_NAME }}',
    phone: '{{ USER_PHONE }}'
});

CDP связывает все предыдущие анонимные события с профилем. Но только если SDK был инициализирован до авторизации — иначе история браузерных событий теряется.

Сегментация и персонализация

После накопления данных (минимум 2–4 недели трафика) CDP позволяет строить сегменты и использовать их:

• Брошенная корзина: пользователи с событием cart_add без order_completed за последние 24 часа — триггер для email/push
• RFM-сегментация: автоматически по данным заказов (recency, frequency, monetary)
• Персонализация на сайте: CDP возвращает атрибуты сегмента через API, Битрикс меняет контент главной страницы или баннеры

Сроки

CDP — инвестиция с отложенной отдачей. Первые осмысленные сегменты появляются через месяц после запуска. Зато персонализированные рассылки по собранным сегментам показывают конверсию в 3–5 раз выше массовых.