Eindeutigkeit: Konfigurationsszenarien

Was diese Szenarien abdecken

Diese Seite führt durch drei praxisnahe Konfigurationen der DQS-Eindeutigkeitsanalyse. Jedes Szenario behandelt ein konkretes geschäftliches Problem, zeigt die exakten Einstellungen und erklärt, wie die Ergebnisse zu lesen sind.

Diese Anleitungen bauen auf den Konzepten aus dem Hauptartikel Eindeutigkeit auf. Lesen Sie diesen zuerst, falls Eindeutigkeitsmetriken, die diagnostischen Ebenen oder der Unterschied zwischen Basic Uniqueness und Advanced Uniqueness Analysis neu für Sie sind.

Szenario 1: E-Mail-Deduplizierungs-Audit auf Leads

Das Problem

Ihr Marketingteam führt Nurture-Kampagnen über Salesforce durch. Die Öffnungsraten sinken, und die E-Mail-Plattform meldet eine steigende Anzahl von „Dubletten-Versand”: dieselbe Person erhält dieselbe E-Mail zweimal. Ihre Duplicate-Management-Regeln erfassen Exact-Match-Datensätze, aber partielle Duplikate rutschen durch. Zwei Lead-Datensätze für dieselbe Person mit derselben E-Mail-Adresse erhalten beide die Kampagne. Sie benötigen eine konkrete Zahl: Wie viele Lead-E-Mail-Adressen werden von mehreren Datensätzen geteilt?

Konfiguration

Dies ist eine einfache Dubletten-Erkennungsprüfung. Verwenden Sie den Modus Basic Uniqueness auf dem Lead-Objekt mit dem Zielfeld Email.

Case Sensitive AUS ist die Standardeinstellung und die richtige Wahl für E-Mail. Wenn zwei Datensätze „jsmith@acme.com” und „JSmith@Acme.com” speichern, sind das dieselben Adressen. Case-Sensitivität würde sie als distinkt zählen und das Duplikat verbergen.

Beispielergebnisse

Grundmetriken:

Gesamtzahl ausgewerteter Lead-Datensätze: 25.000.

Ergebnisse interpretieren

Beginnen Sie mit der Schlagzeile: 74 % Eindeutigkeit. Das bedeutet, dass 26 % der E-Mail-Adressen auf mehr als einem Lead-Datensatz erscheinen. Von 25.000 Leads existieren nur 18.500 distinkte E-Mail-Adressen. Die Lücke von 6.500 Datensätzen sind geteilte E-Mail-Adressen.

Wie 26 % duplizierte E-Mails in der Praxis aussehen. Einige sind legitim: Abteilungsadressen wie info@company.com oder sales@company.com, die von mehreren Contacts desselben Unternehmens geteilt werden. Die meisten sind doppelte Leads, die von verschiedenen Quellen erstellt wurden. Ein Webformular erstellt einen Lead. Ein Listenimport erstellt einen weiteren. Ein Vertriebsmitarbeiter erstellt einen dritten von einer Visitenkarte. Alle drei haben dieselbe E-Mail-Adresse.

Include Blanks EIN zeigt das vollständige Bild. Mit aktiviertem Include Blanks teilen alle Leads ohne E-Mail-Adresse einen einzigen „leeren” Wert. Wenn 2.000 der 25.000 Leads keine E-Mail haben, zählen diese 2.000 Datensätze als Duplikate voneinander. Das senkt die Uniqueness Rate im Vergleich zum Ausschluss von Blanks, gibt Ihnen aber die ehrliche Zahl. Ihre Kampagne kann bestenfalls 18.500 distinkte Adressen erreichen, nicht 25.000.

Warum Basic Uniqueness hier ausreicht. Die Frage lautet „Wie viele E-Mails sind dupliziert?”. Uniqueness Rate und Distinct Count beantworten diese Frage. Sie brauchen keine Entropy oder Rarity, um über ein Deduplizierungsprojekt zu entscheiden. Wenn Sie später das Verteilungsmuster verstehen wollen (wie viele E-Mails genau zweimal vs. zehnmal erscheinen), wechseln Sie zu Advanced Uniqueness Analysis für das vollständige Bild.

