Abgleichen, Zusammenführen und Survivorship

🌐 Auch in 28 Sprachen

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)

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen

Modul 3 von 6 im Kapitel Stammdaten und Identität, Kapitel 6 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Die vier Wege des Stammdatenmanagements · Weiter: Eine Karte ist keine Entscheidung

Die Frage, die dieses Modul beantwortet: Wie finden Sie Duplikate, und wie entscheiden Sie, welche Werte überleben?

Salesforce hat zwei Kontakte: Daniel Reyes, Dallas, d.reyes@example.com, und Dan Reyes, Dallas, d.reyes@example.com. Dieselbe Person? Wahrscheinlich. Sollten wir sie zusammenführen? Das ist eine andere Frage. Und wenn ja, welche Telefonnummer, Adresse und welcher Titel überleben? Wieder eine andere. In der Architektur müssen wir drei Entscheidungen auseinanderhalten:

• Abgleichen: Stellen diese Datensätze dasselbe dar?
• Zusammenführen: Sollen sie ein Datensatz werden?
• Survivorship: Wenn wir Daten kombinieren, welche Werte gewinnen?

Das Abgleichen kommt zuerst

Kapitel 3 hat die Duplikats- und Abgleichsregeln von Salesforce behandelt, also unterrichte ich die Mechanik nicht erneut. Die Architekturfrage lautet: Welcher Beleg ist stark genug, um zu sagen, dass diese dasselbe sein könnten? Bei einer Person: E-Mail, Telefon, Name plus Adresse, eine Kundennummer, eine Kombination. Bei einem Unternehmen: rechtlicher Name, Steuernummer, ERP-Kunden-ID, Adresse, Webdomain. Nicht «Kann Salesforce diese Felder vergleichen?», sondern «Welche Kombination gibt uns genug Sicherheit, um zu handeln?»

Und exakt heisst nicht sicher. Eine gemeinsame E-Mail ist ein starkes Signal, kein Beweis: Familien teilen Adressen, Unternehmen nutzen purchasing@company.com, Telefonnummern gehören Haushalten, Namen und Adressen sind nicht eindeutig, und selbst starke Kennungen werden wiederverwendet, vertippt oder recycelt. Abgleichen ist kein Zeichenkettenvergleich. Es ist eine Aussage über Identität.

Der Preis des Irrtums

Wenn ich das unterrichte, wechsle ich die Branche. In Marketingdaten der Autobranche entscheiden wir fälschlich, dass zwei Daniel Reyes dieselbe Person sind, und der falsche bekommt ein Angebot für einen SUV. Nicht gut, aber geringes Risiko. Machen Sie jetzt denselben falschen Treffer in medizinischen Daten: die Krankengeschichten zweier verschiedener Menschen kombiniert. Derselbe Abgleichfehler, völlig andere Folge. Deshalb gibt es keinen allgemein «guten» Schwellenwert für den Abgleich. Manchmal ist das grössere Risiko, einen Treffer zu verpassen; manchmal, zwei Menschen zu kombinieren, die nicht dieselben sind. Wo falsche Treffer teuer sind, gleiche ich absichtlich zu wenig ab.

Harmonisieren, dann abgleichen, dann konsolidieren

Das Abgleichen hängt auch von der Form der Daten ab. AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198. Harmonisierung macht Werte vergleichbar: Standardformate, normalisierte Abkürzungen, zugeordnete Codes. Dann gleichen Sie ab. Erst wenn bekannt ist, dass Datensätze zusammengehören, konsolidieren Sie ihre Informationen in eine Darstellung. Harmonisieren ist nicht Abgleichen, Abgleichen ist nicht Zusammenführen, und Konsolidieren ist nicht unbedingt Stammdatenführung.

Click to enlarge

Identitätsentscheidungen fallen in Stufen.

Ein Treffer verlangt kein Zusammenführen

Das ist eine der wichtigsten Unterscheidungen in diesem Kapitel. Wir sind sicher, dass zwei Kundendatensätze aus zwei alten Systemen dasselbe Unternehmen sind. Müssen wir sie zusammenführen? Nein. Jeder trägt vielleicht eine Identität aus dem Quellsystem; historische Transaktionen zeigen vielleicht auf jeden; die Prüfung braucht vielleicht die Spur; wir migrieren vielleicht noch; wir müssen vielleicht genau wissen, was das alte System gesagt hat. Zu wissen, dass zwei Datensätze dasselbe sind, zwingt uns nicht, sie zusammenzulegen. Wir können sie verknüpfen, und das ist oft die sicherere Architektur.

Meine Regel fürs Zusammenführen: ein klarer Gewinner

