DEV Community

Cover image for Como o Sentry passou a mostrar o funil. A jornada antes do stacktrace
Tiago Vilas Boas (Montanha)
Tiago Vilas Boas (Montanha)

Posted on Edited on

Como o Sentry passou a mostrar o funil. A jornada antes do stacktrace

Imagine que você instalou uma câmera de segurança de última geração no caixa da sua loja física. A câmera filma com resolução 4K.

Um dia, as vendas caem pela metade. Você abre o sistema de monitoramento e vê 400 gravações de clientes saindo de mãos vazias pela porta da frente. Mas o vídeo só começa no exato segundo em que o cliente já deu as costas e foi embora.

Você não sabe se o cartão passou e foi recusado, se o leitor de código de barras quebrou, se o preço do produto estava errado ou se a pessoa só entrou para pedir uma informação.

Era exatamente assim que o Sentry funcionava no nosso checkout: ele recebia o stacktrace do erro técnico, mas era completamente cego para a jornada do usuário.

Neste artigo, vamos entender por que apenas instalar o SDK do Sentry não significa monitorar de verdade e como enriquecer eventos com contexto de funil para transformar ruído em receita protegida.


1. O Problema: Instalar Não é Instrumentar

Na maioria das empresas, o monitoramento de frontend se resume a adicionar três linhas no index.html:

import * as Sentry from "@sentry/browser";
Sentry.init({ dsn: "https://exemplo@sentry.io/123" });
Enter fullscreen mode Exit fullscreen mode

No dia seguinte, o painel do Sentry amanhece com 15.000 erros agrupados sob títulos genéricos como:

  • TypeError: Cannot read properties of undefined (reading 'split')
  • ChunkLoadError: Loading chunk 842 failed
  • NetworkError: Failed to fetch
[ O Painel de Erros Tradicional: Ruído Incompreensível ]

Painel do Sentry:
┌────────────────────────────────────────────────────────┐
│ 💥 1.200 erros em `app.min.js:142`                      │
│ 💥 800 erros em `vendor.min.js:98`                     │
│ 💥 450 erros de `NetworkError`                         │
└────────────────────────────────────────────────────────┘
          │
          ▼
Pergunta de Negócio:
"O cliente não conseguiu pagar ou foi só um pixel de marketing que falhou?"
Resposta da Engenharia:
"Não faço ideia, os dois dão o mesmo TypeError no código minificado!"
Enter fullscreen mode Exit fullscreen mode

Produto olha para a taxa de conversão caindo e entra em desespero. Engenharia olha para 15 mil erros na tela e fica paralisada. Os dois times olham para dados diferentes e ninguém resolve o problema real.


2. A Virada de Chave: Jornada no Evento (Domain e Phase)

Para que um alerta faça sentido, ele precisa responder em uma frase simples: qual etapa do funil o comprador estava tentando concluir?

Em vez de enviar apenas a pilha de chamadas (stacktrace), adicionamos duas tags obrigatórias em cada interação crítica:

                  ┌─────────────────────────────────────────┐
                  │      Ação do Usuário no Navegador       │
                  └────────────────────┬────────────────────┘
                                       │
           ┌───────────────────────────┴───────────────────────────┐
           ▼                                                       ▼
   [ Cenário A: Crítico ]                                  [ Cenário B: Ruído ]
   Cliente clicou em "Pagar"                               Pixel tentou disparar
   Tag: domain = 'checkout'                                Tag: domain = 'pixel'
   Tag: phase  = 'checkout.pay.submit'                     Tag: phase  = 'pixel.track.lead'
           │                                                       │
           ▼                                                       ▼
   [ ALERTA MÁXIMO NO TIME! ]                              [ Alerta de Baixa Prioridade ]
   Receita em risco imediato!                              A venda já foi concluída!
Enter fullscreen mode Exit fullscreen mode

Como Instrumentar no Código Real:

Sempre que o usuário inicia uma etapa sensível do funil, atualizamos o contexto do Sentry:

