Täsmäytys, yhdistäminen ja säilymissäännöt

🌐 Saatavilla myös 28 kielellä

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 · Español (México) · Français (Canada) · Deutsch (Schweiz)

Kuva on luotu tekoälyllä

Tekoälyn kääntämä. Yhteisö ei ole vielä tarkistanut käännöstä. Lue englanniksi

Moduuli 3/6 luvussa Perustiedot ja identiteetti, Data Architect -kurssin luku 6. Jokainen moduuli on itsenäinen. Edellinen: Neljä tapaa hallita perustietoja · Seuraava: Kartta ei ole päätös

Kysymys, johon tämä moduuli vastaa: Miten löydät kaksoiskappaleet ja päätät, mitkä arvot säilyvät?

Salesforcessa on kaksi yhteyshenkilöä: Daniel Reyes, Dallas, d.reyes@example.com, ja Dan Reyes, Dallas, d.reyes@example.com. Sama henkilö? Todennäköisesti. Pitäisikö ne yhdistää? Se on eri kysymys. Ja jos yhdistämme, mikä puhelinnumero, osoite ja titteli säilyvät? Taas eri kysymys. Arkkitehdin on pidettävä kolme päätöstä erillään:

• Täsmäytys: edustavatko nämä tietueet samaa asiaa?
• Yhdistäminen: pitäisikö niistä tulla yksi tietue?
• Säilymissäännöt: jos yhdistämme tietoja, mitkä arvot voittavat?

Täsmäytys tulee ensin

Luku 3 käsitteli Salesforcen kaksoiskappale- ja vastaavuussääntöjä, joten en opeta mekaniikkaa uudelleen. Arkkitehtuurinen kysymys on: mikä näyttö on tarpeeksi vahva sanomaan, että nämä voivat olla sama? Henkilölle: sähköposti, puhelinnumero, nimi ja osoite, asiakasnumero, jokin yhdistelmä. Yritykselle: virallinen nimi, verotunniste, ERP:n asiakas-ID, osoite, verkkotunnus. Ei ”pystyykö Salesforce vertaamaan näitä kenttiä?” vaan ”mikä yhdistelmä antaa meille tarpeeksi varmuutta toimia?”

Eikä tarkka vastaavuus ole varma. Yhteinen sähköposti on vahva signaali, ei todiste: perheillä on yhteinen osoite, yritykset käyttävät osoitetta purchasing@company.com, puhelinnumerot kuuluvat kotitalouksille, nimet ja osoitteet eivät ole yksilöllisiä, ja vahvatkin tunnisteet käytetään uudelleen, kirjoitetaan väärin tai kierrätetään. Täsmäytys ei ole merkkijonojen vertailua. Se on väite identiteetistä.

Väärässä olemisen hinta

Kun opetan tätä, vaihdan toimialaa. Autoalan markkinointitiedoissa päätämme virheellisesti, että kaksi Daniel Reyesiä ovat sama henkilö, ja väärä henkilö saa tarjouksen katumaasturista. Ei hyvä, mutta pieni riski. Tee nyt sama väärä täsmäytys terveystiedoissa: kahden eri ihmisen sairaushistoriat yhdistetty. Sama täsmäytysvirhe, täysin eri seuraus. Siksi ei ole olemassa yleispätevää ”hyvää” täsmäytyksen kynnysarvoa. Joskus suurempi riski on se, että täsmäys jää löytämättä; joskus se, että yhdistetään kaksi ihmistä, jotka eivät ole sama. Kun väärät täsmäykset tulevat kalliiksi, täsmäytän tarkoituksella liian vähän.

Harmonisoi, sitten täsmäytä, sitten konsolidoi

Täsmäytys riippuu myös tietojen muodosta. AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198. Harmonisointi tekee arvoista vertailukelpoisia: vakiomuodot, normalisoidut lyhenteet, kuvatut koodit. Sitten täsmäytetään. Vasta kun tiedetään, että tietueet kuuluvat yhteen, niiden tiedot konsolidoidaan yhdeksi esitykseksi. Harmonisointi ei ole täsmäytystä, täsmäytys ei ole yhdistämistä, eikä konsolidointi välttämättä ole hallitsemista.

Click to enlarge

Identiteettipäätökset tehdään vaiheittain.

Täsmäys ei vaadi yhdistämistä

Tämä on yksi luvun tärkeimmistä eroista. Olemme varmoja, että kaksi asiakastietuetta kahdesta vanhasta järjestelmästä ovat sama yritys. Onko ne pakko yhdistää? Ei. Kummallakin voi olla lähdejärjestelmän tunniste; historialliset transaktiot voivat osoittaa kumpaankin; tilintarkastajat voivat tarvita jäljen; migraatio voi olla yhä kesken; meidän voi olla tarpeen tietää tarkalleen, mitä vanha järjestelmä sanoi. Tieto siitä, että kaksi tietuetta ovat sama asia, ei pakota meitä yhdistämään niitä. Voimme linkittää ne, ja se on usein turvallisempi arkkitehtuuri.

Yhdistämissääntöni: selvä voittaja

