Einen RuleSet in DQE One Standalone konfigurieren

Ein RuleSet legt fest, wie DQE One Standalone entscheidet, welche Datensätze Duplikate sind, welcher davon zum "parent" (dem Überlebenden) wird, welche Duplikate statt zusammengeführt getrennt bleiben sollen, und welche Feldwerte beim Zusammenführen von Datensätzen gewinnen. Sie benötigen ein veröffentlichtes RuleSet, um einen Unify Process oder einen Index Records-Prozess zu erstellen.

Wo Sie ein RuleSet konfigurieren

Gehen Sie zu Rules Manager (linke Navigation), um alle von Ihnen erstellten RuleSets zu sehen, mit Quelle, Datum der letzten Änderung und Status (Draft oder Published). Von hier aus können Sie auf New ruleset klicken, oder die Zeilenaktionen nutzen: Clone, Download the ruleset as a JSON file, oder Delete.

Delete ist aus zwei unterschiedlichen Gründen gesperrt: Ein RuleSet, das von einem gerade laufenden Prozess genutzt wird, wird wieder entsperrt, sobald dieser Lauf abgeschlossen ist. Ein RuleSet, das an einen Prozess angehängt ist, der aktuell — oder jemals — einen Scheduler hatte, bleibt dagegen dauerhaft gesperrt, selbst nachdem Sie diesen Zeitplan auf Inactive gestellt haben (siehe Schedule a process in DQE One Standalone und Maintain your data and processes in DQE One Standalone).

Sie können den Editor auch über den RuleSet-Auswähler im Process-Erstellungsassistenten erreichen, indem Sie auf Create new set klicken — dies öffnet denselben Editor, bereits mit diesem Process verknüpft.

Nach der Wahl einer Datenquelle und eines Objekts (sowie eines Label/Description) hat der Editor selbst 3 Tabs: Matching Rules, Sibling, Parent Rules und Merge Rules.

Matching Rules

Eine Matching Rule ist ein "Schritt" (angezeigt als eigener benannter Tab, z. B. "Name / Email"), der aus einer oder mehreren Field Match-Zeilen besteht. Jedes hinzugefügte Feld wird mithilfe einer Method verglichen — einer vorgefertigten Kombination aus einem Blocking-Algorithmus, einem Fuzzy-Distanz-Algorithmus und einer Standardtoleranz. Die tatsächliche Liste der verfügbaren Methods:

Default Tolerance ist der Wert, den jede Method in der Field-Match- Zeile vorausfüllt (Sie können ihn weiterhin ändern). Die Spalte Beispiel veranschaulicht die Art von Abweichung, die jede Method erkennen soll — die zugrunde liegenden Matching-Algorithmen sind proprietär und kompiliert, betrachten Sie dies also als veranschaulichend, nicht als Garantie für das genaue Treffer-/Nichttreffer-Verhalten.

Für jede Field-Match-Zeile legen Sie fest:

• Select a Field — das zu vergleichende Feld.
• Ignore Empties — standardmäßig aktiviert; überspringt die Regel für Datensätze, bei denen das Feld leer ist.
• Tolerance — 0 bis 100 %, wie unscharf der Abgleich für dieses Feld sein darf.
• Noise — ermöglicht optional das Auflisten von Wörtern/Phrasen, die beim Vergleich ignoriert werden sollen (nützlich für wiederkehrende Zusätze wie "SARL" in Firmennamen, sofern die gewählte Method dies nicht bereits abdeckt).
• Field Relation — wie sich diese Zeile zum nächsten Field Match in der Liste verhält: No relation, Cross Check, Append oder Invert.

Advanced Rules: für die Feinsteuerung verfügt jedes Field Match über einen Bereich "Advanced Rules", der den rohen Blocking-Algorithmus (KeyAlgo) und den Distanz-Algorithmus (DistAlgo) offenlegt, die die gewählte Method standardmäßig setzt, sowie ein optionales Weight. In der Regel müssen Sie dies nicht anfassen — die Method-Auswahlliste oben wählt bereits sinnvolle Standardwerte — aber der Bereich ist vorhanden, falls Sie einen bestimmten Key-Algorithmus mit einem bestimmten Distanz-Algorithmus kombinieren müssen.

Ein reales Beispiel aus den eigenen Standardregeln von DQE für einen Salesforce Lead (3 separate Matching Rules — "Name / Email", "Name / Phone", "Name / Address"):

