Сопоставление, слияние и правила выживания

🌐 Также доступно на 28 языках

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Изображение создано с помощью ИИ

Переведено ИИ. Сообщество еще не проверило перевод. Читать на английском

Модуль 3 из 6 главы Мастер-данные и идентичность, глава 6 курса Data Architect. Каждый модуль самостоятелен. Назад: Четыре способа управлять мастер-данными · Далее: Карта — это не решение

Вопрос, на который отвечает этот модуль: как находить дубликаты и решать, какие значения выживут?

В Salesforce два контакта: Daniel Reyes, Даллас, d.reyes@example.com, и Dan Reyes, Даллас, d.reyes@example.com. Один и тот же человек? Вероятно. Нужно ли их слить? Это другой вопрос. А если сливать, то какой телефон, адрес и должность выживут? И это снова другой вопрос. Архитектору нужно держать три решения раздельно:

• Сопоставление: представляют ли эти записи одно и то же?
• Слияние: должны ли они стать одной записью?
• Правила выживания значений (survivorship): если мы объединяем данные, какие значения побеждают?

Сначала сопоставление

Глава 3 разобрала правила дубликатов и правила сопоставления Salesforce, поэтому механику я заново объяснять не буду. Архитектурный вопрос такой: каких доказательств достаточно, чтобы сказать «это, возможно, одно и то же»? Для человека: адрес электронной почты, телефон, имя плюс адрес, номер клиента, какая-то комбинация. Для компании: юридическое название, ИНН, ID клиента в ERP, адрес, веб-домен. Не «может ли Salesforce сравнить эти поля?», а «какая комбинация дает нам достаточно уверенности, чтобы действовать?»

И точное совпадение — еще не уверенность. Общий адрес электронной почты — сильный сигнал, но не доказательство: члены семьи живут по одному адресу, компании используют purchasing@company.com, телефоны принадлежат домохозяйствам, имена и адреса не уникальны, и даже сильные идентификаторы используются повторно, вводятся с опечатками или перерабатываются. Сопоставление — это не сравнение строк. Это утверждение об идентичности.

Цена ошибки

Когда я это преподаю, я меняю домен. В маркетинговых данных автодилера мы ошибочно решаем, что два Daniel Reyes — один человек, и не тот получает предложение о внедорожнике. Нехорошо, но риск низкий. Теперь сделайте ту же ложную привязку в медицинских данных: объединены истории болезни двух разных людей. Та же ошибка сопоставления — совершенно другие последствия. Вот почему не существует универсально «хорошего» порога сопоставления. Иногда больший риск — пропустить совпадение; иногда — объединить двух разных людей. Там, где ложные совпадения дорого обходятся, я сознательно сопоставляю меньше.

Гармонизируйте, затем сопоставляйте, затем консолидируйте

Сопоставление зависит и от формы данных. AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198. Гармонизация делает значения сравнимыми: стандартные форматы, нормализованные сокращения, сопоставленные коды. Потом вы сопоставляете. И только когда известно, что записи относятся друг к другу, вы консолидируете их информацию в одно представление. Гармонизация — не сопоставление, сопоставление — не слияние, а консолидация — не обязательно мастеринг.

Click to enlarge

Решения об идентичности принимаются поэтапно.

Совпадение не требует слияния

Это одно из самых важных различий в главе. Мы уверены, что две записи клиентов из двух старых систем — одна и та же компания. Обязаны ли мы их слить? Нет. Каждая может нести идентичность исходной системы; на каждую могут ссылаться исторические транзакции; аудиторам может понадобиться след; мы, возможно, еще в процессе миграции; нам может понадобиться точно знать, что говорила старая система. Знание, что две записи — одно и то же, не заставляет нас схлопывать их. Мы можем их связать, и часто это более безопасная архитектура.

Мое правило слияния: явный победитель

Моя позиция: сливайте, только когда есть явный победитель, а дубликат не добавляет ничего, что нужно сохранить. Торговый представитель вчера создал дубликат организации; оригинал — явно устоявшаяся запись. Хороший кандидат на слияние. Теперь изменим ситуацию: мы импортировали клиентов из унаследованной системы — с ее собственными ID, более старыми значениями, может быть, с привязанными к ним транзакциями или требованиями аудита. Здесь я гораздо осторожнее. Сохраняйте дубликаты из внешних загрузок, если вам может понадобиться проследить путь к старым значениям, потому что слияние уничтожает эту историю.

Что на самом деле делает слияние в Salesforce

Связь говорит: «это относится друг к другу». Слияние говорит: «теперь это одно», и в Salesforce это настоящее изменение. Для организаций вы выбираете до трех записей и назначаете одну из них основной (principal); вы выбираете, какие значения полей из остальных сохранить, а скрытые поля и поля только для чтения берутся из основной. Объединенная запись сохраняет Created By и Created Date самой старой записи, какая бы ни была основной. Неосновные записи попадают в корзину (Recycle Bin). Связанные записи, например активности, переносятся в объединенную запись — с исключениями. В Lightning слияние работает с дубликатами, которые находят ваши правила дубликатов. А для персональных учетных записей (Person Account) объекты точек контакта (contact point) не поддерживают слияние: их связи теряются (Considerations for Merging Duplicate Accounts (opens in a new tab); Merge Duplicate Accounts in Lightning Experience (opens in a new tab)).

