Validade

O que é validade?

Validade mede se os valores dos dados seguem formatos e padrões esperados. Um valor é válido quando corresponde à estrutura definida. É inválido quando quebra as regras de formato.

Um endereço de e-mail é válido quando contém ”@” e um domínio. Uma URL é válida quando começa com um protocolo e contém um domínio. Um código de produto é válido quando tem a contagem exata de caracteres que seu sistema exige.

O DQS valida os valores dos campos usando padrões regex (expressões regulares). Você escolhe entre padrões embutidos para formatos comuns como Email, URL e Fixed Length, ou escreve seu próprio regex para qualquer formato específico do negócio.

Validity Rate = (Registros que casam com o padrão / Total de registros) x 100

Se 35.500 de 50.000 registros de Contact têm endereço de e-mail que corresponde ao padrão, sua taxa de validade em Email é 71%. Os outros 29% contêm valores que falham na verificação do padrão.

Validade vs precisão

Validade e precisão são conceitos diferentes:

O DQS mede validade porque as verificações de formato podem ser automatizadas. Precisão exige verificação externa ou confirmação humana.

Dados válidos funcionam nos seus sistemas mesmo que não reflitam a realidade. Dados inválidos quebram seus sistemas independentemente da verdade no mundo real. Foque na validade primeiro. Resolva a precisão com processos de verificação.

Por que validade importa

Dados inválidos causam falhas em todo o seu stack. E-mails retornados prejudicam a reputação do remetente. Números de telefone malformados desperdiçam tempo de discador. URLs quebradas frustram usuários e bloqueiam ferramentas de enriquecimento.

APIs rejeitam dados malformados. Quando sua integração envia um formato inválido de e-mail para uma plataforma de marketing, o lote inteiro pode falhar. Flows do Salesforce que fazem parse de valores de campo quebram quando o formato é inesperado.

Modelos de IA processam texto como está. Quando um campo de telefone contém “Phone: 555-1234” em vez de um número limpo, o modelo vê padrões inconsistentes. Formatos inválidos reduzem a eficácia da IA e geram saídas pouco confiáveis no Agentforce.

Como o DQS mede validade

O DQS produz 6 métricas de validade organizadas em torno de uma pergunta diagnóstica: “O dado corresponde ao padrão, e há lixo escondido em valores que passam?”

Pense nessas métricas como um fluxo diagnóstico. Cada passo revela uma camada mais profunda do problema.

Passo 1: Corresponde ao padrão?

Validity Rate é a métrica principal. Calcula o percentual de registros em que o valor do campo corresponde ao padrão configurado. Esse é o número para o dashboard.

Você configura o padrão Email no campo PersonEmail de Contacts. Validity Rate volta em 71%. Isso significa que 29% dos endereços de e-mail falham na verificação de formato. Faltam ”@”, faltam domínios ou contêm espaços. Toda campanha de marketing enviada para esses endereços retorna. Todo workflow automatizado que dispara em e-mail falha silenciosamente.

Valid Count informa o número absoluto. De 50.000 Contacts, 35.800 têm e-mails válidos. Essa é sua audiência real endereçável por e-mail, não os 50.000 que estão no sistema. Marketing pode definir projeções realistas em vez de trabalhar com números inflados.

Passo 2: Qual é o quadro completo?

Taxas dizem severidade. Contagens dizem volume de trabalho. Duas métricas completam o quadro:

Passo 3: Há lixo além de erros de formato?

Um valor pode passar por uma checagem de formato e ainda ser lixo. Seu web-to-lead exige um campo Company. A Validity Rate em Company é 98%, pois quase tudo passa em um padrão básico de texto. Mas Noise Rate revela que 14% desses valores são entradas como “asdf”, “test”, “xxxxx” ou “na na na”. Válidos no formato, mas completamente inúteis para roteamento de vendas, enriquecimento ou segmentação.

Noisy Records Count dá o escopo da limpeza. Se Noise Rate é 14% sobre 50.000 registros, são 7.000 Leads com nomes de empresa lixo. Seu time de ops pode montar uma fila de limpeza, estimar horas e decidir entre auto-delete ou revisão manual.

Duas categorias de falha

As métricas de validade distinguem dois problemas fundamentalmente diferentes:

A distinção importa porque a correção é completamente diferente. Erros de formato são remediados limpando os dados. Ruído é remediado consertando a fonte que o produz.

Referência de métricas

Métricas de base

Essas 2 métricas formam a base de toda análise de validade. Informam a taxa de correspondência e o número de registros que passam.

Métricas avançadas

Essas 4 métricas vão além de “corresponde?” para dar o quadro completo, incluindo detecção de ruído. Exigem o modo Advanced Format Validation.

Por que taxas e contagens vêm em pares

A maioria das métricas aparece como taxa (percentual) e contagem (número absoluto). Isso é intencional:

• Taxas são para dashboards, reporting executivo e acompanhamento de tendências. “A validade melhorou de 71% para 92% neste trimestre.”
• Contagens são para planejamento de projetos, estimativa de esforço e escopo de limpeza. “Temos 23.400 números de telefone para reformatar.”

Use taxas para comunicar progresso. Use contagens para planejar trabalho.

Cobertura de tipos de campo

Todas as 6 métricas de validade compartilham o mesmo suporte base de tipos de campo, com as métricas de ruído limitadas a campos de texto.

