Você está na empresa há algumas semanas.

Em uma reunião, o time de marketing comemora:

“O tráfego cresceu 28% este mês.”

Mas o financeiro corta a empolgação:

“O faturamento caiu.”

E agora?

Essa é a hora em que muita gente começa a puxar dado aleatório.

Mas profissional não reage. Profissional investiga com método.

🧠 Etapa 1: Confirmar os números (sem emoção)

Antes de buscar culpado, confirme os fatos.

📌 Perguntas iniciais:

• O tráfego realmente cresceu?
• As vendas realmente caíram?
• Estamos comparando os mesmos períodos?
• O mês está fechado?

Primeiro: validar.

SELECT
DATE_TRUNC('month', DATA_PEDIDO) AS MES,
COUNT(*) AS QTD_PEDIDOS,
SUM(VALOR_TOTAL) AS FATURAMENTO
FROM pedido
GROUP BY DATE_TRUNC('month', DATA_PEDIDO)
ORDER BY MES;

👉 Aqui você quer ver:

• Tendência real
• Queda pontual
• Mudança abrupta

Sem isso, você investiga narrativa, não dado.

🧠 Etapa 2: Separar o problema em partes

Faturamento é: Quantidade × Ticket médio

Então a pergunta vira: O que mudou?

SELECT
DATE_TRUNC('month', DATA_PEDIDO) AS MES,
COUNT(*) AS QTD_PEDIDOS,
AVG(VALOR_TOTAL) AS TICKET_MEDIO,
SUM(VALOR_TOTAL) AS FATURAMENTO
FROM pedido
GROUP BY DATE_TRUNC('month', DATA_PEDIDO)
ORDER BY MES;

Possibilidades:

• Tráfego ↑ mas pedidos ↓: problema de conversão
• Pedidos ↑ mas ticket ↓: problema de preço/desconto/mix
• Ambos ↓: problema mais estrutural

🧠 Etapa 3: Ver conversão (se houver dado de visita)

Se você tiver tabela de visitas:

SELECT
DATE_TRUNC('month', v.DATA_VISITA) AS MES,
COUNT(DISTINCT v.ID_VISITA) AS VISITAS,
COUNT(DISTINCT p.ID_PEDIDO) AS PEDIDOS
FROM visita v
LEFT JOIN pedido p
ON p.ID_VISITA = v.ID_VISITA
GROUP BY DATE_TRUNC('month', v.DATA_VISITA)
ORDER BY MES;

Agora você consegue calcular mentalmente:

Conversão = PEDIDOS / VISITAS

Se tráfego subiu e conversão caiu, o problema não é aquisição.

É eficiência.

🧠 Etapa 4: Descobrir onde está a queda

Agora você começa a localizar.

🔎 Por canal

SELECT
CANAL,
COUNT(*) AS QTD_PEDIDOS,
SUM(VALOR_TOTAL) AS FATURAMENTO
FROM pedido
GROUP BY CANAL
ORDER BY FATURAMENTO DESC;

Talvez:

• tráfego orgânico ↑
• tráfego pago ↓
• canal com maior ticket perdeu força

🔎 Por produto

SELECT
ID_PRODUTO,
SUM(VALOR_ITEM) AS FATURAMENTO
FROM item_pedido
GROUP BY ID_PRODUTO
ORDER BY FATURAMENTO DESC;

Pode ser que:

• produtos de alto valor estejam vendendo menos
• o mix esteja mais barato
• descontos estejam mais agressivos

🧠 Etapa 5: Checar desconto e cancelamento

Às vezes a queda não está na venda. Está no que acontece depois.

SELECT
DATE_TRUNC('month', DATA_PEDIDO) AS MES,
AVG(VALOR_DESCONTO) AS DESCONTO_MEDIO,
SUM(CASE WHEN CANCELADO = 1 THEN 1 ELSE 0 END) AS QTD_CANCELADOS
FROM pedido
GROUP BY DATE_TRUNC('month', DATA_PEDIDO)
ORDER BY MES;

Se desconto ↑ ou cancelamento ↑

Você já tem uma hipótese forte.

⚠️ O erro que mata análise

O erro comum é tentar:

• produto
• canal
• região
• desconto
• cancelamento
• tudo ao mesmo tempo

Isso gera ruído.

Investigação profissional segue ordem:

1. Confirmar
2. Quantificar
3. Separar causa
4. Localizar

🧠 O que esse case realmente ensina

SQL aqui não é sobre sintaxe.

É sobre:

• organizar pergunta
• dividir problema
• testar hipótese
• validar resultado

Esse é o tipo de raciocínio que diferencia quem “roda query” de quem resolve problema.

🎯 Próximo passo natural

Se você quer treinar esse tipo de análise com cenários reais, não com exercício artificial,

👉 A Coleção A Arte da Query foi criada exatamente para isso.

Ela simula problemas de negócio e te força a pensar antes de escrever.

E se você quiser praticar em dados reais:

📚 Baseoteca SQL te entrega bancos prontos para análise.

Tags: Análise De Dados | Case | SQL