Stream Health Metrics Explained: Rebuffering Ratio, Startup Time, Exit-Before-Play

Startup time, rebuffering ratio, and exit-before-video-start measure something the watch-time and retention dashboard covered earlier in this series can't: whether playback actually worked, not just whether someone watched. A video with perfect retention and terrible startup time is a contradiction that can't exist, because the viewers who gave up waiting never show up in a retention chart at all. This is the layer underneath engagement metrics, playback health itself.

TL;DR:

• Startup time is the delay between pressing play and the first frame appearing. The widely-cited benchmark: viewers start abandoning past roughly 2 seconds, and each additional second past that adds about 5.8% more abandonment, per a landmark Akamai study of 6.7 million viewing sessions.
• Rebuffering ratio is stall time divided by total watch time. Target under 1%, ideally under 0.5%; one study found a video that stalled for just 1% of its duration lost viewers 5% of their watch minutes compared to smooth playback.
• Exit-before-video-start (EBVS) counts viewers who clicked play, waited, and left before the first frame ever appeared, a real behavioral loss that doesn't show up in play counts or watch-time metrics at all, since these viewers never technically started a session.
• AIOZ Stream's own QoE documentation describes startup time and rebuffer ratio as metrics it aggregates into "session-level KPIs" internally, but no dedicated API endpoint for retrieving them is documented, a real gap separate from the general Analytics API already covered in this series.
• EBVS specifically doesn't appear anywhere in AIOZ's documentation, not even conceptually, a second, distinct gap from the missing API endpoint.

Startup time: the first quality judgment a viewer ever makes

Startup time (also called video start time or join time) is the elapsed time from pressing play to the first frame actually rendering on screen. The number that anchors most industry guidance traces back to a landmark Akamai study analyzing 6.7 million viewing sessions over 10 days: viewers begin abandoning a video that hasn't started within roughly 2 seconds, and each additional second of delay past that point increases the abandonment rate by approximately 5.8%. That's not a soft guideline, it compounds fast, a 10-second startup delay approximates 58% additional abandonment on top of the baseline. AIOZ Stream's own QoE documentation defines the same metric in nearly identical terms: "how long from play to first frame. Viewers feel the difference between 1.2s and 3s," and includes a startup penalty directly in its documented QoE formula, QoE ≈ Perceived quality (VMAF) − Rebuffer penalty − Startup penalty + Stability, already covered in more depth in the QoE article.

Rebuffering ratio: the metric that erodes trust one freeze at a time

Rebuffering ratio is total stall time divided by total watch time, the share of a viewing session spent frozen waiting for more data rather than actually playing. The commonly cited target is under 1%, with better-performing platforms aiming under 0.5%; AIOZ's own documentation frames the stakes plainly: "total stall time divided by watch time. Even a single two-second freeze can break immersion." The real-world cost is measurable and larger than the raw percentage suggests, one widely cited analysis found that a video which stalled for just 1% of its total duration lost viewers roughly 5% of their watch minutes compared to sessions with smooth playback, a single freeze doesn't just cost the seconds it lasted, it measurably reduces how much of the rest of the video gets watched at all.

Exit-before-video-start: the blind spot general analytics can't see

Exit-before-video-start (EBVS) counts something neither play counts nor watch-time metrics can: viewers who clicked play, watched a loading spinner, and left before the first frame ever rendered. That's a categorically different failure from a slow-but-completed start or mid-playback rebuffering, these are viewers who never technically began a session at all by most analytics' definitions, which is exactly why EBVS matters as its own tracked number rather than something a rebuffer-ratio or startup-time metric implicitly covers. A platform can report a perfectly healthy average startup time while still losing a meaningful share of its audience to abandonment during that wait, since an average hides the tail: the sessions that never started are the ones average startup time, by definition, never counts. Worth being direct about a real gap here: EBVS doesn't appear anywhere in AIOZ Stream's documentation, not in the general Analytics API, and not in the QoE concepts page that does define startup time and rebuffer ratio. That's a genuine blind spot worth knowing about rather than assuming it's covered by proxy.

What AIOZ Stream actually exposes today

Checked directly rather than assumed: AIOZ's QoE concepts documentation states plainly that "the player emits events that map to the metrics above: play request, first frame shown, rendition change, stall start/end, and error. We aggregate these into session-level KPIs, then let you slice by device type, app version, ISP, and region." That's a real, specific description of startup time and rebuffer ratio being tracked and aggregated internally. What isn't documented anywhere: a corresponding API endpoint to actually query those session-level KPIs. The general Analytics API covered in the dashboard article exposes play, start, end, impression, watch_time, view, retention, and play_rate, none of which map to rebuffer ratio or startup time directly. That's a real, specific gap distinct from the general analytics coverage: AIOZ describes tracking QoE session KPIs conceptually but doesn't document a way to pull them back out via API today. The practical workaround, given the player events AIOZ's own docs list by name (play request, first frame shown, stall start/end), is client-side instrumentation: a player integration can listen for those same event types directly in the browser or app and compute startup time and rebuffer ratio locally, the same underlying signal AIOZ's player already emits, just captured at the client rather than pulled from a server-side query.

Frequently Asked Questions

What's a good startup time for video?
Under roughly 2 seconds is the commonly cited threshold before meaningful abandonment begins; each additional second past that point adds about 5.8% more abandonment per the landmark Akamai study this benchmark comes from.

What rebuffering ratio should I target?
Under 1% is the standard target, with strong-performing platforms aiming under 0.5%. Even a 1% stall rate has been shown to cost roughly 5% of total watch minutes.

What is exit-before-video-start (EBVS)?
The share of viewers who click play, wait, and leave before the first frame ever appears. It's distinct from a slow startup time because these sessions never technically start, so they don't show up in play counts or watch-time metrics at all.

Does AIOZ Stream track rebuffering ratio and startup time?
Its own QoE documentation describes both as metrics aggregated into internal session-level KPIs, but no API endpoint for retrieving them is documented, a real gap separate from its general Analytics API.

Does AIOZ Stream track exit-before-video-start?
No, it doesn't appear anywhere in AIOZ Stream's documentation, neither in the Analytics API nor the QoE concepts page.

How can I measure startup time and rebuffering if there's no API for it?
AIOZ's own docs name the underlying player events, play request, first frame shown, stall start/end, which a client-side integration can listen for directly and compute the metrics locally, the same signal the platform's internal aggregation is described as using.

Related Reading

• OBS Studio Setup Guide for AIOZ Stream (encoder values that affect stream health)
• How to Start a Livestream on AIOZ Stream (what to watch in the first two minutes)
• Live Streaming on AIOZ Stream: The Complete Guide: the live statistics endpoint: fps and bitrate in and out, refreshed every 5 to 30 seconds
• What Is QoE in Video Streaming and Why It Matters: the broader formula startup time and rebuffer penalty feed into
• Building a Video Analytics Dashboard: the general Analytics API these session-health metrics are notably absent from
• VMAF Explained: the perceived-quality term in the same QoE formula covered here
• What Is Adaptive Bitrate (ABR) Streaming: the mechanism that directly determines rebuffering and stability outcomes
• How to Build a Video Bitrate Ladder: the ladder design choices that shape how often rendition switching (stability) happens

References

• Fora Soft: Video QoE, Startup Time and Rebuffering Explained: the Akamai abandonment-rate study and rebuffer-ratio watch-time-loss figures quoted above
• Conviva: OTT 101, Your Guide to Streaming Metrics That Matter: the exit-before-video-start (EBVS) definition referenced above