Налаштування дедублікації даних у CRM Бітрікс24
Контакти-дублікати, компанії та угоди — хронічна проблема будь-якої CRM, яка існує більше півроку. Менеджери створюють картки вручну, ліди надходять із різних джерел, а імпорт з Excel накладається на наявну базу. У результаті відділ продажів втрачає контекст листування, аналітика брехні, а автоматизація спрацьовує двічі.
Бітрікс24 має вбудований механізм дедублікації, але «з коробки» він працює лише за точним збігом полів. Щоб він дійсно допомагав, його потрібно налаштувати під конкретну базу.
Як працює дедублікація у Бітрікс24
Система порівнює новий запис з наявними за набором критеріїв збігу: телефон, email, назва компанії, ідентифікаційний код. Логіка реалізована в модулі crm через клас CCrmEntityMerger та REST-метод crm.duplicate.findbycomm.
Пошук дублікатів запускається:
- при ручному створенні картки — з'являється попередження;
- під час імпорту — прапорець «Перевіряти дублікати» у майстрі імпорту;
- через REST при інтеграціях — метод повертає масив потенційних дублікатів до збереження.
Налаштування критеріїв: CRM → Налаштування → Дублікати. Тут задається, за якими полями і з якою вагою система вважає записи такими, що збігаються.
Налаштування критеріїв збігу
Ключовий момент — не вмикати все підряд. Практика показує: що більше критеріїв, то більше хибних спрацьовувань і то повільніше працює перевірка на великих базах (від 50k записів).
Оптимальна конфігурація для більшості B2B-компаній:
| Сутність | Поле | Пріоритет |
|---|---|---|
| Контакт | Телефон (нормалізований) | Високий |
| Контакт | Високий | |
| Компанія | Ідентифікаційний код | Критичний |
| Компанія | Назва | Середній (fuzzy) |
| Угода | Назва + компанія | Низький |
Нормалізація телефону є критичною: +380 (44) 123-45-67 і 0441234567 — один номер. Бітрікс24 нормалізує телефони автоматично через CPhoneNumber::Normalize(), але лише якщо тип поля задано як «Телефон», а не довільний текст.
Масова перевірка наявної бази
Після увімкнення дедублікації наявні дублікати нікуди не зникають — система перевіряє лише нові записи. Для разового очищення використовуйте вбудований інструмент: CRM → Контакти → Ще → Знайти дублікати.
Для баз понад 100k записів вбудований інструмент працює повільно. Розумніше зробити вибірку через REST і обробити батчами:
// Пошук дублікатів за email через REST API
$result = CRest::call('crm.duplicate.findbycomm', [
'type' => 'EMAIL',
'values' => ['[email protected]'],
'entity_type' => 'CONTACT',
]);
// Повертає масив ID потенційних дублікатів
Типовий цикл очищення: вивантажити всі контакти з email → згрупувати за нормалізованим email → для кожної групи з 2+ записів запустити crm.merge із визначеними правилами пріоритету полів.
Автоматичне об'єднання через REST
Якщо процес повторюється регулярно (наприклад, щоночі після імпорту лідів), автоматизуйте його агентом Бітрікса або зовнішнім cron-скриптом:
// crm.merge — об'єднання двох контактів
CRest::call('crm.contact.merge', [
'id' => 1001, // головний запис (зберігається)
'victims' => [1002, 1003], // записи, що поглинаються
]);
Перед запуском об'єднання обов'язково визначте правило вибору «головного» запису: зазвичай це запис з більшою кількістю активностей або ранішою датою створення.
Типові проблеми та їх вирішення
Хибні дублікати за назвою компанії. «ТОВ Ромашка» і «Ромашка ТОВ» — Бітрікс24 вважає різними. Підключіть нормалізацію через хук OnBeforeCRMCompanyAdd з видаленням організаційно-правової форми з назви.
Дублікати з різних джерел лідів. Якщо один клієнт залишив заявку на сайті й зателефонував — два ліди з різним набором даних. Налаштуйте об'єднання лідів у контакт через бізнес-процес із перевіркою дублікатів на етапі конвертації.
Продуктивність на великих базах. Індекси таблиць b_crm_contact і b_crm_company за полями PHONE та EMAIL — обов'язкові. Перевірте їх наявність у БД, особливо після міграцій.
Дедублікація — це не разова акція, а регулярний процес. Налаштуйте щотижневий звіт за кількістю потенційних дублікатів і тримайте метрику під контролем.