/validate-data - Validar análise antes de compartilhar

O que validate-data - Validar análise antes de compartilhar faz?

Se você encontrar placeholders desconhecidos ou precisar verificar quais ferramentas estão conectadas, veja CONNECTORS.md.

Revise uma análise em termos de precisão, metodologia e possíveis vieses antes de compartilhá-la com as partes interessadas. Gera uma avaliação de confiança e sugestões de melhoria.

Uso

/validate-data <análise a ser revisada>

A análise pode ser:

• Um documento ou relatório na conversa
• Um arquivo (markdown, notebook, planilha)
• Consultas SQL e seus resultados
• Gráficos e seus dados subjacentes
• Uma descrição da metodologia e descobertas

Fluxo de trabalho

1. Revisar metodologia e suposições

Examine:

• Formulação da pergunta: A análise está respondendo à pergunta certa? A pergunta poderia ser interpretada de forma diferente?
• Seleção de dados: As tabelas/conjuntos de dados corretos estão sendo usados? O intervalo de tempo é apropriado?
• Definição da população: A população da análise está definida corretamente? Existem exclusões não intencionais?
• Definições de métricas: As métricas estão definidas de forma clara e consistente? Elas correspondem à forma como as partes interessadas as entendem?
• Linha de base e comparação: A comparação é justa? Períodos de tempo, tamanhos de coorte e contextos são comparáveis?

2. Executar a lista de verificação de pré-entrega

Percorra a lista de verificação abaixo — qualidade dos dados, cálculos, razoabilidade e apresentação.

3. Verificar armadilhas analíticas comuns

Revise sistematicamente o catálogo detalhado de armadilhas abaixo (explosão de junções, viés de sobrevivência, comparação de período incompleto, mudança de denominador, média de médias, incompatibilidades de fuso horário, viés de seleção).

4. Verificar cálculos e agregações

Quando possível, faça verificações pontuais:

• Recalcule alguns números-chave independentemente
• Verifique se os subtotais somam aos totais
• Confirme se as porcentagens somam 100% (ou próximo disso) quando esperado
• Confirme se as comparações YoY/MoM usam os períodos base corretos
• Valide se os filtros são aplicados consistentemente em todas as métricas

Aplique as técnicas de verificação de sanidade de resultados abaixo (verificações de magnitude, validação cruzada, detecção de bandeiras vermelhas).

5. Avaliar visualizações

Se a análise incluir gráficos:

• Os eixos começam em valores apropriados (zero para gráficos de barras)?
• As escalas são consistentes em gráficos de comparação?
• Os títulos dos gráficos descrevem com precisão o que é mostrado?
• A visualização poderia enganar um leitor rápido?
• Existem eixos truncados, intervalos inconsistentes ou efeitos 3D que distorcem a percepção?

6. Avaliar narrativa e conclusões

Revise se:

• As conclusões são suportadas pelos dados mostrados
• Explicações alternativas são reconhecidas
• A incerteza é comunicada de forma adequada
• As recomendações seguem logicamente as descobertas
• O nível de confiança corresponde à força da evidência

7. Sugerir melhorias

Forneça sugestões específicas e acionáveis:

• Análises adicionais que fortaleceriam as conclusões
• Ressalvas ou limitações que devem ser anotadas
• Melhores visualizações ou enquadramentos para pontos-chave
• Contexto ausente que as partes interessadas gostariam de saber

8. Gerar avaliação de confiança

Classifique a análise em uma escala de 3 níveis:

Pronto para compartilhar -- Análise metodologicamente sólida, cálculos verificados, ressalvas anotadas. Sugestões menores de melhoria, mas nada impeditivo.

Compartilhar com ressalvas anotadas -- Análise está em grande parte correta, mas tem limitações ou suposições específicas que devem ser comunicadas às partes interessadas. Liste as ressalvas necessárias.

Precisa de revisão -- Erros específicos, problemas metodológicos ou análises ausentes que devem ser resolvidos antes de compartilhar. Liste as alterações necessárias com ordem de prioridade.

