Dopasowanie, scalanie i reguły przetrwania

🌐 Dostępne także w 28 językach

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

Obraz wygenerowany przez AI

Przetłumaczone przez AI. Jeszcze niesprawdzone przez społeczność. Czytaj po angielsku

Moduł 3 z 6 w rozdziale Dane podstawowe i tożsamość, rozdziale 6 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Cztery sposoby zarządzania danymi podstawowymi · Dalej: Mapa to nie decyzja

Pytanie, na które odpowiada ten moduł: jak znaleźć duplikaty i zdecydować, które wartości przetrwają?

Salesforce ma dwa kontakty: Daniel Reyes, Dallas, d.reyes@example.com, i Dan Reyes, Dallas, d.reyes@example.com. Ta sama osoba? Pewnie tak. Czy powinniśmy je scalić? To inne pytanie. A jeśli tak, który numer telefonu, adres i stanowisko przetrwają? To znowu inne pytanie. Architekci muszą trzymać osobno trzy decyzje:

• Dopasowanie: czy te rekordy odwzorowują to samo?
• Scalanie: czy powinny stać się jednym rekordem?
• Reguły przetrwania (survivorship): jeśli łączymy dane, które wartości wygrywają?

Najpierw dopasowanie

Rozdział 3 omówił reguły duplikatów i reguły dopasowania Salesforce, więc nie będę ponownie uczył mechaniki. Pytanie architektoniczne brzmi: jakie dowody są dość mocne, żeby powiedzieć, że to może być to samo? Dla osoby: e-mail, telefon, imię i nazwisko plus adres, numer klienta, jakaś kombinacja. Dla firmy: nazwa prawna, numer identyfikacji podatkowej, identyfikator klienta w ERP, adres, domena internetowa. Nie „czy Salesforce potrafi porównać te pola?”, ale „jaka kombinacja daje nam dość pewności, żeby działać?”.

A dokładne to nie pewne. Wspólny e-mail to mocny sygnał, nie dowód: rodziny mają wspólne adresy, firmy używają purchasing@company.com, numery telefonów należą do gospodarstw domowych, imiona, nazwiska i adresy nie są unikalne, a nawet mocne identyfikatory bywają ponownie używane, błędnie wpisywane albo przydzielane od nowa. Dopasowanie to nie porównywanie ciągów znaków. To stwierdzenie dotyczące tożsamości.

Koszt pomyłki

Kiedy tego uczę, zmieniam dziedzinę. W danych marketingowych branży motoryzacyjnej błędnie uznajemy, że dwóch Danielów Reyesów to ta sama osoba, i niewłaściwy dostaje ofertę na SUV-a. Niedobrze, ale ryzyko niskie. Teraz zróbmy to samo fałszywe dopasowanie w danych medycznych: połączone historie choroby dwóch różnych ludzi. Ten sam błąd dopasowania, zupełnie inna konsekwencja. Dlatego nie ma uniwersalnego „dobrego” progu dopasowania. Czasem większym ryzykiem jest przeoczenie dopasowania; czasem połączenie dwóch ludzi, którzy nie są tą samą osobą. Tam, gdzie fałszywe dopasowania są kosztowne, celowo dopasowuję mniej.

Najpierw harmonizuj, potem dopasuj, potem konsoliduj

Dopasowanie zależy też od kształtu danych. AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198. Harmonizacja sprawia, że wartości da się porównać: standardowe formaty, znormalizowane skróty, zmapowane kody. Potem dopasowujesz. Dopiero gdy wiadomo, że rekordy należą do siebie, konsolidujesz ich informacje w jedną reprezentację. Harmonizacja to nie dopasowanie, dopasowanie to nie scalanie, a konsolidacja to niekoniecznie zarządzanie danymi podstawowymi.

Click to enlarge

Decyzje o tożsamości zapadają etapami.

Dopasowanie nie wymaga scalenia

To jedno z najważniejszych rozróżnień w tym rozdziale. Jesteśmy pewni, że dwa rekordy klientów z dwóch starych systemów to ta sama firma. Czy musimy je scalić? Nie. Każdy może nieść tożsamość z systemu źródłowego; historyczne transakcje mogą wskazywać na każdy z nich; audytorzy mogą potrzebować śladu; możemy nadal być w trakcie migracji; możemy potrzebować wiedzieć dokładnie, co mówił stary system. Wiedza, że dwa rekordy to ta sama rzecz, nie zmusza nas do ich zwinięcia. Możemy je powiązać, a to często bezpieczniejsza architektura.

Moja zasada scalania: wyraźny zwycięzca

