Párování, slučování a přežití hodnot

🌐 K dispozici také v 29 jazycích

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)

Obrázek vytvořený pomocí AI

Přeloženo pomocí AI. Komunita překlad zatím nezkontrolovala. Číst anglicky

Modul 3 z 6 kapitoly Kmenová data a identita, kapitoly 6 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Čtyři způsoby správy kmenových dat · Další: Mapa není rozhodnutí

Otázka, na kterou tento modul odpovídá: Jak najít duplicity a rozhodnout, které hodnoty přežijí?

Salesforce má dva kontakty: Daniel Reyes, Dallas, d.reyes@example.com, a Dan Reyes, Dallas, d.reyes@example.com. Stejná osoba? Nejspíš. Máme je sloučit? To je jiná otázka. A pokud ano, které telefonní číslo, adresa a pracovní pozice přežijí? Zase jiná. Architekti musí držet tři rozhodnutí odděleně:

• Párování (matching): reprezentují tyto záznamy stejnou věc?
• Sloučení (merge): mají se stát jedním záznamem?
• Přežití hodnot (survivorship): když data spojujeme, které hodnoty vyhrají?

Párování je první

Kapitola 3 pokryla pravidla duplicit a pravidla shody v Salesforce, takže mechaniku znovu učit nebudu. Architektonická otázka zní: jaký důkaz je dost silný na to, abychom řekli, že by to mohlo být totéž? U osoby: e-mail, telefon, jméno plus adresa, zákaznické číslo, nějaká kombinace. U firmy: oficiální název, DIČ, zákaznické ID v ERP, adresa, webová doména. Ne „dokáže Salesforce tato pole porovnat?“, ale „jaká kombinace nám dává dost jistoty, abychom jednali?“

A přesná shoda neznamená jistotu. Sdílený e-mail je silný signál, ne důkaz: rodiny sdílejí adresy, firmy používají purchasing@company.com, telefonní čísla patří domácnostem, jména a adresy nejsou jedinečné a i silné identifikátory se znovu používají, překlepnou nebo recyklují. Párování není porovnávání řetězců. Je to tvrzení o identitě.

Cena omylu

Když tohle učím, měním doménu. V marketingových datech z automobilového průmyslu chybně usoudíme, že dva Danielové Reyesové jsou tatáž osoba, a nabídku na SUV dostane ten nesprávný. Nic dobrého, ale nízké riziko. Teď udělejte stejnou falešnou shodu ve zdravotnických datech: zdravotní historie dvou různých lidí spojené dohromady. Stejná chyba párování, úplně jiný důsledek. Proto neexistuje univerzální „dobrý“ práh párování. Někdy je větším rizikem shodu přehlédnout; někdy spojit dva lidi, kteří nejsou titíž. Kde jsou falešné shody drahé, záměrně párujeme méně.

Harmonizujte, pak párujte, pak konsolidujte

Párování závisí také na tvaru dat. AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198. Harmonizace dělá hodnoty porovnatelnými: standardní formáty, normalizované zkratky, namapované kódy. Pak párujete. Teprve když víte, že záznamy k sobě patří, jejich informace konsolidujete do jedné reprezentace. Harmonizace není párování, párování není sloučení a konsolidace nemusí být správou kmenových dat.

Kliknutím zvětšíte

Rozhodnutí o identitě probíhají ve fázích.

Shoda nevyžaduje sloučení

Tohle je jedno z nejdůležitějších rozlišení v kapitole. Jsme si jistí, že dva záznamy zákazníků ze dvou starých systémů jsou stejná firma. Musíme je sloučit? Ne. Každý může nést identitu ze zdrojového systému; historické transakce mohou ukazovat na každý z nich; auditoři mohou potřebovat stopu; možná pořád migrujeme; možná potřebujeme přesně vědět, co říkal starý systém. To, že víme, že dva záznamy jsou stejná věc, nás nenutí je zhroutit do jednoho. Můžeme je propojit, a to je často bezpečnější architektura.

Moje pravidlo pro sloučení: jasný vítěz