Formato de saída

## Relatório de validação

### Avaliação geral: [Pronto para compartilhar | Compartilhar com ressalvas | Precisa de revisão]

### Revisão de metodologia
[Descobertas sobre abordagem, seleção de dados, definições]

### Problemas encontrados
1. [Gravidade: Alta/Média/Baixa] [Descrição do problema e impacto]
2. ...

### Verificações pontuais de cálculos
- [Métrica]: [Verificado / Discrepância encontrada]
- ...

### Revisão de visualizações
[Quaisquer problemas com gráficos ou apresentação visual]

### Melhorias sugeridas
1. [Melhoria e por que é importante]
2. ...

### Ressalvas necessárias para as partes interessadas
- [Ressalva que deve ser comunicada]
- ...

---

Lista de verificação de pré-entrega

Percorra esta lista antes de compartilhar qualquer análise com as partes interessadas.

Verificações de qualidade dos dados

• Verificação da fonte: Confirmado quais tabelas/fontes de dados foram usadas. Elas são as corretas para esta pergunta?
• Atualidade: Os dados são atuais o suficiente para a análise. Anotada a data "de referência".
• Integridade: Sem lacunas inesperadas em séries temporais ou segmentos ausentes.
• Tratamento de nulos: Verificadas as taxas de nulos em colunas-chave. Os nulos são tratados adequadamente (excluídos, imputados ou sinalizados).
• Desduplicação: Confirmado que não há dupla contagem devido a junções ruins ou registros duplicados na fonte.
• Verificação de filtros: Todas as cláusulas WHERE e filtros estão corretos. Sem exclusões não intencionais.

Verificações de cálculos

• Lógica de agregação: GROUP BY inclui todas as colunas não agregadas. O nível de agregação corresponde ao grão da análise.
• Correção do denominador: Os cálculos de taxa e porcentagem usam o denominador correto. Os denominadores são diferentes de zero.
• Alinhamento de datas: As comparações usam o mesmo comprimento de período de tempo. Períodos parciais são excluídos ou anotados.
• Correção da junção: Os tipos de JOIN são apropriados (INNER vs LEFT). Junções muitos-para-muitos não inflaram as contagens.
• Definições de métricas: As métricas correspondem a como as partes interessadas as definem. Quaisquer desvios são anotados.
• Subtotais somam: As partes somam ao todo quando esperado. Se não, explique por que (por exemplo, sobreposição).

Verificações de razoabilidade

• Magnitude: Os números estão em uma faixa plausível. A receita não é negativa. As porcentagens estão entre 0-100%.
• Continuidade da tendência: Sem saltos ou quedas inexplicáveis em séries temporais.
• Referência cruzada: Números-chave correspondem a outras fontes conhecidas (dashboards, relatórios anteriores, dados financeiros).
• Ordem de grandeza: A receita total está na faixa esperada. As contagens de usuários correspondem a números conhecidos.
• Casos extremos: O que acontece nos limites? Segmentos vazios, períodos de atividade zero, novas entidades.

Verificações de apresentação

• Precisão do gráfico: Gráficos de barras começam em zero. Os eixos são rotulados. As escalas são consistentes entre os painéis.
• Formatação de números: Precisão apropriada. Formatação consistente de moeda/porcentagem. Separadores de milhares quando necessário.
• Clareza do título: Os títulos indicam o insight, não apenas a métrica. Os intervalos de datas são especificados.
• Transparência das ressalvas: Limitações e suposições conhecidas são declaradas explicitamente.
• Reprodutibilidade: Outra pessoa poderia recriar esta análise a partir da documentação fornecida.

Armadilhas comuns em análise de dados

Explosão de junção

O problema: Uma junção muitos-para-muitos multiplica silenciosamente as linhas, inflando contagens e somas.

Como detectar:

