Playback Signal

What it is for

When playback degrades, the argument can run for days. The CDN blames the player, the player vendor blames the encode, and nobody has data detailed enough to settle it. Average startup time doesn't help: the average looks fine while the worst tenth of sessions is unwatchable. To settle it you need telemetry broken down by CDN, device, player build and territory at the same time, reported at percentiles, so you can see which one changed.

Client-side playback telemetry aggregated into startup time, rebuffer rate, and bitrate distribution, broken down by CDN, device, player build, and territory. When playback gets worse you can trace it to a cause in one pass, without days of argument between vendors. Everything is reported at percentiles, because averages hide the sessions that went badly.

What it does

• Startup time and rebuffer rate at percentile
• Failure attribution by CDN, device, and player build
• Bitrate distribution and downshift analysis
• Release-over-release regression comparison
• Alerting on percentile movement
• Raw event export to your own warehouse

Coverage

Web, mobile, connected TV

Refresh

Real-time streaming

Delivery

Dashboard, API, warehouse share

What you get

• Client instrumentation for your players, with a documented event schema
• Dashboard covering startup, rebuffer, bitrate, and failure attribution
• Percentile-based alerting tuned to your segments
• Release comparison view for player rollouts
• Raw event export into your own warehouse
• A report format for working out with vendors which of you is at fault

Who it is for

• Platforms running more than one CDN that cannot prove which is at fault
• Teams rolling out player changes without a quality reading for each release
• Operations teams alerting on averages and hearing about problems from users first