O que estes cenários cobrem
Esta página apresenta três configurações reais da análise de unicidade do DQS. Cada cenário cobre um problema específico, mostra as configurações exatas e explica como ler os resultados.
Estes walkthroughs se apoiam nos conceitos do artigo principal de Unicidade. Leia primeiro se você é novo nas métricas de unicidade, nas camadas diagnósticas ou na diferença entre Basic Uniqueness e Advanced Uniqueness Analysis.
Cenário 1: auditoria de deduplicação de e-mail em Leads
O problema
Seu time de marketing roda campanhas de nurture via Salesforce. As taxas de abertura estão caindo e a plataforma de e-mail reporta um número crescente de “envios duplicados”: a mesma pessoa recebendo o mesmo e-mail duas vezes. Suas regras de gestão de duplicatas pegam correspondências exatas, mas duplicatas parciais escapam. Dois registros de Lead para a mesma pessoa com o mesmo e-mail recebem a campanha. Você precisa de um número concreto: quantos endereços de e-mail de Lead são compartilhados entre vários registros?
Configuração
É uma checagem direta de detecção de duplicatas. Use Basic Uniqueness no objeto Lead, no campo Email.
| Configuração | Valor | Por quê |
|---|---|---|
| Modo de análise | Basic Uniqueness | Você precisa da taxa de duplicação e do distinct count, não de distribuição ou boilerplate |
| Case Sensitive | OFF | E-mails são case-insensitive. “John@Company.com” e “john@company.com” são o mesmo. |
| Include Blanks | ON | Um e-mail em branco é um problema que vale quantificar. Incluir blanks faz todos os registros vazios compartilharem um valor “blank”, derrubando a Uniqueness Rate e tornando a lacuna visível. |
Case Sensitive OFF é o padrão e a escolha correta para e-mail. Se dois registros têm “jsmith@acme.com” e “JSmith@Acme.com”, é o mesmo endereço. Habilitar case sensitivity contaria como distintos e esconderia a duplicata.
Resultados de exemplo
Métricas de base:
| Métrica | Valor |
|---|---|
| Uniqueness Rate | 74% |
| Distinct Count | 18.500 |
Total de Leads avaliados: 25.000.
Lendo os resultados
Comece pela headline: 74% de unicidade. Isso significa que 26% dos endereços aparecem em mais de um Lead. Dos 25.000 Leads, só existem 18.500 endereços distintos. A diferença de 6.500 registros são e-mails compartilhados.
Como se parecem 26% de e-mails duplicados na prática. Alguns são legítimos: endereços de departamento como info@company.com ou sales@company.com compartilhados entre múltiplos contatos da mesma empresa. A maioria são Leads duplicados criados por fontes diferentes. Um web form cria um, uma importação cria outro, um rep cria um terceiro a partir de um cartão de visita. Todos com o mesmo e-mail.
Include Blanks ON revela o quadro completo. Com Include Blanks habilitado, Leads sem e-mail compartilham um único valor “blank”. Se 2.000 dos 25.000 não têm e-mail, esses 2.000 contam como duplicatas entre si. Isso derruba a Uniqueness Rate em relação a excluir blanks, mas dá o número honesto. Sua campanha alcança no máximo 18.500 endereços, não 25.000.
Por que Basic Uniqueness basta aqui. A pergunta é “quantos e-mails estão duplicados?”. Uniqueness Rate e Distinct Count respondem. Você não precisa de Entropy ou Rarity para decidir lançar um projeto de deduplicação. Se depois quiser entender o padrão de distribuição (quantos aparecem duas vezes vs dez), mude para Advanced.
O que fazer depois
Use Distinct Count (18.500) como sua audiência real endereçável. Dimensione um projeto de deduplicação para registros com e-mails compartilhados. Comece exportando Leads agrupados por endereço, depois faça merge ou delete. Após a limpeza, re-execute o scan e acompanhe a Uniqueness Rate. Se cair entre scans, surgiu uma nova fonte de duplicata: import, web form sem dedup ou integração criando registros sem checar existentes.
Cenário 2: distribuição do campo Industry em Accounts
O problema
Seu time de dados construiu um modelo de segmentação de Account que agrupa clientes por Industry. O modelo usa 24 valores de picklist para criar segmentos direcionados. Mas os segmentos são desiguais: dois contêm 70% das Accounts, enquanto os outros 22 dividem os 30% restantes. O time de data science suspeita que Industry tem problema de distribuição, não problema de modelo. Você precisa confirmar se a distribuição está genuinamente enviesada e identificar os valores dominantes.
Configuração
Use Advanced Uniqueness Analysis no Account, no campo Industry. Você precisa de métricas de distribuição (Entropy, Max Frequency, Rarity).
| Configuração | Valor | Por quê |
|---|---|---|
| Modo de análise | Advanced Uniqueness Analysis | Você precisa de Entropy, Max Frequency e Rarity |
| Case Sensitive | OFF | Valores de picklist são controlados. Case sensitivity não é relevante aqui. |
| Include Blanks | OFF | Valores de Industry em branco são problema de completude, não de unicidade. Exclua para focar na distribuição dos valores populados. |
Include Blanks OFF é o certo. Você está analisando como os dados existentes se distribuem entre categorias. Adicionar blanks distorceria as métricas sem responder sua pergunta. Se quiser saber quantas Accounts não têm Industry, rode uma análise de completude.
Resultados de exemplo
Métricas de base:
| Métrica | Valor |
|---|---|
| Uniqueness Rate | 0,16% |
| Distinct Count | 24 |
Métricas avançadas:
| Métrica | Valor |
|---|---|
| Entropy | 2,18 |
| Max Frequency | 5.200 |
| Rarity | 0% |
Total de Accounts avaliados: 15.000.
Lendo os resultados
Uniqueness Rate (0,16%) é esperado e irrelevante aqui. Industry é uma picklist com 24 valores em 15.000 registros. Quase todo valor é compartilhado por centenas de registros. Uma Uniqueness Rate baixa em picklist é normal.
Distinct Count (24) confirma que sua picklist está intacta. Todos os 24 valores aparecem. Sem entradas rogue de texto livre. Limpo do ponto de vista de consistência.
Entropy (2,18) revela o desvio. A entropia máxima para 24 valores distintos é log2(24) = 4,58. Sua entropia real é 2,18. O score normalizado é 2,18 / 4,58 = 0,48. Isso fica bem abaixo do limite de 0,7 para distribuições “dominadas”. Poucos valores concentram a maior parte dos registros. A suspeita do time de data science está confirmada: o problema de segmentação está nos dados, não no modelo.
Como interpretar entropia normalizada:
| Normalizada (real / máxima) | Interpretação |
|---|---|
| 0,9 ou acima | Distribuição uniforme |
| 0,7 a 0,9 | Desvio moderado |
| Abaixo de 0,7 | Dominado: poucos valores concentram o resto |
Seu score de 0,48 está na faixa “dominado”.
Max Frequency (5.200) identifica o valor dominante. Um valor aparece em 5.200 de 15.000 registros, ou 34,7% do dataset. Uma checagem rápida revela que é “Technology”. O segundo mais comum provavelmente é responsável pelo resto da concentração. Juntos, dois valores respondem pelos 70% observados pelo time.
Rarity (0%) confirma que não há cauda longa. Cada um dos 24 valores aparece mais de uma vez. Nenhum singleton. Esperado para uma picklist bem controlada. Em texto livre, você usaria Rarity para pegar erros de digitação.
O veredito de segmentação: Seu modelo de 24 categorias é, na prática, um sistema de 2. “Technology” e outro dominam. Os 22 restantes dividem 30%, dando em média ~200 registros por categoria. Alguns segmentos são pequenos demais para análise significativa.
O que fazer depois
Apresente Entropy e Max Frequency ao time de data science. Os números confirmam o problema. Duas opções: (1) Redesenhe o modelo usando categorias mais amplas que reflitam a distribuição real. Agrupe as 22 menores em 4-5 macro-categorias. (2) Enriqueça os dados de Industry. Se a concentração em “Technology” está inflada porque os reps usam como default, investigue se parte dos 5.200 pertence a outra indústria. Rode um scan periódico e acompanhe Entropy. Conforme corrige classificações, Entropy sobe.
Cenário 3: detecção de boilerplate em Case Description para prontidão para IA
O problema
Sua empresa está avaliando sumarização com IA para o time de suporte. A ferramenta lê o campo Description em Cases e gera um resumo para o próximo agente. Antes de investir, você precisa avaliar se as descrições contêm conteúdo original suficiente. O campo está populado em 95% dos cases, então completude não é a preocupação. A preocupação é que os agentes colam templates padrão em todo case.
Configuração
Use Advanced Uniqueness Analysis no objeto Case, no campo Description. Você precisa das métricas de boilerplate.
| Configuração | Valor | Por quê |
|---|---|---|
| Modo de análise | Advanced Uniqueness Analysis | Habilita detecção de boilerplate (Boilerplate Rate, Percentage, Records Count) |
| Case Sensitive | OFF | Detecção de template não depende de caixa |
| Include Blanks | OFF | Descrições vazias são problema de completude. Exclua para focar na qualidade do conteúdo. |
Include Blanks OFF faz sentido aqui porque você está avaliando o conteúdo existente, não contando o que está faltando. Os 5% vazios já são tratados pela completude.
Resultados de exemplo
Métricas de base:
| Métrica | Valor |
|---|---|
| Uniqueness Rate | 97% |
| Distinct Count | 29.100 |
Métricas avançadas:
| Métrica | Valor |
|---|---|
| Entropy | 14,8 |
| Boilerplate Rate | 42% |
| Boilerplate Percentage | 68% |
| Boilerplate Records Count | 20.400 |
Total de Cases avaliados: 30.000.
Lendo os resultados
Uniqueness Rate (97%) parece saudável, mas engana. Quase toda descrição é tecnicamente diferente porque cada uma contém números de caso, nomes e datas únicos. O campo passa em uma checagem básica. Mas “único” não é “original”.
Boilerplate Rate (42%) conta a verdade. 42% do conteúdo textual das descrições é repetitivo ou templated. Agentes colam aberturas padrão (“Obrigado por contatar o suporte. Seu número de caso é…”), fechamentos padrão (“Não hesite em procurar se tiver outras dúvidas.”) e checklists padrão em cada case. Os detalhes do caso preenchem o meio, mas quase metade de cada descrição é copy-paste.
Boilerplate Percentage (68%) mostra a amplitude. 68% dos cases contêm texto templated. São 20.400 de 30.000. O boilerplate não está restrito a alguns agentes ou um time. É padrão sistêmico no processo de suporte.
Boilerplate Records Count (20.400) é seu escopo. Se precisa estimar o esforço para limpar templates antes de alimentar a IA, esse é o ponto de partida.
O veredito de prontidão para IA: A ferramenta vai processar conteúdo templated em 68% dos cases. Vai aprender a resumir seus templates, não seus problemas de cliente. Nos 32% com conteúdo original, a IA vai performar bem. Nos 68% com boilerplate, os resumos vão ecoar as frases padrão que os agentes já sabem de cor.
Entropy (14,8) é alta, confirmando que o texto é diverso no nível de caractere. Alinha com a Uniqueness Rate de 97%: cada descrição é diferente. Entropy não é a métrica relevante aqui porque o problema de duplicação não são valores idênticos — é conteúdo repetido dentro de texto de resto único. Exatamente o que as métricas de boilerplate foram feitas para pegar.
O que fazer depois
Apresente Boilerplate Rate (42%) e Boilerplate Percentage (68%) aos stakeholders do projeto de IA. Os números fazem o argumento: o projeto precisa de uma fase de melhoria de conteúdo antes do deployment. Três abordagens para reduzir boilerplate:
- Remova os templates. Se os agentes colam aberturas e fechamentos padrão, coloque esses elementos no page layout ou em um screen flow. A descrição então captura só o específico do caso.
- Treine agentes em descrições eficazes. Compartilhe exemplos de alta qualidade (dos 32% originais) e explique por que entradas sem template produzem resumos melhores de IA.
- Remova boilerplate dos dados históricos. Antes de alimentar os cases existentes à IA, rode um job de text processing que remova padrões conhecidos.
Rode o scan após cada ciclo. Acompanhe Boilerplate Rate e Percentage como métricas principais de prontidão para IA. Meta: Boilerplate Percentage abaixo de 30% e Rate abaixo de 20% antes do deployment.
Escolhendo sua configuração
Use esta tabela para escolher um ponto de partida.
| Se você precisa… | Comece com | Configurações-chave |
|---|---|---|
| Auditar valores duplicados em um campo identificador (Email, Phone, Account Name) | Basic Uniqueness | Case Sensitive: OFF, Include Blanks: ON |
| Dimensionar um projeto de dedup com contagem concreta | Basic Uniqueness | Use Distinct Count para calcular a lacuna entre total e únicos |
| Analisar distribuição em um campo de picklist ou categórico | Advanced Uniqueness Analysis | Revise Entropy (normalizada), Max Frequency e Rarity |
| Detectar conteúdo templated em campos de texto antes de IA | Advanced Uniqueness Analysis | Revise Boilerplate Rate, Percentage e Records Count |
| Saber se uma pontuação “saudável” esconde problemas | Advanced Uniqueness Analysis | Combine Uniqueness Rate com Entropy (distribuição) ou Boilerplate Rate (originalidade) |
Para referência completa das 8 métricas, das três camadas diagnósticas e detalhes de configuração, volte ao artigo principal de Unicidade.
Pronto para medir sua qualidade de dados? Faça a AI Readiness Assessment para ver suas pontuações de unicidade e muito mais.