Знать к экзамену. Знайте, что делает слияние организаций в Salesforce: до трех записей; одна основная (principal), чьи скрытые поля и поля только для чтения сохраняются; Created By и Created Date самой старой записи, какая бы ни была основной; остальные записи попадают в корзину (Recycle Bin); а для персональных учетных записей объекты точек контакта не сливаются.

Чтобы принять решение, не нужно знать все пограничные случаи. Нужно понимать последствие: после слияния независимых записей, с которых вы начинали, больше нет. Здесь работает тест на обратимость из главы 1: связывание легко отменить; слияние — нет. И клиент редко существует сам по себе: контакты, обращения, возможности, файлы, записи о согласии, пользовательские дочерние записи, внешние ID, ссылки интеграций. Прежде чем сливать родительскую запись, разберитесь, что произойдет со всем, что к ней привязано. Когда дубликаты приходят с загрузкой, я даю командам три варианта для дочерних записей: перенести их на выжившую запись; не загружать их вовсе, если они никому не нужны; или оставить их на другой записи, помеченной как неактивная, чтобы они по-прежнему находились поиском. Первое за вас делает слияние. Два других сохраняют след, а часто именно в этом и смысл.

Правила выживания: какое значение побеждает?

Записи относятся друг к другу, но расходятся: Salesforce и биллинг говорят 602-555-0100, ERP — 602-555-0188. Победителя выбирают правила выживания значений (survivorship). Распространенные: самое свежее (последнее обновление), самое частое (значение, на котором сходится большинство источников) и приоритет источника (этому источнику доверяем больше, чем тому), плюс комбинации, пороги, веса и правила, специфичные для бизнеса. Ни одно из них не верно само по себе.

«Самое свежее» — это не техническая настройка. Это заявление о доверии: когда системы расходятся, самое новое значение с большей вероятностью верно. Разумно для мобильного номера. Ужасно для юридического названия: если им владеет ERP, мне все равно, что кто-то пять минут назад изменил копию в Salesforce. «Самое частое» предполагает, что согласие — это доказательство, но три устаревшие копии ниже по потоку не перевешивают систему записи. «Приоритет источника» говорит прямо: этому источнику мы доверяем больше. Поэтому правила выживания значений относятся к архитектуре и управлению данными, и у каждого правила должен быть владелец. Кто решил, что побеждает самый новый адрес или что ERP старше Salesforce?

Если карта полномочий из модуля 1 уже говорит, что кредитным лимитом владеет ERP, с правилами выживания все просто: побеждает ERP, никакой хитрой системы баллов не нужно. Трудные случаи — атрибуты, полномочия по которым разделены, неясны или основаны на доказательствах, а не на одном мастере. Вот там правила выживания и отрабатывают свой хлеб.

Click to enlarge

Правила выживания значений — это заявления о доверии.

Пороги, проверка и обогащение

Некоторые методы сопоставления взвешивают доказательства: совпадение ID клиента — очень сильное, адрес электронной почты — сильное, телефон — умеренное, похожее имя — слабое, похожий адрес — вспомогательное. Выше одного балла — совпадение; ниже другого — разные; посередине — запись проверяет человек. Урок не в алгоритме. Порог — это ваша терпимость к ошибке, и он должен следовать за бизнес-риском. А когда доказательства поднимают вопрос, но не решают его, не делайте вид, что система знает ответ. Отправьте запись на проверку. Медленнее — и это нормально: автоматизация не ценна, если она уверенно сливает двух разных клиентов.

Обогащение добавляет еще один вопрос о происхождении. Почтовые справочные данные, отраслевые коды, фирмографика, внешние оценки риска улучшают мастер-данные, но откуда пришло каждое значение, насколько оно надежно и актуально, можно ли использовать его для этой цели, содержит ли оно персональные данные? «Отрасль = Транспорт» от поставщика данных — не то же самое, что сказал вам сам клиент. Сохраняйте это различие.

Steve Trucking: похожий — не значит тот же

Два розничных партнера отправляют доставки для John Smith, Main Street, 123, Колумбус, с одним и тем же номером телефона. Один и тот же человек? Вероятно. Должен ли Steve Trucking их унифицировать? Вспомните, чьи они: эти получатели — клиенты партнеров, и один партнер никогда не должен видеть клиентов другого. Ложное совпадение смешало бы данные через эту границу. И вдруг это уже вопрос не качества данных, а конфиденциальности и изоляции — именно поэтому пороги зависят от последствий. Решение примет контрольная точка. А пока: не позволяйте удобству сопоставления принимать бизнес-решение.

Иногда сохраненный беспорядок сам что-то сообщает. Эта запись пришла из старой системы, та — из Salesforce, эта — из купленной компании; их ID, их история и сам факт, что они расходились, могут иметь значение. Чистые данные ценны. Прослеживаемость тоже. Архитектор решает, что важнее для конкретного использования.

За пределами экзамена: что меняет ИИ. Раньше плохое совпадение означало два письма или разорванную историю обслуживания. Теперь агент находит того, кого считает клиентом, и подтягивает его заказы, обращения, адреса и заметки. Если два человека были сопоставлены ошибочно, агент может действовать по информации одного человека в интересах другого. Решение о сопоставлении стало частью границы безопасности, и там, где смешение обходится дорого, более строгое сопоставление — более безопасный дизайн.

Что здесь решает архитектор

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

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

Дополнительно

• Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab) и Merge Duplicate Accounts in Lightning Experience (opens in a new tab) (на английском, проверено 2026-10-14).
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (на английском, проверено 2026-10-14).