// No momento exato em que o usuário clica no botão de pagamento
Sentry.setTag("domain", "checkout");
Sentry.setTag("phase", "checkout.pay.submit");

// Se o usuário estava apenas aplicando um cupom de desconto
Sentry.setTag("domain", "checkout");
Sentry.setTag("phase", "checkout.coupon.apply");
Enter fullscreen mode Exit fullscreen mode

3. O Filtro que Salva o Dia no Discover

Depois de adicionar as tags de jornada, o time de engenharia nunca mais precisou abrir arquivos minificados para entender o impacto de um bug.

No Sentry Discover, montamos consultas focadas no funil de negócio:

phase:checkout.pay.submit AND (
  error.type:TimeoutError OR message:*timeout* OR mechanism:*timeout*
)
Enter fullscreen mode Exit fullscreen mode

Essa consulta simples isola exatamente os compradores que tentaram pagar e não conseguiram por travamento de rede ou timeout de script.

Se o mesmo erro de rede ocorrer em um script de banner ou pixel de tracking (phase:pixel.purchase.track), ele vai para uma fila separada de baixa prioridade, pois a compra já foi aprovada no gateway de pagamento.

O Sensor Perfeito para Agentes Autônomos de Investigação (RCA)

Quando operamos agentes de inteligência artificial para triagem de incidentes ou sustentação (RCA - Root Cause Analysis), o payload do monitoramento é o primeiro documento que o agente lê.

Se o Sentry entrega apenas o stacktrace de um código minificado em produção, o agente gasta milhares de tokens tentando deduzir o fluxo, formulando hipóteses imprecisas e muitas vezes se perdendo em bibliotecas de terceiros.

Por outro lado, quando o evento é enriquecido com domain e phase:

  • O agente sabe exatamente qual fatia de domínio inspecionar logo no primeiro prompt ("Falha na etapa de submissão do cartão no checkout").
  • O contexto é delimitado cirurgicamente aos handlers responsáveis.
  • O tempo de análise (MTTR) e os custos com tokens diminuem drasticamente.

Além disso, a higienização de dados (PII / LGPD) aplicada no cliente de monitoramento funciona como uma barreira de segurança vital: ela impede que CPFs, nomes ou tokens confidenciais de clientes vazem para o prompt dos modelos de IA durante as investigações automatizadas.


4. Cuidados Essenciais: LGPD e Cardinalidade de Métricas

Ao enriquecer eventos de monitoramento, dois erros comuns devem ser evitados rigorosamente:

O Que Fazer O Que NUNCA Fazer
Usar IDs internos ou hashes de usuário (user_id: hash_128) Enviar e-mail, CPF ou dados de cartão de crédito no Sentry
Ativar máscara automática em inputs (maskAllInputs: true) Gravar replays de tela capturando dígitos de cartão ou senhas
Usar tags fixas com poucas opções (ex: 5 phases conhecidas) Colocar IDs dinâmicos de pedidos como Tags (isso explode o banco)

Para triar e verificar anomalias em produção com agilidade, você pode rodar ferramentas locais em Go como o Downshift (harness-downshift) para classificar a severidade das consultas e scripts de análise antes de despachar investigações profundas para modelos via OpenRouter.


Referências Técnicas Canônicas

Para aprofundar na instrumentação profissional de aplicações com Sentry:


O Checklist de Instrumentação para o Próximo Deploy

Antes de considerar sua aplicação "monitorada", faça estas três perguntas no próximo incidente:

  1. O evento tem o passo exato da jornada (domain e phase)?
  2. Você consegue explicar o problema em uma frase para o seu Product Manager sem usar termos técnicos?
  3. O erro impediu o cliente de concluir a compra ou foi apenas um efeito colateral cosmético?

Se você só tem a pilha de código e não tem a jornada, você apenas instalou uma biblioteca. Quando você amarra o erro ao funil, você ganha observabilidade de verdade.

Top comments (0)