Meine Position: Führen Sie nur zusammen, wenn es einen klaren Gewinner gibt und das Duplikat nichts hinzufügt, was Sie behalten müssen. Jemand aus dem Vertrieb hat gestern einen doppelten Account angelegt; das Original ist eindeutig der etablierte Datensatz. Guter Kandidat zum Zusammenführen. Ändern Sie es jetzt: Wir haben Kunden aus einem Altsystem importiert, mit eigenen IDs, älteren Werten, vielleicht Transaktionen oder Prüfanforderungen, die daran hängen. Da bin ich viel vorsichtiger. Behalten Sie Duplikate aus externen Ladevorgängen, wenn Sie vielleicht zu älteren Werten zurückverfolgen müssen, denn das Zusammenführen zerstört diese Historie.

Was ein Zusammenführen in Salesforce tatsächlich tut

Eine Verknüpfung sagt «die gehören zusammen». Ein Zusammenführen sagt «die sind jetzt eins», und auf Salesforce ist das eine echte Änderung. Bei Accounts wählen Sie bis zu drei Datensätze und bestimmen einen als Hauptdatensatz; Sie wählen, welche Feldwerte der anderen Sie behalten, während ausgeblendete und schreibgeschützte Felder vom Hauptdatensatz kommen. Der zusammengeführte Datensatz behält Erstellt von und Erstellungsdatum des ältesten Datensatzes, gleich welcher der Hauptdatensatz ist. Die anderen Datensätze landen im Papierkorb. Verknüpfte Datensätze wie Aktivitäten wandern zum zusammengeführten Datensatz, mit Ausnahmen. In Lightning funktioniert das Zusammenführen bei den Duplikaten, die Ihre Duplikatsregeln erkennen. Und bei Personenaccounts unterstützen Kontaktpunktobjekte das Zusammenführen nicht: Ihre Beziehungen gehen verloren (Considerations for Merging Duplicate Accounts (opens in a new tab); Merge Duplicate Accounts in Lightning Experience (opens in a new tab), auf Englisch).

Prüfungswissen. Wissen Sie, was ein Zusammenführen von Accounts in Salesforce tut: bis zu drei Datensätze; ein Hauptdatensatz (Principal), dessen ausgeblendete und schreibgeschützte Felder erhalten bleiben; Erstellt von und Erstellungsdatum des ältesten Datensatzes, egal welcher der Hauptdatensatz ist; die anderen Datensätze wandern in den Papierkorb; und bei Personenaccounts werden Kontaktpunktobjekte nicht zusammengeführt.

Sie brauchen nicht jeden Randfall, um die Entscheidung zu treffen. Sie brauchen die Folge: Nach einem Zusammenführen sind die unabhängigen Datensätze, mit denen Sie begonnen haben, weg. Der Umkehrbarkeitstest aus Kapitel 1 gilt: Eine Verknüpfung lässt sich leicht rückgängig machen; ein Zusammenführen nicht. Und ein Kunde steht selten allein: Kontakte, Kundenvorgänge, Opportunities, Dateien, Einwilligungsdatensätze, benutzerdefinierte untergeordnete Datensätze, externe IDs, Integrationsreferenzen. Bevor Sie den übergeordneten Datensatz zusammenführen, verstehen Sie, was mit allem passiert, was daran hängt. Wenn Duplikate mit einem Ladevorgang hereinkommen, gebe ich Teams für die untergeordneten Datensätze drei Möglichkeiten: sie zum überlebenden Datensatz verschieben; sie gar nicht laden, wenn niemand sie braucht; oder sie am anderen Datensatz belassen, als inaktiv markiert, damit sie in der Suche noch auftauchen. Die erste erledigt ein Zusammenführen für Sie. Die anderen beiden bewahren die Spur, und genau darum geht es oft.

Survivorship: Welcher Wert gewinnt?

Datensätze gehören zusammen, aber sie widersprechen sich: Salesforce und die Abrechnung sagen 602-555-0100, das ERP sagt 602-555-0188. Survivorship-Regeln wählen den Gewinner. Die üblichen: der neueste (die letzte Aktualisierung), der häufigste (der Wert, auf den sich die meisten Quellen einigen) und Quellenpriorität (dieser Quelle mehr vertrauen als jener), plus Kombinationen, Schwellenwerte, Gewichtungen und geschäftsspezifische Regeln. Keine davon ist an sich richtig.

«Der neueste» ist keine technische Einstellung. Es ist eine Aussage über Vertrauen: Wenn Systeme sich widersprechen, ist der neueste Wert wahrscheinlicher richtig. Vernünftig für eine Mobilnummer. Schrecklich für einen rechtlichen Namen: Wenn er dem ERP gehört, ist mir egal, dass jemand vor fünf Minuten die Salesforce-Kopie geändert hat. «Der häufigste» nimmt an, Übereinstimmung sei ein Beleg, aber drei veraltete nachgelagerte Kopien überstimmen nicht das führende System. «Quellenpriorität» sagt es klar: Wir vertrauen dieser Quelle mehr. Survivorship gehört also in Architektur und Governance, und jede Regel braucht einen Eigentümer. Wer hat entschieden, dass die neueste Adresse gewinnt oder dass das ERP Salesforce übertrumpft?

