Модуль для устранения дублей контактов в Б24

Разработали модуль для Битрикс24, который позволяет удалить и объединить дубли контактов и привести в порядок клиентскую базу в 500 000 записей всего за 2,5 – 3 часа.

Индикатор прокрутки статьи

Модуль для устранения дублей контактов в Б24

Привет! Я CEO Webest Дмитрий Чистяков. Одно из направлений деятельности нашего агентства - внедрение, кастомизация CRM-систем и их интеграция со сторонними сервисами и продуктами. В статье речь пойдет о нашей недавней разработке - модуле контроля дубликатов в Б24.

Рассмотрим использование модуля на примере Автоцентра “Прагматика”. Ранее мы уже проводили для компании миграцию из облачного «Битрикс24» на «1С-Битрикс24»: Энтерпрайз. Произвести примитивную интеграцию SQL баз с облачным порталом “Битрикс24” и импортировали в CRM-систему существующую клиентскую базу. Подробнее об этом читайте в кейсе. Кейс также размещен на сайте партнеров Битрикс24.

Предпосылки создания модуля

В базах контрагентов у крупных компаний, как правило, количество карточек контрагентов доходит до нескольких сотен тысяч.

Отсюда практически у всех компаний есть потребность время от времени производить процедуру дедупликации (избавления от дубликатов данных) клиентской базы. Дубликаты в базе могли появиться по разным причинам и разными способами. Но цель одна — максимально быстро, качественно и безболезненно избавиться от дублирующих копий и сделать клиентскую базу максимально «чистой». 

  • В нашей практике мы очень часто от клиентов получали такой запрос, но решения не было.

