Налаштування єдиного профілю клієнта на 1С-Бітрікс

Налаштування єдиного профілю клієнта на 1С-Бітрікс

Уявіть: клієнт замовляє товар на сайті, потім телефонує в кол-центр з іншого номера, а після заходить через додаток без авторизації. У підсумку база зберігає три незалежні записи, і менеджер не бачить повну історію покупок. На великих проєктах відсоток дублювання сягає 15–20% — на 100 000 записів припадає до 20 000 дублів. Це класична проблема, яку вирішує налаштування єдиного профілю клієнта (Customer Data Profile) на 1С-Бітрікс. Ми налаштовуємо таку систему під ключ: від аудиту таблиць до автоматичного злиття. Працюємо на ринку понад 10 років, виконали 80+ проєктів з інтеграції Бітрікс та Бітрікс24. У нашій команді 15 сертифікованих фахівців. Зв'яжіться з нами для аудиту вашої бази.

Причини дублювання та структура даних користувача

Типовий сценарій: користувач оформлює анонімне замовлення, потім реєструється, але гостьова сесія не прив'язується. Система створює новий запис у b_user, а старі замовлення залишаються з USER_ID = 0. Якщо в CRM паралельно реєструється лід з тим же телефоном — дублів стає два. На базах з 500 000+ записів відсоток дублікатів сягає 15–20%. Ми це бачили на проєктах з тисячами щоденних замовлень.

Ядро оперує двома незалежними сутностями: користувач (b_user) і покупець (b_sale_person_type + b_sale_order_user). При анонімному замовленні створюється запис у b_sale_order з USER_ID = 0 та контактними даними в полях b_sale_order_props_value. При реєстрації або авторизації замовлення прив'язуються до конкретного USER_ID, але зв'язок «гостьові замовлення → зареєстрований користувач» не будується автоматично. Додатково: якщо на проєкті підключений модуль crm, кожне замовлення через подію OnSaleOrderSaved створює або оновлює сутності CCrmContact і CCrmDeal. Дублювання на рівні b_user негайно породжує дублювання контактів у CRM. Без втручання кількість дублів зростає експоненційно.

Механізм злиття профілів

Єдиний профіль будується через три компоненти:

1. Ідентифікація за детермінованими полями. Email і телефон — основні ключі злиття. У таблиці b_user поля EMAIL і PERSONAL_PHONE мають бути унікальними (індекс UQ_USER_EMAIL). Проблема в тому, що за замовчуванням Бітрікс не забороняє двох користувачів з однаковим телефоном, якщо той зберігається у користувацьких властивостях через b_user_field.

2. Злиття через API користувачів. При виявленні дубля викликається CUser::Merge() — метод переносить всі замовлення, підписки, бонусні бали на майстер-акаунт і деактивує дубль. Важливо попередньо перевірити залежні таблиці: b_sale_order, b_sale_fuser, b_rating_vote, b_forum_user, b_subscribe_subscriber.

// Злиття: всі дані дубля переходять до майстер-користувача $result = CUser::Merge($masterUserId, $duplicateUserId); if (!$result) { $GLOBALS['APPLICATION']->GetException(); } 

3. Таблиця b_sale_fuser (fake user). Це ключова таблиця для анонімних сесій. Кожен гість отримує запис у b_sale_fuser з USER_ID = NULL. При авторизації метод CSaleUser::DoAutoLogin() має зв'язати FUSER_ID з реальним USER_ID. Якщо цей крок пропущено — кошик і незавершені замовлення залишаються «підвішеними» і не потрапляють у профіль.

Користувацькі поля та прив'язка гостьових сесій

Додаткові атрибути клієнта (дата народження, стать, вподобання) зберігаються в b_uts_user — автоматично створювана таблиця для користувацьких полів (UserTypeEntity з ENTITY_ID = 'USER'). При злитті CUser::Merge() ці дані не переносяться автоматично — метод копіює лише поля основної таблиці b_user. Потрібно вручну перенести значення з b_uts_user до виклику злиття.

Стандартний обробник OnAfterUserAuthorize спрацьовує при кожному вході. У ньому зручно реалізувати:

AddEventHandler('main', 'OnAfterUserAuthorize', function($fields) { if ($fields['USER_ID'] > 0) { // Переносимо кошик гостя на авторизованого користувача $fuserId = CSaleUser::GetAnonymousUserID(); CSaleBasket::TransferBasket($fuserId, $fields['USER_ID']); } }); 

Як CUser::Merge вирішує проблему?

На одному проєкті з каталогом 150 000 товарів ми виявили 12 000 дублюючихся профілів. Після налаштування злиття через CUser::Merge обробили всю чергу за 4 години. Клієнт перестав втрачати замовлення — кількість анонімних кошиків скоротилась на 87%. Документація CUser::Merge

Важливість єдиного профілю для e‑commerce

Без злиття клієнтської бази втрачається до 20–30% виручки — клієнти йдуть, не бачачи історії замовлень, менеджери витрачають час на ручне об'єднання. Налаштований механізм дає єдину картину, у 2–4 рази швидшу обробку замовлень і менше помилок у доставці. Скорочення бюджету на супровід сягає 40%. Для одного з наших клієнтів економія склала 3000 € на місяць. Замовте аудит вашої бази — стартовий аудит коштує 200 €.

Ми гарантуємо цілісність даних та безпеку під час злиття. Наша команда має сертифікацію Bitrix Partner.

Як злиття профілів впливає на продуктивність?

Злиття через CUser::Merge() — доволі важка операція: вона перезаписує кілька таблиць, оновлює кеш і викликає агентів. На базах із сотнями тисяч користувачів процес може займати до 30 секунд. Щоб не вішати інтерфейс користувача, ми запускаємо злиття як агент з асинхронним виконанням. Для цього створюється черга дублів в окремій таблиці, і агент обробляє по 100 дублів за один запуск.

CAgent::AddAgent( "CMergeAgent::ProcessBatch(100);", "main", "N", 60 ); 

Автоматичне злиття працює в 5 разів швидше за ручне.

Що входить у роботу

Терміни: від 5 до 15 днів. Вартість від 1000 до 5000 €, економія бюджету до 50%. Отримайте консультацію щодо інтеграції.