Name / Email:
  Email      → "Analyze an EMAIL"     (Tolerance 0%)
  LastName   → "Analyze a LAST NAME"  (Tolerance 15%)
  FirstName  → "Analyze a FIRST NAME" (Tolerance 15%)

Matching Rules werden der Reihe nach ausgewertet, und ihre Reihenfolge beeinflusst das Ergebnis. Die eigenen Empfehlungen von DQE geben folgendes Beispiel: Regel 1 — exakter Abgleich auf Email; Regel 2 — unscharfer Abgleich auf First Name + Last Name (Toleranz 80 %); Regel 3 — Cross Check zwischen Home Phone und Mobile Phone.

Sibling, Parent Rules

Parent Rules — wie der überlebende Datensatz bestimmt wird

Wenn mehrere Datensätze übereinstimmen, wird einer davon zum parent (dem Datensatz, der erhalten bleibt), und die übrigen werden zu seinen Duplikaten. Die Parent Rules entscheiden, welcher:

Der eigene Standardwert von DQE für ein Standard-RuleSet Lead/Contact/Account ist Oldest first, nach CreatedDate — "den ältesten Datensatz als parent behalten". Für ein Multi-Objekt-RuleSet Contact+Lead ist der Standard stattdessen Parent is Primary, wobei immer der Contact behalten wird.

Sie können mehrere Parent Rules stapeln. Die erste entscheidet; jede nachfolgende Regel löst nur Gleichstände auf, die von der vorherigen übrig gelassen wurden. Beispiel: Newest first gefolgt von Contains (Email enthält @dqe-software.com) stapeln — wenn zwei Datensätze exakt dasselbe Datum teilen, gewinnt derjenige mit der internen E-Mail; andernfalls gewinnt der neuere Datensatz direkt, und die zweite Regel kommt nie zum Einsatz.

Sibling Rules — übereinstimmende Datensätze absichtlich getrennt halten

Jeder Datensatz, der nicht als parent ausgewählt wird, ist informell ein sibling dieses parent. Eine Sibling Rule ist die Art, wie Sie DQE One Standalone mitteilen: "diese Datensätze stimmen zwar überein, aber führen Sie sie nicht zu einem zusammen — halten Sie sie verknüpft, aber getrennt." Datensätze aus derselben Quelle, die untereinander übereinstimmen, werden ebenfalls automatisch als Siblings behandelt, ohne dass eine Regel nötig ist.

Klicken Sie auf Add a new Sibling Rule und wählen Sie eine Bedingung:

• Record condition — ein Feld des Datensatzes erfüllt eine Bedingung (gleich, ungleich, größer/kleiner als, beginnt mit, endet mit, enthält, in Liste, nicht in Liste).
• Parent condition / Child condition — dasselbe, aber nur auf dem Feld des parent bzw. nur auf dem des child getestet. Beispiel: Child Email endet auf @test.com → Testdatensätze werden nie in einen echten parent zusammengeführt.
• Parent child condition — eine Bedingung auf dem parent UND eine Bedingung auf dem child müssen beide wahr sein. Beispiel: Parent Country gleich FR UND Child Country gleich US → länderübergreifende Treffer bleiben getrennt.
• Date condition — vergleicht das gewählte Datumsfeld zwischen allen Datensätzen der übereinstimmenden Gruppe, jeweils paarweise: ein direkter Operator (gleich, größer als, kleiner als usw.) vergleicht die Daten direkt, während ein "Delta"-Operator die Differenz zwischen zwei Daten (in Tagen) mit einem von Ihnen festgelegten Jahre/Monate/Tage-Schwellenwert vergleicht. Beispiel: CreatedDate, Delta ≥ 1 Jahr → Datensätze, die mehr als ein Jahr auseinander erstellt wurden, bleiben Siblings, statt zusammengeführt zu werden.
• Record value test — Sibling, wenn irgendein Datensatz der übereinstimmenden Gruppe den Wert dieses Felds in einer von Ihnen angegebenen Liste hat. Beispiel: Status in Liste Test, Demo → ein einziger Test-/Demo-Datensatz hält die gesamte Gruppe als Siblings.
• Parent child value test — Sibling, wenn der Wert des parent in einer Liste UND mindestens ein Wert eines child in einer anderen Liste enthalten ist. Beispiel: Parent Type in Prospect UND ein child mit Type in Customer → das Paar bleibt getrennt.
• Parent child value non empty — sowohl der Wert des parent als auch der des child müssen ausgefüllt sein. Beispiel: sowohl der parent als auch ein child haben bereits Legacy_ID__c ausgefüllt → jeder behält seine eigene Legacy-Referenz, statt zusammengeführt zu werden.
• Multiple values / Multiple tuples — die Gruppe wird als Siblings behandelt, wenn ein Feld (oder eine Kombination von Feldern) mehr als einen eindeutigen Wert innerhalb der Gruppe hat. Beide verfügen über eine Option Ignore Empties (standardmäßig aktiviert), die leere Werte von der Zählung ausschließt. Beispiel: die Gruppe hat zwei unterschiedliche Email-Werte → als Siblings erhalten, damit keine der beiden Adressen bei der Zusammenführung verloren geht.
• Tuple cardinality test — vergleicht, wie viele eindeutige Werte eine Feldkombination hat, mithilfe eines von Ihnen gewählten Operators (gleich, ungleich, größer/kleiner als usw.), gegen eine von Ihnen festgelegte Zahl. Verfügt ebenfalls über dieselbe Option Ignore Empties. Beispiel: die Kombination (Country, Language) hat innerhalb der Gruppe eine Kardinalität größer als 1 → wird in Siblings aufgeteilt, sobald mehr als ein Land/Sprache-Paar vorkommt.
• (Custom) — schreiben Sie Ihre eigene Bedingung.

