Streamwake + Bitmovin Analytics.
Don't replace Bitmovin Analytics — we correlate its viewer-side QoE signals against the CDN + origin signals and surface viewer-device failures on the same investigation timeline.
Don't replace Bitmovin Analytics — we read the per-impression QoE signals Bitmovin Analytics already emits (buffering ratio / bitrate switches / startup time / error rate / quality score), correlate them against the CloudFront + CloudWatch + AWS MediaLive pair the adjacent +X pages already name, and surface viewer-device-side failures as ranked candidates on the same investigation timeline. A chart that started at the viewer-side buffer and a chart that started at the CDN edge land on the same frame — never collapsed into one symptom.
Bitmovin Analytics viewer-side qoe — buffering ratio / bitrate / startup time / error rate / quality score. Streamwake doesn't replace Bitmovin Analytics— we correlate its signals and drive remediation on the anomalies it already surfaces.
What Bitmovin Analytics owns. What Streamwake runs on top.
Honest framing of the surface the vendor owns and the surface Streamwake runs on top of it. Both layers run together in production — same signal bus, different obligations.
Player-side QoE telemetry
Impression-level identity + reroute surface
Detect → Classify → Fix on the viewer-device side
Cross-vendor alignment + investigated-side classification
An incident closed
before your viewers notice.
Four steps from a Bitmovin Analyticsanomaly to a closed incident with a typed postmortem. Read top to bottom — the loop is closed end to end.
- 1
Configure Bitmovin Analytics export relay
Configure the Bitmovin Analytics export endpoint + redirect one BundleAnalytics-style relay transport to point at the Streamwake inbound URL. The relay pushes one record per impression QoE event with the typed `{ as, sourceToken, envelope }` JSON shape. The relay is HMAC-free for v1 — the per-source `routerToken` keyed onto `?token=<routerToken>` is the seam that scopes the relay to the right Streamwake tenant.
- 2
Ingest per-impression QoE events
The relay POSTs one Bitmovin Analytics envelope (bufferingRatio / bitrateSwitch / startupTime / errorRate / qualityScore) per impression. The inbound route resolves the tenant from the per-source `routerToken`, dedupes against the `(userId, sourceId, upstreamId)` triple, and persists the typed headline QoE fields — bufferingRatio / startupTimeMs / bitrateKbps / errorRate / qualityScore / customUserAgent — as first-class columns on the row so the panel renders the summary inline without re-parsing JSON.
- 3
Correlate against CDN + origin + align with CloudWatch
The correlator joins the captured QoE events against the closest pull-side CloudwatchEvidence row for the same incident, scores each by a small typed heuristic (buffering > 0.05 → +30; startupMs > 2500 → +20; bitrate < 1200kbps → +15; errorRate > 0.02 → +35; quality < 70 → +30; ±30s of CloudWatch → +20; region-matches → +10), and persists a BitmovinIncidentCandidate row typed by the streaming-native viewer-side anomaly class. Viewer-side failures stay distinct from origin-side regressions on the same incident frame.
- 4
Emit-back into the Bitmovin workspace + postmortem
When the agent applies a remediation, a typed metric (`streamwake.bitmovin.<viewer_side_classification>.remediation.applied`) lands back onto the Bitmovin Analytics workspace the operator already polls — so the same dashboard panel that flagged the bufferingRatio surge renders the loop-closure metric the moment the fix lands. The investigation panel renders the per-the-classification panel + anomaly-chip classification on the same frame.
Four failure modes Bitmovin Analytics alerts alone miss.
Each one is something the Bitmovin Analyticssignal exposes but the agent loop names and acts on — so a chart becomes a closed incident rather than a triage queue.
Viewer-side Buffering Surge
A Bitmovin Analytics bufferingRatio lands > 0.05 on the same title across the same CDN region the CloudFront cache-miss latency sidebar surfaces — but the most likely root cause is the player session buffering under sustained CDN latency, not the CDN edge degrading. Bitmovin Analytics fires a bufferingRatio alarm in the dashboard; Streamwake catches the player-side correlation against the CloudWatch / CloudFront pair in the same window, joins the typed classification as `viewer_side_buffering` with a typed confidence, and surfaces a paired player-side remediation (manifest size retune / CDN region reroute) without collapsing a chart that started at the viewer-device into a chart that started at the CDN-side.
Startup-time Regression
A Bitmovin Analytics startupTimeMs lands above 2500ms on a primetime window — the player-side regression shows up before any CDN-side or origin-side chart surfaces a regression. Bitmovin Analytics fires the per-impression regression in the dashboard; Streamwake joins it against the AWS MediaLive channel-state stream on the origin side in the same window and PINs the classification as `viewer_side_startup_regression` so the player-side retry is the typed remediation — not a CDN retune that wouldn't have helped.
Bitrate Step-down Cascade
A Bitmovin Analytics bitrateSwitch event lands stepping the session down from 2400kbps to 900kbps — the most likely cause is sustained CDN throughput below the previous rendition. Bitmovin Analytics reports the step-down on the dashboard; Streamwake catches the rendition step-down against the CloudFront cache-miss latency fan-out the +CloudFront page already surfaces, joins the two as a single typed classification (`viewer_side_bitrate_step_down` + `cache_miss_surge`) and recommends a CDN region reroute before the second wave of step-down hits the wider primetime audience. Two-step diagnosis — viewer-side signal pins the symptom; CDN-side signal pins the cause.
Error-rate Velocity Vs Quality-score Drop
A Bitmovin Analytics errorRate lands paired with a qualityScore drop below 70 — the most likely cause is a session-end cluster the AWS-tier signals haven't surfaced. Bitmovin Analytics fires the per-impression pair in the dashboard; Streamwake catches the velocity-vs-quality pair on the same signal, surfaces the `viewer_side_error_rate_spike` + `viewer_side_quality_score_drop` classification, and queues a paired CloudWatch side retune (CDN region reroute + manifest retune) so the loop closes
Connect Bitmovin Analytics to your investigation timeline free.
Next to Bitmovin Analytics.
Paste your Bitmovin Analytics export endpoint — /stream-check runs the same five checks (manifest, segments, bitrate ladder, CDN response, playback errors) in under a minute. No login. Pair it with the Book-a-demo block below for a guided walkthrough of the viewer-side-QoE correlation lane on top of your existing CloudFront + CloudWatch pairing.
Bitmovin viewer-side buffering ratio paired against CloudFront cache-miss latency.
bitmovin.buffering_ratio drifted to 0.18 vs 0.02 baseline on topgear-ep05 — paired against Amazon CloudFront cloudfront.cache_miss_latency_p95_ms at 2,184ms vs 812ms baseline on the same edge PoP.
The agent classified the joint Bitmovin-reader-side + CloudFront-edge-side signal as viewer_side_buffering_with_cloudfront_cache_miss_correlation at 88% confidence, emitted a paired CDN-edge reroute + a paired manifest bundle retune, and emitted the remediation back as streamwake.bitmovin.viewer_side_buffering.remediation.applied onto the Bitmovin Analytics workspace — so the same dashboard panel that flagged the bufferingRatio drift re-renders the loop-closure metric the moment the fix lands.
Direct mapping to the Streamwake detect → classify → fix loop on the Bitmovin → CloudFront signal bus — the same per-impression bufferingRatio drift AND the matching CloudFront cache-miss latency fan-out the page pins to are the signals the InvestigationCorrelationsPanel renders under the ranked hypothesis list on /app/incidents/[id], and the typed remediation lands back into Bitmovin Analytics as a new metric the operator can immediately re-scrape or alert on.
Configure the source,
ship your first QoE event, light the inbound.
The in-page setup island mounts the push-side BitmovinSourceCard and a companion inbound webhook card. Configure the source first, copy the per-tenant routerToken, wire your Bitmovin Analytics export relay to POST to /api/v1/bitmovin-events/inbound?token=<routerToken>, and hit Send test event to verify the inbound lands on the same investigation timeline the merged panel reads.
Wire your Bitmovin Analytics export relay so a vendor-side HTTP transport POSTs one BundleAnalytics-style record per impression to the Streamwake endpoint. The webhook-share the per-source routerToken, so the inbound route resolves your tenant from ?token=<routerToken> first and drops the QoE event onto the same investigation timeline the merged panel reads.
(empty)(not configured)(empty)(unset)(no events yet)routerToken from that row.curl -X POST '?token=<routerToken>' \
-H 'content-type: application/json' \
-d '{"as":"__test_fixture__","sourceToken":"<routerToken>","envelope":{"kind":"bufferingRatio","upstreamId":"smoke-1","eventTime":"2026-08-23T19:00:52.166Z","impressionId":"smoke-impression-1","videoId":"topgear-ep05","region":"us-east-1","cdnProvider":"cloudfront","playerType":"bitmovin-player-web","customUserAgent":"BitmovinPlayer/9.0 (web)","bufferingRatio":0.18,"durationSeconds":600}}'Recent QoE events
Loading…
What an operator needs on the Bitmovin side before the export relay can fan in.
What an operator needs in the Bitmovin Analytics account before the export relay can start pushing per-impression QoE events to Streamwake. The list matches the source card on /integrations/bitmovin — the labels, the dropdown, and the radio channel-posture stay in lockstep with what is wired on the relay side.
Bitmovin Analytics workspace + organization
The recommended posture is one Bitmovin Analytics workspace + one organization — the free-form accountName + optional organizationLabel on the source card are the labels Streamwake renders inline. Pick labels an operator on the same Streamwake tenant can tell apart from a second Bitmovin workspace so the +Bitmovin island doesn't collide with a future second-tenant install.
Bitmovin Analytics is push-only — the source row carries NO credentials. The only secret-bearing surface is the per-source routerToken (24 bytes hex, minted on first save), which the operator copies into the export-relay URL — not a credential pair, not a shared admin cookie.
Export relay transport + per-source router token
The export relay pushes one record per impression QoE event with the typed { as, sourceToken, envelope } JSON shape. The envelope.kind discriminator narrows per-kind so the inbound route + correlator reason a typed signal without re-parsing. The route never verifies HMAC for v1 — the seam that scopes the relay to the right Streamwake tenant is the per-source routerToken keyed onto ?token=<routerToken>.
The webhookSecret column is typed but unused on first pass — a future relay that DOES issue per-source HMAC plug in without a schema change. The inbound route resolves tenant purely by routerToken for v1.
The Bitmovin Analytics discriminator kinds the inbound route + correlator read. Every kind on this list is the one a relay pushes through the typed envelope envelope — a kind on this list is the one the InvestigationCorrelationsPanel + the recent-events log render inline with the typed headline QoE column.
| Kind | Covers |
|---|---|
| bufferingRatio | Per-impression seconds-buffered / seconds-played. The headline QoE signal — surfaces as `viewer_side_buffering` (score +30) when the ratio crosses the 0.05 baseline. Streams into the InvestigationCorrelationsPanel as a `viewer-side QoE` candidate with a typed confidence score, aligned within ±30s of the closest CloudWatch row. |
| bitrateSwitch | Per-session bitrate step (the rendition the session parked on after the step-down). Surfaces as `viewer_side_bitrate_step_down` (score +15) when the bitrate crosses the 1200kbps baseline. The correlator joins a step-down against the CloudFront cache-miss fan-out on the same window so the cause is named before the second wave of step-down hits. |
| startupTime | Per-impression cold-start time. Surfaces as `viewer_side_startup_regression` (score +20) when startupTimeMs crosses the 2500ms baseline. The correlator pairs the regression against the AWS MediaLive channel-state stream so the player-side retry is the typed remediation — not a CDN retune that wouldn't have helped. |
| errorRate | Per-impression error ratio (4xx/5xx over the impression window). Surfaces as `viewer_side_error_rate_spike` (score +35) when the ratio crosses the 0.02 baseline. Highest weight in the heuristic set — error-rate spikes on a single title repeatedly correlate to a single typology (manifest URI drift, session-end cluster, or a CDN region brown-out). |
| qualityScore | Per-session viewportQuality score (Bitmovin's 0..100 session QoE). Surfaces as `viewer_side_quality_score_drop` (score +30) when qualityScore drops below 70. Pairs against the `viewer_side_error_rate_spike` reason on the same window so a velocity-vs-quality regression pairs as one classification + one remediation. |
Five steps from a blank source card
to a verified QoE event landing on the timeline.
The wire sequence the operator runs to attach Bitmovin Analytics to Streamwake as a viewer-side QoE source. Matches the order the source card's expanded form walks through — workspace, region, relay URL, token mint, verify.
- 1
Configure the Bitmovin Analytics workspace
In your Bitmovin Analytics account, pick the workspace + organization you want to mirror into Streamwake. The free-form `accountName` + optional `organizationLabel` on the source card are the labels Streamwake renders inline — pick labels an operator on the same tenant can tell apart from a second Bitmovin workspace.
- 2
Pick the viewer region hint (optional)
If your Bitmovin Analytics export relay fans impressions out per-region (us-east-1 / eu-west-1 / ap-southeast-1 / …), set the source card's `region` field to the dominant region so the correlator's region-anchor reason surfaces when a Bitmovin event's `region` matches. Leave empty to skip the cross-vendor region reason and rely on the typed buffering / startup / bitrate classifications.
- 3
Wire the Bitmovin Analytics export relay
Configure one Bitmovin Analytics export endpoint to point at the Streamwake inbound URL. The relay POSTs one record per impression QoE event with `{ as, sourceToken, envelope }` JSON. Wire it to redirect per event type (bufferingRatio / bitrateSwitch / startupTime / errorRate / qualityScore) so a single relay handles all five — the discriminated `envelope.kind` discriminator narrows per event.
- 4
Save the source + mint the router token
Save the source row on /integrations/bitmovin. The first save mints a per-source `routerToken` server-side (24 bytes hex) — copy the token into your Bitmovin Analytics export relay's URL as `?token=<routerToken>`. Bitmovin Analytics does not natively sign HTTP relays, so the `routerToken` is the seam that scopes the relay to the right Streamwake tenant.
- 5
Hit Send test event + verify the inbound lands
Click `Send test event` on the setup card. The test-fixture route synthesizes a canonical `bufferingRatio=0.18` event on the configured account + region + CDN and POSTs it through the same inbound pipeline a relay would land. The recent-events log on the same page lights the moment the inbound closes; the InvestigationCorrelationsPanel on /app/incidents/[id] surfaces the candidate the moment you run the correlation pass with a `bitmovinCandidateCount === 0 → seed correlator` flow.
Bitmovin Analytics relays don't sign — the per-source routerToken keyed onto ?token=<routerToken> is the seam. The token is replaced only by deleting the source row + re-saving (the asset stays stable across re-renders — re-generating would break already-deployed relays that point at the old token). The future webhookSecret surface is reserved but unused on first pass.
What becomes available
once the QoE events flow in.
The typed action set the correlator surfaces once the inbound closes and a BitmovinAnalyticsEvent row lands. The four below are what the agent renders on the same incident detail — ranked hypothesis, Bitmovin-QoE-correlated panel, cross-vendor alignment, and same-frame viewer-side vs CDN-side pairing.
Ranked viewer-side hypothesis + confidence
The agent joins the captured Bitmovin Analytics events against the CDN, encoder, and DRM signals on the same bus and ranks root cause with a typed confidence score. The classification slug (viewer_side_buffering vs viewer_side_startup_regression vs viewer_side_bitrate_step_down vs viewer_side_error_rate_spike vs viewer_side_quality_score_drop) is what ranks — never the raw QoE numeric.
InvestigationCorrelationsPanel Bitmovin QoE row
The InvestigationCorrelationsPanel under the existing HypothesisList on /app/incidents/[id] renders the captured Bitmovin QoE candidate alongside the CloudWatch / CloudTrail / CloudFront rows. Every Bitmovin row carries the streaming-QoE head (bufferingRatio / startupTimeMs / bitrateKbps / errorRate / qualityScore) + the impression-id + the viewer region + the CDN provider + the typed anomaly class + the typed confidence score — same frame, same timeline, one ranked list.
Cross-vendor alignment ±30s of CloudWatch evidence
When a Bitmovin event capturedAt falls within ±30s of a CloudwatchEvidence row on the same incident, the InvestigationCorrelationsPanel surfaces the same `±Xs of CloudWatch evidence` chip every other watcher vendor carries — so a viewer-side regression that started at the player-side and a chart that started at the AWS-side control plane never silently belong to one symptom.
Same-frame viewer-side vs CDN-side pairing
On the incident close, the typed viewer-side remediation fans out as `streamwake.bitmovin.<viewer_side_classification>.remediation.applied` onto the Bitmovin Analytics workspace the operator already polls — so the same dashboard panel that flags the bufferingRatio surge renders the loop-closure metric the moment the fix lands. Operator can re-scrape it, alert on it, or fan it back into the CloudFront / CloudWatch / AWS MediaLive +X pairing without a retune.
Book a 20-minute walkthrough on your Bitmovin Analytics workspace.
We're happy to walk through how the per-impression bufferingRatio / bitrateSwitch / startupTime / errorRate / qualityScorediscriminator signals map onto your existing CloudFront + CloudWatch + AWS MediaLive pairing — and how the typed viewer-side classifications surface on the same investigation timeline the merged panel reads. Drop your details below and we'll follow up within 1 business day.