Streamwake + Conviva Analytics.
Don't replace Conviva — we correlate its session-scoped QoE signals against the CDN + origin signals and surface viewer-device failures on the same investigation timeline as Bitmovin.
Don't replace Conviva Analytics — we read the per-session QoE signals Conviva already emits (rebuffering ratio / exits-before-video-start / video-start failures / bitrate-ladder conformance / session QoE / alert notifications), 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 the Bitmovin pair lands on. 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.
Conviva Analytics viewer-side qoe — rebuffering ratio / exits-before-video-start / video-start failures / bitrate-ladder conformance / session qoe / alerts. Streamwake doesn't replace Conviva Analytics— we correlate its signals and drive remediation on the anomalies it already surfaces.
What Conviva 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.
Session-scoped player telemetry
Alert notifications + asset attribution
Detect → Classify → Fix on the viewer-device side
Bitmovin + Conviva paired viewer-side correlation
An incident closed
before your viewers notice.
Four steps from a Conviva Analyticsanomaly to a closed incident with a typed postmortem. Read top to bottom — the loop is closed end to end.
- 1
Configure the Conviva Insights workspace + alerts relay
Configure the Conviva insights export endpoint + redirect one Conviva alerts relay transport to point at the Streamwake inbound URL. The relay pushes one record per session QoE event or alert 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-session QoE events + alert notifications
The relay POSTs one Conviva Analytics envelope (rebuffer / ebvs / vsf / conformance / sessionQoe / alert) per session, discriminated by the typed `envelope.kind` discriminator. 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 — sessionId / assetId / region / cdnProvider / rebufferRatio / ebvsCount / conformanceScore / sessionQoeScore / alertSeverity / alertCode — as first-class columns on the row so the panel renders the summary inline without re-parsing JSON.
- 3
Correlate against CDN + AWS-side + align with CloudWatch
The correlator joins the captured Conviva events against the closest pull-side CloudwatchEvidence row for the same incident, scores each by a small typed heuristic (rebuffer > 0.05 → +30; ebvs ≥ 1 → +20; vsf with reason → +35; conformance < 0.6 → +25; sessionQoe < 70 → +30; alert severity-weighted critical +35 / major +25 / minor +10 / info +5; ±30s of CloudWatch → +20; region-matches → +10), and persists a ConvivaIncidentCandidate row typed by the streaming-native viewer-side anomaly class. Viewer-device-side failures stay distinct from origin-side regressions on the same incident frame.
- 4
Pair with the existing Bitmovin viewer-side lane
Conviva's session-scoped identity adds to (rather than replaces) the Bitmovin impression-scoped lane. The InvestigationCorrelationsPanel on /app/incidents/[id] renders Conviva candidate rows with the same typed confidence + reason chip the Bitmovin pair already carries, so an operator can see the session-level Bitmovin evidence AND a session-level Bitmovin evidence pair on the same frame. A clustering rate-of-rise or a cross-vendor `viewer_side_buffering_with_*` pair surfaces as one typed classification + one remediation.
Four failure modes Conviva Analytics alerts alone miss.
Each one is something the Conviva Analyticssignal exposes but the agent loop names and acts on — so a chart becomes a closed incident rather than a triage queue.
Viewer-side Rebuffering Surge (Conviva Session-scoped)
A Conviva Analytics rebufferingRatio lands > 0.05 on the same session id 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. Conviva fires a rebufferingRatio alarm in the dashboard; Streamwake catches the session-scoped 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.
Exits-before-video-start Cluster
A Conviva Analytics ebvs event lands with a count > 1 on a primetime window — the session-level "viewers leaving before video start" pattern surfaces before any CDN-side or origin-side chart surfaces a regression. Conviva fires the session-scoped 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_exits_before_video_start` so the player-side retry is the typed remediation — not a CDN retune that wouldn't have helped.
Video-start-failure Cascade
A Conviva Analytics vsf event lands with a vendor `reasonCode` (`MANIFEST_PARSE_ERROR` / `LICENSE_FAIL` / …) — the most likely cause is either a manifest drift upstream or a DRM cert handshake failure. Conviva reports the start-failure on the dashboard; Streamwake catches the reasonCode against the CloudFront edge 5xx + CloudWatch alarm stream on the same window, joins the two as a single typed classification `viewer_side_video_start_failure`, and queues a manifest retune or a DRM cert refresh before the second wave of start-failures hits.
Bitrate-ladder Conformance Drop
A Conviva Analytics conformance event lands with a score below 0.6 — the most likely cause is a bitrate-ladder mismatch between what the encoder output and what the CDN delivered. Conviva fires the per-session regression in the dashboard; Streamwake catches the conformance drop against the MediaLive channel-state stream + the CloudFront distribution cache hit rate on the same window, pins the typed classification as `viewer_side_conformance_drop`, and surfaces a per-title bitrate-ladder retune (re-encode or re-package) so the loop closes.
Session QoE Drop
A Conviva Analytics sessionQoe event lands paired with a quality-score drop below 70 — the most likely cause is a session-end cluster the AWS-tier signals haven't surfaced. Conviva fires the per-session pair in the dashboard; Streamwake catches the sessionQoe drop on the same signal, surfaces the `viewer_side_session_qoe_drop` classification, and queues a paired CloudWatch side retune (CDN region reroute + manifest retune) so the loop closes
Alert Notification Burst
A Conviva Alerts notification lands with severity `critical` / `major` carrying a `CDN_FAILOVER` / `PLAYBACK_ERROR_RATE` / … alert code — the most likely cause is a CDN failover / playback error rate already flagged elsewhere on the bus. Conviva fires the alert in the dashboard; Streamwake catches the alert notification against the CloudFront cache-miss latency fan-out + the CloudWatch alarm stream on the same window, joins them as a single typed classification `viewer_side_alert_raised`, and surfaces a paired viewer-side remediation so the loop closes before a second severity escalation lands.
Connect Conviva Analytics to your investigation timeline free.
Next to Conviva Analytics.
Paste your Conviva insights 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 session-scoped-QoE correlation lane on top of your existing Bitmovin + CloudFront + CloudWatch pairing.
Conviva session-scoped rebuffering paired against Bitmovin + CloudFront cache-miss latency.
conviva.session_rebuffer_ratio drifted to 0.16 vs 0.03 baseline across 4,210 sessions 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 Conviva-session-side + Bitmovin-impression-side + CloudFront-edge-side signal as viewer_side_buffering_with_bitmovin_pair_and_cloudfront_cache_miss_correlation at 91% confidence, emitted a paired CDN-edge reroute + a paired manifest bundle retune, and emitted the remediation back as streamwake.conviva.viewer_side_buffering.remediation.applied onto the Conviva Insights workspace — so the same dashboard panel that flagged the session-level rebufferingRatio drift re-renders the loop-closure metric the moment the fix lands.
Direct mapping to the Streamwake detect → classify → fix loop on the Conviva → Bitmovin → CloudFront signal bus — the same per-session rebufferingRatio drift AND the matching Bitmovin impression-level 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 Conviva Insights 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 ConvivaSourceCard and a companion inbound webhook card. Configure the source first, copy the per-tenant routerToken, wire your Conviva insights export relay to POST to /api/v1/conviva-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 Conviva insights export relay so a vendor-side HTTP transport POSTs one record per QoE / alert event to the Streamwake endpoint. The webhook shares 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":"rebuffer","upstreamId":"smoke-1","eventTime":"2026-08-24T00:10:16.875Z","sessionId":"smoke-session-1","assetId":"topgear-ep05","region":"us-east-1","cdnProvider":"cloudfront","playerType":"conviva-player-web","rebufferRatio":0.18,"durationSeconds":600}}'Recent QoE events
Loading…
What an operator needs on the Conviva side before the export relay can fan in.
What an operator needs in the Conviva Analytics account before the export relay can start pushing per-session QoE events to Streamwake. The list matches the source card on /integrations/conviva — the labels, the dropdown, and the radio channel-posture stay in lockstep with what is wired on the relay side.
Conviva Insights workspace + organization
The recommended posture is one Conviva Insights workspace + one organization — the free-form accountName + optional organizationLabelon the source card are the labels Streamwake renders inline. Pick labels an operator on the same Streamwake tenant can tell apart from a second Conviva workspace so the +Conviva island doesn't collide with a future second-tenant install.
Conviva Alerts 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 session QoE or alert 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 Conviva 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 |
|---|---|
| rebuffer | Per-session seconds-buffered / seconds-played. The headline Conviva 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 (Conviva)` candidate with a typed confidence score, aligned within ±30s of the closest CloudWatch row. |
| ebvs | Per-session count of exits-before-video-start. Conviva coalesces a small burst into a single record — surfaces as `viewer_side_exits_before_video_start` (score +20) on any positive count. Pairs 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. |
| vsf | Per-session video-start-failure carrying a vendor `reasonCode` (MANIFEST_PARSE_ERROR / LICENSE_FAIL / …). Surfaces as `viewer_side_video_start_failure` (score +35) — the highest weight in the Conviva heuristic set. ReasonCode is the typed signal itself, so the correlator pairs the start-failure against the CloudFront edge 5xx + CloudWatch alarm stream on the same window. |
| conformance | Per-session bitrate-ladder conformance (0..1, 1.0 = perfect ladder adherence). Surfaces as `viewer_side_conformance_drop` (score +25) when conformanceScore lands below 0.6. The correlator pairs the drop against the MediaLive channel-state stream + the CloudFront distribution cache hit rate on the same window so a per-title bitrate-ladder retune (re-encode or re-package) is the typed remediation. |
| sessionQoe | Per-session Conviva QoE score (0..100). Surfaces as `viewer_side_session_qoe_drop` (score +30) when the score lands below 70. Pairs against the existing Bitmovin `qualityScore` family on the same window so a session-level Conviva regression AND an impression-level Bitmovin regression both fit on the same investigation frame. |
| alert | Conviva alert notifications tagged by severity (critical / major / minor / info) + a vendor `alertCode` (CDN_FAILOVER / PLAYBACK_ERROR_RATE / …). Surfaces as `viewer_side_alert_raised` (severity-weighted: critical → +35, major → +25, minor → +10, info → +5). The alert notification tier is Conviva-specific — it never collapses with the Bitmovin telemetry on the same incident frame. |
Five steps from a blank source card
to a verified QoE event landing on the timeline.
The wire sequence the operator runs to attach Conviva Analytics to Streamwake as a session-scoped 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 Conviva Insights workspace
In your Conviva 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 Conviva workspace.
- 2
Pick the viewer region hint (optional)
If your Conviva insights export relay fans sessions 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 Conviva event's `region` matches. Leave empty to skip the cross-vendor region reason and rely on the typed rebuffer / ebvs / vsf / conformance / sessionQoe / alert classifications.
- 3
Wire the Conviva insights + alerts export relay
Configure one Conviva insights export endpoint + a Conviva alerts relay to point at the Streamwake inbound URL. The relay POSTs one record per session QoE or alert event with `{ as, sourceToken, envelope }` JSON. Wire it to redirect per event type (rebuffer / ebvs / vsf / conformance / sessionQoe / alert) so a single relay handles all six — the discriminated `envelope.kind` discriminator narrows per event.
- 4
Save the source + mint the router token
Save the source row on /integrations/conviva. The first save mints a per-source `routerToken` server-side (24 bytes hex) — copy the token into your Conviva export relay's URL as `?token=<routerToken>`. Conviva alerts relays do not natively sign HTTP transports, 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 `rebuffer=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 `convivaCandidateCount === 0 → seed correlator` flow.
Conviva insights alerts 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 ConvivaEvent row lands. The four below are what the agent renders on the same incident detail — ranked hypothesis, Conviva-QoE-correlated panel, cross-vendor alignment, and same-frame Bitmovin + Conviva pairing.
Ranked viewer-side hypothesis + confidence
The agent joins the captured Conviva sessions against the Bitmovin + CDN + AWS-side signals on the same bus and ranks root cause with a typed confidence score. The classification slug (viewer_side_buffering vs viewer_side_exits_before_video_start vs viewer_side_video_start_failure vs viewer_side_conformance_drop vs viewer_side_session_qoe_drop vs viewer_side_alert_raised) is what ranks — never the raw QoE numeric.
InvestigationCorrelationsPanel Conviva QoE row
The InvestigationCorrelationsPanel under the existing HypothesisList on /app/incidents/[id] renders the captured Conviva QoE candidate alongside the CloudWatch / CloudTrail / CloudFront / Bitmovin rows. Every Conviva row carries the streaming-QoE head (rebuffer / ebvsCount / conformance / sessionQoe / alert.severity + alertCode) + the session-id + the asset 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 Conviva 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 session-scoped regression that started at the viewer-device and a chart that started at the AWS-side control plane never silently belong to one symptom.
Bitmovin impression-level + Conviva session-level pairing
On the incident close, the typed viewer-side remediation fans out as `streamwake.conviva.<viewer_side_classification>.remediation.applied` onto the Conviva Analytics workspace the operator already polls — so the same dashboard panel that flags the session-level regression renders the loop-closure metric the moment the fix lands. Operators can re-scrape it, alert on it, or fan it back into the Bitmovin + CloudFront + CloudWatch + AWS MediaLive +X pairing without a retune.
Book a 20-minute walkthrough on your Conviva Analytics workspace.
We're happy to walk through how the per-session rebuffer / ebvs / vsf / conformance / sessionQoe / alertdiscriminator signals map onto your existing Bitmovin + CloudFront + CloudWatch + AWS MediaLive pairing — and how the typed session-scoped classifications surface on the same investigation timeline the merged panel reads. Drop your details below and we'll follow up within 1 business day.