Můj postoj: slučujte jen tehdy, když je jasný vítěz a duplicita nepřidává nic, co potřebujete uchovat. Obchodník včera vytvořil duplicitní účet; originál je zjevně zavedený záznam. Dobrý kandidát na sloučení. Teď to změňte: importovali jsme zákazníky ze staršího systému, s jeho vlastními ID, staršími hodnotami, možná s transakcemi nebo požadavky na audit, které jsou na ně navázané. Jsem mnohem opatrnější. Duplicity z externích nahrávání si nechte, když možná budete potřebovat dohledat starší hodnoty, protože sloučení tuto historii zničí.

Co sloučení v Salesforce skutečně dělá

Odkaz říká „tohle k sobě patří“. Sloučení říká „tohle je teď jedno“, a v Salesforce je to skutečná změna. U účtů vyberete až tři záznamy a jeden zvolíte jako hlavní záznam (principal); vyberete, které hodnoty polí z ostatních ponechat, přičemž skrytá pole a pole jen pro čtení pocházejí z hlavního záznamu. Sloučený záznam si ponechá Created By a Created Date nejstaršího záznamu, ať je hlavním kterýkoli. Záznamy, které nejsou hlavní, jdou do Koše. Související záznamy, jako jsou aktivity, se přesunou ke sloučenému záznamu, s výjimkami. V Lightning funguje sloučení na duplicitách, které odhalí vaše pravidla duplicit. A u osobních účtů objekty kontaktních bodů sloučení nepodporují: jejich vztahy se ztratí (Considerations for Merging Duplicate Accounts (otevře se v nové kartě); Merge Duplicate Accounts in Lightning Experience (otevře se v nové kartě)).

Ke zkoušce. Vězte, co dělá sloučení účtů v Salesforce: až tři záznamy; jeden hlavní, jehož skrytá pole a pole jen pro čtení se ponechají; Created By a Created Date nejstaršího záznamu, ať je hlavním kterýkoli; ostatní záznamy jdou do Koše; a u osobních účtů se objekty kontaktních bodů neslučují.

Abyste rozhodli, nepotřebujete znát každý okrajový případ. Potřebujete znát důsledek: po sloučení jsou nezávislé záznamy, se kterými jste začali, pryč. Platí test vratnosti z kapitoly 1: propojení se dá snadno vrátit; sloučení ne. A zákazník málokdy stojí sám: kontakty, případy, příležitosti, soubory, záznamy souhlasů, vlastní podřízené záznamy, externí ID, integrační odkazy. Než sloučíte nadřazený záznam, pochopte, co se stane se vším, co k němu je připojené. Když duplicity přijdou s nahráváním, dávám týmům tři možnosti pro podřízené záznamy: přesunout je k přežívajícímu záznamu; vůbec je nenahrát, pokud je nikdo nepotřebuje; nebo ponechat je u druhého záznamu, označené jako neaktivní, aby se pořád objevovaly ve vyhledávání. První udělá sloučení za vás. Další dvě uchovávají stopu, a o to často jde.

Přežití hodnot: která hodnota vyhraje?

Záznamy k sobě patří, ale neshodnou se: Salesforce a fakturace říkají 602-555-0100, ERP říká 602-555-0188. Pravidla přežití hodnot vybírají vítěze. Ta běžná: nejnovější (poslední aktualizace), nejčastější (hodnota, na které se shodne nejvíc zdrojů) a priorita zdroje (věř tomuto zdroji víc než tamtomu), plus kombinace, prahy, váhy a pravidla specifická pro byznys. Žádné z nich není samo o sobě správné.

„Nejnovější“ není technické nastavení. Je to tvrzení o důvěře: když se systémy neshodnou, nejnovější hodnota je spíš správná. Rozumné pro číslo mobilu. Strašné pro oficiální název: pokud ho vlastní ERP, je mi jedno, že někdo před pěti minutami změnil kopii v Salesforce. „Nejčastější“ předpokládá, že shoda je důkaz, ale tři zastaralé kopie po proudu nepřehlasují zdrojový systém. „Priorita zdroje“ to říká na rovinu: tomuto zdroji věříme víc. Přežití hodnot tedy patří do architektury a do řízení a každé pravidlo potřebuje vlastníka. Kdo rozhodl, že vyhrává nejnovější adresa, nebo že ERP má přednost před Salesforce?

