CMCD v2: Should Proprietary Metrics Providers Be Worried?

I’ve been thinking about recent CMCDv2 activity, and wondering what it means for the streaming delivery ecosystem we’ve spent many hours troubleshooting.

I’m sure you know the feeling:

It’s late. Something’s not right. Viewers are complaining. You’ve been paged and somewhere in the background there’s a senior voice asking which CEO they might need to call if this turns out not to be our fault.

You’re looking at network graphs, CDN dashboards, player analytics and QoE reports — and they’re not telling the same story.

So you triangulate. You line up timestamps. You compare metrics defined slightly differently. You try to work out which system is closest to the truth.

Eventually you piece together what actually happened.

However, you’ve had to stitch together multiple data sources, in different formats, across different platforms, just to reconstruct one session.

For years, that fragmentation has been normal. If you wanted deep session insight — startup time, rebuffer patterns, bitrate instability — you embedded one or more proprietary metrics SDKs in the player. Each with its own schema. Each feeding different downstream systems.

That wasn’t irrational. It was necessary and provided some absolutely rich data.

CMCD v1 helped. It standardised request-scoped player hints and made CDNs more context-aware. But it was still tightly coupled to segment requests and largely a delivery optimisation tool.

CMCD v2 is where the conversation changes.

For me it’s not just richer metrics. It’s multi-mode reporting — particularly event-mode signalling.

Telemetry is no longer chained to media requests.

Player health can be emitted on stall transitions, periodically, or when thresholds are crossed.

Telemetry cadence is no longer hostage to segment cadence.

That means session health can move beyond, client logs and CDN logs and become a portable, standards-based telemetry surface.

So here’s the question.

If startup behaviour, rebuffer patterns and stability signals can flow through an open specification — and steering engines can consume that telemetry directly — does some of what historically required proprietary plumbing become less structurally essential?

Maybe not all of it? but enough to reduce fragmentation in the control loop?

Today, streaming operations often involve CDN metrics in one system, player analytics in another, QoE scoring somewhere else, and steering logic in yet another platform — each with different schemas and time models.

CMCD v2 may not eliminate specialist system level analytics but it introduces the possibility that some of the signals feeding optimisation and steering can move through a common, interoperable layer.

That reduces stitching. It reduces translation. It reduces the number of times someone has to say, ‘Those numbers don’t match ours.’

So we’ve been trying to support that picture at Synamedia: Fluid Edge CDN already consumes CMCD for optimisation. Quortex Switch can ingest CMCD v2 telemetry directly as steering input.

That creates a tighter loop: Player → Standards-based telemetry → Steering decision → CDN selection → Player outcome.

CMCD v2 starts nudging the control plane.

So that’s what I’m thinking about and whenever open standards begin influencing the control plane, I think it’s worth asking the question:

“Are we looking at a meaningful shift in how standardized session telemetry feeds the control plane?”