Wenn die Autoritätskarte aus Modul 1 schon sagt, dass dem ERP das Kreditlimit gehört, ist Survivorship einfach: Das ERP gewinnt, keine raffinierte Bewertung nötig. Die schweren Fälle sind Attribute, bei denen die Autorität geteilt, unklar oder auf Belegen statt auf einem Master gegründet ist. Dort verdienen sich Survivorship-Regeln ihren Platz.

Click to enlarge

Survivorship-Regeln sind Aussagen über Vertrauen.

Schwellenwerte, Prüfung und Anreicherung

Manche Abgleiche gewichten die Belege: eine übereinstimmende Kunden-ID ist sehr stark, eine E-Mail stark, ein Telefon mittel, ein ähnlicher Name schwach, eine ähnliche Adresse unterstützend. Über einer Punktzahl ein Treffer; unter einer anderen verschieden; dazwischen prüft ein Mensch. Der Algorithmus ist nicht die Lektion. Der Schwellenwert ist Ihre Fehlertoleranz, und er sollte dem geschäftlichen Risiko folgen. Und wenn die Belege die Frage aufwerfen, ohne sie zu klären, tun Sie nicht so, als wüsste das System Bescheid. Leiten Sie sie zur Prüfung weiter. Langsamer, und das ist in Ordnung: Automatisierung ist nichts wert, wenn sie selbstbewusst zwei verschiedene Kunden zusammenführt.

Anreicherung bringt eine weitere Herkunftsfrage. Postalische Referenzdaten, Branchencodes, Firmendaten, externe Risikowerte verbessern Stammdaten, aber woher kommt jeder Wert, wie verlässlich und aktuell ist er, dürfen wir ihn für diesen Zweck nutzen, enthält er personenbezogene Daten? «Branche = Transport» von einem Datenanbieter ist nicht dasselbe, wie wenn der Kunde es Ihnen sagt. Bewahren Sie diese Unterscheidung.

Steve Trucking: Ähnlich ist nicht gleich

Zwei Handelspartner schicken Lieferungen an John Smith, 123 Main Street, Columbus, mit derselben Telefonnummer. Dieselbe Person? Wahrscheinlich. Sollte Steve Trucking sie vereinheitlichen? Erinnern Sie sich, wem sie gehören: Diese Empfänger sind die Kunden der Partner, und ein Partner darf nie die eines anderen sehen. Ein falscher Treffer würde Daten über diese Grenze vermischen. Plötzlich ist es keine Datenqualitätsfrage mehr, sondern eine Frage von Datenschutz und Trennung, und genau deshalb hängen Schwellenwerte von den Folgen ab. Der Checkpoint trifft die Entscheidung. Für jetzt: Lassen Sie nicht die Bequemlichkeit des Abgleichens die geschäftliche Entscheidung treffen.

Manchmal sagt Ihnen das Durcheinander etwas, wenn Sie es behalten. Dieser Datensatz kam aus dem alten System, jener aus Salesforce, dieser aus dem übernommenen Unternehmen; ihre IDs, ihre Historie und die Tatsache, dass sie sich widersprachen, können alle zählen. Saubere Daten sind wertvoll. Nachverfolgbarkeit auch. Die Architektur entscheidet, was für die Nutzung mehr zählt.

Über die Prüfung hinaus: Was KI ändert. Ein schlechter Treffer hiess früher zwei E-Mails oder eine aufgeteilte Servicehistorie. Jetzt findet ein Agent, was er für den Kunden hält, und holt dessen Aufträge, Kundenvorgänge, Adressen und Notizen. Wenn zwei Menschen fälschlich abgeglichen wurden, kann er für eine Person auf die Informationen einer anderen handeln. Die Abgleichentscheidung ist Teil der Sicherheitsgrenze geworden, und wo Vermischung teuer ist, ist strengeres Abgleichen der sicherere Entwurf.

Was Architekt:innen hier entscheiden

• Welche Belege in jedem Datenbereich reichen, um ein mögliches Duplikat zu melden.
• Ob ein bestätigter Treffer zu einem Zusammenführen, einer Verknüpfung oder einer menschlichen Prüfung wird.
• Welche Werte einen Widerspruch überleben und wem jede Survivorship-Regel gehört.
• Wie viel Risiko falscher Treffer das Geschäft gegenüber dem Risiko verpasster Treffer tolerieren kann.
• Welche Quellidentitäten, Historie und verknüpften Datensätze vor jedem Zusammenführen bewahrt werden müssen.

Gleichen Sie sorgfältig ab, führen Sie bewusst zusammen, wählen Sie Survivorship-Regeln absichtlich. Ein sauberer Kundendatensatz ist nicht viel wert, wenn Sie dorthin gekommen sind, indem Sie die falschen Kunden kombiniert haben.

Weiterlesen

• Salesforce-Hilfe, Considerations for Merging Duplicate Accounts (opens in a new tab) und Merge Duplicate Accounts in Lightning Experience (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.
• Salesforce-Hilfe, Things to Know About Duplicate Rules (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.