-- Verificar contagem de linhas antes e depois da junção
SELECT COUNT(*) FROM tabela_a;  -- 1.000
SELECT COUNT(*) FROM tabela_a a JOIN tabela_b b ON a.id = b.a_id;  -- 3.500 (opa)

Como prevenir:

• Sempre verificar as contagens de linhas após as junções
• Se as contagens aumentarem, investigar o relacionamento da junção (é realmente 1:1 ou 1:muitos?)
• Use COUNT(DISTINCT a.id) em vez de COUNT(*) ao contar entidades através de junções

Viés de sobrevivência

O problema: Analisar apenas entidades que existem hoje, ignorando aquelas que foram excluídas, cancelaram ou falharam.

Exemplos:

• Analisar o comportamento do usuário de "usuários atuais" perde os usuários que cancelaram
• Olhar para "empresas que usam nosso produto" ignora aquelas que avaliaram e saíram
• Estudar propriedades de resultados "bem-sucedidos" sem os "malsucedidos"

Como prevenir: Pergunte "quem NÃO está neste conjunto de dados?" antes de tirar conclusões.

Comparação de período incompleto

O problema: Comparar um período parcial a um período completo.

Exemplos:

• "A receita de janeiro é de R$ 500 mil vs. a de dezembro de R$ 800 mil" -- mas janeiro ainda não terminou
• "As inscrições desta semana estão baixas" -- verificado na quarta-feira, comparando com uma semana completa anterior

Como prevenir: Sempre filtrar para períodos completos, ou comparar o mesmo dia do mês / mesmo número de dias.

Mudança de denominador

O problema: O denominador muda entre períodos, tornando as taxas incomparáveis.

Exemplos:

• A taxa de conversão melhora porque você mudou a forma de contar usuários "elegíveis"
• A taxa de churn muda porque a definição de "ativo" foi atualizada

Como prevenir: Use definições consistentes em todos os períodos comparados. Anote quaisquer alterações de definição.

Média de médias

O problema: Fazer a média de médias pré-calculadas dá resultados errados quando os tamanhos dos grupos diferem.

Exemplo:

• Grupo A: 100 usuários, receita média R$ 50
• Grupo B: 10 usuários, receita média R$ 200
• Errado: Média de médias = (R$ 50 + R$ 200) / 2 = R$ 125
• Correto: Média ponderada = (100R$ 50 + 10R$ 200) / 110 = R$ 63,64

Como prevenir: Sempre agregar a partir dos dados brutos. Nunca faça a média de médias pré-agregadas.

Incompatibilidades de fuso horário

O problema: Diferentes fontes de dados usam fusos horários diferentes, causando desalinhamento.

Exemplos:

• Carimbos de data/hora de eventos em UTC vs. datas voltadas ao usuário no horário local
• Agregações diárias que usam horários de corte diferentes

Como prevenir: Padronize todos os carimbos de data/hora para um único fuso horário (UTC recomendado) antes da análise. Documente o fuso horário usado.

Viés de seleção em segmentação

O problema: Segmentos são definidos pelo resultado que você está medindo, criando lógica circular.

Exemplos:

• "Usuários que concluíram a integração têm maior retenção" -- obviamente, eles se autosselecionaram
• "Usuários avançados geram mais receita" -- eles se tornaram usuários avançados AO gerar receita

Como prevenir: Defina segmentos com base em características pré-tratamento, não em resultados.

Outras armadilhas estatísticas

• Paradoxo de Simpson: A tendência se inverte quando os dados são agregados vs. segmentados
• Correlação apresentada como causalidade sem evidência de suporte
• Tamanhos de amostra pequenos levando a conclusões não confiáveis
• Valores atípicos afetando desproporcionalmente as médias (medianas devem ser usadas em vez disso?)
• Testes múltiplos / cherry-picking de resultados significativos
• Viés de olhar para frente: Usar informações futuras para explicar eventos passados
• Intervalos de tempo escolhidos a dedo que favorecem uma narrativa particular

Verificação de sanidade de resultados

Verificações de magnitude

