Setting up CDP (Customer Data Platform) for 1C-Bitrix

Setting Up CDP (Customer Data Platform) for 1C-Bitrix

If a marketer cannot answer how many customers bought an item from the "Electronics" category twice in the last 90 days — customer data exists, but CDP does not. Information is scattered: sessions in Bitrix, orders in 1C, inquiries in Bitrix24 CRM, events in Yandex.Metrica. CDP collects this into a unified customer profile and makes data suitable for segmentation and personalization.

What's Included in CDP Integration with Bitrix

Setting up CDP for a 1C-Bitrix site solves three tasks: data collection from all touchpoints, profile unification (one person — one profile, despite different devices and channels), activation — using data for personalization and mailings.

Data sources for a Bitrix project:

• Website: browser events (views, clicks, cart additions) — via CDP JavaScript SDK
• Orders: data from the sale module — via Bitrix webhooks or agent
• Profiles: user data from b_user, b_sale_order_user — via CDP API
• Bitrix24 CRM: deals, contacts — via REST API Bitrix24
• Email campaigns: opens, clicks from ESP (UniSender, SendPulse) — via ESP webhooks

Connection Scheme

Most CDP systems (Segment, mParticle, Mindbox, Retail Rocket) provide JavaScript SDK and server-side SDK. For a Bitrix project:

Frontend tracking — CDP script connects via site template in header.php (or via 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 events — critical events (order placement, registration) are duplicated from the server to avoid data loss due to script blocking. Sending from Bitrix via event handler:

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()],
    ]));
}

Profile Unification: Technical Complexity

The main engineering challenge of CDP — identification. A user browsed anonymously on their phone, added to cart, left. Two days later they opened an email, clicked a link, completed checkout from desktop. This is one person, but three different identifiers: browser anonymous_id, email from mailing, user_id after authorization.

CDP solves this via identify call on authorization:

// after successful login
analytics.identify('{{ USER_ID }}', {
    email: '{{ USER_EMAIL }}',
    name: '{{ USER_NAME }}',
    phone: '{{ USER_PHONE }}'
});

CDP links all previous anonymous events to the profile. But only if the SDK was initialized before authorization — otherwise browser event history is lost.

Segmentation and Personalization

After data accumulation (minimum 2–4 weeks of traffic) CDP allows building segments and using them:

• Abandoned cart: users with cart_add event without order_completed in the last 24 hours — trigger for email/push
• RFM segmentation: automatically from order data (recency, frequency, monetary)
• On-site personalization: CDP returns segment attributes via API, Bitrix changes homepage content or banners

Timeframes

CDP — an investment with delayed payoff. First meaningful segments appear after a month of operation. But personalized mailings by collected segments show conversion 3–5x higher than mass mailings.