We build sports streaming and fan analytics, with AI agents held to every rights deal.

A streaming report is only as good as the events the player sends. The useful set is small. A session start with the viewer, device and app version, then play, pause and seek, an ad start and an ad complete, and a heartbeat every thirty seconds or so while the video is actually moving.

The heartbeat is the one people skip, and it's the one that matters, because an app that gets swiped away never sends a session end. Without heartbeats you can count starts but you can't count minutes. Three numbers then get confused in every meeting. Viewers counts distinct people across the whole game, peak concurrent is the most people watching at one moment, and minutes watched comes from multiplying heartbeats by the interval.

A rights holder asking how many watched usually means the first, a sponsor usually means the third, and the platform's own dashboard often shows the second. Agreeing which one goes in the contract is worth doing before anyone builds a chart. On Databricks the heartbeats land as a stream, and a watermark tells Structured Streaming how late an event may arrive and still count.

For a live screen during the game, approx_count_distinct gives viewers cheaply, and the docs give its default maximum relative standard deviation as 5%. For the number that goes to a club, count the distinct IDs exactly, because a 5% gap is an argument nobody needs.

SELECT game_id,
       count(DISTINCT viewer_id)        AS viewers,
       approx_count_distinct(viewer_id) AS viewers_live_estimate,
       count(*) * 30 / 60.0             AS minutes_watched
FROM   media.playback.heartbeats
WHERE  event_date = current_date()
GROUP  BY game_id;

Sources: approx_count_distinct, watermarks in Structured Streaming

BZZR's live games run on an AWS Elemental stack with ad injection. The general mechanism, as AWS documents it for MediaTailor, goes like this. The player asks for the stream with some information about the viewer.

MediaTailor asks an ad decision server what to show, gets back a VAST response, and rewrites the manifest for that one viewer. In a live stream it replaces the content between the ad markers, so an ad break has to be signalled with a cue-out and either a duration or a matching cue-in.

The detail that changes reporting is what happens when the ads don't fit. AWS's own example is a 70-second break and two 40-second ads, which plays one ad and fills the remaining 30 seconds with slate or the underlying content.

Fill rate and slate time live in the gap between the break schedule and the ad beacons, which the player or MediaTailor sends at the start, middle and end of each ad. Join those two and you can tell a sponsor what actually ran.

Sources: how MediaTailor ad insertion works, live ad stitching behaviour, ad tracking and beacons

The BZZR pipeline ingests partner video, transcribes it and mines it for key terms and the moments worth surfacing, and that output builds the sports graph of who is talking about whom. The part that makes a transcript useful is timing.

Amazon Transcribe, for example, returns a start time, an end time and a confidence score for every word, so a mention of a player can point at the second it happened rather than at a two-hour file.

Keep the timestamps through every step, and a search for a name lands on the clip. Drop them, and you've built a very large text file.

Checked on 11 October 2026 against Amazon Transcribe output format.

The subscriber question is the one that bites late. When the Texas Rangers moved their direct-to-consumer streaming to BZZR in July 2026, part-way through the season, the existing subscribers came across transferred and authenticated rather than being asked to sign up again.

That only works if identity was designed as something you can move. The whole build is written up in [the BZZR case study](/case-studies/bzzr).