Give your observability context: name your front-end transactions

“Cool graph. But… what am I looking at?”

We’ve all been there. You open your observability tool, see a bunch of traces and metrics, maybe even a slow flamegraph, and yet, you’re still not sure what real-world action this data represents. Was it a page load? A user login? A failed checkout?

The truth is, raw performance data is powerful, but without context, it’s just noise.

That’s why we’re excited to introduce manual transaction naming in Blackfire’s Front-End Observability. It’s a small change with a big impact: you can now add a data-transaction-name attribute to your browser monitoring snippet and give every user action a meaningful name.

And with that, context comes into play.

From raw traces to real stories

Until now, Blackfire automatically grouped front-end requests into transactions based on routing or auto-detection. That worked great for most apps, but in some cases, it left room for ambiguity.

With manual transaction naming, you decide what matters:

<script
  async
  src="https://admin.pipeline.blackfire.io/js/probe.js"
  data-browser-key="your-key"
  data-transaction-name="checkout"
/>

That’s it. One line of code. One data-transaction-name attribute. And suddenly your performance data starts telling real, human-readable stories.

Why this matters: putting performance in context

Here’s what you unlock when you name your front-end transactions:

• Smarter debugging
  “Why is the checkout flow slow?” is much easier to answer when you can filter directly on checkout and compare across time or user segments.
  
• Full-stack correlation
  When your front-end transaction is named signup, and your back-end transaction is also named signup, Blackfire can automatically link them. That’s true full-stack profiling with no extra config.
  
• Meaningful trend analysis
  Track the performance of key user flows over time. Spot regressions not just in JS render time, but in business-critical journeys.
  
• Prioritization that aligns with product goals
  Why chase down a slow image load on a marketing page when your add_to_cart flow is bleeding users?
  
• Better conversations with non-dev stakeholders
  Your performance data now speaks the same language as your product team: “checkout,” “search,” “dashboard.” Not just URLs and trace IDs.

Observability is good. Contextual observability is better.

Blackfire has always aimed to give you the visibility you need, without the overwhelm. With this update, we’re helping you go a step further: from visibility to clarity.

You get to choose the lens. Name the transaction. Frame the data in a way that reflects your actual app, and your actual users.

Because at the end of the day, no one cares that route=/submit was slow.
They care that the signup experience was broken.

Try it today

If you already use Blackfire’s Browser Monitoring, you’re just one attribute away

Add it to your most important views. Filter your data. Correlate with the backend. And see what you’ve been missing.

Need help setting it up? Check out our docs or reach out to us on Discord (#blackfire-general-chat); we’d love to hear what stories your performance data is ready to tell.

Here’s to more meaningful insights, faster fixes, and fewer head scratches.

To better observability and beyond