# Validade

> Todas as 6 métricas de validade que o DQS mede, o fluxo diagnóstico para encontrar erros de formato e ruído e como configurar a validação baseada em padrões.

Source: https://dataqualitysense.com/pt/resources/data-quality/validity/
Last updated: 2026-04-16

---

## 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:

| Verificação | Válido? | Preciso? |
|-------|--------|-----------|
| john@company.com | Sim | Desconhecido sem verificação |
| john@company | Não | N/A (formato errado) |
| john.doe@formerjob.com | Sim | Não (pessoa saiu da empresa) |
| 555-123-4567 | Sim | Desconhecido sem ligar |
| 555-12-456 | Não | N/A (contagem de dígitos errada) |

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.

| Sistema | Impacto da validade |
|--------|-----------------|
| Campanhas de e-mail | Bounces prejudicam reputação do remetente |
| Telefonia | Números inválidos desperdiçam tempo do discador |
| Links web | URLs quebradas bloqueiam enriquecimento e navegação |
| APIs | Dados malformados causam falhas de sincronização |
| IA e Agentforce | Formatos inconsistentes reduzem a precisão do modelo |

## 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:

| Métrica | O que ela diz |
|--------|-------------------|
| **Invalid Rate** | O enquadramento negativo da pontuação de validade. "29% dos nossos e-mails são estruturalmente inválidos" chama mais atenção em uma apresentação ao board do que "71% são válidos". Mesmos dados, enquadrados para a ação. |
| **Invalid Count** | O volume de limpeza como número concreto. Sua empresa está migrando para um novo sistema de telefonia que exige formato E.164. Invalid Count no campo Phone: 23.400. Esse é o número exato de registros que precisam ser reformatados antes do go-live. |

### 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:

| Problema | Métricas | Causa-raiz | Correção |
|---------|---------|------------|-----|
| **Erros de formato** | Validity Rate, Invalid Rate, Valid/Invalid Count | Erros humanos, bugs de integração, falta de validation rules | Limpar os dados: validation rules, transformação de dados, enriquecimento |
| **Ruído e lixo** | Noise Rate, Noisy Records Count | Bots, submissões forçadas de form, importações em massa com defaults lixo | Consertar a origem: CAPTCHA, redesenho de campos obrigatórios, exclusão de registros |

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étrica | Tipo | O que mede |
|--------|------|-----------------|
| Validity Rate | Percentual | Parcela de registros correspondendo ao padrão configurado |
| Valid Count | Contagem | Número de registros correspondendo ao padrão configurado |

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

| Métrica | Tipo | O que mede |
|--------|------|-----------------|
| Invalid Rate | Percentual | Parcela de registros falhando no padrão configurado |
| Invalid Count | Contagem | Número de registros falhando no padrão configurado |
| Noise Rate | Percentual | Parcela de registros contendo padrões de ruído (lixo) |
| Noisy Records Count | Contagem | Número de registros contendo padrões de ruído |

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

| Métrica | Todos os 6 tipos | Apenas String e TextArea |
|--------|:--:|:--:|
| Validity Rate | X | |
| Valid Count | X | |
| Invalid Rate | X | |
| Invalid Count | X | |
| Noise Rate | | X |
| Noisy Records Count | | X |

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.

| Necessidade de negócio | Modo recomendado |
|---------------|-----------------|
| Checagem rápida de conformidade de formato | Format Validation |
| Reporting ou auditoria de compliance | Advanced (quadro valid/invalid completo para reguladores) |
| Avaliação de qualidade de leads | Advanced (Noise Rate pega lixo que passa pela checagem) |
| Avaliação pré-migração | Advanced (quadro completo para dimensionar remediação por categoria) |
| Governança contínua | Comece com Format Validation e mude para Advanced para detecção de ruído |

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

| Configuração | O que controla |
|---------|-----------------|
| **Pattern Type** | O formato contra o qual validar. Escolha entre Email, URL, Fixed Length ou Custom regex. Obrigatório: você precisa selecionar um tipo antes de rodar um scan. |
| **Pattern / Fixed Length** | O valor específico para o tipo escolhido. Para Fixed Length, insira uma contagem de caracteres (1 a 255). Para Custom, insira um padrão regex. Email e URL usam padrões embutidos. |
| **Custom Pattern** | Seu próprio regex quando o Pattern Type é Custom. O DQS valida o regex antes de salvar e bloqueia expressões inválidas. |
| **Include Blanks** | Quando habilitado, o DQS conta valores em branco como inválidos. Quando desabilitado (padrão), blanks são excluídos da avaliação. |
| **Case Sensitive** | Quando habilitado, a correspondência considera caixa. Quando desabilitado (padrão), a correspondência é case-insensitive. |

### Tipos de padrão

| Tipo | O que valida | Exemplo válido | Exemplo inválido |
|------|-------------------|-------------|-------------|
| **Email** | Formato padrão de e-mail: user@domain.tld | user@example.com | user@domain, invalid-email |
| **URL** | Endereços web HTTP/HTTPS com domínio válido | https://example.com | example.com, htp://site.com |
| **Fixed Length** | Contagem exata de caracteres (você define o número) | `AAAAAAAAAA` (10 caracteres, se length = 10) | `SHORT` (5 caracteres) |
| **Custom** | Qualquer padrão regex que você definir | Depende do padrão | Depende do 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.

| Heurística | O que pega | Valores ruidosos | Valores limpos |
|-----------|-----------------|---------------------|---------------------|
| 3+ caracteres idênticos consecutivos | Preenchimento, filler, tecla segurada | "aaaa", "!!!", "---", "xxxxx" | "Premium", "DOT AB3 2024" |
| Mais de 50% de caracteres especiais | Keyboard smash, input de bots, lixo | "!@#$%^", "***test", "//--//" | "test@email.com", "O'Brien Inc" |

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.

| Problema | Exemplo |
|-------|---------|
| Falta @ | john.company.com |
| Falta domínio | john@ |
| Pontos duplos | john@company..com |
| Erros de digitação | john@comapny.com |

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

| Problema | Exemplo |
|-------|---------|
| Letras misturadas | 555-CALL-NOW |
| Contagem de dígitos errada | 555-12 |
| Ramal no campo | 555-1234 ext 5 |
| Confusão de código de país | 1-555-123-4567 vs 555-123-4567 |

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

| Problema | Exemplo |
|-------|---------|
| Falta protocolo | www.company.com |
| Falta domínio | https:// |
| Erros de digitação | htps://company.com |
| Handles sociais | @company (não é URL) |

**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:

| Campo | Limite sugerido | Razão |
|-------|---------------------|-----------|
| E-mail primário | 95%+ | Crítico para comunicação |
| Phone | 90%+ | Importante, mas dados legados são esperados |
| Website | 85%+ | Frequentemente inserido incompleto |
| Códigos de texto custom | 98%+ | Gerados por sistema, alta conformidade esperada |

### 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](/pt/resources/salesforce/data-quality-in-salesforce/) - aplique formatos válidos aos seus campos do Salesforce
- **Próximo:** [Unicidade](/pt/resources/data-quality/uniqueness/) - Detecte e previna registros duplicados
- **Anterior:** [Completude](/pt/resources/data-quality/completeness/) - Garanta que os dados obrigatórios estão presentes
- **Relacionado:** [As cinco dimensões](/pt/resources/data-quality/five-dimensions/) - Visão geral
- **Ação:** [AI Readiness Assessment](/pt/ai-readiness/) - Veja suas pontuações atuais de validade