Unicidad: escenarios de configuración

Lo que cubren estos escenarios

Esta página recorre tres configuraciones del mundo real del análisis de unicidad de DQS. Cada escenario cubre un problema de negocio concreto, muestra los ajustes exactos que utilizar y explica cómo leer los resultados.

Estos recorridos se apoyan en los conceptos del artículo principal de Unicidad. Léalo primero si es nuevo en las métricas de unicidad, las capas de diagnóstico o la diferencia entre Basic Uniqueness y Advanced Uniqueness Analysis.

Escenario 1: auditoría de deduplicación de correo en Leads

El problema

Su equipo de marketing ejecuta campañas de nutrición a través de Salesforce. Las tasas de apertura caen y la plataforma de correo informa de un número creciente de «envíos duplicados»: la misma persona recibe el mismo correo dos veces. Sus reglas de gestión de duplicados detectan los registros con coincidencia exacta, pero los duplicados parciales se escapan. Dos registros de Lead para la misma persona con la misma dirección de correo reciben ambos la campaña. Necesita una cifra concreta: ¿cuántas direcciones de correo de Lead se comparten entre varios registros?

Configuración

Esta es una comprobación directa de detección de duplicados. Utilice el modo Basic Uniqueness sobre el objeto Lead, dirigiéndose al campo Email.

Case Sensitive desactivado es el valor por defecto y la opción correcta para el correo. Si dos registros almacenan «jsmith@acme.com» y «JSmith@Acme.com», son la misma dirección. Activar la sensibilidad a mayúsculas los contaría como distintos y ocultaría el duplicado.

Resultados de ejemplo

Métricas base:

Total de registros de Lead evaluados: 25 000.

Leer los resultados

Empiece por la cifra principal: 74 % de unicidad. Eso significa que el 26 % de las direcciones de correo aparece en más de un registro de Lead. De 25 000 Leads, solo existen 18 500 direcciones de correo distintas. La diferencia de 6500 registros son direcciones de correo compartidas.

Qué aspecto tiene en la práctica un 26 % de correos duplicados. Algunos son legítimos: direcciones de departamento como info@empresa.com o sales@empresa.com compartidas entre varios contactos de la misma empresa. La mayoría son Leads duplicados creados por fuentes distintas. Un formulario web crea un Lead. Una importación de lista crea otro. Un representante de ventas crea un tercero desde una tarjeta de visita. Los tres tienen la misma dirección de correo.

Include Blanks activado revela la imagen completa. Con Include Blanks activado, los Leads sin dirección de correo comparten todos un único valor «blank». Si 2000 de los 25 000 Leads no tienen correo, esos 2000 registros cuentan como duplicados entre sí. Esto reduce la Uniqueness Rate frente a excluir los blancos, pero le da la cifra honesta. Su campaña puede llegar, como máximo, a 18 500 direcciones distintas, no a 25 000.

Por qué Basic Uniqueness es suficiente aquí. La pregunta es «¿cuántos correos están duplicados?». Uniqueness Rate y Distinct Count responden a esa pregunta. No necesita Entropy ni Rarity para decidir si lanzar un proyecto de deduplicación. Si más adelante quiere comprender el patrón de distribución (cuántos correos aparecen exactamente dos veces frente a diez), cambie a Advanced Uniqueness Analysis para la imagen completa.

Qué hacer a continuación

Utilice Distinct Count (18 500) como su audiencia direccionable real para las campañas de correo. Delimite un proyecto de deduplicación para los registros con correos compartidos. Empiece exportando los Leads agrupados por dirección de correo y fusione o elimine los duplicados. Tras la limpieza, vuelva a ejecutar el análisis y siga la Uniqueness Rate a lo largo del tiempo. Si cae entre análisis, ha aparecido una nueva fuente de duplicados: una importación de lista, un formulario web sin lógica de deduplicación o una integración que crea registros sin comprobar los existentes.

Escenario 2: distribución del campo Industry en Accounts

El problema

Su equipo de datos construyó un modelo de segmentación de Account que agrupa a los clientes por Industry. El modelo utiliza 24 valores de la lista desplegable de sector para crear segmentos dirigidos. Pero los segmentos son desiguales: dos segmentos contienen el 70 % de todos los Accounts, mientras que los 22 restantes se reparten el otro 30 %. El equipo de ciencia de datos sospecha que el campo Industry tiene un problema de distribución, no de modelo. Necesita confirmar si la distribución de valores del campo está realmente sesgada e identificar los valores dominantes.

