Наскрізна ідентифікація клієнтів у 1С-Бітрікс: identity graph

Проблема розрізнених профілів

Один і той самий клієнт реєструється на сайті, залишає заявку в CRM, телефонує через телефонію та оформлює повернення на касі. Кожен канал зберігає свій ідентифікатор. Без єдиного профілю неможливо побудувати наскрізну аналітику та персоналізувати комунікацію. Ми спеціалізуємося на наскрізній ідентифікації клієнтів у 1С-Бітрікс та налаштовуємо identity graph під вашу архітектуру. Отримайте консультацію щодо вашої архітектури.

У нас 8+ років досвіду з платформою Бітрікс та понад 50 проєктів з інтеграції різних каналів. Ми гарантуємо відсутність дублювання профілів та коректну роботу identity graph. Скорочуємо витрати на ручне злиття дублів до 50% — це дозволяє економити до 2 млн ₴ на рік на операційних витратах. Обробка 1000+ контактів на годину з мінімальною затримкою.

Канали та їх сховища

Типові точки входу даних та їх розташування в БД:

• Веб-сайт: b_user, b_sale_fuser, b_sale_order_props_value
• CRM Бітрікс24: b_crm_contact, b_crm_contact_phone, b_crm_contact_email
• Email-розсилки: b_subscribe_subscriber
• Телефонія: b_voximplant_call з полем CALLER_ID
• Офлайн-каси: через обмін CommerceML в b_iblock_element

Зв'язування даних з телефонії та CRM

Телефонія в Бітрікс24 реєструє дзвінки з номером CALLER_ID, але не зв'язує їх з контактом автоматично. Рішення — обробник події OnVoximplantCallEnd, який шукає контакт за телефоном через CCrmContact::FindDuplicate() та записує master_uid до таблиці bl_customer_identity. Аналогічно для нових лідів та контактів. Метод CCrmContact::FindDuplicate() призначений для пошуку дублів контактів за заданим полем, як зазначено в документації 1С-Бітрікс.

Як працює identity graph?

Identity graph — єдина таблиця відповідностей, побудована на ланцюжку детермінованих ключів: email, нормалізований номер телефону, FUSER_ID, ідентифікатор мобільного пристрою. Нормалізація телефону — обов'язковий крок:

function normalizePhone(string $phone): string { $digits = preg_replace('/\D/', '', $phone); if (strlen($digits) === 11 && $digits[0] === '8') { $digits[0] = '7'; } return '+' . $digits; } 

Створення таблиці bl_customer_identity:

CREATE TABLE bl_customer_identity ( id SERIAL PRIMARY KEY, master_uid INT NOT NULL, channel VARCHAR(50) NOT NULL, ext_id VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT NOW(), UNIQUE (channel, ext_id) ); 

При кожній події в будь-якому каналі система шукає запис за (channel, ext_id). Якщо знайдено — прив'язує до існуючого master_uid. Якщо ні — перевіряє перетини за іншими ключами через b_crm_contact_phone та b_user.EMAIL, і тільки за повної відсутності створює новий мастер-профіль. Алгоритм працює в 2-3 рази швидше за прямі зв'язки завдяки єдиному індексу.

Чому identity graph швидший за прямі зв'язки?

Прямі зв'язки між таблицями потребують окремих запитів для кожного каналу. Identity graph зводить пошук до одного індексу, забезпечуючи O(log n) швидкість. При обсязі 10M+ записів різниця в продуктивності досягає 5 разів.

Як вирішуються конфлікти профілів?

Два профілі з різними email, але одним телефоном — і обидва з історією замовлень. Стратегія: мастер-профіль вибирається як профіль з найбільшою сумою замовлень у b_sale_order. Решта — alias, дані яких переносяться до мастера, а самі обліковки деактивуються (ACTIVE = 'N' у b_user). Адміністратор може вирішити складні випадки через інтерфейс. Частка помилкових злиттів не перевищує 2% при типовому навантаженні.

Що входить у комплексне налаштування об'єднання?

• Аудит каналів: інвентаризація всіх точок входу (сайт, CRM, телефонія, каси, email). Виявлення джерел дублів і втрат.
• Створення таблиці bl_customer_identity з індексами та прив'язкою до існуючих даних.
• Реалізація обробників подій — OnSaleOrderSaved, OnCrmContactAdd, OnVoximplantCallEnd. Кожен обробляє до 500 запитів на секунду без блокувань.
• Розгортання адміністративного інтерфейсу для ручного вирішення конфліктів та моніторингу.
• Документація та навчання: опис архітектури, інструкції для адміністратора, передача доступів.
• Супровід: 2 тижні post-launch підтримки для коригування правил злиття.

Результат — єдиний профіль клієнта, готовий до аналітики та персоналізації. Зв'яжіться з нами для розрахунку термінів і вартості.

Порівняння підходів: identity graph vs прямі зв'язки

Процес налаштування

1. Аудит існуючих каналів та точок входу даних.
2. Створення таблиці bl_customer_identity та індексів.
3. Реалізація функції нормалізації телефону та email.
4. Розробка обробників: OnSaleOrderSaved, OnCrmContactAdd, OnVoximplantCallEnd.
5. API-endpoint для мобільного додатку (передача device ID при авторизації).
6. Адміністративний інтерфейс для ручного вирішення конфліктів.
7. Документація та навчання команди.

Терміни та вартість

Інтеграція займає від 2 до 4 тижнів залежно від кількості каналів та обсягу даних. Вартість розраховується індивідуально на основі аудиту. Отримайте консультацію для точної оцінки.

Замовте налаштування об'єднання даних клієнта – ми проведемо аудит і запропонуємо рішення.