# Summary Statistics

## Overview

Summary statistics are statistical measures that represent the distribution of metric values over time. Instead of showing thousands of individual measurements, summary statistics provide meaningful aggregate views of performance in different operational scenarios.

Available options:

* **ThousandEyes Recommended (default)**: Uses optimal percentile per metric.
* **Average**: Arithmetic mean.
* **P95 (95th percentile)**: Worst-case performance.
* **P75 (75th percentile)**: Better than typical.
* **P50 (Median)**: Typical performance.
* **P25 (25th percentile)**: Better than average.
* **P5 (5th percentile)**: Best-case performance.

Change your statistic selection from the **Summary Statistics** dropdown above the results table.

**Important**: Your selection applies globally to all metrics and all providers in the results table. You cannot select different statistics for different metrics or different providers within the same view.

## Understanding Percentiles

### What Is A Percentile?

A percentile indicates the value below which a given percentage of observations fall. Percentiles represent different parts of the data distribution for any given provider over your chosen time frame.

**Example with latency**:

| Percentile | Value (ms) | Interpretation                            |
| ---------- | ---------- | ----------------------------------------- |
| P5         | 5          | Best 5% of latency values are below 5 ms  |
| P25        | 10         | 25% of latency values are below 10 ms     |
| P50        | 20         | Median latency is 20 ms                   |
| P75        | 45         | 75% of latency values are below 45 ms     |
| P95        | 50         | Almost all latency values are below 50 ms |

### How Values Translate to Performance

For most metrics (except throughput), lower values when comparing providers mean better performance. Higher values indicate worse performing providers.

```
Best Performance ←―――――――――――――――――――――――――――→ Worst Performance
ms:    5, 10, 15 ...     20, 25, 30 ...    45, 50, 60
%:         P5      P25      P50      P75      P95
```

**Examples**:

* A provider with a P95 latency of 50 ms performs better in worst-case scenarios than one with a P95 of 100 ms.
* A provider with a P5 latency of 5 ms has better best-case performance than one with a P5 of 15 ms.

**Why use percentiles?**

Each percentile focuses on a different segment of the data distribution, helping you understand performance from best-case through median to worst-case scenarios.

## When to Use Each Statistic

### 5th Percentile

* Purpose: Best-case performance.
* Use for: Packet loss evaluation; understanding theoretical capability.
* Answers: "What's the lowest latency this provider can achieve?"

### 25th Percentile

* Purpose: Better-than-average performance.
* Use for: Identifying performance under lighter load conditions; early warning of degradation.
* Answers: "How does the provider perform during quieter periods?"

### 50th Percentile (Median)

* Purpose: Typical, everyday performance.
* Use for: General-purpose provider comparisons; understanding normal conditions.
* Answers: "What latency will my users typically experience?"

### 75th Percentile

* Purpose: Balances typical and peak performance.
* Use for: Latency-sensitive applications that can tolerate occasional spikes.
* Answers: "How does performance hold up when moderately busy?"

### 95th Percentile

* Purpose: Worst-case performance (excluding extreme outliers).
* Use for: SLA validation; latency-sensitive applications; risk-averse analysis.
* Answers: "What's the worst latency during peak hours?"
* Note: Commonly used in provider SLAs.

### Average (Mean)

* Purpose: Arithmetic mean of all measurements.
* Use for: Simple comparisons; total throughput over time.
* Answers: "What is the overall average latency?"
* Limitation: Can be skewed by outliers; doesn't reveal consistency.

### ThousandEyes Recommended

Provider Intelligence uses domain expertise to choose the most appropriate percentile for each metric when calculating scores.

**Rationale**:

Not all metrics are best evaluated at the same percentile. For example:

* **Latency** is best assessed at the 75th percentile (captures typical performance without being skewed by outliers).
* **Loss** is best assessed at the 5th percentile (because packet loss should be near-zero, and even small amounts are problematic).

Use for: When unsure which percentile to use; presenting to non-technical stakeholders; general-purpose evaluation.

**How It Works**:

| Metric  | Percentile Used | Reasoning                                      |
| ------- | --------------- | ---------------------------------------------- |
| Latency | 75th            | Balances typical and peak performance          |
| Loss    | 5th             | Packet loss should be near-zero                |
| Jitter  | Average         | Smooths out momentary spikes                   |
| TTFB    | 75th            | Balances typical and peak application response |

## How Summary Statistics Affect Results

Changing your summary statistic can significantly impact scores. Consider a provider with highly variable latency:

| Percentile | Latency Value | Performance Score |
| ---------- | ------------- | ----------------- |
| 5th        | 8ms           | 95                |
| 50th       | 20ms          | 80                |
| 95th       | 55ms          | 60                |

This provider performs excellently at its best (5th percentile) but poorly during congestion periods (95th percentile). The provider you choose depends on whether you prioritize best-case, typical, or worst-case performance.

### Special Considerations

* **Outages and Total Unique AS Paths**: The **Outages** and **Total Unique AS Paths** metrics show counts and remain constant regardless of percentile selection.
* **Trends**: Trend indicators (up, down, flat), visible in single-destination views, are calculated separately for each percentile. See [Trend Analysis](https://docs.thousandeyes.com/product-documentation/internet-insights/provider-intelligence/scoring-methodologies/trend-analysis) for details.


---

# 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/view-results/summary-statistics.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.