Налаштування CDP (Customer Data Platform) для 1С-Бітрікс

Налаштування CDP (Customer Data Platform) для 1С-Bitrix

Якщо маркетолог не може відповісти, скільки покупців купили товар із категорії «Електроніка» двічі за останні 90 днів, — дані про клієнтів існують, але CDP немає. Інформація розкидана: сеанси в Bitrix, замовлення в 1С, звернення в Bitrix24 CRM, eventi в Яндекс.Метриці. CDP збирає це в єдиний профіль клієнта й робить дані придатними для сегментації та персоналізації.

Що входить у інтеграцію CDP з Bitrix

Налаштування CDP для сайту на 1С-Bitrix вирішує три завдання: збір даних з усіх точок контакту, об'єднання профілів (одна людина — один профіль, незважаючи на різні пристрої та канали), активація — використання даних для персоналізації та розсилок.

Джерела даних для проекту Bitrix:

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

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

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

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: [...]
});

Серверні события — критичні события (оформлення замовлення, реєстрація) дублюються з сервера, щоб не втратити дані при блокуванні скриптів. Відправка з Bitrix через обробник события:

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 — ідентифікація. Користувач заходив анонімно з телефону, додав у кошик, пішов. Через два дні відкрив лист із розсилки, клікнув по посиланню, оформив замовлення з комп'ютера. Це одна людина, але три різні ідентифікатори: anonymous_id браузера, email із розсилки, user_id після авторизації.

CDP вирішує це через виклик identify при авторизації:

// після успішного входу
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, Bitrix змінює контент головної сторінки або банери

Графіки виконання

CDP — це інвестиція з відстроченою дохідністю. Перші осмислені сегменти з'являються через місяць після запуску. Але персоналізовані розсилки за зібраними сегментами показують конверсію в 3–5 разів вищу за масові.