Our uses URL patterns for data on the Page views page and AJAX page. Benefits of using URL patterns include:
- Present timings for page views and AJAX calls by using helpful groupings of similar pages.
- Use a format that is intuitive based on the site's URLs.
URL grouping can be done automatically based on browser's analysis of the website's URL space. This results in URL patterns such as www.foo.com/users/*/profile, which omit the varying user ID parameter and group similar "user profile" page views together.
You can create your own URL groups to capture those parts of the URL that are similar across many different individual page views, and to provide information about the code path that generated the URL's content. You can also create conditions to add specific domains to your allow list or deny list.
Input for allow lists
URL groups are created automatically when an application first reports data to New Relic. The inputs to these grouping algorithm include:
- The URLs that users access on your site
- The AJAX endpoints that your site makes calls to (whether those are your own endpoints or third-party endpoints)
When a URL is loaded or an AJAX call is recorded, the URL is first filtered by stripping any query parameters out of the URL. Hash fragments are also stripped unless you are using SPA monitoring. These parameters may contain sensitive information, and in many cases they vary too extensively to create useful groupings.
Automatic grouping behavior
After the URL has been filtered, New Relic analyzes requests and splits URLs into segments on separator characters (dots for domains, slashes for paths). This logic also preserves useful terms and uses them in the automated grouping. Domain information is separated by port number automatically, so that (for example) HTTP and HTTPS endpoints are listed separately.
Add URL groupings
You can modify how browser groups your data by adding to your application's URL allow list. Adding segments makes these terms always appear in your URL groups for new data reported to New Relic. They will never be rolled up to *.
Order is not important when listing multiple segments. However, make sure the segments you add exactly match the way the segments appear in your URLs. If a URL path segment ends in .html or .jsp, the extension must be included in the segment. Segments are case-sensitive.
To add new URL segments to your application's allow list, you can add them programmatically using GraphQL, or you can use segment allow lists in the New Relic browser monitoring UI:
- Go to one.newrelic.com > All capabilities > Browser > (select an app) > Settings > Application settings > Segment allow lists.
- In Allow listed segments, select the plus icon.
- Type the segments you want to appear in groupings on the Page views and AJAX pages.
- Enter domain segments (elements of the domain between dots) or path segments (elements of the URL path between slashes).
Create rules
Follow these guidelines for creating your URL allow list.
If you want to... | Do this... |
|---|---|
Add a segment you do not see to the list | Enter the segment. For example, if you see You cannot list numbers, GUIDs, or extremely long segments (100 or more characters). |
List a domain | Enter each segment of the domain. For example, to add |
List a path | Add every term for that path. For example, to see |
Maintain URL allow lists
Over time, the URLs or domains for your application may change. We automatically adapt your application's groupings based on these changes, but you may also want to make changes better suited to your current needs. Follow standard procedures to add or remove segments from your allow list to change the way your URLs are grouped.
The automated grouping algorithm aims to group URLs usefully, but occasionally you may see more different groupings than you expect. If you see too many URL groupings or terms that are not useful to you, or if you have trouble grouping your URLs effectively, get support at support.newrelic.com.
Controller names
Browser monitoring uses URL patterns for data grouping instead of server-side controller action names, such as ApplicationsController#show. It includes links to related backend events as applicable. However, this is not the primary grouping strategy for browser as a standalone service.