Pessoal, o SDK tava verde. O TypeError chegou. A jornada, não.
Dashboard cheio. Ninguém sabia se era o clique de pagar, o cupom ou o pixel. Três stacks iguais. Três donos diferentes. A próxima pessoa abria o evento e ia pro arquivo no bundle. Conversão do checkout era OKR de produto. O Sentry não falava a língua do OKR.
O denso do +10% no checkout é o dinheiro. Este texto é o contrato que faz o Sentry servir naquele case. Sem ele, você vê erro. Não vê o funil. E o OKR fica só no backoffice, no dia seguinte.
O que você leva daqui: observabilidade é a ação do usuário no filtro, não o SDK instalado. Mesma ordem do case de conversão: sintoma, causa, o que mudou, como mediu, resultado, o que copiar.
Tabela de Conteúdo
- 1. Sintoma: o tracker gritava, o funil não
- 2. Causa: instalar não é instrumentar
- 3. O que mudou: jornada no evento, não só a stack
- 4. Como a gente mediu: o filtro da próxima pessoa
- 5. Resultado: o +10% ficou visível no mesmo funil do OKR
- 6. O que copiar no próximo alerta
1. Sintoma: o tracker gritava, o funil não
O SDK tava instalado. Volume de evento subia. Ninguém decidia.
Um TypeError em massa, sem domínio e sem a ação, só prova que o JS quebrou. Não prova se o comprador estava no pagar, no cupom ou no pixel que nem deveria derrubar o checkout. O filtro no Discover era o arquivo minificado. Não era a jornada.
Produto olhava conversão. Engenharia olhava stack. Os dois boards não se falavam. Timeout no pagar e pixel quebrado depois da venda viravam o mesmo card.
2. Causa: instalar não é instrumentar
Auto-instrumentation pega HTTP, crash, às vezes replay. Não pega “a pessoa apertou pagar e o request nem saiu”. Esse é o furo do denso: timeout no first load, catch silencioso, UI genérica, back sem request.
Catch que só faz console.error: a tela mostra “tente de novo”, o gateway nem foi chamado, o Sentry não vê. Você instalou. Não instrumentou.
Não é pitch de vendor. Grafana, Sentry, Datadog: a ferramenta é o adapter. O domínio emite o evento. Se a regra de cupom importa Sentry.captureException no meio do if, você inverteu. A regra não deveria saber o nome da ferramenta.
Form incompleto, cupom expirado, cartão recusado: a regra funcionou. Breadcrumb. Não incidente. Se misturar com gateway 500, o board grita e você trata recusa de cartão como queda de conversão. Aí o OKR de produto vira ruído.
3. O que mudou: jornada no evento, não só a stack
A gente parou de mandar stack nua. Passou a mandar a ação.
Quatro campos. Não uma taxonomia de 40 tags:
-
domain: checkout, payment, lead, pixel -
phase: a ação (coupon.apply,payment.updateCard,checkout.pay.submit) - tipo: exception vs resultado de negócio
- sem
user_idem label de métrica (explode cardinalidade)
IDs de pedido e de pessoa: log e trace. Não série do Prometheus.
Alerta de sintoma de usuário: o pagar não completa. Não cada if da regra de desconto. Replay, se existir, no caminho curto do dinheiro. Admin longo não precisa da mesma cota.
Exemplo sintético, de propósito. Dois eventos iguais na stack:
A extra.phase = checkout.pay.submit → o POST de pagar nem saiu
B extra.phase = pixel.purchase.track → o pixel quebrou depois da venda
A é receita em risco. B é ruído com a venda já feita. Sem phase, os dois viram o mesmo card. Com phase, o Sentry fala a língua do OKR: conversão do checkout.
4. Como a gente mediu: o filtro da próxima pessoa
A prova não é “temos Sentry”. É: a próxima pessoa filtra a ação do usuário antes de abrir o stacktrace.
No Discover, o recorte que importa é checkout.pay.submit com timeout, não o nome do chunk. No Datadog, se o caminho até o JS saturava. No backoffice, se vendeu. As três no mesmo OKR de produto. Lighthouse fora dessa conta: lab.
Se o alerta não cabe numa frase (“o pagar não completa”), ainda é volume. Não é funil.
5. Resultado: o +10% ficou visível no mesmo funil do OKR
No denso o mês fechou +10% de conversão. Métrica de venda no backoffice, cruzada com observabilidade, alinhada ao OKR de produto. Esse case pesou na promoção a Staff II. Não pelo SDK. Pelo funil visível e pela conversão.
Este texto é o que torna essa cruzada possível. Sem jornada no evento, o +10% existe no painel e some no Sentry. Com jornada, timeout de pagar e conversão do mês apontam pro mesmo funil. Engenharia e produto param de discutir score versus “a campanha foi ruim”.
O +10% não veio deste contrato sozinho. Veio do JS chegar a tempo. O contrato faz o timeout aparecer no mesmo dia, no recorte que o OKR entende.
6. O que copiar no próximo alerta
1. O último evento tem domain + phase, ou só a stack?
2. Dá pra nomear a ação do usuário em uma frase?
3. Exception ou resultado de negócio (cupom, recusa, form)?
4. O alerta é sintoma de usuário (pagar não completa) ou qualquer JS?
5. user_id foi pra log/trace, ou virou label de métrica?
6. Esse recorte conversa com o OKR de produto (conversão), ou só com o board de erro?
Último alerta que você abriu: consegue nomear a ação do usuário em uma frase? Sim, não, ou só o stack?
Top comments (0)