Pokud mapa autorit z modulu 1 už říká, že úvěrový limit vlastní ERP, je přežití hodnot snadné: vyhrává ERP, žádné chytré bodování není potřeba. Těžké případy jsou atributy, kde je autorita sdílená, nejasná nebo postavená na důkazech, a ne na jednom masteru. Tam si pravidla přežití hodnot vydělávají.

Kliknutím zvětšíte

Pravidla přežití hodnot jsou tvrzení o důvěře.

Prahy, revize a obohacení

Některé párování váží důkazy: shoda zákaznického ID je velmi silná, e-mail silný, telefon střední, podobné jméno slabé, podobná adresa podpůrná. Nad jedním skóre shoda; pod jiným různé; mezi tím to posoudí člověk. Poučením není algoritmus. Práh je vaše tolerance chyb a měl by se řídit obchodním rizikem. A když důkazy otázku vyvolají, ale nerozhodnou, nepředstírejte, že systém to ví. Pošlete to k revizi. Pomalejší, a to je v pořádku: automatizace nemá hodnotu, když sebevědomě sloučí dva různé zákazníky.

Obohacení (enrichment) přidává další otázku o původu. Poštovní referenční data, odvětvové kódy, firemní údaje, externí rizikové skóre kmenová data vylepšují, ale odkud každá hodnota přišla, jak je spolehlivá a aktuální, smíme ji pro tento účel použít, obsahuje osobní údaje? „Odvětví = Doprava“ od poskytovatele dat není totéž, jako když vám to řekne zákazník. Toto rozlišení si uchovejte.

Steve Trucking: podobné není totéž

Dva maloobchodní partneři posílají doručení pro Johna Smithe, 123 Main Street, Columbus, se stejným telefonním číslem. Stejná osoba? Nejspíš. Má je Steve Trucking sjednotit? Vzpomeňte si, čí jsou: tito příjemci jsou zákazníky partnerů a jeden partner nikdy nesmí vidět zákazníky druhého. Falešná shoda by smíchala data přes tuto hranici. Najednou to není otázka kvality dat, ale otázka soukromí a izolace, a právě proto prahy závisejí na důsledcích. Rozhodne kontrolní bod. Prozatím: nenechte pohodlí párování dělat obchodní rozhodnutí.

Někdy vám ponechaný nepořádek něco říká. Tento záznam přišel ze starého systému, tamten ze Salesforce, tenhle z koupené firmy; jejich ID, jejich historie i to, že se neshodovaly, mohou být důležité. Čistá data mají hodnotu. Dohledatelnost také. Architekt rozhoduje, co je pro dané použití důležitější.

Nad rámec zkoušky: co mění AI. Špatná shoda dřív znamenala dva e-maily nebo rozdělenou servisní historii. Teď agent najde toho, koho považuje za zákazníka, a stáhne jeho objednávky, případy, adresy a poznámky. Pokud byli dva lidé chybně spárováni, může jednat podle informací jedné osoby za jinou. Rozhodnutí o párování se stalo součástí bezpečnostní hranice, a kde je smíchání drahé, je přísnější párování bezpečnějším návrhem.

Co tady rozhoduje architekt

• Jaký důkaz stačí k označení možné duplicity v každé datové doméně.
• Zda se z potvrzené shody stane sloučení, propojení, nebo lidská revize.
• Které hodnoty přežijí neshodu a kdo vlastní každé pravidlo přežití hodnot.
• Kolik rizika falešné shody byznys snese oproti riziku přehlédnuté shody.
• Které zdrojové identity, historie a související záznamy je třeba uchovat před jakýmkoli sloučením.

Párujte opatrně, slučujte uváženě, pravidla přežití hodnot volte záměrně. Čistý záznam zákazníka nemá velkou hodnotu, pokud jste se k němu dostali spojením nesprávných zákazníků.

K prozkoumání

• Salesforce Help, Considerations for Merging Duplicate Accounts (otevře se v nové kartě) a Merge Duplicate Accounts in Lightning Experience (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Help, Things to Know About Duplicate Rules (otevře se v nové kartě), ověřeno 2026-10-17.