"O gráfico mostra que melhoramos 300%." Olhe novamente. O eixo Y começa em 90, não em zero. A melhoria real foi de 3%. Gráficos são ferramentas poderosas de comunicação, mas podem enganar — intencionalmente ou não. Este artigo ensina a identificar e evitar visualizações enganosas.
Um gráfico pode mentir sem conter nenhum número falso.
Técnicas de Distorção
1. Truncar o eixo Y
Gráfico Enganoso: Gráfico Honesto:
Latência Latência
102 ┤ ╭─╮ 200 ┤
101 ┤ ╱ ╲ 150 ┤
100 ┤──╯ ╲ 100 ┤──────────
99 ┤ ╲ 50 ┤
98 ┼─────────╯ 0 ┼──────────
Jan Fev Mar Jan Fev Mar
"Latência caiu 4%!" "Latência estável"
Por que engana:
- Exagera variações pequenas
- Faz mudança trivial parecer significativa
Quando é aceitável:
- Quando variação é genuinamente importante
- Com aviso claro de que eixo está truncado
2. Escala inconsistente
Antes: Depois:
p95 (ms) p95 (ms)
1000 ┤ 500 ┤
800 ┤ ╭─── 400 ┤
600 ┤ ╱ 300 ┤ ╭───
400 ┤──╯ 200 ┤ ╱
200 ┤ 100 ┤──╯
0 ┼───── 0 ┼─────
"Antes era 800ms!" "Agora é 300ms!"
Realidade: Antes 800ms, depois 300ms
Mas gráficos têm escalas diferentes
3. Período de tempo seletivo
Últimos 3 meses: Último ano:
Error % Error %
5 ┤ 5 ┤ ╭─╮
4 ┤ 4 ┤ ╱ ╲
3 ┤ ╭── 3 ┤ ╱ ╲
2 ┤ ╱ 2 ┤ ╱ ╲
1 ┤──╯ 1 ┤╯ ╲──
0 ┼───── 0 ┼─────────────
Jan Fev Mar Jan Jul Jan
"Erros triplicaram!" "Voltamos ao normal após pico"
4. Agregação que esconde
Média diária: Por hora:
Latência (ms) Latência (ms)
200 ┤ 2000 ┤ ╭╮
150 ┤───────── 1500 ┤ ││
100 ┤ 1000 ┤ ╱╲╲
50 ┤ 500 ┤───╯ ╲───
0 ┼───────── 0 ┼───────────
Seg Ter Qua 0h 6h 12h 18h
"Latência estável em 150ms" "Pico de 2s às 14h"
5. Escolha de métrica errada
Throughput: Latência:
(req/s) (ms)
5000 ┤ ╭─── 5000 ┤ ╱
4000 ┤ ╱ 4000 ┤ ╱
3000 ┤ ╱ 3000 ┤ ╱
2000 ┤ ╱ 2000 ┤ ╱╱
1000 ┤╱ 1000 ┤───╯
0 ┼───── 0 ┼─────────
Carga → Carga →
"Sistema escala bem!" "Sistema satura em 3000 req/s"
Gráficos Honestos
Regras básicas
1. Eixo Y começa em zero:
- Exceto quando justificado E sinalizado
2. Escalas consistentes:
- Mesma escala ao comparar períodos
3. Contexto temporal adequado:
- Período que mostra padrão completo
- Não cherry-pick início/fim
4. Agregação apropriada:
- Não esconder variância
- Mostrar distribuição quando relevante
5. Métricas relevantes:
- Mostrar o que importa para a pergunta
- Incluir métricas correlacionadas
Gráfico de latência bem feito
Elementos essenciais:
┌────────────────────────────────────────┐
│ Latência de Checkout - Últimas 24h │
│ │
│ ms │
│ 500 ┤ p99 │
│ 400 ┤ ╭╮ ╭╮ │
│ 300 ┤ ╱╲╲ ╱ ╲ p95 │
│ 200 ┤──╱ ╲──╱ ╲────── │
│ 100 ┤ p50 ───────────── │
│ 0 ┼───────────────────────────── │
│ 0h 6h 12h 18h 24h │
│ │
│ ⚠ Deploy às 14h | Pico normal: 11h-13h │
└────────────────────────────────────────┘
Inclui:
- Múltiplos percentis
- Período completo
- Eixo começando em zero
- Anotações de eventos
- Contexto (horário de pico)
Dashboard que não engana
Layout recomendado:
┌───────────────────────────────────────────┐
│ OVERVIEW - Sistema de Pedidos │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ p95 │ │ Errors │ │ Throughput│ │
│ │ 180ms │ │ 0.3% │ │ 1.2K/s │ │
│ │ ↓12% │ │ ↓50% │ │ ↑15% │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ Latência por Percentil (7 dias) │
│ [gráfico com p50, p95, p99] │
│ │
│ Distribuição de Latência (histograma) │
│ [mostra shape da distribuição] │
│ │
│ Correlação: Latência vs Throughput │
│ [scatter plot com linha de tendência] │
└───────────────────────────────────────────┘
Inclui:
- Números e tendência (Δ vs período anterior)
- Múltiplas perspectivas (tempo, distribuição, correlação)
- Comparação consistente
Erros Comuns e Correções
Comparação de barras
❌ Errado:
Barras com cores diferentes,
sem legenda, eixo truncado
✅ Correto:
Mesma escala, cores com significado,
legenda clara, eixo do zero
Gráfico de pizza
❌ Evitar para:
- Muitas fatias (>5)
- Comparações precisas
- Valores similares
✅ Usar para:
- Proporções de um todo
- Poucos segmentos
- Quando % é mais importante que valor absoluto
Linhas de tendência
❌ Errado:
Linha reta em dados não-lineares
✅ Correto:
- Escolher modelo apropriado
- Mostrar intervalo de confiança
- Não extrapolar além dos dados
Comunicando Honestamente
Para executivos
Faça:
- Simplificar sem distorcer
- Destacar o que importa para decisão
- Incluir contexto mínimo necessário
- Indicar incerteza
Não faça:
- Exagerar melhorias
- Esconder problemas
- Usar escalas enganosas
- Omitir período de comparação
Para times técnicos
Faça:
- Mostrar distribuição completa
- Incluir correlações
- Permitir drill-down
- Documentar metodologia
Não faça:
- Média sem percentis
- Agregação excessiva
- Esconder outliers
Checklist de Visualização
## Antes de publicar um gráfico
### Eixos
- [ ] Y começa em zero (ou justificado)?
- [ ] Escalas são consistentes entre gráficos?
- [ ] Labels são claros?
- [ ] Unidades estão indicadas?
### Dados
- [ ] Período é representativo?
- [ ] Agregação é apropriada?
- [ ] Outliers estão tratados corretamente?
- [ ] Amostra é suficiente?
### Contexto
- [ ] Baseline está indicado?
- [ ] Eventos relevantes anotados?
- [ ] Fonte está clara?
- [ ] Data está indicada?
### Honestidade
- [ ] A primeira impressão é correta?
- [ ] Alguém sem contexto entenderia?
- [ ] Estou mostrando a realidade?
Exemplos Reais
Caso 1: Relatório de melhoria
Versão enganosa:
"Latência reduziu 400%"
[gráfico com eixo Y truncado]
Versão honesta:
"Latência p95 reduziu de 250ms para 180ms (-28%)
após otimização de query. Baseline: última semana.
Medido em ambiente de staging com carga similar."
Caso 2: Dashboard de produção
Versão enganosa:
[Apenas média de latência]
"Sistema saudável: 100ms"
Versão honesta:
[Percentis p50/p95/p99]
"p50=80ms, p95=200ms, p99=1.2s
⚠ p99 alto indica problemas para 1% dos usuários"
Conclusão
Gráficos honestos:
- Eixos do zero - exceto quando claramente justificado
- Escalas consistentes - para comparações válidas
- Período representativo - não cherry-pick
- Agregação adequada - não esconder variância
- Contexto incluído - baselines, eventos, metodologia
Lembre-se: um gráfico que engana destrói confiança. Um gráfico honesto, mesmo mostrando problemas, constrói credibilidade.
O objetivo não é que o gráfico pareça bom. É que a realidade seja compreendida.
Este artigo faz parte da série sobre a metodologia OCTOPUS de Performance Engineering.