Para qualquer número-chave em sua análise, verifique se ele passa no "teste do cheiro":

Tipo de métrica	Verificação de sanidade
Contagens de usuários	Isso corresponde aos números conhecidos de MAU/DAU?
Receita	Isso está na ordem de grandeza correta vs. o ARR conhecido?
Taxas de conversão	Isso está entre 0% e 100%? Corresponde aos números do dashboard?
Taxas de crescimento	Um crescimento MoM de 50%+ é realista, ou há um problema nos dados?
Médias	A média é razoável dado o que você sabe sobre a distribuição?
Porcentagens	As porcentagens dos segmentos somam ~100%?

Técnicas de validação cruzada

1. Calcule a mesma métrica de duas maneiras diferentes e verifique se correspondem
2. Verifique registros individuais -- escolha algumas entidades específicas e rastreie seus dados manualmente
3. Compare com benchmarks conhecidos -- compare com dashboards publicados, relatórios financeiros ou análises anteriores
4. Engenharia reversa -- se a receita total é X, a receita por usuário vezes o número de usuários se aproxima de X?
5. Verificações de limite -- o que acontece quando você filtra para um único dia, um único usuário ou uma única categoria? Esses microrresultados são sensatos?

Bandeiras vermelhas que merecem investigação

• Qualquer métrica que mudou mais de 50% período a período sem uma causa óbvia
• Contagens ou somas que são números redondos exatos (sugere um problema de filtro ou valor padrão)
• Taxas exatamente em 0% ou 100% (pode indicar dados incompletos)
• Resultados que confirmam perfeitamente a hipótese (a realidade geralmente é mais bagunçada)
• Valores idênticos entre períodos de tempo ou segmentos (sugere que a consulta está ignorando uma dimensão)

Padrões de documentação para reprodutibilidade

Template de documentação de análise

Toda análise não trivial deve incluir:

## Análise: [Título]

### Pergunta
[A pergunta específica que está sendo respondida]

### Fontes de dados
- Tabela: [schema.nome_da_tabela] (a partir de [data])
- Tabela: [schema.outra_tabela] (a partir de [data])
- Arquivo: [nome_do_arquivo] (fonte: [de onde veio])

### Definições
- [Métrica A]: [Exatamente como é calculada]
- [Segmento X]: [Exatamente como a associação é determinada]
- [Período de tempo]: [Data de início] a [data de fim], [fuso horário]

### Metodologia
1. [Passo 1 da abordagem de análise]
2. [Passo 2]
3. [Passo 3]

### Suposições e limitações
- [Suposição 1 e por que é razoável]
- [Limitação 1 e seu impacto potencial nas conclusões]

### Principais descobertas
1. [Descoberta 1 com evidência de suporte]
2. [Descoberta 2 com evidência de suporte]

### Consultas SQL
[Todas as consultas usadas, com comentários]

### Ressalvas
- [Coisas que o leitor deve saber antes de agir com base nisso]

Documentação de código

Para qualquer código (SQL, Python) que possa ser reutilizado:

"""
Análise: Retenção de coorte mensal
Autor: [Nome]
Data: [Data]
Fonte de dados: tabela de eventos, tabela de usuários
Última validação: [Data] -- resultados corresponderam ao dashboard em até 2%

Objetivo:
    Calcular coortes de retenção mensal de usuários com base na data da primeira atividade.

Suposições:
    - "Ativo" significa pelo menos um evento no mês
    - Exclui contas de teste/internas (user_type != 'internal')
    - Usa datas UTC em todo o processo

Saída:
    Matriz de retenção de coorte com linhas de coorte mensal e colunas de meses desde a inscrição.
    Os valores são taxas de retenção (0-100%).
"""

Controle de versão para análises

• Salve consultas e código em controle de versão (git) ou em um sistema de documentos compartilhado
• Anote a data do snapshot dos dados usado
• Se uma análise for executada novamente com dados atualizados, documente o que mudou e por que
• Vincule a versões anteriores de análises recorrentes para comparação de tendências