Kantani: yhdistä vain, kun voittaja on selvä eikä kaksoiskappale tuo mitään, mitä sinun pitää säilyttää. Myyjä loi eilen kaksoiskappaleen tilistä; alkuperäinen on selvästi vakiintunut tietue. Hyvä yhdistämisehdokas. Muutetaan tilannetta: toimme asiakkaat vanhasta järjestelmästä, ja niillä on omat ID:nsä, vanhemmat arvonsa ja ehkä niihin sidottuja transaktioita tai auditointivaatimuksia. Olen paljon varovaisempi. Säilytä ulkoisista latauksista tulleet kaksoiskappaleet, kun saatat joutua jäljittämään vanhempiin arvoihin, koska yhdistäminen tuhoaa sen historian.

Mitä Salesforcen yhdistäminen todella tekee

Linkki sanoo ”nämä kuuluvat yhteen”. Yhdistäminen sanoo ”nämä ovat nyt yksi”, ja Salesforcessa se on todellinen muutos. Tileistä valitset enintään kolme tietuetta ja valitset yhden niistä pääasialliseksi tietueeksi (principal); valitset, mitkä muiden kenttien arvot säilytetään, kun taas piilotetut ja vain luku -kentät tulevat pääasiallisesta tietueesta. Yhdistetty tietue säilyttää vanhimman tietueen Created By- ja Created Date -arvot (luoja ja luontipäivä), oli pääasiallinen tietue mikä tahansa. Muut kuin pääasialliset tietueet menevät roskakoriin. Liittyvät tietueet, kuten aktiviteetit, siirtyvät yhdistettyyn tietueeseen, poikkeuksin. Lightningissa yhdistäminen toimii kaksoiskappaleisiin, jotka kaksoiskappalesääntösi havaitsevat. Ja henkilötileillä yhteyspisteobjektit (contact point objects) eivät tue yhdistämistä: niiden suhteet menetetään (Considerations for Merging Duplicate Accounts (opens in a new tab); Merge Duplicate Accounts in Lightning Experience (opens in a new tab)).

Koetieto. Tunne, mitä Salesforcen tilien yhdistäminen tekee: enintään kolme tietuetta; yksi pääasiallinen tietue, jonka piilotetut ja vain luku -kentät säilytetään; vanhimman tietueen Created By ja Created Date, oli pääasiallinen mikä tahansa; muut tietueet menevät roskakoriin; ja henkilötileillä yhteyspisteobjekteja ei yhdistetä.

Et tarvitse jokaista reunatapausta tehdäksesi päätöksen. Tarvitset seurauksen: yhdistämisen jälkeen ne itsenäiset tietueet, joista lähdit, ovat poissa. Luvun 1 peruttavuustesti pätee: linkityksen voi helposti perua; yhdistämistä ei. Ja asiakas on harvoin yksin: yhteyshenkilöt, tapaukset, myyntimahdollisuudet, tiedostot, suostumustietueet, mukautetut lapsitietueet, ulkoiset ID:t, integraatioviittaukset. Ennen kuin yhdistät vanhemman, ymmärrä, mitä tapahtuu kaikelle siihen liitetylle. Kun kaksoiskappaleita tulee latauksen mukana, annan tiimeille lapsitietueille kolme vaihtoehtoa: siirrä ne säilyvään tietueeseen; älä lataa niitä lainkaan, jos kukaan ei tarvitse niitä; tai pidä ne toisessa tietueessa passiiviseksi merkittynä, jotta ne löytyvät yhä haussa. Ensimmäisen yhdistäminen tekee puolestasi. Kaksi muuta säilyttävät jäljen, ja usein juuri siitä on kyse.

Säilymissäännöt: mikä arvo voittaa?

Tietueet kuuluvat yhteen, mutta ne ovat eri mieltä: Salesforce ja laskutus sanovat 602-555-0100, ERP sanoo 602-555-0188. Säilymissäännöt (survivorship) valitsevat voittajan. Yleisimmät: uusin (viimeisin päivitys), yleisin (arvo, josta useimmat lähteet ovat samaa mieltä) ja lähteen prioriteetti (luota tähän lähteeseen enemmän kuin tuohon), sekä yhdistelmät, kynnysarvot, painotukset ja liiketoimintakohtaiset säännöt. Mikään niistä ei ole luonnostaan oikea.

”Uusin” ei ole tekninen asetus. Se on väite luottamuksesta: kun järjestelmät ovat eri mieltä, uusin arvo on todennäköisemmin oikea. Järkevää matkapuhelinnumerolle. Kamalaa viralliselle nimelle: jos ERP omistaa sen, en välitä siitä, että joku muutti Salesforcen kopiota viisi minuuttia sitten. ”Yleisin” olettaa, että yksimielisyys on näyttöä, mutta kolme vanhentunutta alavirran kopiota eivät äänestä lähdejärjestelmää kumoon. ”Lähteen prioriteetti” sanoo sen suoraan: luotamme tähän lähteeseen enemmän. Siksi säilymissäännöt kuuluvat arkkitehtuuriin ja hallintaan, ja jokainen sääntö tarvitsee omistajan. Kuka päätti, että uusin osoite voittaa tai että ERP menee Salesforcen edelle?