Да, в штатном функционале Битрикс24 есть возможность объединять дубликаты контрагентов (подробное описание предоставлено по ссылке — https://helpdesk.bitrix24.ru/open/10649014/), но данный функционал учитывает далеко не все сценарии и потребности клиентов.

В связи с этим мы разработали модуль поиска и объединения дубликатов для коробочных порталов Битрикс24. Модуль включает в себя следующие возможности, которых нет в штатном функционале Б24:

  • Поиск дубликатов клиентов [контактов] на портале по абсолютно любым комбинациям реквизитов, как штатным [системным], так и пользовательским полям;
  • Объединение дубликатов клиентов с возможностью оставить на портале карточку «оригинала» с минимальным (первым по дате создания) или максимальным ID (последним по дате создания);
  • После объединения дубликатов на портале в карточку «оригинала» передаются все связанные объекты, такие как: лиды, компании, сделки, смарт-процессы, универсальные списки, дела;
  • Передача/выгрузка данных о результатах дедупликации в сторонние сервисы; Это даёт возможность производить процедуру дедупликации контрагентов в сервисах, с которыми настроен обмен данными, например с 1С.
  • Быстрый поиск и объединение дубликатов по клиентской базе, которая измеряется сотнями тысяч контрагентов.

Особенности модуля

Отмечу сразу, что:

  • На момент публикации модуль позволяет искать и объединять сущности дубликатов только для «Контактов». В дальнейшем по мере необходимости будет реализован аналогичный функционал и для «Компаний»;
  • Умышленно не реализована возможность объединения/переноса данных из штатных /пользовательских реквизитов, так как дубликаты практически всегда содержат одни и те же значения пользовательских полей в карточках.

Концепция модуля заточена под сценарий, когда необходимо найти дубликаты, произвести их объединение и перенести все связанные объекты, но при этом обогащение карточек оригиналов пользовательскими полями не требуется. Это обстоятельство обусловлено запросами от клиентов. В большинстве случаев достаточно только произвести объединение и перенести все связанные объекты.

Основные настройки модуля

Основные настройки модуля

Раздел «Основные настройки» включает в себя следующее:

  1. ID пользователя, от которого будет проходить объединение. Необходимо указать ID пользователя на портале, который будет проводить удаление карточек дубликатов, а также перепривязывать связанные объекты при объединении. То есть здесь необходимо указать ID того пользователя, у которого есть права администратора для удаления карточек контактов на портале.
  2. Выбираем, какую сущность оставляем на портале. То есть необходимо указать, какая карточка после процедуры объединения будет оставлена на портале – с максимальным ID или наоборот с минимальным.
  3. Сущности (справочники), которые будут переданы в карточку. Необходимо выбрать, какие сущности (объекты) будут перенесены в карточку «оригинала». При этом все связанные «дела» в карточку «оригинала» будут переданы по умолчанию.
  4. Настройки подключения к базе данных. Указываем доступы к внешней базе данных для синхронизации изменений на портале.

Поиск дубликатов

В разделе «CRM контакты» задаем параметры для поиска дубликатов на портале.

В настройках отбора/поиска можно задать фактически любые комбинации по условию поиска:

и по типу пользовательского поля/реквизита:

Приведу несколько простых примеров (комбинаций), по которым можно получить результаты по проверке дубликатов на портале:

  • Пример 1: NAME [строка] и PHONE [Множественное, где есть совпадение хотя бы по 1 номеру телефона] и BIRTHDATE [Дата] В результате мы получим выборку, где у контактов одинаковые значения в реквизитах: Имя и Дата рождения, а также где есть совпадения хотя бы по одному номеру телефона
  • Пример 2: UF_CRM_1608182734 [Диапазон по числовому полю с 100 до 1000] и EMAIL [Множественное, где есть совпадение по 2 e-mail адресам]В результате мы получим выборку контактов, у которых в реквизите «Бонусные баллы» значения в диапазоне от 100 до 1000, а также где есть совпадения по двум e-mail адресам.
  • Пример 3: UF_CRM_1587988967578 [строка не заполнено] и LAST_NAME [строка] и NAME [строка]В результате мы получим выборку контактов, у которых реквизит «GUID_1С» не заполнен, а также где есть совпадения по имени и фамилии клиента.

Процесс поиска дубликатов

  1. При нажатии на кнопку «Запустить задание на поиск дубликатов» мы составляем оптимальный sql запрос, который получает все необходимые данные по контакту за один раз, не подтягивая избыточные данные, что экономит как память, так и время.
  2. Далее мы собираем массив всех контактов с уже найденными свойствами и имеем на выходе базу только необходимых данных, что позволяет быстрее производить поиск.
  3. Проходясь по каждому элементу массива, мы находим группы дубликатов по первому свойству в списке полей.
  4. Затем производим фильтр уже по найденным группам, уменьшая выборку дубликатов. Таким образом, процедура поиска дубликатов на клиентской базе более чем в 500 000 записей занимает всего порядка 2,5 – 3 часов.

В процессе запуска задания на поиск дубликатов также создается одиночный агент, который автоматически самоудаляется в конце операции. Агент осуществляет функцию блокировки запуска поиска либо объединения дубликатов для предотвращения наслаивания процессов. 

Функции агента:

Функции агента

  • Соответственно, после окончания поиска или объединения дубликатов кнопки вновь становятся активными для использования.
  • После того, как процесс поиска дубликатов отработал, все найденные дубликаты заносятся в таблицу b_crm_duplicates

Мониторинг производительности: таблица b_crm_duplicates:

В данной таблице фиксируется:

  • ID_parent – уникальный (оригинальный) ID клиента, который в последствии останется на портале;
  • Parent_data и duplicate_data – в данных реквизитах фиксируются значения реквизитов, по которым осуществлялся поиск.

В случае необходимости можно визуально сравнить/проверить отработку поиска дубликатов, а также экспортировать результаты в таблицу excel.

Отображение прогресса

Для удобства отображения прогресса на странице поиска дубликатов используется специальный компонент, который обращается к таблицам и агентам, чтобы 1) определить, запущена ли какая-то из операций, 2) либо чтобы отобразить прогресс в режиме реального времени.

Результат поиска дубликатов выглядит следующим образом:

Объединение дубликатов

