Зіставлення, злиття і survivorship

🌐 Також доступно 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, Dallas, d.reyes@example.com, і Dan Reyes, Dallas, d.reyes@example.com. Та сама людина? Мабуть. Чи варто їх злити? Це інше запитання. А якщо зіллємо, які телефон, адреса й посада виживуть? Знову інше. Архітекторам треба тримати три рішення окремо:

• Зіставлення: чи представляють ці записи те саме?
• Злиття: чи мають вони стати одним записом?
• Survivorship: якщо ми поєднуємо дані, які значення перемагають?

Зіставлення йде першим

Розділ 3 розглянув правила дублікатів і зіставлення Salesforce, тож механіку я не викладатиму знову. Архітектурне запитання — які докази достатньо сильні, щоб сказати, що це, можливо, те саме? Для людини: пошта, телефон, ім’я плюс адреса, номер клієнта, якесь поєднання. Для компанії: юридична назва, податковий ID, ID клієнта в ERP, адреса, вебдомен. Не «чи може Salesforce порівняти ці поля?», а «яке поєднання дає нам достатньо впевненості, щоб діяти?»

І точний збіг — не певність. Спільна пошта — сильний сигнал, а не доказ: родини мають спільні адреси, компанії використовують purchasing@company.com, номери телефонів належать домогосподарствам, імена й адреси не унікальні, і навіть сильні ідентифікатори використовують повторно, вводять із помилками чи переприсвоюють. Зіставлення — не порівняння рядків. Це твердження про ідентичність.

Ціна помилки

Викладаючи це, я змінюю домен. В автомобільних маркетингових даних ми помилково вирішуємо, що два Daniel Reyes — одна людина, і не той отримує пропозицію на SUV. Не добре, але ризик низький. Тепер зробіть той самий хибний збіг у медичних даних: поєднано медичні історії двох різних людей. Та сама помилка зіставлення, зовсім інший наслідок. Тому немає універсального «доброго» порогу зіставлення. Іноді більший ризик — пропустити збіг; іноді — поєднати двох людей, що не є однією. Там, де хибні збіги дорогі, я свідомо зіставляю менше.

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

Зіставлення також залежить від форми даних. AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198. Гармонізація робить значення порівнюваними: стандартні формати, нормалізовані скорочення, зіставлені коди. Потім ви зіставляєте. Лише коли відомо, що записи належать разом, ви консолідуєте їхню інформацію в одне представлення. Гармонізація — не зіставлення, зіставлення — не злиття, а консолідація — не обов’язково керування.

Click to enlarge

Рішення про ідентичність ухвалюються етапами.

Збіг не вимагає злиття

Це одна з найважливіших відмінностей розділу. Ми впевнені, що два записи клієнтів із двох старих систем — та сама компанія. Чи мусимо ми їх злити? Ні. Кожен може нести ідентичність із системи-джерела; історичні транзакції можуть вказувати на кожен; аудиторам може знадобитися слід; ми, можливо, ще мігруємо; нам, можливо, треба точно знати, що казала стара система. Знання, що два записи — одне й те саме, не змушує нас їх згортати. Ми можемо їх пов’язати, і часто це безпечніша архітектура.

Моє правило злиття: явний переможець

Моя позиція: зливайте лише тоді, коли є явний переможець, а дублікат не додає нічого, що треба зберегти. Продавець учора створив дубль акаунта; оригінал явно є усталеним записом. Добрий кандидат на злиття. Тепер змініть умови: ми імпортували клієнтів із застарілої системи — з її власними ID, старішими значеннями, можливо транзакціями чи вимогами аудиту, прив’язаними до них. Я набагато обережніший. Зберігайте дублікати із зовнішніх завантажень, якщо, можливо, доведеться простежити назад до старіших значень, бо злиття знищує цю історію.

Що насправді робить злиття в Salesforce