Was als Nächstes zu tun ist

Verwenden Sie Distinct Count (18.500) als Ihre tatsächlich erreichbare Zielgruppe für E-Mail-Kampagnen. Dimensionieren Sie ein Deduplizierungsprojekt für die Datensätze mit geteilten E-Mails. Exportieren Sie zunächst Leads gruppiert nach E-Mail-Adresse, führen Sie dann die Duplikate zusammen oder löschen Sie sie. Scannen Sie nach der Bereinigung erneut und verfolgen Sie die Uniqueness Rate über die Zeit. Fällt sie zwischen Scans, ist eine neue Duplikatquelle aufgetaucht: ein Listenimport, ein Webformular ohne Dedup-Logik oder eine Integration, die Datensätze erstellt, ohne auf bestehende zu prüfen.

Szenario 2: Verteilung des Industry-Felds auf Accounts

Das Problem

Ihr Datenteam hat ein Account-Segmentierungsmodell gebaut, das Kunden nach Industry gruppiert. Das Modell verwendet 24 Industry-Picklist-Werte, um zielgerichtete Segmente zu erzeugen. Aber die Segmente sind ungleichmäßig: Zwei Segmente enthalten 70 % aller Accounts, während sich die restlichen 22 Segmente die anderen 30 % teilen. Das Data-Science-Team vermutet, dass das Industry-Feld ein Verteilungsproblem hat, kein Modellproblem. Sie müssen bestätigen, ob die Werteverteilung des Felds tatsächlich schief ist, und die dominanten Werte identifizieren.

Konfiguration

Verwenden Sie den Modus Advanced Uniqueness Analysis auf dem Account-Objekt mit dem Zielfeld Industry. Sie benötigen Verteilungsmetriken (Entropy, Max Frequency, Rarity), um Fragen zur Werteverteilung zu beantworten.

Include Blanks AUS ist hier die richtige Wahl. Sie analysieren, wie die bestehenden Daten über Kategorien verteilt sind. Blanks in die Berechnung aufzunehmen würde die Verteilungsmetriken verzerren, ohne Ihre Segmentierungsfrage zu beantworten. Wenn Sie wissen möchten, wie viele Accounts keinen Industry-Wert haben, führen Sie stattdessen eine Vollständigkeitsanalyse durch.

Beispielergebnisse

Grundmetriken:

Erweiterte Metriken:

Gesamtzahl ausgewerteter Account-Datensätze: 15.000.

Ergebnisse interpretieren

Uniqueness Rate (0,16 %) ist erwartet und hier irrelevant. Industry ist eine Picklist mit 24 Werten über 15.000 Datensätze. Fast jeder Wert wird von Hunderten Datensätzen geteilt. Eine niedrige Uniqueness Rate auf einem Picklist-Feld ist normal. Diese Metrik ist nicht der Punkt dieser Analyse.

Distinct Count (24) bestätigt, dass Ihre Picklist intakt ist. Alle 24 konfigurierten Werte kommen in den Daten vor. Es existieren keine abtrünnigen Freitexteinträge. Die Daten sind aus Konsistenzsicht sauber.

Entropy (2,18) offenbart die Schieflage. Die maximale Entropy für 24 distinkte Werte ist log2(24) = 4,58. Ihre tatsächliche Entropy ist 2,18. Der normalisierte Wert ist 2,18 / 4,58 = 0,48. Das liegt deutlich unter der 0,7-Schwelle für „dominierte” Verteilungen. Wenige Werte halten die meisten Datensätze. Die Vermutung Ihres Data-Science-Teams ist bestätigt: Das Segmentierungsproblem liegt in den Daten, nicht im Modell.

So interpretieren Sie normalisierte Entropy:

Ihr Wert von 0,48 liegt im „dominiert”-Bereich.

Max Frequency (5.200) identifiziert den dominanten Wert. Ein Industry-Wert erscheint auf 5.200 von 15.000 Datensätzen, also 34,7 % des Datensatzes. Eine schnelle Prüfung zeigt, dass es „Technology” ist. Der zweithäufigste Wert ist wahrscheinlich für den Großteil der verbleibenden Konzentration verantwortlich. Zusammen machen zwei Werte die 70-%-Clusterung aus, die Ihr Team beobachtet hat.