Moje stanowisko: scalaj tylko wtedy, gdy jest wyraźny zwycięzca, a duplikat nie wnosi niczego, co trzeba zachować. Handlowiec wczoraj utworzył duplikat konta; oryginał to wyraźnie ugruntowany rekord. Dobry kandydat do scalenia. Teraz zmieńmy sytuację: zaimportowaliśmy klientów ze starego systemu, z jego własnymi identyfikatorami, starszymi wartościami, może z powiązanymi transakcjami albo wymaganiami audytowymi. Jestem dużo ostrożniejszy. Zachowuj duplikaty z zewnętrznych importów, gdy możesz potrzebować dotrzeć do starszych wartości, bo scalenie niszczy tę historię.

Co naprawdę robi scalanie w Salesforce

Powiązanie mówi „te należą do siebie”. Scalenie mówi „to jest teraz jedno”, a w Salesforce to prawdziwa zmiana. W przypadku kont wybierasz maksymalnie trzy rekordy i jeden z nich wskazujesz jako główny (principal); wybierasz, które wartości pól z pozostałych zachować, a pola ukryte i tylko do odczytu pochodzą z rekordu głównego. Scalony rekord zachowuje pola Utworzone przez i Data utworzenia najstarszego rekordu, niezależnie od tego, który jest główny. Rekordy niebędące głównymi trafiają do Kosza. Rekordy powiązane, takie jak działania, przechodzą do scalonego rekordu, z wyjątkami. W Lightning scalanie działa na duplikatach wykrytych przez twoje reguły duplikatów. A w przypadku kont osób obiekty punktów kontaktu nie obsługują scalania: ich relacje przepadają (Considerations for Merging Duplicate Accounts (opens in a new tab); Merge Duplicate Accounts in Lightning Experience (opens in a new tab), po angielsku).

Wiedza egzaminacyjna. Wiedz, co robi scalanie kont w Salesforce: do trzech rekordów; jeden rekord główny (principal), którego ukryte pola i pola tylko do odczytu są zachowywane; Created By i Created Date najstarszego rekordu, niezależnie od tego, który jest główny; pozostałe rekordy trafiają do Kosza; a w przypadku kont osób obiekty punktów kontaktu nie są scalane.

Nie potrzebujesz każdego przypadku brzegowego, żeby podjąć decyzję. Potrzebujesz konsekwencji: po scaleniu niezależnych rekordów, od których wszystko się zaczęło, już nie ma. Stosuje się tu Test Odwracalności z rozdziału 1: powiązanie łatwo cofnąć; scalenia nie. A klient rzadko stoi sam: kontakty, zgłoszenia, szanse sprzedaży, pliki, rekordy zgód, niestandardowe rekordy podrzędne, identyfikatory zewnętrzne, odwołania z integracji. Zanim scalisz rekord nadrzędny, zrozum, co stanie się ze wszystkim, co jest do niego przypięte. Gdy duplikaty przychodzą z ładowaniem danych, daję zespołom trzy możliwości dla rekordów podrzędnych: przenieść je do rekordu, który przetrwa; w ogóle ich nie ładować, jeśli nikt ich nie potrzebuje; albo zostawić je na drugim rekordzie, oznaczonym jako nieaktywny, żeby nadal pojawiały się w wyszukiwaniu. Pierwszą robi za ciebie scalenie. Dwie pozostałe zachowują ślad, a często właśnie o to chodzi.

Reguły przetrwania: która wartość wygrywa?

Rekordy należą do siebie, ale się nie zgadzają: Salesforce i system rozliczeń mówią 602-555-0100, ERP mówi 602-555-0188. Reguły przetrwania wybierają zwycięzcę. Najczęstsze to: najnowsza (ostatnia aktualizacja), najczęstsza (wartość, co do której zgadza się najwięcej źródeł) i priorytet źródła (ufaj temu źródłu bardziej niż tamtemu), plus kombinacje, progi, wagi i reguły specyficzne dla biznesu. Żadna z nich nie jest z natury właściwa.

„Najnowsza” to nie ustawienie techniczne. To stwierdzenie o zaufaniu: gdy systemy się nie zgadzają, najnowsza wartość jest bardziej prawdopodobnie poprawna. Rozsądne dla numeru komórkowego. Fatalne dla nazwy prawnej: jeśli jej właścicielem jest ERP, nie obchodzi mnie, że ktoś pięć minut temu zmienił kopię w Salesforce. „Najczęstsza” zakłada, że zgoda jest dowodem, ale trzy nieaktualne kopie w dalszych systemach nie przegłosują systemu ewidencji. „Priorytet źródła” mówi to wprost: temu źródłu ufamy bardziej. Reguły przetrwania należą więc do architektury i zarządzania, a każda reguła potrzebuje właściciela. Kto zdecydował, że wygrywa najnowszy adres albo że ERP ma pierwszeństwo przed Salesforce?

