En karta är inget beslut

🌐 Finns även på 28 språk

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

Bilden är skapad med AI

Översatt med AI. Gemenskapen har inte granskat översättningen än. Läs på engelska

Modul 4 av 6 i kapitlet Masterdata och identitet, kapitel 6 i kursen Data Architect. Varje modul står på egna ben. Föregående: Matchning, sammanslagning och överlevnadsregler · Nästa: När auktoriteten delas

Frågan den här modulen besvarar: Är en enhetlig profil samma sak som en golden record?

Samma kund finns i tre system. Salesforce känner Daniel Reyes, d.reyes@example.com, Dallas. E-handeln känner Dan Reyes, samma e-post, Dallas, TX. Supporten känner Daniel Reyes, 214-555-0100, Dallas. Data 360 avgör att alla tre är samma person och bygger en enhetlig profil. Utmärkt. Har vi en golden record? Inte nödvändigtvis. Vi vet att posterna hör ihop; vi har inte bestämt vilken källa som äger sanningen. Det här kan förvirra folk: identitetsupplösning skapar en enhetlig individ, men inte en golden record. Så jag lär ut skillnaden rakt på sak:

En enhetlig profil är en karta. En golden record är ett beslut.

Identitetsupplösning besvarar ”vem?”

Utan identitetsupplösning dyker en person upp som frånkopplade profiler: marknadsföringen ser en, försäljningen en annan, servicen en tredje. Data 360 läser in dem och använder regler för identitetsupplösning för att avgöra vilka som hör ihop. Sedan kan vi säga de här posterna verkar vara samma person. Det löser identiteten. Det löser inte masterdatahanteringen.

Och den enhetliga profilen behåller kartan tillbaka till sina källor. Enligt Salesforce egen beskrivning är en enhetlig profil ingen golden record: den är en uppsättning nycklar, med identitetslänkobjekt som knyter varje källposts ID till den enhetliga profilens ID (Data 360 Architecture (opens in a new tab)). Den enhetliga personen 10042 mappas till kontakten 003… i Salesforce, kunden EC-48372 i e-handeln och kunden SUP-9128 i supporten. Originalen försvinner inte. Det ligger väldigt nära registret i modul 2.

Click to enlarge

En enhetlig profil är en karta tillbaka till källornas identiteter.

Matchningsregler: striktheten är ett riskbeslut

Hur avgör Data 360 vem som förenas? Matchningsregler. Profiler matchar när alla kriterier i en regel är uppfyllda, och om du har flera regler skapar en matchning på vilken som helst av dem den enhetliga profilen. Salesforce egen vägledning: använd fler kriterier för precision (fler distinkta profiler), färre för konsolidering (Identity Resolution Match Rules (opens in a new tab)). Att lägga till kriterier i en regel gör den alltså striktare; att lägga till alternativa regler breddar sätten som profiler kan matcha på. Att konfigurera identitetsupplösning är inte att ”slå på matchning”. Det är att definiera vilka bevis som räcker för att säga att de här profilerna är en person.

Mer matchning är inte automatiskt bättre. Tio miljoner källprofiler blir åtta miljoner enhetliga. Lätta på reglerna, och nu är de sex miljoner. Bättre? Kanske hittade du fler dubbletter. Eller kanske började du kombinera olika personer. Ett lägre antal är inget bevis för bättre data. Målet är inte så få profiler som möjligt; det är de mest försvarbara identiteterna för syftet. Och varje kriterium har en matchningsmetod: Exact, Exact Normalized eller Fuzzy med hög, medelhög eller låg precision. Salesforce egen varning är poängen: en mindre exakt metod höjer konsolideringsgraden, ”men kan ge oönskade matchningar”. (Fuzzy finns inte för Account-fält, och de normaliserade värdena används bara för jämförelsen; de lagras inte i den enhetliga profilen, vilket är harmoniseringssteget från modul 3 i praktiken: Identity Resolution Match Methods (opens in a new tab).) Ju lösare metod, desto mer blir själva identiteten en bedömning. Om den är fel, personaliserar vi då bara en sida dåligt, eller visar vi en persons supporthistorik för en annan, eller låter vi en agent agera på två personers data?

Det är min hållning: hur strikt matchningen är, är ett riskbeslut. Det beror på hur unikt matchningsfälten identifierar en person och vad en felaktig matchning kostar. Där sammanblandning är dyr matchar du för lite med avsikt. Två profiler för en person är opraktiskt. En profil som rymmer två personer kan vara farlig.

Avstämning är fortfarande inte masterdatahantering

När profilerna väl är förenade är källorna fortfarande oense: Salesforce säger Dallas, e-handeln Plano, supporten Dallas. Vad visar den enhetliga profilen? Avstämningsregler (reconciliation rules) avgör: Last Updated, Most Frequent eller Source Priority, som ställs in per objekt och kan åsidosättas per fält (Identity Resolution Reconciliation Rules (opens in a new tab)). Det bör låta som överlevnadsreglerna i modul 3.

Det är här teamen hamnar i trubbel. Den enhetliga profilen visar Dallas, och någon säger: ”Toppen, Dallas är vårt gyllene värde.” Sakta ner. E-handeln säger fortfarande Plano. Salesforce säger uttryckligen att avstämning inte raderar eller ändrar källdata och inte uppdaterar källsystemen, och den är inte tänkt att välja ett ”bästa” värde för varje applikation. Den avgör bara vad den enhetliga profilen visar (samma källa). Presentation är inte auktoritet.

Provkunskap. Känn till hur identitetsupplösningen i Data 360 avgör och visar: i en matchningsregel måste alla kriterier matcha, och om vilken regel som helst matchar förenas profilerna (fler kriterier för precision, färre för konsolidering); de tre avstämningsreglerna är Last Updated, Most Frequent och Source Priority, som ställs in per objekt och kan åsidosättas per fält; och avstämningen ändrar inte källdata, och kontaktpunkter stäms inte av.

