Unicita: scenari di configurazione

Cosa coprono questi scenari

Questa pagina illustra tre configurazioni reali dell’analisi di unicita di DQS. Ogni scenario affronta un problema aziendale specifico, mostra le impostazioni esatte da utilizzare e spiega come leggere i risultati.

Queste guide si basano sui concetti trattati nell’articolo principale sull’Unicita. Si consiglia di leggerlo prima se non si ha familiarita con le metriche di unicita, i livelli diagnostici o la differenza tra Basic Uniqueness e Advanced Uniqueness Analysis.

Scenario 1: audit di deduplicazione delle email sui Lead

Il problema

Il team marketing esegue campagne di nurturing tramite Salesforce. I tassi di apertura sono in calo e la piattaforma email segnala un numero crescente di «invii duplicati»: la stessa persona riceve la stessa email due volte. Le regole di gestione dei duplicati intercettano i record con corrispondenza esatta, ma i duplicati parziali sfuggono. Due record Lead per la stessa persona con lo stesso indirizzo email ricevono entrambi la campagna. Serve un numero concreto: quanti indirizzi email dei Lead sono condivisi tra piu record?

Configurazione

Si tratta di un semplice controllo di rilevamento duplicati. Utilizzare la modalita Basic Uniqueness sull’oggetto Lead, selezionando il campo Email.

Case Sensitive OFF e il valore predefinito e la scelta corretta per le email. Se due record memorizzano «jsmith@acme.com» e «JSmith@Acme.com», si tratta dello stesso indirizzo. Abilitare la distinzione tra maiuscole e minuscole li conterebbe come distinti e nasconderebbe il duplicato.

Risultati di esempio

Metriche di base:

Totale record Lead valutati: 25.000.

Lettura dei risultati

Si parta dal dato principale: 74% di unicita. Cio significa che il 26% degli indirizzi email appare su piu di un record Lead. Su 25.000 Lead, esistono solo 18.500 indirizzi email distinti. Il gap di 6.500 record e costituito da indirizzi email condivisi.

Come si presenta il 26% di email duplicate nella pratica. Alcuni sono legittimi: indirizzi di reparto come info@company.com o sales@company.com condivisi tra piu contatti della stessa azienda. La maggior parte sono Lead duplicati creati da fonti diverse. Un modulo web crea un Lead. Un’importazione di lista ne crea un altro. Un commerciale ne crea un terzo da un biglietto da visita. Tutti e tre hanno lo stesso indirizzo email.

Include Blanks ON rivela il quadro completo. Con Include Blanks abilitato, i Lead senza indirizzo email condividono tutti un singolo valore «blank». Se 2.000 dei 25.000 Lead non hanno email, quei 2.000 record contano come duplicati l’uno dell’altro. Cio abbassa l’Uniqueness Rate rispetto all’esclusione dei blank, ma fornisce il numero reale. Le campagne possono raggiungere al massimo 18.500 indirizzi distinti, non 25.000.

Perche Basic Uniqueness e sufficiente in questo caso. La domanda e «quante email sono duplicate?» Uniqueness Rate e Distinct Count rispondono a questa domanda. Non servono Entropy o Rarity per decidere se avviare un progetto di deduplicazione. Se in seguito si desidera comprendere il pattern di distribuzione (quante email appaiono esattamente due volte vs dieci volte), passare ad Advanced Uniqueness Analysis per il quadro completo.

Cosa fare dopo

Utilizzare il Distinct Count (18.500) come audience realmente raggiungibile per le campagne email. Dimensionare un progetto di deduplicazione per i record con email condivise. Iniziare esportando i Lead raggruppati per indirizzo email, quindi unire o eliminare i duplicati. Dopo il cleanup, eseguire nuovamente la scansione e monitorare l’Uniqueness Rate nel tempo. Se scende tra le scansioni, e comparsa una nuova fonte di duplicati: un’importazione di lista, un modulo web senza logica di dedup o un’integrazione che crea record senza verificare quelli esistenti.

Scenario 2: distribuzione del campo Industry sugli Account

Il problema

Il team dati ha costruito un modello di segmentazione degli Account che raggruppa i clienti per Industry. Il modello utilizza 24 valori di picklist di settore per creare segmenti mirati. Ma i segmenti sono disomogenei: due segmenti contengono il 70% di tutti gli Account, mentre i restanti 22 segmenti si dividono l’altro 30%. Il team di data science sospetta che il campo Industry abbia un problema di distribuzione, non un problema del modello. E necessario confermare se la distribuzione dei valori del campo e realmente distorta e identificare i valori dominanti.