Configuración

Utilice el modo Advanced Uniqueness Analysis sobre el objeto Account, dirigiéndose al campo Industry. Necesita métricas de distribución (Entropy, Max Frequency, Rarity) para responder a las preguntas sobre cómo se reparten los valores.

Include Blanks desactivado es la elección correcta para este escenario. Está analizando cómo se distribuyen los datos existentes entre categorías. Añadir los blancos al cálculo distorsionaría las métricas de distribución sin responder a su pregunta de segmentación. Si quiere saber cuántos Accounts no tienen valor de Industry, ejecute en su lugar un análisis de completitud.

Resultados de ejemplo

Métricas base:

Métricas avanzadas:

Total de registros de Account evaluados: 15 000.

Leer los resultados

Uniqueness Rate (0,16 %) es esperable e irrelevante aquí. Industry es una lista desplegable con 24 valores en 15 000 registros. Casi todos los valores son compartidos por cientos de registros. Una Uniqueness Rate baja en un campo de lista desplegable es normal. Esta métrica no es el objetivo de este análisis.

Distinct Count (24) confirma que su lista desplegable está intacta. Aparecen los 24 valores configurados. No hay entradas de texto libre fuera de la lista. Los datos están limpios desde el punto de vista de la consistencia.

Entropy (2,18) revela el sesgo. La entropía máxima para 24 valores distintos es log2(24) = 4,58. Su entropía real es 2,18. La puntuación normalizada es 2,18 / 4,58 = 0,48. Cae muy por debajo del umbral de 0,7 para distribuciones «dominadas». Unos pocos valores concentran la mayoría de los registros. La sospecha de su equipo de ciencia de datos queda confirmada: el problema de segmentación está en los datos, no en el modelo.

Cómo interpretar la entropía normalizada:

Su puntuación de 0,48 está en el rango «dominada».

Max Frequency (5200) identifica el valor dominante. Un valor de sector aparece en 5200 de 15 000 registros, o el 34,7 % del conjunto de datos. Una comprobación rápida revela que es «Technology». El segundo valor más habitual probablemente sea responsable de la mayor parte de la concentración restante. Juntos, dos valores explican la agrupación del 70 % que observó su equipo.

Rarity (0 %) confirma que no hay una larga cola. Cada uno de los 24 valores distintos aparece más de una vez. No existen valores singleton. Es lo esperable para un campo de lista desplegable bien controlado. En un campo de texto libre, querría ver Rarity para detectar erratas y entradas puntuales, pero en una lista desplegable, un 0 % de Rarity es normal.

El veredicto de la segmentación: su modelo de 24 categorías es, en realidad, un sistema de 2 categorías. «Technology» y otro sector dominan el conjunto de datos. Las 22 categorías restantes comparten el 30 % de los registros, con un promedio de unos 200 registros por categoría. Algunos segmentos son demasiado pequeños para un análisis significativo.

Qué hacer a continuación

Presente Entropy y Max Frequency a su equipo de ciencia de datos. Las cifras confirman el problema de distribución. Dos opciones: (1) rediseñar el modelo de segmentación para utilizar categorías más amplias y menos numerosas que reflejen la distribución real. Agrupe los 22 sectores más pequeños en 4 o 5 macrocategorías. (2) Enriquecer los datos de Industry. Si la concentración en «Technology» está inflada porque los representantes la marcan por defecto al crear el registro, investigue si una gran parte de esos 5200 registros pertenece a otro sector. Ejecute un análisis periódico y siga Entropy a lo largo del tiempo. A medida que corrija los registros mal clasificados, la entropía subirá hacia una distribución más saludable.

Escenario 3: detección de boilerplate en Case Description para la preparación para la IA

El problema

Su empresa está evaluando una capacidad de resumen de casos impulsada por IA para el equipo de soporte. La herramienta de IA lee el campo Description de los Cases y genera un resumen para el siguiente agente que retome el caso. Antes de invertir, necesita evaluar si las descripciones de sus casos contienen suficiente contenido original para que la IA produzca resúmenes útiles. El campo está cumplimentado en el 95 % de los casos, así que la completitud no es la preocupación. La preocupación es que los agentes de soporte copian y pegan plantillas estándar en cada caso.

Configuración

