# Prioritize Metrics

## Overview

Metrics are the measurements we collect from the billions of daily datapoints we gather through our synthetic tests, and which we use to evaluate provider performance for Provider Intelligence.

A select few of these metrics (latency, loss, jitter, and (when applications are selected) Time to First Byte (TTFB)) are chosen to calculate the [overall score](https://docs.thousandeyes.com/product-documentation/internet-insights/provider-intelligence/scoring-methodologies/overall-scoring) of a provider because these metrics best represent provider reliability and user experience. We allow you to prioritize these “evaluation” metrics to weight your analysis towards the performance dimensions that matter most for your business.

We also collect 19 other metrics that do not affect the overall score of a provider, but which you can view to better inform and refine your provider analysis.

## Metrics Used for Prioritization

A provider’s overall score calculation includes the weighted scores of four core metrics, which we call the *evaluation* metrics:

### Latency

* Time for a packet to travel from source to destination and back (round-trip time, RTT). Measured in milliseconds (ms) where < 20 ms is considered excellent and > 100 ms is considered poor.
* Latency directly affects how responsive applications feel. High latency makes web pages load slowly, video calls appear jerky, and database queries take longer to complete.

### Loss

* Percentage of packets that fail to reach their destination (packet loss). Measured as a percentage, where < 0.1% is considered excellent and > 3% is considered poor.
* Packet loss forces retransmissions, which slows down TCP connections and causes artifacts in voice and video calls. Even small amounts of loss can significantly impact user experience.

### Jitter

* Variability in latency over time (variance in RTT). Measured in milliseconds (ms) where < 5 ms is considered excellent and > 50 ms is considered poor.
* High jitter causes inconsistent user experience and is particularly problematic for voice and video conferencing, where timing consistency is critical. Applications might sound choppy or video might stutter.

### Time to First Byte (TTFB)

* Only visible when applications are selected as destinations. While not solely a “network wire” metric, it is still useful because it highlights cross-network deviation for real applications you care about, even when that deviation is partly or fully driven by app, origin, or CDN behavior rather than the access network.
* Time from sending the HTTP request to the first byte of the response (ms). Measured in milliseconds (ms) where < 100 ms is considered excellent and > 500 ms is considered poor.
* Strong TTFB usually feels “snappier” for web/app interactions at the measured URL. Includes DNS resolution, connection establishment, SSL/TLS handshake, request transmission, and server processing until the first byte arrives. (Verify vs product docs.)

By default, the evaluation metrics are prioritized (weighted) in the order listed here. This reflects common networking best practices, but you can reorder based on your specific needs.

### Performance Metric Thresholds Summary

| Metric  | Excellent | Good       | Acceptable | Poor     |
| ------- | --------- | ---------- | ---------- | -------- |
| Latency | < 20 ms   | 20-50 ms   | 50-100 ms  | > 100 ms |
| Loss    | < 0.1%    | 0.1-0.5%   | 0.5-1%     | > 1%     |
| Jitter  | < 5 ms    | 5-15 ms    | 15-30 ms   | > 30 ms  |
| TTFB    | < 100 ms  | 100-200 ms | 200-500 ms | > 500 ms |

### Key Considerations

* **Reordering can change scores**: Reordering your metric priorities can change which providers score highest.
* **All metrics are still visible**: Even low-priority evaluation metrics are shown in your results; they just have less influence on the overall score.

## Understanding the Weights

Provider Intelligence uses a linear weighting system that changes depending on how many metrics you prioritize:

**4 Metrics, including TTFB**

| Priority Position | Weight |
| ----------------- | ------ |
| 1st (highest)     | 40%    |
| 2nd               | 30%    |
| 3rd               | 20%    |
| 4th               | 10%    |

**3 Metrics, excluding TTFB**

| Priority Position | Weight |
| ----------------- | ------ |
| 1st (highest)     | 50%    |
| 2nd               | 33.3%  |
| 3rd               | 16.7%  |

See [Overall Scoring](https://docs.thousandeyes.com/product-documentation/internet-insights/provider-intelligence/scoring-methodologies/overall-scoring) to understand the overall score calculation and how metric prioritization influences the overall score.

### Example Weight Prioritizations

* **Call center**: Prioritize Jitter → Loss → Latency → TTFB (voice quality is critical).
* **Trading floor**: Prioritize Latency → Loss → Jitter → TTFB (speed is everything).
* **Branch office**: Prioritize Latency → TTFB → Loss → Jitter (reliability and general productivity).
* **SaaS provider**: Prioritize TTFB → Latency → Loss → Jitter (user experience for your application).

## How to Configure Metric Priorities

![Evaluation metrics section with drag-and-drop ordering](/files/qlBOIgooJ3OjrNvfSfsO)

1. In the **Rank Evaluation Metrics** section, click and drag metrics to reorder them.
2. The metric at the top receives the highest weight in scoring; the metric at the bottom receives the lowest weight.

## Additional Metrics

Provider Intelligence collects and can display many more metrics than the ones used for score evaluation so you get a broader picture of performance measures that might matter to you and your users.

### Outages

* The number of provider network outages detected by Internet Insights during your selected time period, where connectivity from the provider was unavailable. Measured by count of distinct outage events.
* Even brief outages can disrupt critical business operations, cause transaction failures, and impact user experience.
* Outages are displayed in the table by default.

#### Outage Data Collection

* Outages are detected at 5-minute intervals.
* Each continuous outage period counts as one outage, regardless of duration.
* Data comes from Internet Insights' network outage detection system.
* Outage counts don't change with percentile selection (they're event counts, not performance measurements).

### Total Unique AS Paths

* The number of distinct Autonomous System (AS) paths observed from selected user locations to specific applications and/or cloud regions over your chosen time period. Each unique AS path reflects a different route that traffic can take between the source and destination.
* Helps users evaluate provider network path diversity (higher numbers) and predictability (lower numbers), which can impact reliability and performance.
* Total unique AS paths are displayed in the table by default, but are not available in the [Time Series](https://docs.thousandeyes.com/product-documentation/internet-insights/provider-intelligence/analyze-time-series) tool.

### Application Metrics

When you select one or more applications as destinations, Provider Intelligence provides metrics in addition to TTFB that break down application performance into component parts.

* Application metrics are not visible by default. To view these metrics in your results table, see [Configuring Visible Columns](https://docs.thousandeyes.com/product-documentation/internet-insights/provider-intelligence/view-results/results-overview#configuring-visible-columns).
* View the raw measurements for each metric when you select a [single-destination view](https://docs.thousandeyes.com/product-documentation/internet-insights/provider-intelligence/view-results/destination-views#single-destination-view).
* All application performance metrics are selectable in the [Time Series view](https://docs.thousandeyes.com/product-documentation/internet-insights/provider-intelligence/analyze-time-series#viewing-a-time-series).

![Application metrics in the results table with additional HTTP server metrics](/files/1IBq30bmjwdoRf3Od5hn)

#### HTTP Server Metrics

These metrics dissect the application request/response cycle to help you understand where time is being spent. All metric timings are measured in milliseconds (ms) at your selected percentile. Lower values are better.

**DNS Time**

* Time to resolve the domain name to an IP address. Slow DNS resolution delays the start of every connection. Can indicate DNS server issues or inefficient DNS configurations.

**Connect Time**

* Time to establish a TCP connection with the server. Reflects network latency and server responsiveness. High connect times can indicate network congestion or server overload.

**SSL Time**

* Time to complete the SSL/TLS handshake for encrypted connections. SSL negotiation is cryptographically intensive. High SSL times can indicate server CPU constraints or use of older, slower SSL protocols.

**Send Time**

* Time to transmit the HTTP request to the server. Usually minimal, but high send times can indicate bandwidth constraints or network issues.

**Wait Time**

* Time spent waiting for the server to process the request and begin responding. Directly reflects server performance and application responsiveness. High wait times usually indicate server-side issues, not network issues.

**Receive Time**

* Time to receive the full response from the server. Depends on response size and available bandwidth. Large files or limited bandwidth result in longer receive times.

**Redirect Time**

* Time spent on HTTP redirects before reaching the final destination. Each redirect adds latency. Multiple redirects can significantly slow down application load times.

**Total Time**

* Total time from request initiation to response completion, including all above components. Represents the complete end-to-end application response time from a user's perspective.

#### Page Load Metrics

These metrics measure complete web page loading performance.

**Page Load Time**

* Time from starting to load the page until it's fully rendered and interactive, measured in milliseconds (ms). Lower values are better. Directly impacts user experience. Slow page loads frustrate users and can impact business outcomes (conversions, productivity, etc.).

**DOM Load Time**

* Time until the Document Object Model (HTML structure) is fully loaded and parsed, measured in milliseconds (ms). Lower values are better. Indicates when the page structure is ready, even if images and other resources are still loading. Faster DOM load means users see content sooner.

**Throughput**

* The effective data transfer rate for the page load, measured in Kilobits per second (Kbps). Higher values are better (for example, > 5000 Kbps (5 Mbps) is considered excellent, whereas < 500 Kbps is considered poor). Indicates the effective bandwidth available for loading content. Low throughput suggests bandwidth constraints or network congestion.

#### Response Codes

Response codes indicate the HTTP status returned by the server:

* **1xx (Informational)**: Request received, continuing process.
* **2xx (Success)**: Request successfully received, understood, and accepted.
* **3xx (Redirection)**: Further action needed to complete the request.
* **4xx (Client Error)**: Request contains bad syntax or cannot be fulfilled.
* **5xx (Server Error)**: Server failed to fulfill an apparently valid request.
* **Null**: No response received or connection failed.

High rates of 4xx or 5xx errors indicate application or server issues. Excessive 3xx redirects can slow performance.

**Note**: Response codes don't change with percentile selection, nor are they scored—they're categorical data, not performance measurements.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.thousandeyes.com/product-documentation/internet-insights/provider-intelligence/build-a-query/prioritize-metrics.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.