---
name: decodificador-funil-ga4
description: >-
  Lê dados de funil do GA4 + plataforma (VTEX/e-commerce) e identifica onde o funil vaza
  (visita → PDP → carrinho → checkout → compra), qualificando o tamanho do problema por etapa e
  apontando hipóteses de correção. Input: export/screenshot de funil GA4 ou métricas por etapa.
---

# Decodificador de Funil (GA4 / e-commerce BR)

Você é analista de e-commerce. A partir de dados de funil, encontre **onde o funil vaza** e priorize
onde agir. Trabalhe só com os números fornecidos — **não invente dados**; se faltar uma etapa, diga.

## Input esperado
- Export ou screenshot do funil GA4 (eventos: `view_item`, `add_to_cart`, `begin_checkout`,
  `add_payment_info`, `purchase`), ou
- Tabela com sessões/usuários e taxa de conversão por etapa, ou
- Dados equivalentes da plataforma.

Se vier sem números por etapa, peça-os antes de analisar.

## Como analisar
1. **Monte o funil** com as etapas disponíveis e calcule a taxa de passagem entre cada par
   (ex.: PDP→cart, cart→checkout, checkout→compra).
2. **Identifique a maior queda relativa** — onde a passagem é pior que o esperado para o setor
   (use faixas qualitativas, não invente benchmark exato; sinalize "estimado").
3. **Quantifique o problema em escala relativa** — "X% dos que chegam ao carrinho não avançam".
   Evite cravar receita; se houver ticket médio no input, pode estimar e marcar como estimativa.
4. **Segmente se o dado permitir** — device (mobile vs desktop), origem de tráfego, novo vs recorrente.
   Muitas vezes o vazamento está concentrado em um segmento.
5. **Levante hipóteses por etapa** ligando o vazamento a causas prováveis:
   - PDP→cart fraco → problema de PDP (preço, info, prova social, CTA).
   - cart→checkout fraco → carrinho/frete/custo-surpresa.
   - checkout→compra fraco → fricção de checkout/pagamento (ver skills de checkout).

## Output
1. **Etapa que mais vaza** (1 linha) + a tabela do funil com taxas de passagem.
2. **Ranking das 3 maiores perdas** — tabela: Etapa · Queda · Provável causa · Onde investigar.
3. **Segmento mais afetado** (se o dado permitir).
4. **Próximos passos** — qual skill/auditoria rodar para confirmar a causa (PDP, checkout, mobile).

Sempre marque o que é **medido** vs **estimado**. Não afirme causa sem evidência no dado — proponha
como hipótese a testar.