Validade: cenários de configuração

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. 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.

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

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.

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étricas avançadas:

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.

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étricas avançadas:

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:

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.

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.

Pronto para medir sua qualidade de dados? Faça a AI Readiness Assessment para ver suas pontuações de validade e muito mais.