The four numbers that matter
Start-up time, rebuffer ratio, average delivered bitrate and error rate — per session, sliceable by network, device, region and title.
Quality is measured, not surveyed
Start-up time, rebuffer ratio, bitrate changes and errors stream back from every player into a store you operate. You find out that playback is bad from the data, not from a support ticket.
The gap between 'the servers are fine' and 'it is watchable'
Infrastructure monitoring tells you the edge is healthy and the origin is responding. It cannot tell you that viewers on one mobile network are getting a rebuffer every ninety seconds, because from the server's perspective those requests all succeeded.
The only place that shows up is the player. So every player — web, phone and television — reports start-up time, rebuffer events, bitrate changes and errors per session, continuously, into a store built for that ingest pattern. It runs in your estate, which means there is no per-session licence and no third-party processor holding your viewers' behaviour.
What is measured
Cache and origin behaviour
Hit ratio by content class, origin fetch volume and edge saturation — the numbers that predict the next capacity decision.
Metrics, logs and traces
The conventional three, across both estates in a hybrid deployment, in one view rather than two consoles.
The data stays yours
Self-hosted ingest and storage. No per-session licence that grows with success, and no processor to declare in a privacy assessment.
How the pipeline stays small enough to survive the night it matters
Player telemetry is the highest-cardinality data a streaming service produces. Every session carries a session id, a device, a network, a title, a rendition and a region, and any store asked to keep all of those as queryable dimensions at full resolution will fall over on precisely the night you need it — the big match, when session count and the value of the data both peak together.
So the pipeline reduces in stages, and each stage is placed where its cost is lowest. Players batch beacons locally and post them at an interval rather than per event, which removes most of the request volume before anything leaves the device. The collector runs on the edge node that served the segments, so ingest never crosses to the control plane at beacon time and stays available when that plane is not.
Reduction happens at the collector, not at the query. Raw events are appended to owned storage where they are cheap to keep and cheap to re-read. In parallel the collector emits pre-aggregated series — counts, sums and quantile sketches bucketed by minute, keyed on the dimensions that are actually queried: channel, zone, device class, rendition. Session id is deliberately not a series key, because it is unbounded and one unbounded key is all it takes to turn a metrics store into an outage.
Quantiles are computed from sketches rather than averages, and that is the difference between a dashboard that is reassuring and one that is true. A mean start-up time hides the tail that people actually abandon on. A merge-able sketch gives a real 95th percentile that can be re-aggregated across nodes and across time buckets without going back to the raw events.
What crosses into the control plane is only the rolled-up series, on an interval, and it is small — bounded by the number of dimension combinations rather than by the number of viewers. Doubling the audience does not double what the control plane ingests. The full-resolution events stay where they were written, which is what makes a per-session investigation possible after the fact without any of that volume ever having been a live dependency.
Retention follows the same split for the same reason. Raw events age out on a disk budget. Aggregates are kept far longer because they are small, and they are what a year-on-year comparison actually needs.
Telemetry characteristics
| Concern | Licensed analytics | Self-hosted telemetry |
|---|---|---|
| Cost shape | Per session, grows with success | Storage and compute you already run |
| Latency | Batched, often next day | Continuous ingest |
| Granularity | Sampled or aggregated | Per session, retained as you choose |
| Data control | Held by a processor | Held in your estate |
| Custom events | Vendor schema | Your schema |
| Ingest path | Direct from player to processor | Player to edge collector, then to owned storage |
| Cardinality control | Vendor's decision | Session id kept off series keys; aggregates bounded by dimensions |
| Tail latency | Reported as an average | Quantiles from merge-able sketches, re-aggregatable across nodes |
| Control-plane load | Scales with sessions | Scales with dimension combinations, not audience size |
The things people ask first
Does this replace a commercial analytics vendor?
For quality-of-experience monitoring, yes. Business analytics and attribution are a different question and often stay where they are.
How much data is this?
Less than expected — beacons are small and the volume follows sessions rather than bytes delivered. Retention is a policy decision rather than a cost cliff.
Can we alert on it?
Yes, and that is the point. Rebuffer ratio crossing a threshold for a network or a region is an alert, not a monthly finding.
What do you know about playback right now?
If the answer is a monthly report, there is a gap worth closing before the next big night.