Telemetry: From F1 Cars to VR Headsets. Why We Measure What People Do and How They Do It

In this article:

1. What telemetry is
2. Telemetry in games
3. Telemetry in apps and business

Measurement at a distance

Telemetry is a word older than computers. The Greek roots are simple: tele — far, metron — measure. Measurement at a distance. The instrument is where something interesting is happening, and the person who wants to understand it is somewhere else — and gets a reading instead of travelling to the spot.

For most of the twentieth century that is exactly what telemetry looked like: a sensor, a transmission channel, a receiver. Sputnik 1 encoded the temperature and pressure inside its sphere in its famous beeps. A bedside cardiac monitor sends the ECG trace to the nurses’ station. A jet engine reports its parameters to the manufacturer in flight, before the aircraft lands.

Today the same word describes something broader: any system that records what a machine or a person is doing and passes it on to where someone can draw conclusions. Race cars fit that definition. So do mobile apps, games — and VR headsets.

Where telemetry is obvious: Formula 1

If you want to see telemetry in its purest form, look at F1. There are hundreds of sensors on a car; according to Mercedes, a single car generates over a terabyte of data across a race weekend, and two to three times that after post-processing. The temperature of each tyre, brake pressure, steering angle, suspension load on every kerb — all of it lands on engineers’ screens in the garage and back at the factory before the driver has exited the corner.

Two things in this example matter, because they come back when we talk about games.

First, F1 doesn’t only measure the machine. It measures the driver: braking point, smoothness on the throttle, the difference between two drivers in the same car in the same corner. Telemetry there is a tool for comparing people — with each other and with their own best lap.

Second, data without a question is useless. The team doesn’t read a terabyte; it reads a dozen charts that answer a specific question: why are we losing two tenths in sector three? The rest sits on disk in case the question changes.

Games: the end of guessing

The games industry discovered telemetry relatively late — roughly when games started to have a permanent internet connection. Before that, a designer knew as much about the player as they had seen in playtests: twenty people, two weeks, a sheet of notes. Then the game shipped and became a black box.

Telemetry opened that box. The classic questions it answers today in every major production:

• Where do players die? A death heatmap on a level shows in five minutes what a hundred surveys couldn’t. Bungie was publishing such maps for Halo 3 back in 2007.
• Where do players drop off? The tutorial funnel: how many started, how many reached the end, which step “eats” the most people.
• What is overpowered, and what does nobody use? Weapon, spell and build balance — from numbers, not from the forum.
• How long is a session, and when does the player come back? D1/D7/D30 retention — the language publishers and investors speak.

The common denominator: all these questions are about what the player did. Events. Clicked, died, quit, bought, completed. Telemetry in “flat” games is essentially a timestamped event log.

And it works. But in VR it’s only half the story.

VR: not just what, but how

In VR the input device is the body. Not a button — a hand that rises, a head that turns, a step to the side, a gaze that lingers on something a fraction of a second longer. Each of those movements is a data stream the headset produces dozens of times per second anyway, because without it a frame couldn’t be rendered.

For telemetry this changes everything. Suddenly what’s available is not only what the player did but how they did it. Continuous data — positions, rotations — is expensive, though: it has to be sampled and aggregated on the device rather than sent raw. And events need spatial context: “player died” without a position, a gaze direction and what they were holding is nearly worthless in VR.

How we use telemetry in our games

We know this subject from the inside. Our in-game telemetry system was built as an R&D project under the GameINN sectoral programme, co-funded by the European Union from the European Regional Development Fund under the Smart Growth Operational Programme. The premise from day one was a single layer for all our titles — regardless of engine or platform — rather than a set of scripts rewritten for every launch. That way the same metrics can be compared across games, and a new project gets measurement in the first week of production, not the last.

What we read from it, title by title:

The Wizards — gestures. Across the series, spells are cast with gestures, so the most important question is: does the recognition system understand the players, or do the players have to learn the system? We log every gesture attempt — successful or not — with execution time, an aggregated shape of the motion, and what happened next. That shows which spells have the highest failure rate, whether the problem affects everyone or, say, left-handed players, and at which point a player stops trying and falls back to the simplest fireball. The answer is surprisingly rarely “fix the recogniser”. More often: “fix the tutorial” or “change the tolerance threshold for this one gesture”.