Kontaktpunkter gör poängen ännu tydligare. En person kan ha en privat och en jobbmejl, en mobil och en hemtelefon, alla legitima. Data 360 stämmer inte av kontaktpunkter alls: varje e-postadress och telefon stannar på den enhetliga profilen (samma källa). Ibland är flera värden helt enkelt sanningen. ”Enhetlig” betyder inte ett värde för allt.

En golden record är ett beslut

Jämför med ett verkligt krav på masterdatahantering. Verksamheten säger att ERP:t är auktoritativt för det juridiska namnet, och det masterhanterade värdet är ”Oakline Logistics LLC”. Salesforce, faktureringen och servicen måste alla använda det, och om någon är oense skickar masterdataprocessen tillbaka det styrda värdet. Det är en annan arkitektur. Vi väljer inte vad en vy visar; vi bestämmer att det här är värdet som företaget använder, och att varje deltagande system konvergerar mot det.

Alltså: en enhetlig profil för samman identiteter och information. En golden record är ett styrt beslut om vilka värden som är auktoritativa. En enhetlig profil kan ge en utmärkt samlad bild av kunden, sammansatt från auktoritativa källor. Det gör den inte till systemet som hanterar kunden som masterdata.

Click to enlarge

En enhetlig profil är en karta. En golden record är ett beslut.

Spårbarhet

Om den enhetliga profilen säger Dallas, var kom det ifrån: Salesforce, ERP:t, e-handeln? Valdes det som senast uppdaterat, vanligast, källprioritet? Det ursprunget spelar roll för revision, integritet, felsökning, rättning av datakvalitet och agenters beslut, och framför allt för att veta var en rättelse hör hemma. Om Dallas är fel rättar du inte källan genom att redigera den sammansatta vyn. Du behöver External ID:na, identitetslänkarna och härkomstfälten för att spåra tillbaka till posten som borde ändras.

Tre verktyg för tre jobb

Så här skiljer jag dem åt:

1. Dubbletthantering och sammanslagning, inom en org i Salesforce, när det finns en tydlig vinnare och du inte längre behöver dubbletterna (modul 3).
2. Identitetsupplösning i Data 360, för en identitet och en samlad bild över källorna utan att ändra dem: ett register.
3. En dedikerad MDM-plattform, när värden måste bestämmas en gång och skickas tillbaka till varje deltagande system: samexistens eller centraliserad.

Click to enlarge

Tre verktyg för tre jobb: slå samman, länka, hantera masterdata.

Köp inte MDM när du behöver en karta. ”Vi vill att serviceagenten ska se att den här kunden i Salesforce är samma person som köpte på nätet” kan behöva identitetsupplösning och kombinerad kontext, inte centraliserad MDM. ”ERP:t, Salesforce, e-handeln och faktureringen måste alla använda samma styrda juridiska namn, och ändringar måste flöda tillbaka till dem alla” är något annat: det är masterdatahantering. Lös inte det andra när du har det första, och låtsas inte att det första löste det andra.

En identitet är inte en behörighet

Identitetsupplösningen säger att de här posterna är en person. Det betyder inte att alla som kan se en källpost får se allt som hänger på den enhetliga identiteten. En detaljhandelspartner (Retail Partner) får se de leveranser den skickade; en annan partners leveranser till samma mottagare (Recipient) har den inget med att göra, även om identitetslagret vet att de är relaterade. Identitetsgrafen kan vara rätt medan åtkomstdesignen är fel. Att förena identiteter suddar inte ut säkerhetsgränser. Därför blir övermatchning ett integritetsproblem, och därför behandlar kontrollpunkten för Steve Trucking förenandet av mottagare så försiktigt: en karta över vem som är vem ger inget ägarskap, och ingen åtkomst.

Bortom provet: vad AI ändrar. Agenter behöver en identitet att agera på, och den enhetliga profilen ger dem den. Det höjer insatserna åt båda hållen. Övermatchning är nu en integritetsincident: en agent som agerar för en person på en annans data. Och en agent som ”uppdaterar kunden” måste skriva till attributets system of record, med hjälp av auktoritetskartan från modul 1, inte till den enhetliga profilen. Kartan säger agenten vem personen är; auktoritetsmodellen säger var en ändring hör hemma.

Vad en arkitekt bestämmer här

• Vilka bevis som räcker för att förena profiler, och hur kostnaden för en felaktig matchning sätter striktheten.
• Vilka avstämningsregler som avgör vad den enhetliga profilen visar.
• Om behovet är att städa dubbletter i en org, identitet över källor, eller verklig masterdatahantering för hela företaget.
• Vilken källa som förblir auktoritativ för varje attribut, även när Data 360 visar ett avstämt värde.
• Hur den enhetliga identiteten samspelar med säkerhet, integritet, ursprung och agenters handlingar.

Data 360 kan säga oss att de här profilerna hör ihop, ge oss en enhetlig identitet, stämma av vad den visar och behålla länkarna tillbaka till varje källa. Det är oerhört värdefullt. Men om Salesforce säger en sak och ERP:t en annan måste någon fortfarande avgöra vilket system som får ändra företagets sanning. Så när någon säger ”vi har en enhetlig profil, så vi har vår golden record”, fråga: förenade vi data, eller hanterade vi dem som masterdata?

Utforska vidare

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (på engelska, kontrollerad 2026-10-14).
• Salesforce Help, Data 360: Identity Resolution Match Rules (opens in a new tab) och Identity Resolution Match Methods (opens in a new tab) och Identity Resolution Reconciliation Rules (opens in a new tab) (på engelska, kontrollerad 2026-10-14).