При нажатии на кнопку «Запустить объединение дубликатов» мы проверяем существование специального агента для объединения на портале.

  1. В случае его отсутствия, агент автоматически будет создан.
  2. В случае его наличия данный агент просто активируется, когда происходит повторный запуск объединения дубликатов на портале.

То есть агент создается только один раз, а далее он просто деактивируется на время поиска либо паузы операций.

  • Запустившийся агент получает данные из таблицы b_crm_duplicates и производит объединение записей по родителю (id_parent). Следовательно, все найденные дубликаты будут удалены с портала, а связанные с ними объекты/сущности перенесены в карточку родителя.

Следует отметить, что при запуске агента, процесс запускается только для одного родителя. При этом агент запускается каждые 10 секунд.

По нашим наблюдениям, данный временной интервал является оптимальным для того, чтобы успеть удалить карточки всех дубликатов, а также перенести все связанные сущности в карточку основного контакта.

  • В результате, после окончания процедуры, объединение дубликатов и всех связанных сущностей из карточек дубликатов, а также «дела» (звонки, комментарии, встречи, письма и пр.) будут перенесены в карточку родителя (основного контакта).

Результаты объединения

Результаты объединения можно посмотреть в отдельной таблице базы данных b_crm_duplicates_saved

В данной таблице фиксируется:

  • ID_ITEM – уникальный (оригинальный) ID клиента, который остался на портале;
  • ITEM_FIELDS – в данных реквизитах фиксируются значения реквизитов, по которым осуществлялся поиск.

В случае необходимости можно из публичной части портала найти данного контрагента в клиентской базе и убедиться в корректности отработки процедуры объединения дубликатов. Также данные из таблицы можно экспортировать в excel.

Обмен с внешними сервисами

В рамках данного решения заложен функционал, который предоставляет возможность передавать/выгружать данные о результатах произведенной дедупликации в сторонние сервисы.

Для понимания приведем пример из практики:

  • У клиента на портале реализована интеграция с 1С с разными клиентскими базами. Соответственно, из каждой базы выгружаются контрагенты. Каждый контрагент обладает уникальным GUID (идентификатором).
  • В разных базах 1С GUID может быть уникальным, но при этом клиент может являться дубликатом. Этому могут служить разные причины: ошибки при заведении контрагентов на стороне 1С, специфика рода деятельности компании и др.
  • Через модуль контроля дубликатов мы находим дубликаты по комбинации соответствующих реквизитов, например: фамилия + имя + отчество + дата рождения. Производим объединение найденных дубликатов.
  • Выгружаем во внешнюю базу данных SQL информацию о найденных и удаленных дубликатах на портале. При этом передаем информацию по GUID клиента и ID уникального объекта на портале, по которым уже 1С, в свою очередь, может произвести процедуру дедупликации в соответствующих базах.

  • Сценариев и кейсов обмена с внешними сервисами может быть достаточно много. Мы готовы адаптировать и дорабатывать такого рода «связку» и с другими информационными системами/ресурсами, но как правило (в большинстве случаев) это всё же типовой обмен с базами данных SQL, из которых поступают данные для обмена/выгрузки из разных баз 1С.

Использование модуля

Реализовали нужное решение, которое подойдет многим, кто использует коробочную версию Битрикс24, хочет быстро провести дедупликацию контактов и перенести все связанные сущности в карточку основного контакта.

Обращайтесь к нам: с удовольствием проконсультируем, обсудим детали и адаптируем/доработаем функционал решения под потребности вашего проекта.

Оставить заявку можно на нашем сайте.

 

Другие статьи по теме:

вверх

Расскажите о вашем проекте

Заполните форму и мы ответим вам в течение рабочего дня

Обязательное поле для заполнения
Обязательное поле для заполнения
Обязательное поле для заполнения
Обязательное поле для заполнения
Обязательное поле для заполнения
Резюме.pdf

Нажимая на кнопку, вы принимаете политику конфиденциальности и даете согласие на обработку ваших персональных данных