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

Sentry showed the funnel with a new approach. Previously, the SDK was green but the TypeError arrived without clear information. The dashboard showed a full funnel, but no one knew if it was a payment click, a coupon, or a pixel. Three identical stacks and three different owners. The next person opened the event and went to the file in the bundle.

Conversion at checkout was an OKR of the product. Sentry didn't speak the language of the OKR. The density of a +10% increase at checkout was the money. This text is the contract that makes Sentry serve in that case. Without it, you see only errors. You don't see the funnel, and the OKR is only in the back office the next day.

1. Symptoms: The tracker shouted, the funnel didn't work. The SDK was installed, event volume increased, and no one decided. A mass TypeError with no domain and no action proved only that JavaScript broke, not if the buyer was on pay, coupon, or pixel. The Discover filter was the minified file, not the journey. Product looked at conversion, engineering at stack. Two boards didn't speak to each other. Timeouts on payment and pixel failure after the sale turned into the same card.

2. Cause: Installing isn't instrumenting. Auto-instrumentation gets HTTP, crashes, and sometimes replay. It doesn't get "the person clicked pay and the request didn't leave." That's the hole in the density: timeout at first load, silent catch, generic UI, no request in the back office. Catch only does console.error: the screen says "try again," the gateway hasn't been called, Sentry doesn't see it.

You installed it but didn't instrument it. It's not a vendor pitch. Grafana, Sentry, Datadog: the tool is the adapter. The domain emits the event. If the coupon rule imports Sentry.captureException in the middle of an if, you've inverted it. The rule shouldn't know the tool's name. A missing form, expired coupon, or rejected card: the rule worked.

Breadcrumb. No incident. Mixing with 500 errors makes the board yell, and you treat card rejection as a conversion drop. Then the product OKR becomes noise.

3. What changed: The event journey, not just the stack. They stopped sending stacks alone and started sending actions. Four fields instead of a taxonomy of 40 tags: domain (checkout, payment, lead, pixel), phase (coupon.apply, payment.updateCard, checkout.pay.submit), type (exception vs business result), and IDs for the request and person (no Prometheus series).

No long admin needs the same quota. Synthetic example: two events with the same stack. Extra.phase = checkout.pay.submit → the payment POST didn't leave. B extra.phase = pixel.purchase.track → the pixel broke after the sale. Both look like the same card without phase. With phase, Sentry speaks the language of the OKR: checkout conversion.

4. How we measured: The proof isn't "we have Sentry." It's: the next person filters the user's action before opening the stacktrace. In Discover, the important cut is checkout.pay.submit with timeout, not the chunk name. In Datadog, if the path to JS saturates. In the back office, if a sale occurred. All three are part of the product OKR. Lighthouse isn't enough: it's a lab. If the alert doesn't fit in a sentence ("payment didn't complete"), it's volume, not funnel.

5. Result: The +10% conversion became visible on the same funnel as the OKR. The month ended with a 10% increase in sales. The metric in the back office crossed with observability, aligned with the product OKR. This case helped get promoted to Staff II, not because of the SDK, but because of the visible funnel and conversion. This text makes the connection possible.

Without event journey, the +10% exists in the dashboard and disappears in Sentry. With journey, timeout and checkout conversion point to the same funnel. Engineering and product stop arguing about score versus "the campaign was bad." The +10% didn't come alone. It came with JavaScript arriving on time. The contract made the timeout visible on the same day, in the cut the OKR understands.

6. What to copy in the next alert: Is the last event domain + phase, or just the stack? Can we name the user action in a sentence? Is it an exception or business result (coupon, rejection, form)? Is the alert a user symptom (payment didn't complete) or any JS? Was user_id in the log/trace or turned into a metric label? Does this cut talk to the product OKR (conversion) or just the error board?