[DOCS-11406] Clean up inaccurate mentions of metrics

content/en/real_user_monitoring/_index.md

@@ -141,7 +141,7 @@ Select an application from the top navigation, or follow the setup instructions
 
 The [RUM Performance Monitoring summary][1] page provides relevant and actionable insights for both web and mobile applications. You have a tailored experience for each platform that helps you:
 
-- **Focus on key data points** by platform, such as the UI latency for web or mobile crashes
+- **Focus on key datapoints** by platform, such as the UI latency for web or mobile crashes
 - **Monitor application health** through familiar KPIs, such as Core Web Vitals for web apps or hang rate for iOS, to assess app reliability
 - **Dive into investigations directly** from interactive widgets without leaving the page
 

content/en/real_user_monitoring/browser/data_collected.md

@@ -27,9 +27,9 @@ further_reading:
 
 ## Overview
 
-The RUM Browser SDK generates events that have associated metrics and attributes. Every RUM event has all of the [default attributes](#default-attributes), for example, the URL of the page (`view.url`) and user information such as their device type (`device.type`) and their country (`geo.country`).
+The RUM Browser SDK generates events that have associated telemetry and attributes. Every RUM event has all of the [default attributes](#default-attributes), for example, the URL of the page (`view.url`) and user information such as their device type (`device.type`) and their country (`geo.country`).
 
-There are additional [metrics and attributes specific to a given event type](#event-specific-metrics-and-attributes). For example, the `view.loading_time` metric is associated with view events, and the `resource.method` attribute is associated with resource events.
+There are additional [attributes specific to a given event type](#event-specific-attributes). For example, the `view.loading_time` telemetry is associated with view events, and the `resource.method` attribute is associated with resource events.
 
 | Event Type     | Retention | Description                                                                                                                                                                                                                                                   |
 |----------------|-----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
@@ -48,11 +48,11 @@ The following diagram illustrates the RUM event hierarchy:
 
 See a complete list of [Standard Attributes][1] for RUM Browser. By default, the attributes are attached to each event type, so you can use them regardless of the RUM event type being queried.
 
-## Event-specific metrics and attributes
+## Event-specific attributes
 
-### Session metrics
+### Session attributes
 
-| Metric  | Type   | Description                |
+| Attribute  | Type   | Description                |
 |------------|--------|----------------------------|
 | `session.time_spent` | number (ns) | Duration of the user session. |
 | `session.view.count`        | number      | Count of all views collected for this session. |
@@ -83,9 +83,9 @@ See a complete list of [Standard Attributes][1] for RUM Browser. By default, the
 | `session.last_view.url_query` | object | The query string parts of the URL decomposed as query params key/value attributes. |
 | `session.last_view.url_scheme` | object | The scheme part of the URL. |
 
-### View timing metrics
+### View timing attributes
 
-**Note**: View timing metrics include time that a page is open in the background.
+**Note**: View timing telemetry includes time that a page is open in the background.
 
 | Attribute                       | Type        | Description                                                                                                                                                                                                           |
 |---------------------------------|-------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
@@ -110,16 +110,16 @@ See a complete list of [Standard Attributes][1] for RUM Browser. By default, the
 | `view.resource.count`           | number      | Count of all resources collected for this view.                                                                                                                                                                       |
 | `view.action.count`             | number      | Count of all actions collected for this view.                                                                                                                                                                         |
 
-### Resource timing metrics
+### Resource timing attributes
 
 Detailed network timing data for the loading of an application's resources are collected with the [Performance Resource Timing API][10].
 
-| Metric                              | Type           | Description                                                                                                                               |
+| Attribute                              | Type           | Description                                                                                                                               |
 |----------------------------------------|----------------|-------------------------------------------------------------------------------------------------------------------------------------------|
 | `resource.duration`            | number         | Entire time spent loading the resource.                                                                                                   |
 | `resource.size`                | number (bytes) | Resource size.                                                                                                                            |
 | `resource.connect.duration`    | number (ns)    | Time spent establishing a connection to the server (connectEnd - connectStart).                                                            |
-| `resource.ssl.duration`        | number (ns)    | Time spent for the TLS handshake. If the last request is not over HTTPS, this metric does not appear (connectEnd - secureConnectionStart). |
+| `resource.ssl.duration`        | number (ns)    | Time spent for the TLS handshake. If the last request is not over HTTPS, this attribute does not appear (connectEnd - secureConnectionStart). |
 | `resource.dns.duration`        | number (ns)    | Time spent resolving the DNS name of the last request (domainLookupEnd - domainLookupStart).                                               |
 | `resource.redirect.duration`   | number (ns)    | Time spent on subsequent HTTP requests (redirectEnd - redirectStart).                                                                      |
 | `resource.first_byte.duration` | number (ns)    | Time spent waiting for the first byte of response to be received (responseStart - RequestStart).                                           |
@@ -141,9 +141,9 @@ Detailed network timing data for the loading of an application's resources are c
 | `resource.provider.domain` | string | The resource provider domain.                                                                        |
 | `resource.provider.type`   | string | The resource provider type (for example, `first-party`, `cdn`, `ad`, or `analytics`).                |
 
-### Long task timing metrics
+### Long task timing attributes
 
-| Metric  | Type   | Description                |
+| Attribute  | Type   | Description                |
 |------------|--------|----------------------------|
 | `long_task.duration` | number | Duration of the long task. |
 
@@ -164,9 +164,9 @@ Source errors include code-level information about the error. For more informati
 |-----------------|--------|-------------------------------------------------------------------|
 | `error.type`    | string | The error type (or error code in some cases).                   |
 
-### Action timing metrics
+### Action timing attributes
 
-| Metric    | Type   | Description              |
+| Attribute    | Type   | Description              |
 |--------------|--------|--------------------------|
 | `action.loading_time` | number (ns) | The loading time of the action. See how it is calculated in the [Tracking User Actions documentation][13]. |
 | `action.long_task.count`        | number      | Count of all long tasks collected for this action. |
@@ -218,5 +218,5 @@ Source errors include code-level information about the error. For more informati
 [10]: https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming
 [11]: /real_user_monitoring/browser/collecting_browser_errors#error-sources
 [12]: https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming
-[13]: /real_user_monitoring/browser/tracking_user_actions/?tab=npm#action-timing-metrics
+[13]: /real_user_monitoring/browser/tracking_user_actions/?tab=npm#action-timing-telemetry
 [14]: /real_user_monitoring/browser/tracking_user_actions/?tab=npm#custom-actions

content/en/real_user_monitoring/browser/frustration_signals.md

@@ -65,7 +65,7 @@ Frustration signals require actions. Enabling `trackFrustrations` automatically
 
 ## Usage
 
-Frustration signals appear as high-level data points representing sources of user frustration on the [**RUM Applications** page][1]. To display a list of frustration counts in the [RUM Explorer][2], click the **Options** button and add a column for `@session.frustration.count`.
+Frustration signals appear as high-level datapoints representing sources of user frustration on the [**RUM Applications** page][1]. To display a list of frustration counts in the [RUM Explorer][2], click the **Options** button and add a column for `@session.frustration.count`.
 
 ### Application list
 

content/en/real_user_monitoring/browser/monitoring_page_performance.md

@@ -23,45 +23,45 @@ further_reading:
 
 ## Overview
 
-RUM view events collect extensive performance metrics for every pageview. Monitor your application's pageviews and explore performance metrics in dashboards and the RUM Explorer.
+RUM view events collect extensive performance telemetry for every pageview. Monitor your application's pageviews and explore performance telemetry in dashboards and the RUM Explorer.
 
 {{< img src="real_user_monitoring/browser/waterfall-4.png" alt="A waterfall graph on the Performance tab of a RUM view in the RUM Explorer" style="width:100%;" >}}
 
-You can access performance metrics for your views in:
+You can access performance telemetry for your views in:
 
-- Out-of-the-box [RUM dashboards][1], which provide a high-level view of your application's performance. For example, you can filter on [default attributes][2] collected by RUM to surface issues impacting a subset of users in the [Performance Overview dashboard][3]. You can also clone this dashboard, customize it to your needs, and use any [RUM performance metrics](#all-performance-metrics) in the dashboard's query.
+- Out-of-the-box [RUM dashboards][1], which provide a high-level view of your application's performance. For example, you can filter on [default attributes][2] collected by RUM to surface issues impacting a subset of users in the [Performance Overview dashboard][3]. You can also clone this dashboard, customize it to your needs, and use any [RUM performance telemetry](#all-performance-telemetry) in the dashboard's query.
 - A performance waterfall, accessible for every RUM view event in the [RUM Explorer][4], which enables you to troubleshoot the performance of a specific page view. It displays how your website assets and resources, long tasks, and frontend errors affect the page-level performance for your end users.
 
 ## Event timings and core web vitals
 
 <div class="alert alert-warning">
-  Datadog's Core Web Vitals metrics are available from the <a href="https://github.com/DataDog/browser-sdk">@datadog/browser-rum</a> package v2.2.0+.
+  Datadog's Core Web Vitals telemetry is available from the <a href="https://github.com/DataDog/browser-sdk">@datadog/browser-rum</a> package v2.2.0+.
 </div>
 
-[Google's Core Web Vitals][5] are a set of three metrics designed to monitor a site's user experience. These metrics focus on giving you a view of load performance, interactivity, and visual stability. Each metric comes with guidance on the range of values that translate to good user experience. Datadog recommends monitoring the 75th percentile for these metrics.
+[Google's Core Web Vitals][5] are a set of three KPIs designed to monitor a site's user experience. These KPIs focus on giving you a view of load performance, interactivity, and visual stability. Each KPI comes with guidance on the range of values that translate to good user experience. Datadog recommends monitoring the 75th percentile for these KPIs.
 
 {{< img src="real_user_monitoring/browser/core-web-vitals-1.png" alt="Core Web Vitals summary visualization" >}}
 
 - Interaction to Next Paint and Largest Contentful Paint are not collected for pages opened in the background (for example, in a new tab or a window without focus).
-- Metrics collected from your real users' pageviews may differ from those calculated for pages loaded in a fixed, controlled environment such as a [Synthetic browser test][6]. Synthetic Monitoring displays Largest Contentful Paint and Cumulative Layout Shift as lab metrics, not real metrics.
+- Telemetry collected from your real users' pageviews may differ from those calculated for pages loaded in a fixed, controlled environment such as a [Synthetic browser test][6]. Synthetic Monitoring displays Largest Contentful Paint and Cumulative Layout Shift as lab telemetry, not real telemetry.
 
-| Metric                   | Focus            | Description                                                                                           | Target value |
+| Datapoint                   | Focus            | Description                                                                                           | Target value |
 |--------------------------|------------------|-------------------------------------------------------------------------------------------------------|--------------|
 | [Largest Contentful Paint][7] | Load performance | Moment in the page load timeline in which the largest DOM object in the viewport (as in, visible on screen) is rendered.         | <2.5s       |
 | [Interaction To Next Paint][19]| Interactivity    | Longest duration between a user's interaction with the page and the next paint. Requires RUM SDK v5.1.0. | <200ms        |
 | [Cumulative Layout Shift][9]  | Visual stability | Quantifies unexpected page movement due to dynamically loaded content (for example, third-party ads) where 0 means that no shifts are happening. | <0.1        |
 
 ### Core web vitals target elements
 
-Identifying what element triggered a high Core Web Vitals metric is the first step in understanding the root cause and being able to improve performance.
+Identifying what element triggered a high Core Web Vitals KPI is the first step in understanding the root cause and being able to improve performance.
 RUM reports the element that is associated with each Core Web Vital instance:
 
 - For Largest Contentful Paint, RUM reports the CSS Selector of the element corresponding to the largest contentful paint.
 - For Interaction to Next Paint, RUM reports the CSS selector of the element associated with the longest interaction to the next paint.
 - For First Input Delay, RUM reports the CSS selector of the first element the user interacted with.
 - For Cumulative Layout Shift, RUM reports the CSS selector of the most shifted element contributing to the CLS.
 
-## All performance metrics
+## All performance telemetry
 
 | Attribute                       | Type        | Description                                                                                                                                                                                                                      |
 |---------------------------------|-------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
@@ -90,7 +90,7 @@ RUM reports the element that is associated with each Core Web Vital instance:
 
 For single page applications (SPAs), the RUM Browser SDK differentiates between `initial_load` and `route_change` navigation with the `loading_type` attribute. If an interaction on your web page leads to a different URL without a full refresh of the page, the RUM SDK starts a new view event with `loading_type:route_change`. RUM tracks URL changes using the [History API][16].
 
-Datadog provides a unique performance metric, `loading_time`, which calculates the time needed for a page to load. This metric works for both `initial_load` and `route_change` navigation.
+Datadog provides a unique KPI, `loading_time`, which calculates the time needed for a page to load. This KPI works for both `initial_load` and `route_change` navigation.
 
 ### How loading time is calculated
 
@@ -144,7 +144,7 @@ window.DD_RUM.init({
 
 The RUM SDK automatically monitors frameworks that rely on hash (`#`) navigation. The SDK watches for `HashChangeEvent` and issues a new view. Events coming from an HTML anchor tag which do not affect the current view context are ignored.
 
-## Create custom performance metrics
+## Create custom performance telemetry
 
 ### Measure component-level performance with custom vitals
 

content/en/real_user_monitoring/browser/monitoring_resource_performance.md

@@ -31,7 +31,7 @@ See [Connect RUM and Traces][2] for information about setting up this feature.
 
 {{< img src="real_user_monitoring/browser/resource_performance_graph.png" alt="APM Trace information for a RUM Resource" >}}
 
-## Resource timing and metrics
+## Resource attributes
 
 Detailed network timing data for resources is collected from the Fetch and XHR native browser methods and from the [Performance Resource Timing API][3].
 
@@ -40,7 +40,7 @@ Detailed network timing data for resources is collected from the Fetch and XHR n
 | `resource.duration`            | number         | Entire time spent loading the resource.                                                                                                    |
 | `resource.size`                | number (bytes) | Resource size.                                                                                                                             |
 | `resource.connect.duration`    | number (ns)    | Time spent establishing a connection to the server (connectEnd - connectStart).                                                            |
-| `resource.ssl.duration`        | number (ns)    | Time spent for the TLS handshake. If the last request is not over HTTPS, this metric does not appear (connectEnd - secureConnectionStart). |
+| `resource.ssl.duration`        | number (ns)    | Time spent for the TLS handshake. If the last request is not over HTTPS, this attribute does not appear (connectEnd - secureConnectionStart). |
 | `resource.dns.duration`        | number (ns)    | Time spent resolving the DNS name of the last request (domainLookupEnd - domainLookupStart).                                               |
 | `resource.redirect.duration`   | number (ns)    | Time spent on subsequent HTTP requests (redirectEnd - redirectStart).                                                                      |
 | `resource.first_byte.duration` | number (ns)    | Time spent waiting for the first byte of response to be received (responseStart - RequestStart).                                           |