Rarity (0 %) bestätigt, dass es keinen Long Tail gibt. Jeder der 24 distinkten Werte erscheint mehr als einmal. Es existieren keine Singleton-Werte. Das ist für ein gut kontrolliertes Picklist-Feld zu erwarten. In einem Freitextfeld würden Sie Rarity nutzen, um Tippfehler und Einzeleinträge zu erfassen, aber auf einer Picklist ist 0 % Rarity normal.

Das Segmentierungsurteil: Ihr 24-Kategorien-Modell ist in Wirklichkeit ein 2-Kategorien-System. „Technology” und eine weitere Branche dominieren den Datensatz. Die restlichen 22 Kategorien teilen sich 30 % der Datensätze, was jeder Kategorie durchschnittlich etwa 200 Datensätze gibt. Einige Segmente sind zu klein für sinnvolle Analysen.

Was als Nächstes zu tun ist

Präsentieren Sie Entropy und Max Frequency Ihrem Data-Science-Team. Die Zahlen bestätigen das Verteilungsproblem. Zwei Optionen: (1) Gestalten Sie das Segmentierungsmodell neu, um weniger, breitere Kategorien zu verwenden, die die tatsächliche Verteilung widerspiegeln. Gruppieren Sie die 22 kleineren Branchen in 4–5 Makrokategorien. (2) Reichern Sie die Industry-Daten an. Wenn die Konzentration in „Technology” überhöht ist, weil Mitarbeitende diese bei der Datensatzerstellung standardmäßig wählen, untersuchen Sie, ob ein großer Teil dieser 5.200 Datensätze zu einer anderen Branche gehört. Führen Sie regelmäßig Scans durch und verfolgen Sie Entropy über die Zeit. Wenn Sie fehlklassifizierte Datensätze korrigieren, steigt Entropy in Richtung einer gesünderen Verteilung.

Szenario 3: Boilerplate-Erkennung in Case-Beschreibungen für KI-Bereitschaft

Das Problem

Ihr Unternehmen evaluiert KI-gestützte Case-Zusammenfassung für das Support-Team. Das KI-Tool liest das Feld Description auf Cases und erzeugt eine Zusammenfassung für den nächsten Mitarbeitenden, der den Case übernimmt. Vor der Investition müssen Sie beurteilen, ob Ihre Case-Beschreibungen genug originalen Inhalt enthalten, damit die KI brauchbare Zusammenfassungen erzeugt. Das Feld ist auf 95 % der Cases befüllt, also ist Vollständigkeit nicht das Anliegen. Das Anliegen ist, dass Support-Mitarbeitende Standardvorlagen in jeden Case kopieren.

Konfiguration

Verwenden Sie den Modus Advanced Uniqueness Analysis auf dem Case-Objekt mit dem Zielfeld Description. Sie benötigen die Boilerplate-Metriken, um die Inhalts-Originalität zu bewerten.

Include Blanks AUS macht hier Sinn, weil Sie den vorhandenen Inhalt bewerten, nicht den fehlenden Inhalt zählen. Die 5 % der Cases mit leeren Beschreibungen werden bereits von Ihrer Vollständigkeitsanalyse abgedeckt.

Beispielergebnisse

Grundmetriken:

Erweiterte Metriken:

Gesamtzahl ausgewerteter Case-Datensätze: 30.000.

Ergebnisse interpretieren

Uniqueness Rate (97 %) sieht gesund aus, ist aber irreführend. Fast jede Case-Beschreibung ist technisch anders, weil jede eindeutige Case-Nummern, Kundennamen und Daten enthält. Das Feld besteht eine einfache Duplikationsprüfung. Aber „einzigartig” bedeutet nicht „original”.

Boilerplate Rate (42 %) erzählt die wahre Geschichte. 42 % des Textinhalts in Case-Beschreibungen sind repetitiv oder vorlagenbasiert. Mitarbeitende fügen Standard-Öffnungen („Thank you for contacting support. Your case number is …”), Standard-Schlüsse („Please do not hesitate to reach out if you have further questions.”) und Standard-Diagnose-Checklisten in jeden Case ein. Die fallspezifischen Details füllen die Mitte, aber fast die Hälfte jeder Beschreibung ist Copy-Paste-Inhalt.