Warhammer Age of Sigmar: Tempestfall — combat and fatigue. In a game where you swing a hammer, motion telemetry tells you how hard and how often players strike, and how that changes over a session. A drop in amplitude after twenty minutes is fatigue, not boredom — and you answer fatigue differently than boredom: with the rhythm of enemy waves, not with more enemies.

Hunt Together — the match as the unit. In a multiplayer game, questions about the player are joined by questions about the match: how long it lasts, how it ends (win, loss, someone left), how much time players spend in the lobby, whether they stick together or scatter across the map. This is telemetry that translates directly into balance and matchmaking — decisions the industry too often makes based on Discord, which means based on the loudest voices.

Arizona Truck Driver — cabin ergonomics. A VR driving simulator is, at heart, a workstation design project. Telemetry tells us where players’ heads sit relative to the dashboard, how they reach for switches, which elements they try to grab even though they aren’t interactive, and in which manoeuvres the number of steering corrections climbs. The cabin is set up by a developer with a specific height and arm reach; players have different ones. The data closes that gap.

Comfort — everywhere. Nobody fills in a survey saying “I felt sick”. But telemetry sees that after a specific locomotion segment sessions get shorter, the head starts moving differently, and the player takes the headset off more often. That is a how you cannot log as a single event — and in VR it is a more important metric than retention, because it precedes retention.

What’s in it for the developer

It’s easy to think of telemetry as a tool for the producer and the marketing department. For us the most interesting part is what the team actually making the game gets out of it.

• Bug reproduction. A session trace — the last events before a crash, the scene, position, device, build version — turns “works on my machine” into a concrete scenario to replay. In VR, where a bug often depends on where the player stood and what they held, that saves days.
• Performance in context. Frame time on its own says little. Frame time combined with where the player stood and which way they looked says: “that wall in that corner costs us three milliseconds”. On mobile headsets that start thermal throttling after a quarter of an hour, a map like this is the optimisation plan.
• Failed grabs. VR players try to grab everything. Logging grabs that hit nothing interactive is free affordance research: a ready-made list of objects that should be interactive, because players are certain they are.
• Real bodies and real rooms. The distribution of player heights, the share playing seated, play-space sizes, left-handedness, hand tracking versus controllers. Each of those numbers is a design decision that is otherwise made “by eye” — which means made for yourself.
• Defaults. Teleport or smooth locomotion, snap-turn angle, vignette — telemetry shows what players actually choose and when they change their minds. Good defaults are half of comfort.
• Build-to-build comparison. Did the tutorial change in the patch achieve anything? Without telemetry the answer is an opinion. With telemetry it’s two funnels side by side.
• The device fleet. The split across headset generations and platforms tells you where weeks of optimisation pay off and where a lower preset is enough.

The common lesson from all of the above: every measured parameter should have a question assigned to it that it answers. If it doesn’t — we don’t measure it.

B2B projects: what you can learn

In games telemetry serves the product. In projects for businesses it serves the person on the other side — the trainee, the customer, the visitor — and the client who wants to know whether the deployment is working. This is where it gets genuinely interesting, because the questions are different from games.

Training and simulators

A classic safety course or machine-operation training ends with a test: tick the correct answer. VR makes something else possible: put the employee in front of a virtual machine, have them carry out the procedure — and record every movement. Not “pass / fail”, but:

• in what order they performed the steps and where they hesitated,
• how long each stage took compared with an experienced operator,
• whether they looked at the pressure gauge before opening the valve, or only after,
• whether their hand entered a hazard zone — even if nothing happened,
• whether on the third repetition they do it faster, or merely less accurately.

That turns training into competence measurement. The trainer gets a record, not an impression. The company gets proof that the procedure was mastered — not merely listened to. Recordings of experts become a benchmark to compare novices against: “this is how the master does it” stops being a story and becomes a trajectory.

There is also something companies usually don’t expect. If eighty percent of trainees hesitate at the same point of the procedure, the trainees are rarely the problem. Step four is. Telemetry from training can be an audit of the procedure itself — and comparing shifts, plants or cohorts of new hires shows where to invest in further modules and which ones can be shortened.

