# Unicidade: cenários de configuração > Três walkthroughs práticos mostrando como configurar a análise de unicidade do DQS para diferentes necessidades de negócio. Source: https://dataqualitysense.com/pt/resources/use-cases/uniqueness-scenarios/ Last updated: 2026-04-16 --- ## 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](/pt/resources/data-quality/uniqueness/). 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](/pt/resources/use-cases/completeness-scenarios/). ### 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](/pt/resources/data-quality/uniqueness/). Pronto para medir sua qualidade de dados? Faça a [AI Readiness Assessment](/pt/ai-readiness/) para ver suas pontuações de unicidade e muito mais.