Player telemetry on Analytics Engine

Startup time, stalls and errors from your own players, stored and queried on Cloudflare

Example design

01CollectA small script in the player records startup time, stalls, bitrate changes and errors for each session.
02Send in batchesEvents go to the Worker in batches with sendBeacon, including a final batch when the page closes.
03WriteThe Worker adds the country and network from the request and writes one data point per event, with the session ID as the index.
04Ask for a chartThe dashboard asks the Worker for a chart, and the Worker runs SQL against Analytics Engine.
05Rows backStartup time and stall rate by player version, country and network come back, weighted by the sample interval.
ifA player release makes things worseEvery event carries the player version, so comparing the new release with the previous one is one query, on the day it ships.

The problem

Most teams find out about playback problems from support tickets. Commercial QoE products measure playback quality, but they cost a lot per session and the data lives in someone else's system. For many platforms a small player script, a Worker and Analytics Engine are enough to see startup time, stalls and errors by player version, country and network, and to see them on the day a release ships.

What it uses

Workers: Event intake and the query API for dashboards
Analytics Engine: Event storage and SQL queries
D1: Daily rollups kept beyond three months

The decisions, and why

IndexSession ID: The index is Analytics Engine's sampling key. Sessions are what the charts count, so the session ID is the natural choice.
TransportBatched beacons: Batching keeps request counts down, and sendBeacon still delivers when the viewer closes the tab.
IdentityNo user IDs: Country, network and player version are enough for these charts, and identifying viewers would add risk.
HistoryDaily rollups in D1: Raw events last three months. Rollups keep the long-term trend for comparing seasons and big events.