---
title: Define Services And Track UI Components In Your Browser Application
description: >-
  Organize large browser applications by defining services and tracking UI
  components for better team ownership and troubleshooting.
breadcrumbs: >-
  Docs > RUM & Session Replay > Real User Monitoring & Session Replay Guides >
  Define Services And Track UI Components In Your Browser Application
---

# Define Services And Track UI Components In Your Browser Application

## Overview{% #overview %}

RUM captures events from your browser applications and lets you explore them to troubleshoot slow pages and code errors, or to analyze application usage. All captured events are available in [RUM Explorer](https://docs.datadoghq.com/real_user_monitoring/explorer/) for querying, dashboarding, and alerting.

If your browser application is large, it's likely been built by multiple web development teams. Each team has an area of ownership that they focus on when troubleshooting errors, slowness, or analyzing usage.

This guide describes how to define an application in RUM. In addition, it covers common use cases in large applications where web development teams may require visibility into the health and usage of their area of ownership.

## Create a RUM application{% #create-a-rum-application %}

The first step to tracking and analyzing your browser application is to [create a RUM application](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/setup/). A RUM application maps a browser application available at a given domain that renders the experience for what customers would perceive as a website.

## Track pages in your browser application{% #track-pages-in-your-browser-application %}

Whether your browser application is a single page application or is one that uses server-side rendering, the Browser RUM SDK automatically tracks route changes and creates a view event for every route change.

- A view has a **URL** available at `@view.url`, such as `https://www.yourwebsite.com/about`.
- A view has a **path** available at `@view.url_path`, such as `/about`.

If, for example, automatically capturing pageviews by route change does not provide enough visibility, you can specify a different name for your pages. To do this, you can [track views manually](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/advanced_configuration/?tab=npm#override-default-rum-view-names) and assign them each a name available at `@view.name`, such as "About Us".

## Track timings during the rendering lifecycle of your pages{% #track-timings-during-the-rendering-lifecycle-of-your-pages %}

The Browser SDK automatically tracks a set of industry-standard timings, Core Web Vitals, page loading times [and more](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/monitoring_page_performance/#all-performance-metrics).

In addition, you can track the time it takes for a specific item on the page to render, such as an image or a component. You can track more timings by capturing them in code, then pasting the values in your view events. For details on how to do this, see the documentation on [adding your own performance timing](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/monitoring_page_performance/#add-your-own-performance-timing).

Once timings are captured, they are available like any auto-collected timing. You can use timings to do the following:

- Analyze the distribution of the time across versions of the code in the RUM Explorer
- Troubleshoot possible high values in the [view waterfall](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/monitoring_page_performance/#overview)

## Track components in web pages{% #track-components-in-web-pages %}

If your browser application uses UI components that are present across multiple pages in one application and/or across multiple applications, you can use custom instrumentation to track the usage and rendering time of these components across pages.

[Generate a custom vital](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/monitoring_page_performance/#measure-component-level-performance-with-custom-vitals) to track the lifecycle of components across pages. Let's imagine the `/myorders` page and the `/search` page both use the search box component below.

{% image
   source="https://datadog-docs.imgix.net/images/real_user_monitoring/guide/define-applications-services-components-rum/rum-guide-autofill.6290583812ab4c6d3b9daf17565cf819.jpg?auto=format"
   alt="Generate a custom vital to track the lifecycle of components across pages" /%}

You can track the following milestones in the lifecycle of the search component by sending a custom vital every time:

- `search_component_render`: The search component renders
- `search_component_input`: The search component gets input from the user keyboard
- `search_component_suggestions_display`: The search component displays suggestions

The custom vital then automatically carries attributes for:

- The RUM application it was used in
- `@view`: The page it was rendered in
- `@geo`: Geolocation information (if enabled)
- `@session`: The session identifier of the user

For example, with custom instrumentation, the custom vital can be assigned attributes for:

- The team it belongs to
- The time it took to render
- Additional context like suggested items

```javascript
window.DD_RUM.startDurationVital('search_component_render', {
    context: {
        'team': 'Team A',
        'suggested_items': ['tomato', 'strawberries']
    }
})
// ... component renders ...
window.DD_RUM.stopDurationVital('search_component_render')
```

The time it took to render is automatically calculated and available at `@vital.duration`.

From the RUM Explorer, you can then analyze:

- The page where a component is used the most
- The browser application where a component is used the most
- The P75 percentile for the time for the component to fully render

## Track team ownership{% #track-team-ownership %}

You can use [view-based ownership](https://docs.datadoghq.com/real_user_monitoring/ownership_of_views/) to automatically assign teams to RUM views based on service names, enabling teams to filter and monitor their specific areas of responsibility directly in the RUM Applications Overview page.

### Teams own a set of pages{% #teams-own-a-set-of-pages %}

Imagine a web development team owns a set of pages like the example below.

{% image
   source="https://datadog-docs.imgix.net/images/real_user_monitoring/guide/define-applications-services-components-rum/rum-guide-track-team-ownership-2.1fb9410ac018ed5dc3e3527aba03c232.png?auto=format"
   alt="Examples of sets of pages a web development could own" /%}

Inside your RUM application, create services for each set of pages owned by a team by doing the following:

1. Turn on manual view tracking by setting the configuration option `trackViewsManually` to `true`.
1. For each page of your website, assign a view name and a service following [the instructions for overriding default RUM view names](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/advanced_configuration/?tab=npm#override-default-rum-view-names).
   - `"purchase"` service for the pages available at `/checkout`, `/payment`, `/confirmOrder`.
   - `"catalog"` service for the pages available at `/beds`, `/chairs/123`, `/search`.
1. [Upload a source map for each service](https://docs.datadoghq.com/real_user_monitoring/guide/upload-javascript-source-maps/?tabs=webpackjs#upload-your-source-maps) to view unminified stack traces in Error Tracking.

Get insights into the performance or the adoption of a given team's scope by using the `service` attribute in RUM:

1. From the RUM Application Overview page, narrow down all graphs by `service` to get a holistic view for a team's scope
1. Any query done in the RUM Explorer can use the `service` attribute to filter:
   - Errors by service
   - Pageviews by service

{% image
   source="https://datadog-docs.imgix.net/images/real_user_monitoring/guide/define-applications-services-components-rum/rum-guide-rum-applications-overview-page-5.fcdc778f7745540b5f7e5b9f9138186e.png?auto=format"
   alt="Search query for actions grouped by user name on Shopist's Cart page" /%}

### Teams own UI components{% #teams-own-ui-components %}

{% image
   source="https://datadog-docs.imgix.net/images/real_user_monitoring/guide/define-applications-services-components-rum/rum-guide-team-owns-ui-components-2.474176e6659cc38ab08a052520119274.png?auto=format"
   alt="Components can be tracked using custom vitals" /%}

Components are tracked using custom vitals mentioned above:

1. Add a team attribute inside the custom vital definition.
1. Track the loading time and other timings during the component's lifecycle as attributes in the custom vitals.

## Further reading{% #further-reading %}

- [RUM Browser Monitoring](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/)