Configurazione

Utilizzare la modalita Advanced Uniqueness Analysis sull’oggetto Account, selezionando il campo Industry. Servono le metriche di distribuzione (Entropy, Max Frequency, Rarity) per rispondere alle domande su come sono distribuiti i valori.

Include Blanks OFF e la scelta corretta per questo scenario. Si sta analizzando come i dati esistenti sono distribuiti tra le categorie. Aggiungere i blank nel calcolo distorcerebbe le metriche di distribuzione senza rispondere alla domanda sulla segmentazione. Se si desidera sapere quanti Account non hanno un valore Industry, eseguire un’analisi di completezza.

Risultati di esempio

Metriche di base:

Metriche avanzate:

Totale record Account valutati: 15.000.

Lettura dei risultati

Uniqueness Rate (0,16%) e atteso e irrilevante in questo caso. Industry e una picklist con 24 valori su 15.000 record. Quasi ogni valore e condiviso da centinaia di record. Un basso Uniqueness Rate su un campo picklist e normale. Questa metrica non e il fulcro di questa analisi.

Distinct Count (24) conferma che la picklist e intatta. Tutti i 24 valori configurati sono presenti nei dati. Non esistono voci di testo libero irregolari. I dati sono puliti dal punto di vista della coerenza.

Entropy (2,18) rivela la distorsione. L’entropia massima per 24 valori distinti e log2(24) = 4,58. L’entropia effettiva e 2,18. Il punteggio normalizzato e 2,18 / 4,58 = 0,48. Questo valore si colloca ben al di sotto della soglia di 0,7 per le distribuzioni «dominate». Pochi valori detengono la maggior parte dei record. Il sospetto del team di data science e confermato: il problema di segmentazione e nei dati, non nel modello.

Come interpretare l’entropia normalizzata:

Il punteggio di 0,48 rientra nell’intervallo «dominata».

Max Frequency (5.200) identifica il valore dominante. Un valore di settore appare su 5.200 dei 15.000 record, ovvero il 34,7% del dataset. Una rapida verifica rivela che si tratta di «Technology». Il secondo valore piu comune e probabilmente responsabile della maggior parte della concentrazione rimanente. Insieme, due valori rappresentano il 70% di concentrazione osservato dal team.

Rarity (0%) conferma che non c’e una coda lunga. Ognuno dei 24 valori distinti appare piu di una volta. Non esistono valori singleton. Questo e atteso per un campo picklist ben controllato. Su un campo a testo libero, si vorrebbe vedere la Rarity per intercettare refusi e voci occasionali, ma su una picklist, lo 0% di Rarity e normale.

Il verdetto sulla segmentazione: il modello a 24 categorie e in realta un sistema a 2 categorie. «Technology» e un altro settore dominano il dataset. Le restanti 22 categorie condividono il 30% dei record, con una media di circa 200 record per categoria. Alcuni segmenti sono troppo piccoli per un’analisi significativa.

Cosa fare dopo

Presentare Entropy e Max Frequency al team di data science. I numeri confermano il problema di distribuzione. Due opzioni: (1) Riprogettare il modello di segmentazione per utilizzare meno categorie, piu ampie, che riflettano la distribuzione effettiva. Raggruppare i 22 settori piu piccoli in 4-5 macro-categorie. (2) Arricchire i dati Industry. Se la concentrazione in «Technology» e gonfiata perche i commerciali lo selezionano come default durante la creazione dei record, indagare se una parte consistente di quei 5.200 record appartiene a un settore diverso. Eseguire una scansione periodica e monitorare l’Entropy nel tempo. Man mano che si correggono i record classificati erroneamente, l’Entropy sale verso una distribuzione piu sana.

Scenario 3: rilevamento boilerplate nelle descrizioni dei Case per la preparazione all’IA

Il problema

L’azienda sta valutando uno strumento di riassunto dei Case basato sull’IA per il team di supporto. Lo strumento IA legge il campo Description dei Case e genera un riassunto per il prossimo agente che prende in carico il Case. Prima di investire, e necessario valutare se le descrizioni dei Case contengono abbastanza contenuto originale affinche l’IA produca riassunti utili. Il campo e popolato nel 95% dei Case, quindi la completezza non e la preoccupazione. La preoccupazione e che gli agenti di supporto copino e incollino modelli standard in ogni Case.

Configurazione

