---
title: Group browser data by URLs
source: https://docs.newrelic.com/docs/browser/new-relic-browser/configuration/group-browser-metrics-urls
---

Our browser monitoring uses URL patterns for data on the [**Page views** page](https://docs.newrelic.com/docs/browser/new-relic-browser/additional-standard-features/page-views-insights-your-sites-popularity) and [**AJAX** page](https://docs.newrelic.com/docs/browser/new-relic-browser/browser-pro-features/ajax-dashboard-identifying-time-consuming-calls). 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](https://docs.newrelic.com/docs/browser/new-relic-browser/installation-configuration/monitor-or-block-specific-domains) to your allow list or deny list.

## Input for allow lists [#whitelists]

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](https://docs.newrelic.com/docs/browser/single-page-app-monitoring/use-spa-data/understand-spa-data-collection). These parameters may contain sensitive information, and in many cases they vary too extensively to create useful groupings.

## Automatic grouping behavior [#hierarchy]

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 [#adding]

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](https://docs.newrelic.com/docs/apis/nerdgraph/examples/browser-monitoring-config-nerdgraph#browser-segments), or you can use segment allow lists in the New Relic browser monitoring UI:

1.  Go to **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Browser > (select an app) > Settings > Application settings > Segment allow lists**.
2.  In **Allow listed segments**, select the plus  icon.
3.  Type the [segments](#format) you want to appear in groupings on the **Page views** and **AJAX** pages.
4.  Enter domain segments (elements of the domain between dots) or path segments (elements of the URL path between slashes).

## Create rules [#format]

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 `/users/*` and you have a path `/users/edit` that you don't see, enter `edit` in the list. 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 `www.newrelic.com` to your allow list, enter `www`, `newrelic`, and `com`.                                                                                           |
| List a path                              | Add every term for that path. For example, to see `www.domain1.com/bar/foo`,and you already see `www.domain1.com`, enter `bar` and `foo` as segments.                                                                      |

## Maintain URL allow lists [#maintaining]

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](#adding) 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](https://support.newrelic.com).

## Controller names [#controller]

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 APM events as applicable. However, this is not the primary grouping strategy for browser as a standalone service.