Зв’язок каже «ці належать разом». Злиття каже «тепер це одне», і в Salesforce це справжня зміна. Для акаунтів ви обираєте до трьох записів і один із них — як основний (principal); ви обираєте, які значення полів інших зберегти, а приховані й доступні лише для читання поля беруться з основного. Злитий запис зберігає Created By і Created Date найстарішого запису, хоч би котрий був основним. Неосновні записи йдуть у кошик. Пов’язані записи, як-от активності, переходять до злитого запису, з винятками. У Lightning злиття працює з дублікатами, які виявляють ваші правила дублікатів. А для персональних акаунтів об’єкти контактних точок не підтримують злиття: їхні зв’язки втрачаються (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, посилання інтеграцій. Перш ніж зливати батька, зрозумійте, що станеться з усім, що до нього прикріплено. Коли дублікати приходять із завантаженням, я даю командам три варіанти для дочірніх записів: перенести їх на запис, що виживає; не завантажувати їх узагалі, якщо вони нікому не потрібні; або лишити їх на іншому записі, позначеному як неактивний, щоб вони все одно знаходилися пошуком. Перший — це те, що злиття робить за вас. Два інші зберігають слід, і часто саме в цьому суть.

Survivorship: яке значення перемагає?

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

«Найновіше» — не технічне налаштування. Це твердження про довіру: коли системи розходяться, найновіше значення ймовірніше правильне. Розумно для мобільного номера. Жахливо для юридичної назви: якщо нею володіє ERP, мені байдуже, що хтось змінив копію в Salesforce п’ять хвилин тому. «Найчастіше» припускає, що згода — це доказ, але три застарілі копії нижче за потоком не переголосують систему обліку. «Пріоритет джерела» каже прямо: ми довіряємо цьому джерелу більше. Тож survivorship належить до архітектури й врядування, і кожному правилу потрібен власник. Хто вирішив, що перемагає найновіша адреса чи що ERP переважає Salesforce?

Якщо карта авторитетності з модуля 1 уже каже, що ERP володіє кредитним лімітом, survivorship простий: перемагає ERP, жодного хитрого оцінювання не треба. Складні випадки — атрибути, авторитетність щодо яких спільна, неясна чи базується на доказах, а не на одному майстрі. Саме там правила survivorship відпрацьовують свій хліб.

Click to enlarge

Правила survivorship — це твердження про довіру.

Пороги, перегляд і збагачення

Деяке зіставлення зважує докази: збіг ID клієнта дуже сильний, пошти — сильний, телефону — помірний, схоже ім’я — слабкий, схожа адреса — допоміжний. Вище одного балу — збіг; нижче іншого — різні; між ними — переглядає людина. Урок не в алгоритмі. Поріг — це ваша толерантність до помилок, і він має йти за бізнес-ризиком. А коли докази порушують запитання, але не розв’язують його, не вдавайте, що система знає. Відправте на перегляд. Повільніше, і це нормально: автоматизація не цінна, коли впевнено зливає двох різних клієнтів.

Збагачення додає ще одне запитання про походження. Поштові довідкові дані, галузеві коди, фірмографіка, зовнішні оцінки ризику покращують основні дані, але звідки кожне значення, наскільки воно надійне й актуальне, чи можемо ми використовувати його для цієї мети, чи містить воно персональні дані? «Галузь = Транспорт» від постачальника даних — не те саме, що сказав вам клієнт. Тримайте цю відмінність.

Steve Trucking: схоже — не означає те саме

Два роздрібні партнери надсилають доставки John Smith, 123 Main Street, Columbus, з тим самим номером телефону. Та сама людина? Мабуть. Чи має Steve Trucking їх уніфікувати? Згадайте, чиї вони: ці отримувачі — клієнти партнерів, а один партнер ніколи не має бачити отримувачів іншого. Хибний збіг змішав би дані через цю межу. Раптом це вже не питання якості даних, а питання приватності й ізоляції — саме тому пороги залежать від наслідків. Рішення ухвалює контрольна точка. Поки що: не дайте зручності зіставлення ухвалити бізнес-рішення.

Іноді збережений безлад щось вам каже. Цей запис зі старої системи, той — із Salesforce, цей — від придбаної компанії; їхні ID, їхня історія і сам факт, що вони розходилися, можуть мати значення. Чисті дані цінні. Простежуваність — теж. Що важливіше для конкретного використання, вирішує архітектор.

За межами іспиту: що змінює ШІ. Раніше поганий збіг означав два листи чи розщеплену історію сервісу. Тепер агент знаходить того, кого вважає клієнтом, і витягує його замовлення, звернення, адреси й нотатки. Якщо двох людей помилково зіставили, він може діяти на інформації однієї людини замість іншої. Рішення про зіставлення стало частиною межі безпеки, і там, де змішування дороге, суворіше зіставлення — безпечніший дизайн.

Що тут вирішує архітектор

• Яких доказів достатньо, щоб позначити можливий дублікат у кожному домені даних.
• Чи стає підтверджений збіг злиттям, зв’язком чи переглядом людиною.
• Які значення переживають розбіжність і хто володіє кожним правилом survivorship.
• Скільки ризику хибного збігу бізнес може стерпіти порівняно з ризиком пропущеного збігу.
• Які ідентичності джерел, історію й пов’язані записи треба зберегти перед будь-яким злиттям.

Зіставляйте ретельно, зливайте свідомо, обирайте правила survivorship навмисно. Чистий запис клієнта мало чого вартий, якщо ви дійшли до нього, поєднавши не тих клієнтів.

Додаткові матеріали

• 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).