Produto de dados B2B: frescor, cobertura e confiança como requisitos de produto

Em um software de gestão, o cliente compra o fluxo: cadastrar, aprovar, emitir. Em um produto de dados, o cliente compra a resposta. A interface pode ser impecável, mas se o telefone está errado, a empresa já fechou ou o número não bate com o que o cliente sabe, a confiança vai embora, e com ela a renovação.

Por isso, em produtos de dados B2B, atributos que costumam ficar na lista de "requisitos não funcionais" precisam virar funcionalidade de primeira classe. Este artigo propõe um jeito de tratar três deles (frescor, cobertura e confiança) como requisitos de produto, com telas, métricas e critérios de priorização.

Por que qualidade de dados é problema de produto

Quando a qualidade fica só com a engenharia, ela vira uma promessa genérica ("dados atualizados e confiáveis") e um conjunto de alertas internos que o cliente nunca vê. O resultado é previsível:

• o cliente encontra um dado errado, não sabe se é exceção ou regra, e passa a desconfiar de tudo;
• o time de suporte não tem como explicar de onde veio a informação;
• o roadmap prioriza novas telas, porque ninguém mede quanto a qualidade custa em cancelamentos.

A alternativa é tornar a qualidade visível, mensurável e priorizável, como qualquer outra funcionalidade.

Requisito 1: frescor

A pergunta do cliente: "Isso ainda é verdade?"

Frescor é a distância entre o mundo real e o dado que você mostra. Ele depende da fonte (o cadastro da Receita, por exemplo, é publicado mensalmente), do seu pipeline (quanto tempo você leva para carregar) e do tipo de informação (um endereço muda pouco; um telefone muda mais).

Como vira produto:

• Data de referência visível em cada bloco de informação: "Dados cadastrais: base da Receita de agosto de 2026."
• Data da última verificação para dados que você checa ativamente, como contatos.
• Indicador de envelhecimento: a interface sinaliza quando o dado passou de um limite definido para aquele tipo de campo.

Como medir:

• Tempo até o dado: horas entre a publicação na fonte e a disponibilidade no produto.
• Idade mediana por tipo de campo.
• Percentual de registros acima do limite de frescor.

Requisito 2: cobertura

A pergunta do cliente: "Vocês têm o que eu preciso para as empresas que me interessam?"

Cobertura é a proporção de registros que têm um campo preenchido. Ela quase nunca é uniforme: um campo pode estar presente em quase todas as empresas grandes e em poucas microempresas. A média geral esconde exatamente o que o cliente quer saber.

Como vira produto:

• Cobertura no contexto da busca: ao filtrar um segmento, mostre quantos resultados têm telefone, e-mail ou site naquele segmento, antes da exportação.
• Estados vazios honestos: "A Receita Federal não informa sócios para este estabelecimento" é muito melhor que um campo em branco que parece erro.
• Expectativa no preço: se o crédito só é consumido quando há dado, diga isso. Se não, diga também.

Como medir:

• Cobertura por campo, segmentada por porte, setor e região.
• Taxa de exportações com campos-chave vazios.
• Tickets de suporte do tipo "faltou dado".

Requisito 3: confiança

A pergunta do cliente: "Posso agir com base nisso?"

Confiança junta três coisas: a origem do dado, o método que o produziu e a certeza que você tem sobre ele. Um CNPJ ativo segundo a Receita é um fato. Um faturamento estimado por modelo é uma inferência. Misturar os dois na mesma tela, com a mesma formatação, é a forma mais rápida de perder credibilidade.

Como vira produto:

• Fonte por campo: um ícone ou rótulo que diz "Receita Federal", "site da empresa" ou "estimativa".
• Estimativas como faixa, não como número exato: "entre 20 e 49 funcionários (estimativa)" é mais honesto e mais útil que "37 funcionários".
• Método explicável: um "como calculamos" acessível a partir do campo.
• Canal de correção: um botão "reportar dado incorreto" que alimenta a fila de qualidade e responde ao usuário.

Um contrato de dados que carrega frescor, cobertura e confiança

Esses requisitos não podem ficar só na interface. Se a API devolve apenas o valor, toda integração do cliente perde o contexto. Um formato que carrega os metadados junto com o dado resolve isso:

{
  "cnpj": "11222333000181",
  "situacao": {
    "valor": "ATIVA",
    "fonte": "receita_federal",
    "referencia": "2026-08"
  },
  "telefone": {
    "valor": null,
    "motivo_ausencia": "nao_informado_na_fonte"
  },
  "funcionarios": {
    "faixa": [20, 49],
    "tipo": "estimativa",
    "metodo": "modelo_setorial_v2",
    "confianca": "media"
  }
}

O exemplo é ilustrativo, mas os princípios valem para qualquer produto:

• todo valor tem fonte e referência temporal;
• ausência tem motivo (não informado, removido a pedido do titular, não coletado);
• estimativas são marcadas como tal, com método e grau de confiança.

Como priorizar qualidade no roadmap

Qualidade de dados compete com funcionalidades novas por tempo de engenharia. Para competir em pé de igualdade, ela precisa de números de negócio.

1. Conecte qualidade a cancelamento. Nas entrevistas de saída, pergunte explicitamente sobre dados errados ou faltantes. Classifique os motivos.
2. Meça o custo do suporte. Quantos tickets por mês são sobre qualidade? Quanto tempo cada um consome?
3. Teste o efeito da transparência. Mostrar data de referência e fonte reduz tickets? Aumenta exportações? Faça um teste antes e depois.
4. Trate fontes como dependências críticas. Uma mudança de layout no arquivo da fonte é um incidente, com o mesmo rigor de uma queda de servidor.

Anti-padrões comuns

• Precisão falsa. Mostrar "faturamento: R$ 4.732.118,00" para uma estimativa. Parece sofisticado e é desonesto.
• Data escondida. Omitir a referência para não "parecer desatualizado". O cliente descobre do pior jeito.
• Média que engana. Divulgar a cobertura geral quando o cliente trabalha com um segmento em que ela é muito menor.
• Correção sem retorno. O usuário reporta um erro e nunca sabe se foi corrigido. Ele não vai reportar de novo.
• Dado pessoal sem critério. Tratar contato de pessoa física como qualquer outro campo. Além do risco jurídico, isso gera reclamação de titulares.

Um checklist para o próximo ciclo de produto

• Toda tela mostra a referência temporal dos dados que exibe?
• A busca informa a cobertura dos campos-chave para o segmento filtrado?
• Fatos e estimativas têm apresentação visualmente diferente?
• Existe um botão de correção com retorno ao usuário?
• A API devolve fonte, referência e motivo de ausência?
• Há métricas de frescor e cobertura num painel que o time de produto olha toda semana?

Conclusão

Num produto de dados, frescor, cobertura e confiança não são detalhes de implementação: são o que o cliente está comprando. Tornar esses atributos visíveis na interface, explícitos na API e medidos no painel do time muda a conversa com o cliente, de "os dados são bons?" para "eu sei exatamente quanto posso confiar em cada informação".

Para ver como esses princípios aparecem num produto de dados de empresas, conheça a CNPJpedia.