Validita: scenari di configurazione

Cosa coprono questi scenari

Questa pagina illustra tre configurazioni reali dell’analisi di validita 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 sulla Validita. Si consiglia di leggerlo prima se non si ha familiarita con le metriche di validita, il flusso diagnostico o la configurazione dei pattern.

Scenario 1: validazione dell’email secondaria su un campo di testo personalizzato

Il problema

L’organizzazione memorizza un indirizzo email secondario in un campo di testo personalizzato Secondary_Email__c sull’oggetto Contact. A differenza del campo Email standard di Salesforce, un campo di testo non ha una validazione di formato integrata. Gli utenti incollano, digitano e importano qualsiasi cosa al suo interno. Il marketing desidera utilizzare questi indirizzi secondari per una campagna di re-engagement, ma nessuno sa quanti siano strutturalmente validi. Serve un numero concreto affinche il marketing possa impostare proiezioni realistiche per la campagna e il team operations possa dimensionare il cleanup.

Perche non il campo Email standard? Il tipo di campo Email nativo di Salesforce valida il formato al momento dell’inserimento. I valori in un campo Email standard superano gia i controlli di formato base. La validazione email di DQS e utile sui campi Text personalizzati che memorizzano indirizzi email senza l’applicazione integrata di Salesforce.

Configurazione

Utilizzare la modalita Format Validation sull’oggetto Contact, selezionando il campo Secondary_Email__c. Servono il tasso di validita principale e un conteggio dei record utilizzabili. Il rilevamento dei segnaposto e l’analisi del rumore non sono rilevanti in questo caso perche gli indirizzi email corrispondono al formato oppure no.

Il pattern Email e un preset integrato. Non e necessario scrivere alcun regex. Selezionare «Email» dal selettore dei pattern e il regex viene applicato automaticamente.

Risultati di esempio

Totale record Contact valutati: 50.000.

Lettura dei risultati

Si parta dal dato principale: 71% di validita. Cio significa che il 29% degli indirizzi email secondari non supera il controllo di formato. Su 50.000 Contact con un Secondary_Email__c popolato, solo 35.500 hanno un indirizzo strutturalmente valido.

Come si presenta il 29% di invalidi nella pratica: si tratta di valori senza il simbolo «@» (john.company.com), senza estensione di dominio (john@company), con doppi punti (john@company..com) o con spazi (john @company.com). Poiche si tratta di un campo di testo, Salesforce li ha tutti accettati al momento dell’inserimento. Ogni campagna inviata a questi indirizzi genera un bounce.

Il calcolo della campagna cambia. Il marketing stava proiettando la portata del re-engagement sulla base di 50.000 indirizzi secondari. L’audience realmente raggiungibile e 35.500. I tassi di apertura, i tassi di clic e le proiezioni di conversione devono essere tutti ricalcolati sulla base valida, non sul totale gonfiato.

Perche Format Validation e sufficiente in questo caso. Non serve la modalita Advanced per questo scenario. La domanda e semplice: «Quante email secondarie corrispondono a un formato valido?» Validity Rate e Valid Count rispondono a questa domanda. Se in seguito si necessita di dimensionare un progetto di cleanup con conteggi esatti degli invalidi, passare ad Advanced Format Validation per la suddivisione completa.

Cosa fare dopo

Utilizzare il Valid Count (35.500) come audience realmente raggiungibile per la pianificazione delle campagne. Dimensionare un progetto di cleanup per i restanti 14.500 record: esportarli, identificare gli errori di formato piu comuni e correggerli tramite arricchimento dati o correzione manuale. Considerare l’aggiunta di una Validation Rule in Salesforce su Secondary_Email__c per imporre il formato email sulle future voci, oppure convertire il campo nel tipo Email se i processi lo consentono.

Scenario 2: validazione del codice prodotto a lunghezza fissa

Il problema

L’azienda utilizza codici prodotto a 8 caratteri in un campo personalizzato Product_Code__c sull’oggetto Opportunity Product. Questi codici guidano le ricerche nell’inventario, le regole di pricing e l’integrazione ERP. La sincronizzazione ERP fallisce su circa il 5% dei record ogni settimana, e il team di integrazione sospetta codici prodotto malformati. E necessario confermare quanti codici non superano il controllo di formato e ottenere l’ambito esatto del cleanup.

Configurazione

Utilizzare la modalita Advanced Format Validation sull’oggetto Opportunity Product, selezionando il campo Product_Code__c. Serve la suddivisione completa validi/invalidi affinche il team di integrazione abbia conteggi esatti dei record per il progetto di remediation.

Il pattern Fixed Length genera automaticamente il regex ^.{8}$. Qualsiasi valore che non sia esattamente di 8 caratteri non supera la validazione.

Risultati di esempio

Metriche di base:

Metriche avanzate:

Totale record valutati: 10.000.

Lettura dei risultati

Il 5,8% di invalidi conferma la stima del team di integrazione. 580 codici prodotto su 10.000 non corrispondono al formato a 8 caratteri. Questi sono i record che bloccano la sincronizzazione ERP.

Invalid Count (580) e l’ambito del cleanup. Il team di integrazione dispone ora di un numero concreto. Invece di investigare ogni fallimento di sincronizzazione singolarmente, possono estrarre i 580 record, categorizzare gli errori di formato e correggerli in blocco. I problemi comuni nei campi codice prodotto includono codici troncati (5-7 caratteri da errori di copia-incolla), codici con spazi finali (9 caratteri a causa di uno spazio invisibile) e codici con trattini o prefissi aggiunti dagli utenti («PC-12345678»).

