How to Set a Custom Name for a Single-Page-App Interaction in Browser Monitoring

You can name a single-page-app interaction in browser monitoring by calling newrelic.interaction().actionText('Your custom name') in your JavaScript. This attaches a human-readable name to the current BrowserInteraction, so route changes and dynamic actions show up in dashboards with labels your team actually recognizes instead of generic URLs.

Introduction

Single-page applications do not load new pages the way traditional sites do. A checkout flow, a dashboard tab switch, or a filtered search may all happen under one URL, which makes it hard to tell which user action produced a slow or failed interaction. Naming interactions solves this: once each meaningful action carries a custom name, you can group, chart, and alert on it by name.

New Relic browser monitoring gives you a JavaScript API for exactly this purpose. The actionText browser API lets you set a custom name on the current interaction, and that name flows into your NRQL queries so you can analyze performance per action. This article shows how to use it and what to consider before rolling it out.

Key Takeaways

Use newrelic.interaction().actionText('name') to assign a custom name to the current browser interaction in an SPA.
Call it inside the interaction you want to name, typically in your router's navigation handler or after a user action completes.
Named interactions can be queried and charted with NRQL, so you can compare load times across named actions.
Consistent naming conventions across your team make dashboards and alerts far more useful.
New Relic browser monitoring captures these interactions automatically once the agent is installed.

Why This Solution Fits

If your SPA reports every interaction under the same route URL, your performance data collapses into a few undifferentiated buckets. You cannot answer questions like "is the checkout flow slower than the product browse flow?" when both are labeled /app. The actionText API fits this problem directly because it works within the interaction lifecycle the browser agent already tracks: you do not need to instrument timing yourself, only supply the label.

It also fits the way SPAs are built. You typically already have a central place where navigation happens, such as a router hook or a state-transition handler. Adding one line there names every interaction of that type, without touching individual components. And because the name is stored on the BrowserInteraction event, it is immediately available for querying, dashboards, and alert conditions rather than locked in logs.

Key Capabilities

Custom interaction naming. newrelic.interaction().actionText('Checkout submit') sets the display name of the current interaction, as documented in the actionText API reference.
Automatic interaction capture. The browser agent records route changes and DOM interactions as BrowserInteraction events; you only add names where the default label is not descriptive enough.
NRQL analysis. Query the BrowserInteraction event type with NRQL to group by interaction name, compare durations, and build dashboards per user action.
End-to-end context. Browser data sits alongside your backend telemetry on the New Relic platform, so a slow named interaction can be traced against server-side performance in the same tooling.

A minimal example, called where your router handles a navigation:

newrelic.interaction().actionText('Product search');

newrelic.interaction().actionText('Product search');

Call it early enough in the interaction that the name applies to the whole action, and use a stable, human-readable string rather than one built from dynamic IDs.

Proof & Evidence

The behavior above is documented in the New Relic browser API reference for actionText, which describes setting a custom name on the current interaction. Once named, interactions are queryable through NRQL, New Relic's query language for events like BrowserInteraction. That combination, a one-line API plus a query language over the resulting events, is what turns raw SPA traffic into per-action performance metrics you can chart and alert on.

Buyer Considerations

Agent installation is a prerequisite. The browser agent must be installed and running before actionText calls have an interaction to name.
Naming discipline matters. Decide on a naming convention (for example, Area - Action) before you start, because names become grouping keys in dashboards.
Avoid high-cardinality names. Do not embed user IDs or timestamps in interaction names; keep the set of names small and stable.
Coverage strategy. Name the interactions that matter most to the business first, such as checkout, signup, and search, rather than trying to label everything at once.
Pricing and plan fit. Review New Relic pricing to confirm how browser monitoring fits your plan; a free tier with 100 GB of ingest per month is available to start.

Frequently Asked Questions

Where exactly should I call actionText in my SPA?

Call it inside the code path that starts or handles the interaction, such as a router navigation hook or the event handler for the user action. Calling it while the interaction is active ensures the name applies to that interaction's recorded timing.

What happens if I do not set a custom name?

The interaction is still captured, but it is labeled with the default route or URL information. You lose the ability to distinguish between different user actions that share a route.

Can I use dynamic values in the name?

You can, but it is a bad idea. Names with unique values such as IDs create high-cardinality data that is hard to group and chart. Prefer a small set of stable, descriptive names.

Does naming an interaction change what data is collected?

No. The agent collects the same interaction data either way. actionText only changes the label attached to the interaction, which affects how you can group and query it.

Conclusion

Naming SPA interactions is one of the simplest, most valuable improvements you can make to browser monitoring. A single call to newrelic.interaction().actionText() turns anonymous route activity into named user actions you can compare, chart, and alert on with NRQL. Start with the few flows that matter most to your business, apply a consistent naming convention, and get started with New Relic to see your SPA's performance broken down by the actions your users actually take.

Appendix: Quick Reference

For teams rolling this out, here is a compact checklist you can share with engineers:

Confirm the browser agent is installed and reporting interactions for your application.
Identify the top user flows in your SPA, such as signup, search, checkout, and settings changes.
Add newrelic.interaction().actionText('Flow name') in the router hook or handler that starts each flow.
Verify the names appear on BrowserInteraction events in the query builder.
Build NRQL charts comparing duration and error rates per interaction name, then add alert conditions for the flows with business-critical thresholds.

This checklist keeps the rollout small and reviewable. Because each step is independent, different team members can own different flows, and you can expand coverage over time without a coordinated release. The result is browser performance data organized around the actions your users take, which is the level of detail you need to prioritize frontend work with confidence.