Boilerplate Percentage (68 %) zeigt, wie verbreitet das Problem ist. 68 % der Case-Datensätze enthalten vorlagenbasierten Text. Das sind 20.400 von 30.000 Cases. Die Boilerplate ist nicht auf ein paar Mitarbeitende oder ein Team beschränkt. Es ist ein systemisches Muster, das in Ihren Support-Prozess eingebettet ist.

Boilerplate Records Count (20.400) ist Ihre Umfangszahl. Wenn Sie den Aufwand schätzen müssen, Vorlagen zu bereinigen, bevor Sie Daten an die KI liefern, ist dies der Ausgangspunkt. 20.400 Datensätze enthalten Inhalt, den die KI als Muster lernt, aber diese Muster sind Ihre Vorlagen, nicht Ihre Kundenprobleme.

Das Urteil zur KI-Bereitschaft: Das KI-Zusammenfassungstool wird vorlagenbasierten Inhalt in 68 % der Cases verarbeiten. Es wird lernen, Ihre Vorlagen zusammenzufassen, nicht Ihre Kundenprobleme. Auf den 32 % der Cases mit originalem Inhalt wird die KI gut performen. Auf den 68 % mit Boilerplate werden die Zusammenfassungen die Standardphrasen widerspiegeln, die Mitarbeitende bereits auswendig kennen.

Entropy (14,8) ist hoch und bestätigt, dass der Text auf Zeichenebene vielfältig ist. Das stimmt mit den 97 % Uniqueness Rate überein: jede Beschreibung ist anders. Entropy ist hier nicht die relevante Metrik, weil das Duplikationsproblem nicht identische Werte sind. Das Problem sind wiederholte Inhaltsmuster innerhalb ansonsten einzigartigen Texts. Genau das erfassen die Boilerplate-Metriken.

Was als Nächstes zu tun ist

Präsentieren Sie Boilerplate Rate (42 %) und Boilerplate Percentage (68 %) Ihren KI-Projekt-Stakeholdern. Die Zahlen sprechen eine klare Sprache: Das KI-Projekt braucht vor dem Einsatz eine Phase zur Verbesserung der Inhaltsqualität. Drei Ansätze zur Reduzierung von Boilerplate:

• Entfernen Sie die Vorlagen. Wenn Mitarbeitende Standard-Öffnungen und -Schlüsse einfügen, bauen Sie diese Elemente in das Case-Layout oder einen Screen Flow ein, damit sie das Beschreibungsfeld nicht verunreinigen. Die Beschreibung erfasst dann nur fallspezifische Informationen.
• Schulen Sie Mitarbeitende in effektiven Beschreibungen. Teilen Sie Beispiele für qualitativ hochwertige Beschreibungen (aus den 32 %, die original sind) und erklären Sie, warum vorlagenfreie Einträge bessere KI-Zusammenfassungen erzeugen.
• Entfernen Sie Boilerplate aus historischen Daten. Bevor Sie bestehende Cases an die KI liefern, führen Sie einen Textverarbeitungs-Job aus, der bekannte Vorlagenmuster aus dem Beschreibungsfeld entfernt.

Scannen Sie nach jedem Verbesserungszyklus erneut. Verfolgen Sie Boilerplate Rate und Boilerplate Percentage als Ihre primären KI-Bereitschafts-Metriken für dieses Feld. Ihr Ziel: Boilerplate Percentage unter 30 % und Boilerplate Rate unter 20 %, bevor Sie das KI-Zusammenfassungstool einsetzen.

Ihre Konfiguration wählen

Nutzen Sie diese Tabelle, um den richtigen Ausgangspunkt für Ihre Eindeutigkeitsanalyse zu wählen.

Für eine vollständige Referenz aller 8 Eindeutigkeitsmetriken, der drei diagnostischen Ebenen und der Konfigurationsdetails kehren Sie zum Hauptartikel Eindeutigkeit zurück.

Bereit, Ihre eigene Datenqualität zu messen? Nehmen Sie am AI Readiness Assessment teil, um Ihre Eindeutigkeitswerte und mehr zu sehen.