As métricas baseadas em padrão (Validity Rate, Valid Count, Invalid Rate, Invalid Count) funcionam em todos os 6 tipos suportados: String, TextArea, Email, Phone, URL e Picklist.

As métricas de ruído (Noise Rate, Noisy Records Count) aplicam-se apenas a campos String e TextArea. Padrões de ruído como caracteres repetidos e “keyboard smash” são fenômenos de texto livre. Um campo Picklist com valor válido não pode conter ruído. A detecção de ruído só faz sentido em campos em que usuários digitam texto livre.

Dois modos de análise

O DQS oferece dois modos de análise de validade:

Format Validation responde à pergunta: “Os valores correspondem ao padrão esperado?” Produz as 2 métricas de base e cobre o essencial para uma checagem de conformidade de formato ou auditoria rápida.

Advanced Format Validation vai mais fundo. Produz todas as 6 métricas, incluindo o quadro completo de valid/invalid e detecção de ruído. Use quando precisar distinguir entre erros de formato e dados lixo, ou quando precisar de contagens precisas para planejar a limpeza.

Configurando validade

Ao contrário de completude (que funciona automaticamente em qualquer campo), validade exige configuração. Você precisa definir o que “válido” significa para cada campo antes que o DQS possa verificar. Um scan de validade sem padrão não significa nada: válido em relação a quê?

O DQS oferece 5 inputs de configuração. Cada um pode ser definido no nível global (aplica-se a todos os campos) e sobrescrito no nível do campo.

Tipos de padrão

Exemplo: Seus códigos de produto seguem o formato “DQS-” seguido de 6 dígitos. Defina Pattern Type como Custom e insira o regex ^DQS-\d{6}$. O DQS sinaliza qualquer código de produto que não siga essa estrutura.

Detecção de ruído

A detecção de ruído captura dados que passam pelas checagens de formato mas ainda são lixo. O DQS usa duas heurísticas embutidas para identificar valores ruidosos:

Heurística 1: caracteres idênticos consecutivos. Três ou mais do mesmo caractere em sequência. Valores como “aaaa”, ”!!!”, ”---” ou “xxxxx” disparam essa verificação. Costumam vir de teclas seguradas, preenchimento forçado ou abuso de placeholder.

Heurística 2: excesso de caracteres especiais. Mais de 50% de caracteres não alfanuméricos (excluindo espaços). Valores como ”!@#$%^” ou ”***///---” disparam essa verificação. Indicam keyboard smash, input de bots ou lixo deliberado.

Você também pode definir padrões de ruído customizados via regex para lixo específico da org que as heurísticas embutidas não cobrem.

Dica: A detecção de ruído é mais valiosa em campos de texto livre em que usuários podem digitar qualquer coisa: Company, Description, Notes e campos de texto custom. Rode nos seus campos de web-to-lead primeiro, onde submissões de bots e entradas forçadas são mais comuns.

Problemas comuns de validade

Endereços de e-mail inválidos

Usuários inserem e-mails sem formato apropriado. Falta de ”@”, falta de domínio, pontos duplos e erros de digitação são os problemas mais comuns.

Impacto: E-mails retornados, reputação de remetente prejudicada, comunicação perdida.

Números de telefone malformados

Campos de telefone aceitam qualquer texto no Salesforce, levando a formatos inconsistentes e inválidos.

Impacto: Ligações falhas, tempo de vendas desperdiçado, erros de sync de telefonia.

URLs inválidas

Campos de endereço web costumam conter valores parciais ou malformados.

Impacto: Links quebrados, enriquecimento falhando, erros de navegação.

Melhores práticas

Valide na entrada

A melhor verificação de validade acontece no momento da entrada. Use validation rules do Salesforce para impor formatos antes que os dados entrem no sistema.

// Exemplo: validation rule de formato de e-mail
NOT(ISBLANK(Email)) && NOT(REGEX(Email, "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$"))

Padronize formatos antes de scanear

Escolha um formato para cada campo e imponha-o. Para números de telefone, E.164 (+15551234567) é o padrão mais universalmente aceito. Para URLs, exija o protocolo https://. Documente suas decisões de formato para que o time conheça o padrão.

Defina limites por prioridade do campo

Campos diferentes precisam de padrões de validade diferentes:

Use detecção de ruído em campos de texto livre

Rode a detecção de ruído em campos em que usuários digitam texto livre: Company, Description, campos de texto custom e qualquer campo populado por web forms. Noise Rate revela problemas que a validação de formato não pega.

Documente os formatos esperados

Crie um dicionário de dados que especifique o formato esperado para cada campo, variações aceitáveis e exemplos de valores válidos e inválidos. Compartilhe com o time e use como referência em projetos de limpeza.

Próximos passos

Você agora entende como validar formatos e detectar valores ruidosos. Continue aprendendo sobre a próxima dimensão:

• No Salesforce: Qualidade de dados no Salesforce - aplique formatos válidos aos seus campos do Salesforce
• Próximo: Unicidade - Detecte e previna registros duplicados
• Anterior: Completude - Garanta que os dados obrigatórios estão presentes
• Relacionado: As cinco dimensões - Visão geral
• Ação: AI Readiness Assessment - Veja suas pontuações atuais de validade