Feldnamen, Listen und Schwellenwerte in den obigen Beispielen sind generische Veranschaulichungen davon, wie sich jede Bedingung verhält (anhand der tatsächlichen Filterfunktionen bestätigt), keine Werte aus einem echten Org — passen Sie sie an Ihre eigenen Felder an.

Reales Beispiel — Datensätze als Siblings behandeln, statt sie zusammenzuführen, wenn ein Gruppierungsfeld einem bestimmten Wert entspricht:

Record condition:
  Field: Compte_de_regroupement__c
  Condition: in list
  Value: CLIENT ESPACE PRO

Wenn Sie Salesforce verwenden: als Siblings markierte Datensätze werden dort als "Unique" angezeigt, nicht als "Sibling" — das Ergebnisfeld von DQE bildet ab: Parent → "Parent", Child → "Child", und Sibling → "Unique". Behalten Sie dies im Hinterkopf, wenn Sie Ergebnisse in Salesforce abgleichen.

Merge Rules

Merge Rules entscheiden, welcher Wert Feld für Feld gewinnt, wenn ein Duplikat mit seinem parent zusammengeführt wird. Für jedes Feld hängen Sie eine oder mehrere Methoden an, die der Reihe nach wie eine Kaskade ausgewertet werden: Die erste Methode, die eine eindeutige Antwort liefert, gewinnt; findet sie parent und child für diesen Zweck gleich, geht die Auswertung zur nächsten Methode über; finden alle Methoden sie gleich, bleibt der bestehende Wert des parent erhalten.

Terminal-Methoden (Concatenate Lists, Sum of Fields, Custom) berechnen den Endwert direkt und können nicht mit den anderen, bedingungsbasierten Methoden für dasselbe Feld kombiniert werden.

Felder gruppieren

Wenn mehrere Felder immer aus demselben Datensatz stammen müssen (damit Adresszeilen nicht aus zwei unterschiedlichen Quelldatensätzen gemischt werden), fassen Sie sie in einer Group zusammen und markieren Sie eines als Main Field. Die Methoden, die Sie auf dem Main Field festlegen, gelten für die gesamte Gruppe.

Beispiel: Street, City und ZipCode unter einer Gruppe namens ADDRESS gruppieren, Street als Main Field mit "Newer Than" festlegen — welcher Datensatz bei Street gewinnt, liefert dann zusammen auch City und ZipCode.

Sie können auf Preview klicken, um vor der Veröffentlichung zu sehen, was die generierte Merge-Logik erzeugen würde.

Veröffentlichung

Klicken Sie auf Publish. Ein RuleSet kann erst veröffentlicht werden, wenn es mindestens eine Matching Rule mit mindestens einem Field Match und mindestens eine Parent Rule hat — Merge Rules und Sibling Rules sind optional. Fehlt eine dieser Voraussetzungen, sehen Sie "Publication error: Required rules missing".

Das Veröffentlichen sperrt das RuleSet nicht dauerhaft gegen weitere Bearbeitungen — es gibt keine "Unpublish"-Schaltfläche. Ein RuleSet ist nur vorübergehend gesperrt (schreibgeschützt), solange ein Process, der es verwendet, aktiv läuft; sobald dieser Run beendet ist, können Sie es wieder bearbeiten.