Utilizzare la modalita Advanced Uniqueness Analysis sull’oggetto Case, selezionando il campo Description. Servono le metriche boilerplate per valutare l’originalita del contenuto.

Include Blanks OFF ha senso in questo caso perche si sta valutando il contenuto che esiste, non contando il contenuto che manca. Il 5% dei Case con descrizioni vuote e gia gestito dall’analisi di completezza.

Risultati di esempio

Metriche di base:

Metriche avanzate:

Totale record Case valutati: 30.000.

Lettura dei risultati

Uniqueness Rate (97%) sembra sano, ma e fuorviante. Quasi ogni descrizione di Case e tecnicamente diversa perche contiene numeri di Case, nomi di clienti e date univoci. Il campo supera un controllo base di duplicazione. Ma «unico» non significa «originale».

Boilerplate Rate (42%) racconta la vera storia. Il 42% del contenuto testuale nelle descrizioni dei Case e ripetitivo o basato su modelli. Gli agenti incollano introduzioni standard («Thank you for contacting support. Your case number is…»), chiusure standard («Please do not hesitate to reach out if you have further questions.») e checklist diagnostiche standard in ogni Case. I dettagli specifici del Case riempiono la parte centrale, ma quasi la meta di ogni descrizione e contenuto copiato e incollato.

Boilerplate Percentage (68%) mostra quanto e diffuso il problema. Il 68% dei record Case contiene testo basato su modelli. Ovvero 20.400 su 30.000 Case. Il boilerplate non e limitato a pochi agenti o a un team. E un pattern sistemico incorporato nel processo di supporto.

Boilerplate Records Count (20.400) e il numero di riferimento per il dimensionamento. Se e necessario stimare l’impegno per ripulire i modelli prima di alimentare i dati nell’IA, questo e il punto di partenza. 20.400 record contengono contenuto che l’IA apprendera come pattern, ma quei pattern sono i modelli, non i problemi dei clienti.

Il verdetto sulla preparazione all’IA: lo strumento di riassunto IA elaborera contenuto basato su modelli nel 68% dei Case. Imparera a riassumere i modelli, non i problemi dei clienti. Sul 32% dei Case con contenuto originale, l’IA funzionera bene. Sul 68% con boilerplate, i riassunti riecheggieranno le frasi standard che gli agenti conoscono gia a memoria.

Entropy (14,8) e alto, confermando che il testo e diversificato a livello di caratteri. Cio e coerente con il 97% di Uniqueness Rate: ogni descrizione e diversa. L’Entropy non e la metrica rilevante in questo caso perche il problema di duplicazione non riguarda valori identici. Il problema sono i pattern di contenuto ripetuti all’interno di testi altrimenti unici. E esattamente cio che le metriche boilerplate sono progettate per intercettare.

Cosa fare dopo

Presentare Boilerplate Rate (42%) e Boilerplate Percentage (68%) agli stakeholder del progetto IA. I numeri parlano chiaro: il progetto IA necessita di una fase di miglioramento della qualita del contenuto prima del deployment. Tre approcci per ridurre il boilerplate:

• Rimuovere i modelli. Se gli agenti incollano introduzioni e chiusure standard, integrare questi elementi nel layout del Case o in uno screen Flow cosi che non inquinino il campo descrizione. La descrizione cattura cosi solo le informazioni specifiche del Case.
• Formare gli agenti sulla scrittura di descrizioni efficaci. Condividere esempi di descrizioni di alta qualita (dal 32% che sono originali) e spiegare perche le voci prive di modelli producono riassunti IA migliori.
• Rimuovere il boilerplate dai dati storici. Prima di alimentare i Case esistenti nell’IA, eseguire un job di elaborazione del testo che rimuova i pattern di modello noti dal campo descrizione.

Eseguire nuovamente la scansione dopo ogni ciclo di miglioramento. Monitorare Boilerplate Rate e Boilerplate Percentage come metriche primarie di preparazione all’IA per questo campo. L’obiettivo: Boilerplate Percentage sotto il 30% e Boilerplate Rate sotto il 20% prima del deployment dello strumento di riassunto IA.

Scelta della configurazione

Utilizzare questa tabella per scegliere il punto di partenza corretto per l’analisi di unicita.

Per un riferimento completo di tutte le 8 metriche di unicita, i tre livelli diagnostici e i dettagli di configurazione, tornare all’articolo principale sull’Unicita.

Pronti a misurare la qualita dei propri dati? Effettuare la Valutazione di preparazione all’IA per vedere i punteggi di unicita e altro ancora.