Jeśli mapa autorytetów z modułu 1 już mówi, że właścicielem limitu kredytowego jest ERP, reguła przetrwania jest prosta: wygrywa ERP, bez sprytnej punktacji. Trudne przypadki to atrybuty, w których autorytet jest wspólny, niejasny albo oparty na dowodach, a nie na jednym źródle nadrzędnym. Tam reguły przetrwania zarabiają na siebie.

Click to enlarge

Reguły przetrwania to stwierdzenia o zaufaniu.

Progi, przegląd i wzbogacanie

Niektóre dopasowania ważą dowody: zgodność identyfikatora klienta jest bardzo mocna, e-maila mocna, telefonu umiarkowana, podobne imię i nazwisko słabe, podobny adres pomocniczy. Powyżej jednego wyniku dopasowanie; poniżej innego różne rekordy; pomiędzy przegląda człowiek. Algorytm to nie lekcja. Próg to twoja tolerancja błędu i powinien wynikać z ryzyka biznesowego. A gdy dowody stawiają pytanie, ale go nie rozstrzygają, nie udawaj, że system wie. Skieruj to do przeglądu. Wolniej, i to w porządku: automatyzacja nie ma wartości, gdy z pewnością siebie scala dwóch różnych klientów.

Wzbogacanie dodaje kolejne pytanie o pochodzenie. Pocztowe dane referencyjne, kody branżowe, dane firmograficzne, zewnętrzne oceny ryzyka ulepszają dane podstawowe, ale skąd pochodzi każda wartość, jak jest wiarygodna i aktualna, czy wolno nam jej użyć w tym celu, czy zawiera dane osobowe? „Branża = Transport” od dostawcy danych to nie to samo co informacja od samego klienta. Zachowaj to rozróżnienie.

Steve Trucking: podobny to nie ten sam

Dwóch partnerów detalicznych wysyła dostawy do Johna Smitha, Main Street 123, Columbus, z tym samym numerem telefonu. Ta sama osoba? Pewnie tak. Czy Steve Trucking powinien ich ujednolicić? Pamiętaj, czyi to są ludzie: ci odbiorcy to klienci partnerów, a jeden partner nigdy nie może widzieć klientów drugiego. Fałszywe dopasowanie zmieszałoby dane ponad tą granicą. Nagle to nie jest pytanie o jakość danych, ale o prywatność i izolację, i właśnie dlatego progi zależą od konsekwencji. Decyzję podejmuje punkt kontrolny. Na razie: nie pozwól, żeby wygoda dopasowania podjęła decyzję biznesową.

Czasem zachowanie bałaganu coś ci mówi. Ten rekord przyszedł ze starego systemu, tamten z Salesforce, ten z przejętej firmy; ich identyfikatory, historia i sam fakt, że się nie zgadzały, mogą mieć znaczenie. Czyste dane są cenne. Możliwość prześledzenia też. Architekt decyduje, co jest ważniejsze dla danego zastosowania.

Poza egzaminem: co zmienia AI. Złe dopasowanie kiedyś oznaczało dwa e-maile albo rozdzieloną historię serwisową. Teraz agent znajduje kogoś, kogo uważa za klienta, i pobiera jego zamówienia, zgłoszenia, adresy i notatki. Jeśli dwie osoby zostały błędnie dopasowane, może działać na informacjach jednej osoby w sprawie drugiej. Decyzja o dopasowaniu stała się częścią granicy bezpieczeństwa, a tam, gdzie mieszanie jest kosztowne, ostrzejsze dopasowanie to bezpieczniejszy projekt.

Co tu decyduje architekt

• Jakie dowody wystarczą, żeby oznaczyć możliwy duplikat w każdej domenie danych.
• Czy potwierdzone dopasowanie staje się scaleniem, powiązaniem czy przeglądem przez człowieka.
• Które wartości przetrwają niezgodność i kto jest właścicielem każdej reguły przetrwania.
• Ile ryzyka fałszywego dopasowania może tolerować biznes w porównaniu z ryzykiem przeoczonego dopasowania.
• Które tożsamości źródłowe, historię i rekordy powiązane trzeba zachować przed jakimkolwiek scaleniem.

Dopasowuj ostrożnie, scalaj świadomie, wybieraj reguły przetrwania celowo. Czysty rekord klienta niewiele jest wart, jeśli doszło się do niego, łącząc niewłaściwych klientów.

Do zgłębienia

• Pomoc Salesforce, Considerations for Merging Duplicate Accounts (opens in a new tab) i Merge Duplicate Accounts in Lightning Experience (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.
• Pomoc Salesforce, Things to Know About Duplicate Rules (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.