PwC’s study of VR soft-skills training found that participants completed VR training four times faster than in a classroom and felt up to 275% more confident in applying what they had learned. Those numbers are impressive, but in our view the most important advantage of VR in training is different: it is the first form of training that records what the trainee did by itself. Without telemetry a VR simulator is just a more expensive instructional video. That is exactly the premise behind our VR/XR services for business: the measurement layer is not an add-on to a simulator. It is the reason the simulator is worth building.

Showrooms, configurators and visualisations

A virtual showroom or product configurator is an experience for the end customer and, for the company, market research that runs itself. Time spent on each element, viewing order, which variants people open and which they ignore, the moment the “wow” ends and the search for the exit begins. In architectural visualisations the same data shows which rooms visitors linger in and what they look at before they ask their first question. This is information a sales team normally gathers over months of conversations.

Events and activations

A VR experience at a trade fair or in a shopping centre without telemetry ends with a report saying “it was great, there was a queue”. With telemetry it ends with numbers: how many people completed the experience, after how long headsets came off, which scene lost people, how long the average run took and whether the staff kept up. The next activation is then designed on data, not on the hosts’ memories.

AI avatars

In projects with AI avatars, the conversation is the telemetry. What people really ask about, where the dialogue breaks down, which answers end in “that’s not what I meant”. For us it’s the way to improve the avatar. For the client it is often the first honest picture of what their customers are looking for, as opposed to what the marketing department thinks they should be.

Health, ergonomics, spaces

A VR exercise for a stroke patient is a game and a range-of-motion measurement at the same time — therapy progress shows up as a curve over time, not as “seems better”. An assembly workstation built first in VR and “staffed” by ten workers shows where they reach, how they bend and which movements they will repeat three hundred times a shift, before anyone pours concrete. A museum installation tells the curator what a heatmap tells a game designer: what people stand in front of, what they skip, when they take the headset off.

The pattern is always the same — a person, a sensor, a question. Only who reads the answer at the end changes.

The other side of the coin: motion is biometric data

This has to be said plainly, because the enthusiasm around “data about how people move” has a serious consequence.

In 2023 a team at UC Berkeley showed that from head and hand motion alone — no face, no voice, no login — a VR user can be uniquely identified in a pool of more than 55,000 people. After one hundred seconds of motion the accuracy was 94%; after ten seconds, 73%. The data came from public Beat Saber gameplay recordings. In other words: the way someone waves a controller is a fingerprint.

For anyone building VR telemetry this means the stream of positions and rotations is not an “anonymous log”. It is data that can identify a person and, combined with eye tracking, say something about their state, their attention, perhaps their health. GDPR has its articles for this; common sense has its rules:

1. Measure for a question, not for stock. If you don’t know what a parameter will be used for, don’t collect it.
2. Aggregate as close to the device as possible. An average, a histogram, a gesture-recognition result — instead of the raw trajectory, whenever you can.
3. Separate motion from identity. Motion data should not live in the same table as an email address.
4. Tell players and trainees what you measure — and why it works in their favour.
5. Set an expiry date. Data that no longer answers any question should disappear.

In training there is one more thing: the trainee has to know they are being assessed, and understand on what basis. A system that measures everything and then displays a single red number doesn’t build competence — it builds anxiety.

Where to start

If you’re building a game, a simulator or an XR application and are thinking about telemetry, a few pieces of advice from our practice:

• Start with a list of questions, not a list of events. “Why do players abandon level 3?” is a good start. “Let’s log everything” is a bad one.
• Every event in VR has a position, a gaze direction and a hand state. Without that context you can’t tell “didn’t notice” from “noticed and ignored”.
• The session is the unit of analysis. Not the user, not the event — a session with a beginning, an end and a reason for ending.
• Close the loop with design. Telemetry nobody looks at in the week when something can still be changed is an archive, not a tool.
• Playtests stay. Telemetry tells you what and how. Why still has to be heard from a human.

Measurement as a form of attention

We like to think of telemetry not as surveillance but as a form of attention. The F1 engineer looks at a chart to help the driver go faster. The trainer looks at a session record so the trainee doesn’t hurt themselves or anyone else. The game designer looks at a heatmap so the next player doesn’t get stuck in the same place.

In VR we have access to the richest stream of information about human behaviour that has ever been available outside a laboratory. The question isn’t whether to use it. It’s which questions we will allow it to answer — and whom those answers are meant to serve.