Should I build my own getStats collector?

Sooner or later someone on your team suggests it. getStats() is right there in the browser, a polling loop is twenty lines, and the metrics land in a table you already own. The instinct is reasonable and the first version works. The cost arrives later, and it arrives in two places:

1. The stats move under you
2. Somebody has to keep up with them.

What a collector has to do

The polling loop is the small part. A collector that answers a real support ticket has to wrap RTCPeerConnection so it sees the session from the first offer, record the offer/answer exchange and the ICE candidates, capture getUserMedia calls with their constraints and their failures, watch enumerateDevices for the headset that appeared halfway through the call, poll getStats() on an interval and keep the series rather than the last reading, and then send all of it somewhere durable over a connection that is itself on the user's flaky network. It has to do that without adding latency to the call, without holding the session in memory until the tab crashes, and without losing the last ten seconds when the user closes the window.

Each of these pieces is small on its own. Together they are a project.

The stats move under you

The WebRTC statistics API is a living spec, and Chrome tracks it. The legacy callback form of getStats() is gone. The goog-prefixed stats that most early collectors were built on are gone. The track stats type was deprecated and its fields redistributed across media-source, inbound-rtp and outbound-rtp, which means a collector written against track did not throw an error when the change was made. It kept running and quietly returned less. That is the failure mode worth planning for.

Another aspect is additional metrics and APIs that can and should be collected to get a broader picture of the user experience. Compute pressure is such an API.

A snapshot vs a timeline

Many homegrown collectors store the final reading, or an average across the call, because that is what fits a row in a table. Others collect a small fraction of the metrics they deem important. In both cases, this leads to being unable to troubleshoot a user's complaint beyond being stating that something went wrong.

Keeping the series across all metrics costs more storage and more thought about sampling than keeping a summary does, so it is the part that gets deferred, and it is the part most needed to troubleshoot.

See experience score and other scores for how rtcStats reduces the series once it has one.

Who owns it in eighteen months

This is the biggest question, and it is an organizational one rather than a technical one.

The collector gets written by whoever is deepest in WebRTC on your team, during a week when debugging pain is fresh. It works. The pain goes away, that engineer moves to another part of the product or to another company, and the collector becomes a file nobody opens until it is already wrong.

There is no test that fails when Chrome deprecates a field, because the shape of the response is still valid. Budget for a recurring owner who reads the WebRTC release notes and re-checks the collector against a real session every few releases, or accept that the thing you built to answer support tickets will itself become one. The honest version of the build decision prices that owner in from the start, alongside the week it takes to write the first version.

When writing your own is the right call

There are real cases. If you need three numbers and only three numbers, a fifteen-line loop that writes them to your existing metrics pipeline is the correct amount of engineering and this page is not arguing otherwise. If your environment forbids third-party client dependencies outright, you write your own or you collect nothing. If you are instrumenting a non-browser stack where the standard library does not apply, you are building anyway.

The useful test before you start is to write down the last three support tickets you could not close, then ask which fields a collector would have needed to close them. If the answer is a handful of numbers, build it. If the answer is the whole session, you are scoping the project.

What rtcstats-js gives you instead

rtcstats-js is the maintained version of that project, and it is open source. It wraps the WebRTC globals, captures the lifecycle, the media calls, the device list and the getStats() series, and streams the trace to rtcstats-server, which you run in your own infrastructure. All of it is free and open source.

In rtcstats-server, what happens with the dump files is yours to decide:

• Configure privacy to strip what you do not want to leave your network
• Query the extracted features in your own SQL; or
• Send sessions to rtcstats.com for Observations, Deductions and an Experience Score

You are not handing over the collection layer to get the analysis, and the choice is per session rather than all or nothing. The maintenance argument above is the whole point of the arrangement: the part that has to track every Chrome release is the part that is shared and maintained in the open, and the part that holds your users' data stays on your side of the network. Start at the integration guide.

NOTE: Can't get this to work? Need help? Contact us