Noise Rate (0,4%) e basso ma merita attenzione. 40 record contengono pattern di rumore: caratteri ripetuti («XXXXXXXX»), inserimenti da tastiera («asdfghjk») o stringhe di caratteri speciali. Questi 40 record non sono errori di formato. Sono voci spazzatura che sono esattamente di 8 caratteri. Il Validity Rate li ha contati come validi perche superano il controllo di lunghezza, ma sono dati spazzatura che faranno fallire la ricerca ERP per un motivo diverso. Il Noise Rate intercetta cio che il controllo di formato non rileva.

Include Blanks ON e importante in questo caso. Con Include Blanks abilitato, qualsiasi record dove Product_Code__c e vuoto conta come invalido. Se si fosse lasciata questa impostazione disattivata, quei record vuoti sarebbero stati esclusi dalla valutazione interamente, e l’Invalid Count sarebbe stato inferiore al numero reale di record che falliscono la sincronizzazione ERP. Poiche un codice prodotto vuoto blocca l’integrazione allo stesso modo di uno malformato, includere i blank fornisce l’ambito accurato del fallimento.

Cosa fare dopo

Esportare i 580 record invalidi per il team di integrazione. Categorizzare gli errori per tipo: codici troncati, caratteri in eccesso, spazi finali. Correggerli in blocco tramite un job di aggiornamento dati. Per i 40 record con rumore, indagare la fonte. Se provengono da un’importazione specifica o da un utente, affrontare la causa radice. Dopo il cleanup, aggiungere una Validation Rule in Salesforce che imponga la lunghezza di 8 caratteri su Product_Code__c per prevenire nuove voci errate. Eseguire nuovamente la scansione per verificare il nuovo Validity Rate.

Scenario 3: rilevamento del rumore nei nomi aziendali del Web-to-Lead

Il problema

Il modulo web-to-lead richiede il campo Company. Il volume dei Lead e elevato: 20.000 nuovi Lead per trimestre. Ma il team SDR segnala che molti Lead hanno nomi aziendali spazzatura, voci come «asdf», «test», «xxx» o «na na na». Questi Lead sprecano il tempo degli SDR e inquinano la segmentazione. Un controllo base di completezza mostra che il 98% dei Lead ha un valore Company. Si sospetta che il 98% sia fuorviante perche le voci spazzatura sono tecnicamente «popolate».

Configurazione

Utilizzare la modalita Advanced Format Validation sull’oggetto Lead, selezionando il campo Company. Serve il Noise Rate per quantificare la spazzatura che si nasconde dietro un punteggio di completezza sano.

Per il pattern di formato, non esiste una regola di formato rigida per i nomi aziendali. I nomi aziendali sono testo libero. Utilizzare una validazione testuale minima per verificare che il valore contenga almeno un carattere alfanumerico.

Il valore reale di questa scansione risiede nelle metriche di rumore, non nella validazione del formato. Il pattern personalizzato e intenzionalmente permissivo perche non si sta imponendo un formato specifico per i nomi aziendali. Si sta eseguendo la scansione in modalita Advanced per accedere a Noise Rate e Noisy Records Count.

Risultati di esempio

Metriche di base:

Metriche avanzate:

Totale record Lead valutati: 20.000.

Lettura dei risultati

Il 97,5% di validita e atteso e non e il punto. Quasi ogni valore supera il controllo di formato permissivo perche il pattern richiede solo un carattere alfanumerico. I 500 record invalidi sono voci con soli caratteri speciali o spazi, valori come «---», «…» o «!!!». Questi sono facili da identificare e eliminare.

Noise Rate (12%) e la vera scoperta. 2.400 Lead hanno nomi aziendali che contengono pattern di rumore. Si tratta di voci con caratteri ripetuti («aaaa», «xxxxx»), caratteri speciali consecutivi («!@#$%») o caratteri di controllo. Superano il controllo di formato perche contengono caratteri alfanumerici, ma i valori sono spazzatura.

Il quadro reale della qualita dei dati:

Il team SDR ha ragione: il problema di qualita dei Lead e reale. 2.900 su 20.000 Lead (14,5%) hanno dati aziendali inutilizzabili. Questo rappresenta il 14,5% del tempo degli SDR sprecato su Lead che non possono mai essere correttamente instradati, arricchiti o segmentati.

Il divario tra completezza e validita. La completezza dice che il 98% dei Lead ha un valore Company. La validita dice che il 97,5% supera il controllo di formato. Il Noise Rate dice che il 12% di quei valori che superano il controllo sono spazzatura. Ogni dimensione rivela un livello diverso del problema. La completezza da sola non rileva la spazzatura che il Noise Rate intercetta.

Cosa fare dopo

Costruire una coda di cleanup per i 2.900 record combinati invalidi e rumorosi. Per i 500 record puramente invalidi, eliminarli automaticamente o metterli in quarantena. Per i 2.400 record rumorosi, decidere: eliminare automaticamente i Lead senza altri dati utili, oppure contrassegnarli per la revisione manuale se i dati di telefono o email sono ancora utilizzabili.

Correggere la fonte. La spazzatura proviene dal modulo web. Aggiungere validazione lato client: una lunghezza minima di caratteri, bloccare i pattern di caratteri ripetuti e considerare il CAPTCHA per la prevenzione dei bot. Dopo aver implementato le modifiche al modulo, eseguire nuovamente la scansione il trimestre successivo e confrontare il Noise Rate con questa baseline.

Scelta della configurazione

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

Per un riferimento completo di tutte le 6 metriche di validita, i tipi di pattern e i dettagli del rilevamento del rumore, tornare all’articolo principale sulla Validita.

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