Utilice el modo Advanced Uniqueness Analysis sobre el objeto Case, dirigiéndose al campo Description. Necesita las métricas de boilerplate para evaluar la originalidad del contenido.

Include Blanks desactivado tiene sentido aquí porque está evaluando el contenido que existe, no contando el contenido que falta. El 5 % de los casos con descripciones vacías ya se gestiona en su análisis de completitud.

Resultados de ejemplo

Métricas base:

Métricas avanzadas:

Total de registros de Case evaluados: 30 000.

Leer los resultados

La Uniqueness Rate (97 %) parece saludable, pero es engañosa. Casi todas las descripciones de caso son técnicamente distintas porque cada una contiene números de caso, nombres de cliente y fechas únicos. El campo supera una comprobación básica de duplicación. Pero «único» no significa «original».

Boilerplate Rate (42 %) cuenta la historia real. El 42 % del contenido de texto en las descripciones de los casos es repetitivo o de plantilla. Los agentes pegan aperturas estándar («Gracias por contactar con soporte. Su número de caso es…»), cierres estándar («No dude en ponerse en contacto si tiene más preguntas») y listas de verificación de diagnóstico estándar en cada caso. Los detalles específicos del caso rellenan la parte central, pero casi la mitad de cada descripción es contenido copiado y pegado.

Boilerplate Percentage (68 %) muestra lo extendido que está el problema. El 68 % de los registros de caso contiene texto de plantilla. Son 20 400 de 30 000 casos. El boilerplate no se limita a unos pocos agentes ni a un equipo. Es un patrón sistémico incrustado en su proceso de soporte.

Boilerplate Records Count (20 400) es su cifra de alcance. Si necesita estimar el esfuerzo para limpiar las plantillas antes de alimentar la IA, este es el punto de partida. 20 400 registros contienen contenido que la IA aprenderá como patrones, pero esos patrones son sus plantillas, no los problemas de sus clientes.

El veredicto de preparación para la IA: la herramienta de resumen de IA procesará contenido de plantilla en el 68 % de los casos. Aprenderá a resumir sus plantillas, no los problemas de sus clientes. En el 32 % de los casos con contenido original, la IA rendirá bien. En el 68 % con boilerplate, los resúmenes devolverán las frases estándar que los agentes ya conocen de memoria.

La entropía (14,8) es alta, lo que confirma que el texto es diverso a nivel de carácter. Esto encaja con la Uniqueness Rate del 97 %: cada descripción es distinta. La entropía no es la métrica relevante aquí porque el problema de duplicación no son valores idénticos. El problema son los patrones de contenido repetidos dentro de un texto por lo demás único. Exactamente lo que las métricas de boilerplate están diseñadas para captar.

Qué hacer a continuación

Presente Boilerplate Rate (42 %) y Boilerplate Percentage (68 %) a los grupos de interés del proyecto de IA. Las cifras dejan claro el argumento: el proyecto de IA necesita una fase de mejora de calidad del contenido antes del despliegue. Tres enfoques para reducir el boilerplate:

• Elimine las plantillas. Si los agentes están pegando aperturas y cierres estándar, integre esos elementos en el page layout del caso o en un screen flow para que no contaminen el campo de descripción. La descripción captura entonces solo la información específica del caso.
• Forme a los agentes en descripciones eficaces. Comparta ejemplos de descripciones de alta calidad (del 32 % que es original) y explique por qué las entradas sin plantilla producen mejores resúmenes de IA.
• Retire el boilerplate de los datos históricos. Antes de alimentar los casos existentes a la IA, ejecute un trabajo de procesamiento de texto que elimine los patrones de plantilla conocidos del campo de descripción.

Vuelva a ejecutar el análisis tras cada ciclo de mejora. Siga Boilerplate Rate y Boilerplate Percentage como sus métricas principales de preparación para la IA para este campo. Su objetivo: Boilerplate Percentage por debajo del 30 % y Boilerplate Rate por debajo del 20 % antes de desplegar la herramienta de resumen de IA.

Elegir su configuración

Utilice esta tabla para elegir el punto de partida adecuado para su análisis de unicidad.

Para una referencia completa de las 8 métricas de unicidad, las tres capas de diagnóstico y los detalles de configuración, vuelva al artículo principal de Unicidad.

¿Listo para medir su propia calidad de datos? Realice la Evaluación de preparación para la IA para ver sus puntuaciones de unicidad y más.