# Validade: cenários de configuração > Três walkthroughs práticos mostrando como configurar a análise de validade do DQS para diferentes necessidades de negócio. Source: https://dataqualitysense.com/pt/resources/use-cases/validity-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 validade 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 [Validade](/pt/resources/data-quality/validity/). Leia primeiro se você é novo nas métricas de validade, no fluxo diagnóstico ou na configuração de padrões. ## Cenário 1: validação de e-mail secundário em um campo custom de texto ### O problema Sua organização guarda um endereço de e-mail secundário em um campo `Secondary_Email__c` do objeto Contact. Diferente do campo Email padrão do Salesforce, um campo de texto não tem validação de formato. Usuários colam, digitam e importam qualquer coisa. O marketing quer usar esses endereços secundários em uma campanha de reengajamento, mas ninguém sabe quantos são estruturalmente válidos. Você precisa de um número concreto. > **Por que não o campo Email padrão?** O tipo Email nativo do Salesforce valida formato na entrada. Valores nesse tipo já passam em checagens básicas. A validação de e-mail do DQS é útil em campos de texto custom que guardam e-mails sem o enforcement nativo. ### Configuração Use **Format Validation** no Contact, no campo `Secondary_Email__c`. Você precisa da taxa de validade e da contagem de registros utilizáveis. Detecção de placeholder e análise de ruído não são relevantes aqui porque e-mails ou casam com o formato ou não. | Configuração | Valor | Por quê | |---------|-------|-----| | Modo de análise | Format Validation | Você precisa da taxa de match e do valid count, não do quadro completo de inválidos | | Pattern Type | Email | Padrão embutido: `^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$` | | Include Blanks | OFF | E-mails em branco são problema de completude, não de validade | | Case Sensitive | OFF | E-mails são case-insensitive por definição | O padrão Email é um preset embutido. Você não precisa escrever regex. Selecione "Email" no pattern picker e o regex é aplicado automaticamente. ### Resultados de exemplo | Métrica | Valor | |--------|-------| | Validity Rate | 71% | | Valid Count | 35.500 | Total de Contacts avaliados: 50.000. ### Lendo os resultados Comece pela headline: 71% de validade. Isso significa que 29% dos e-mails secundários falham na checagem de formato. De 50.000 Contacts com `Secondary_Email__c` populado, só 35.500 têm endereço estruturalmente válido. **Como se parecem os 29% inválidos na prática:** valores sem "@" (`john.company.com`), sem extensão de domínio (`john@company`), com pontos duplos (`john@company..com`) ou com espaços (`john @company.com`). Como é campo de texto, o Salesforce aceitou tudo na entrada. Toda campanha enviada para esses endereços retorna. **A matemática da campanha muda.** O marketing projetava alcance com base em 50.000 endereços. A audiência real endereçável é 35.500. Taxas de abertura, clique e conversão precisam ser recalculadas sobre a base válida. **Por que Format Validation basta aqui.** Você não precisa do modo Advanced. A pergunta é simples: "Quantos e-mails secundários casam com um formato válido?" Validity Rate e Valid Count respondem. Se depois precisar de contagens exatas de inválidos para um projeto de limpeza, mude para Advanced. ### O que fazer depois Use Valid Count (35.500) como a audiência real endereçável. Dimensione um projeto de limpeza para os 14.500 restantes: exporte, identifique os erros mais comuns e corrija via enriquecimento ou correção manual. Considere adicionar uma validation rule em `Secondary_Email__c` para exigir formato de e-mail em novas entradas, ou converta o campo para o tipo Email se os processos permitirem. --- ## Cenário 2: validação de código de produto com Fixed Length ### O problema Sua empresa usa códigos de produto de 8 caracteres em um campo `Product_Code__c` no Opportunity Product. Esses códigos alimentam lookups de inventário, regras de preço e integração com ERP. A sincronização com ERP vem falhando em cerca de 5% dos registros por semana, e o time de integração suspeita de códigos malformados. Você precisa confirmar quantos falham na checagem e obter o escopo exato de limpeza. ### Configuração Use **Advanced Format Validation** no Opportunity Product, no campo `Product_Code__c`. Você precisa do quadro completo valid/invalid para ter contagens exatas. | Configuração | Valor | Por quê | |---------|-------|-----| | Modo de análise | Advanced Format Validation | Você precisa de Invalid Count para dimensionar a limpeza e Noise Rate para checar lixo | | Pattern Type | Fixed Length | Códigos sempre têm exatamente 8 caracteres | | Fixed Length | 8 | Seu comprimento padrão | | Include Blanks | ON | Um código em branco é inválido para o ERP. Conte como falha. | | Case Sensitive | OFF | Códigos não dependem de caixa no seu sistema | O padrão Fixed Length gera o regex `^.{8}$` automaticamente. Qualquer valor que não tenha exatamente 8 caracteres falha. ### Resultados de exemplo **Métricas de base:** | Métrica | Valor | |--------|-------| | Validity Rate | 94,2% | | Valid Count | 9.420 | **Métricas avançadas:** | Métrica | Valor | |--------|-------| | Invalid Rate | 5,8% | | Invalid Count | 580 | | Noise Rate | 0,4% | | Noisy Records Count | 40 | Total de registros avaliados: 10.000. ### Lendo os resultados **5,8% de inválidos confirma a estimativa do time de integração.** 580 códigos de 10.000 não casam com o formato de 8 caracteres. São os registros quebrando a sync com o ERP. **Invalid Count (580) é o escopo de limpeza.** O time agora tem um número concreto. Em vez de investigar cada falha individualmente, podem puxar os 580 registros, categorizar os erros e corrigir em lote. Problemas comuns incluem códigos truncados (5-7 caracteres por copy-paste), códigos com espaços em branco ao final (9 caracteres por um espaço invisível) e códigos com hifens ou prefixos ("PC-12345678"). **Noise Rate (0,4%) é baixa, mas vale notar.** 40 registros contêm padrões de ruído: caracteres repetidos ("XXXXXXXX"), teclado ("asdfghjk") ou strings de caracteres especiais. Esses 40 não são erros de formato. São lixo que por acaso tem exatamente 8 caracteres. A Validity Rate contou como válidos porque passam na checagem de comprimento, mas são dados lixo que vão falhar no lookup do ERP por outra razão. Noise Rate pega o que a checagem de formato perde. **Include Blanks ON importa aqui.** Com Include Blanks habilitado, qualquer registro em que `Product_Code__c` está vazio conta como inválido. Se deixasse desativado, esses ficariam fora da avaliação, e o Invalid Count seria menor do que o real. Como um código em branco quebra a integração igual, incluir blanks dá o escopo correto. ### O que fazer depois Exporte os 580 inválidos para o time de integração. Categorize os erros: truncados, com caracteres extras, com espaços ao final. Corrija em massa com um data update. Para os 40 ruidosos, investigue a origem. Se vieram de um import ou usuário específico, trate a causa. Após a limpeza, adicione uma validation rule exigindo 8 caracteres em `Product_Code__c`. Re-execute para verificar sua nova Validity Rate. --- ## Cenário 3: detecção de ruído em Company Name de web-to-lead ### O problema Seu web-to-lead exige o campo `Company`. O volume é forte: 20.000 novos leads por trimestre. Mas o time de SDR reporta que muitos têm nomes de empresa lixo, como "asdf", "test", "xxx" ou "na na na". Esses leads desperdiçam tempo dos SDRs e poluem sua segmentação. Uma checagem básica de completude mostra que 98% dos leads têm valor em Company. Você suspeita que os 98% são enganosos porque entradas lixo estão "populadas" tecnicamente. ### Configuração Use **Advanced Format Validation** no Lead, no campo `Company`. Você precisa de Noise Rate para quantificar o lixo que se esconde atrás de uma pontuação saudável de completude. Não há regra estrita de formato para nomes de empresa. Use uma validação mínima de texto para checar que o valor contém pelo menos um caractere alfanumérico. | Configuração | Valor | Por quê | |---------|-------|-----| | Modo de análise | Advanced Format Validation | Você precisa de Noise Rate e Noisy Records Count | | Pattern Type | Custom | Nenhum padrão embutido serve para texto livre | | Custom Pattern | `^.*[a-zA-Z0-9].*$` | Casa com qualquer valor contendo pelo menos uma letra ou dígito. Pega valores puramente de caracteres especiais. | | Include Blanks | ON | Nomes em branco também são problema. Inclua na contagem de falhas. | | Case Sensitive | OFF | Não relevante para este padrão; deixe desligado | O valor real deste scan está nas métricas de ruído, não na validação de formato. O padrão custom é propositalmente solto porque você não está impondo formato específico. Roda em modo Advanced para ter acesso a Noise Rate e Noisy Records Count. ### Resultados de exemplo **Métricas de base:** | Métrica | Valor | |--------|-------| | Validity Rate | 97,5% | | Valid Count | 19.500 | **Métricas avançadas:** | Métrica | Valor | |--------|-------| | Invalid Rate | 2,5% | | Invalid Count | 500 | | Noise Rate | 12% | | Noisy Records Count | 2.400 | Total de Leads avaliados: 20.000. ### Lendo os resultados **97,5% de validade é esperado e não é o ponto.** Quase todo valor passa na checagem solta porque o padrão só exige um caractere alfanumérico. Os 500 inválidos são entradas só com caracteres especiais ou espaços, valores como "---", "..." ou "!!!". Esses são fáceis de identificar e deletar. **Noise Rate (12%) é o achado real.** 2.400 leads têm nomes de empresa contendo padrões de ruído. São entradas com caracteres repetidos ("aaaa", "xxxxx"), caracteres especiais consecutivos ("!@#$%") ou caracteres de controle. Passam na checagem de formato porque contêm alfanuméricos, mas os valores são lixo. **O quadro real de qualidade de dados:** | Categoria | Registros | O que significa | |----------|---------|---------------| | Limpo e válido | 17.100 | Nomes reais prontos para outreach | | Inválido (lixo puro) | 500 | Sem conteúdo alfanumérico. Delete ou quarentena. | | Ruidoso (lixo escondido) | 2.400 | Parece populado mas contém lixo. Revisão manual ou auto-flag. | Seu time de SDR está certo: o problema de qualidade é real. 2.900 de 20.000 leads (14,5%) têm dados inutilizáveis. São 14,5% do tempo do SDR desperdiçado em leads que nunca poderão ser roteados, enriquecidos ou segmentados corretamente. **A lacuna completude vs validade.** Completude diz que 98% dos leads têm valor em Company. Validade diz que 97,5% passam na checagem. Noise Rate diz que 12% desses valores "válidos" são lixo. Cada dimensão revela uma camada diferente do problema. Completude sozinha perde o lixo que Noise Rate pega. ### O que fazer depois Monte uma fila de limpeza para os 2.900 combinados. Para os 500 puramente inválidos, auto-delete ou quarentena. Para os 2.400 ruidosos, decida: auto-delete se não há outros dados úteis, ou flag para revisão manual se phone ou e-mail ainda servem. Conserte a origem. O lixo vem do seu web form. Adicione validação client-side: comprimento mínimo, bloqueio de padrões de caracteres repetidos e considere CAPTCHA para bots. Após implementar mudanças no form, rode o scan no próximo trimestre e compare a Noise Rate com esta baseline. --- ## Escolhendo sua configuração Use esta tabela para escolher um ponto de partida. | Se você precisa... | Comece com | Configurações-chave | |--------------------|------------|--------------| | Checar formato de e-mail em campos de texto custom | Format Validation | Pattern Type: Email, Include Blanks: OFF | | Validar códigos de comprimento fixo (product codes, SKUs, CEPs) | Advanced Format Validation | Pattern Type: Fixed Length, defina o comprimento, Include Blanks: ON | | Validar formato de URL em campos de website | Format Validation | Pattern Type: URL, Include Blanks: OFF | | Exigir um formato de negócio custom (regex) | Advanced Format Validation | Pattern Type: Custom, insira seu regex | | Detectar lixo e ruído em campos de texto livre | Advanced Format Validation | Padrão solto, foque em Noise Rate e Noisy Records Count | | Dimensionar limpeza para uma integração | Advanced Format Validation | Include Blanks: ON, use Invalid Count e Noisy Records Count | Para referência completa das 6 métricas, tipos de padrão e detalhes da detecção de ruído, volte ao artigo principal de [Validade](/pt/resources/data-quality/validity/). Pronto para medir sua qualidade de dados? Faça a [AI Readiness Assessment](/pt/ai-readiness/) para ver suas pontuações de validade e muito mais.