Jos moduulin 1 auktoriteettikartta jo sanoo, että ERP omistaa luottorajan, säilymissääntö on helppo: ERP voittaa, nokkelaa pisteytystä ei tarvita. Vaikeat tapaukset ovat attribuutteja, joiden auktoriteetti on jaettu, epäselvä tai perustuu näyttöön yhden masterin sijaan. Niissä säilymissäännöt ansaitsevat paikkansa.

Click to enlarge

Säilymissäännöt ovat väitteitä luottamuksesta.

Kynnysarvot, tarkistus ja rikastaminen

Osa täsmäytyksestä punnitsee näyttöä: asiakas-ID:n vastaavuus on hyvin vahva, sähköposti vahva, puhelinnumero kohtalainen, samankaltainen nimi heikko, samankaltainen osoite tukeva. Yhden pistemäärän yläpuolella täsmäys; toisen alapuolella eri tietueet; siltä väliltä ihminen tarkistaa. Algoritmi ei ole opetus. Kynnysarvo on toleranssisi virheille, ja sen pitäisi seurata liiketoimintariskiä. Ja kun näyttö herättää kysymyksen ratkaisematta sitä, älä teeskentele, että järjestelmä tietää. Ohjaa se tarkistettavaksi. Hitaampaa, ja se on ihan hyvä: automaatiosta ei ole hyötyä, kun se yhdistää itsevarmasti kaksi eri asiakasta.

Rikastaminen tuo uuden alkuperäkysymyksen. Postin viitetiedot, toimialakoodit, yritystiedot ja ulkoiset riskipisteet parantavat perustietoja, mutta mistä kukin arvo tuli, kuinka luotettava ja ajantasainen se on, saammeko käyttää sitä tähän tarkoitukseen, sisältääkö se henkilötietoja? ”Toimiala = kuljetus” tietopalvelun toimittajalta ei ole sama asia kuin se, että asiakas kertoo sen sinulle. Pidä se ero.

Steve Trucking: samankaltainen ei ole sama

Kaksi vähittäiskauppakumppania lähettää toimituksia John Smithille, osoitteeseen 123 Main Street, Columbus, samalla puhelinnumerolla. Sama henkilö? Todennäköisesti. Pitäisikö Steve Truckingin yhtenäistää heidät? Muista, keiden he ovat: nuo vastaanottajat ovat kumppanien asiakkaita, eikä yksi kumppani saa koskaan nähdä toisen asiakkaita. Väärä täsmäys sekoittaisi tietoja tuon rajan yli. Yhtäkkiä kyse ei ole tietojen laadusta vaan tietosuojasta ja eristämisestä, ja juuri siksi kynnysarvot riippuvat seurauksista. Tarkistuspiste tekee ratkaisun. Toistaiseksi: älä anna täsmäytyksen helppouden tehdä liiketoimintapäätöstä.

Joskus sotkun säilyttäminen kertoo jotain. Tämä tietue tuli vanhasta järjestelmästä, tuo Salesforcesta, tämä ostetusta yrityksestä; niiden ID:t, niiden historia ja se tosiasia, että ne olivat eri mieltä, voivat kaikki olla tärkeitä. Puhtaat tiedot ovat arvokkaita. Niin on jäljitettävyyskin. Arkkitehti päättää, kumpi on tärkeämpää kyseisessä käytössä.

Kokeen jälkeen: mitä tekoäly muuttaa. Huono täsmäys tarkoitti ennen kahta sähköpostia tai pirstoutunutta palveluhistoriaa. Nyt agentti löytää sen, mitä se pitää asiakkaana, ja hakee tämän tilaukset, tapaukset, osoitteet ja muistiinpanot. Jos kaksi ihmistä täsmäytettiin virheellisesti, agentti voi toimia yhden ihmisen tietojen perusteella toisen puolesta. Täsmäytyspäätöksestä on tullut osa tietoturvarajaa, ja kun sekoittuminen tulee kalliiksi, tiukempi täsmäytys on turvallisempi suunnitelma.

Mitä arkkitehti tässä päättää

• Mikä näyttö riittää mahdollisen kaksoiskappaleen merkitsemiseen kullakin tietoalueella.
• Tuleeko vahvistetusta täsmäyksestä yhdistäminen, linkki vai ihmisen tarkistus.
• Mitkä arvot säilyvät erimielisyydessä ja kuka omistaa kunkin säilymissäännön.
• Kuinka paljon väärän täsmäyksen riskiä liiketoiminta sietää verrattuna löytymättä jääneen täsmäyksen riskiin.
• Mitkä lähdetunnisteet, historia ja liittyvät tietueet on säilytettävä ennen mitään yhdistämistä.

Täsmäytä huolella, yhdistä harkiten, valitse säilymissäännöt tarkoituksella. Puhtaasta asiakastietueesta ei ole paljon iloa, jos pääsit siihen yhdistämällä väärät asiakkaat.

Lue lisää

• Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab) ja Merge Duplicate Accounts in Lightning Experience (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).