> ## Documentation Index
> Fetch the complete documentation index at: https://docs.streampixel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Reading your analytics

> How to interpret session counts, latency, FPS, and other metrics in the analytics dashboard.

Open your project's **Analytics** tab and pick a time window (24h, 7d, 30d, or custom). The dashboard splits into **Sessions**, **Audience**, and **Quality**.

## Sessions

### Session count

The number of unique connections in the selected window. One viewer who reloads the page counts twice — Streampixel measures connections, not unique users.

| Reading                        | Interpretation                                    |
| ------------------------------ | ------------------------------------------------- |
| Steady day-over-day            | Healthy baseline                                  |
| Spike with no marketing change | Investigate — possibly a viral share or a bot     |
| Drop to zero                   | Build is failing to start; check disconnect codes |

### Average duration

Mean session length in minutes. Useful as an engagement signal.

* **Under 30 seconds** — Most viewers are bouncing. Often a loading-time or quality issue.
* **1-3 minutes** — Typical for casual demos.
* **5+ minutes** — Strong engagement; viewers are exploring.

### Concurrent sessions

The number of viewers connected at the same time, plotted over the selected window. Two values matter:

* **Peak** — the highest concurrent count. Use this to size your plan.
* **Current** — live count right now.

If peak ever hits your plan limit, new viewers were queued or rejected. Upgrade or expect drop-off at peak times.

## Audience

### Region distribution

Breakdown by client region — typically `US`, `EU`, `APAC`, plus a long tail. Use it to choose which Streampixel regions to deploy to:

* Heavy `EU` traffic → enable **Europe** if you haven't already.
* Heavy `APAC` traffic → enable **Asia Pacific**.

A region without a nearby Streampixel deployment will show higher latency in the Quality section.

### OS / browser distribution

Breakdown of viewer operating systems and browsers. Useful for:

* Prioritising browser-specific bug fixes (a Safari-only crash matters more if 40% of your audience is on iOS).
* Validating your Web SDK testing matrix matches the real audience.

<Tip>
  If you see a surprising fraction of `Unknown` browsers, it usually means bots or scrapers. Cross-check with session duration — bots typically last under 5 seconds.
</Tip>

## Quality

These metrics are reported by the client over WebRTC. They reflect what the viewer actually experienced.

### FPS

Frames per second the client received and rendered.

| FPS     | Quality                                |
| ------- | -------------------------------------- |
| `>= 60` | Ideal — smooth for fast-paced content  |
| `30-59` | Acceptable — most viewers won't notice |
| `15-29` | Visibly choppy                         |
| `< 15`  | Unwatchable; viewers will bounce       |

A low average FPS with high bitrate usually means the client device cannot decode fast enough. A low average FPS with low bitrate means the network is the bottleneck.

### Bitrate

Client-reported video bitrate in kbps.

| Bitrate          | Quality                              |
| ---------------- | ------------------------------------ |
| `> 5000 kbps`    | High quality, suitable for 1080p+    |
| `2000-5000 kbps` | Good quality, suitable for 720p      |
| `500-2000 kbps`  | Watchable but compressed             |
| `< 500 kbps`     | Heavy compression; expect blockiness |

Bitrate naturally adapts to network conditions — WebRTC drops it before dropping FPS. A long-term low bitrate average usually means viewers are on weak connections.

### Latency

Round-trip time (RTT) in milliseconds between the client and the streaming server.

| Latency      | Feel                                |
| ------------ | ----------------------------------- |
| `< 50 ms`    | Imperceptible — feels native        |
| `50-100 ms`  | Excellent — most users won't notice |
| `100-150 ms` | Acceptable for most experiences     |
| `150-250 ms` | Noticeable input lag                |
| `> 250 ms`   | Frustrating for interactive content |

Latency is dominated by physical distance. If average latency is high in a region, deploy a Streampixel edge there.

### Disconnects by code

Distribution of disconnect reasons. Each code has a meaning — a few common ones:

| Code   | Meaning                                                   |
| ------ | --------------------------------------------------------- |
| `1000` | Normal close — user navigated away or closed the tab      |
| `1006` | Abnormal closure — usually a network drop or TURN failure |
| `4001` | AFK / idle timeout                                        |
| `4003` | Queue timeout                                             |

See the full table in [disconnect codes](/resources/quick-start-guide/disconnect-codes).

## Spotting issues

Use the patterns below to triage anomalies.

<AccordionGroup>
  <Accordion title="Spike in 1006 disconnects" icon="triangle-exclamation">
    Indicates abnormal closure — the WebRTC connection died unexpectedly. Common causes:

    * **TURN server overloaded** — viewers behind strict NATs can't relay traffic. Check region distribution; if one region spikes, the local TURN may need attention.
    * **Network instability on the client** — usually correlates with mobile traffic.
    * **Build crash mid-session** — pair with FPS dropping to zero just before disconnect.
  </Accordion>

  <Accordion title="FPS drops with stable bitrate" icon="gauge-high">
    Bitrate is fine, but frames are not rendering. The client device cannot decode fast enough.

    * Check OS/browser distribution — older mobile devices often hit decode limits.
    * Lower the build's resolution or codec complexity.
  </Accordion>

  <Accordion title="Bitrate drops with stable FPS" icon="signal">
    WebRTC's adaptive logic chose to keep frames smooth at the cost of pixel quality. The client's network is the bottleneck.

    * Check region distribution — a region without a local edge will show this.
    * If the audience is mobile-heavy, this is normal during commute hours.
  </Accordion>

  <Accordion title="Average duration drops while session count stays flat" icon="hourglass-half">
    Same number of viewers, but each one leaves sooner. Typically a regression in load time, first-frame quality, or onboarding.

    * Compare to the date of your last build upload. Roll back if the timing matches.
  </Accordion>

  <Accordion title="Concurrent peak hits plan limit" icon="users">
    New viewers are being queued or rejected at peak times.

    * Upgrade your plan, or
    * Use the queue messaging in [branding](/resources/dashboard/branding) to set viewer expectations during peaks.
  </Accordion>
</AccordionGroup>

## Per-session detail

Click any row in the **Recent sessions** table to see metrics for that single session — FPS over time, bitrate over time, disconnect reason, region, and OS/browser. Useful for debugging individual viewer reports.

## Exporting data

The dashboard view covers most needs. For raw session data — to ingest into your own analytics warehouse — contact support. Streampixel can provide CSV or JSON exports on request.

## Data retention

Recent session data is kept for the duration of your account. Historical depth depends on your plan; if you need a longer retention guarantee for compliance, contact support before relying on the dashboard for long-term records.

<Note>
  Deleting a project also deletes its analytics. Export anything you need before removing a project.
</Note>

## Next

<CardGroup cols={2}>
  <Card title="Disconnect codes" icon="plug-circle-xmark" href="/resources/quick-start-guide/disconnect-codes">
    Full reference for every code shown in analytics.
  </Card>

  <Card title="Stream statistics" icon="chart-simple" href="/resources/web-sdk/features/stream-statistics">
    Read live FPS, bitrate, latency from the Web SDK.
  </Card>
</CardGroup>