← Back to NextFrag

What CS2 Demo Analysis Can and Cannot Measure

A trustworthy analyzer should explain its limits before its features. CS2 demo files contain a lot of useful information, but not everything that matters in a duel. This page is the honest scope: what NextFrag reads directly from a demo, what it derives, what it estimates with confidence, and what it deliberately does not claim to measure.

If you came here looking for a product overview, that lives at CS2 demo analyzer. This page is about methodology and trust.

Why Demo Analysis Is Powerful

Demos record the simulated game state. Every shot, every position update, every weapon event, every damage call — they were authored by the server, not reconstructed after the fact from highlight clips. That makes them the closest a player can get to the underlying physics of their own match without instrumenting the game.

For mechanics — movement state, shot timing, hit and miss patterns — that is the right level of evidence to use.

Why Demo Analysis Is Not Magic

A demo is a record of the simulation as the server saw it. It is not a record of the player's monitor, the player's hand, or the network path between them. Anything that lived only in those layers is invisible to the demo.

Pretending otherwise is how analytics tools start lying to users. We would rather under-claim and stay accurate.

Directly Observable Signals

These come straight out of the demo with no inference required:

• Shot events. When a weapon fired, what weapon, by whom.
• Damage events. Who damaged whom, how much, with what weapon, where it hit.
• Player positions. Coordinates per tick.
• Movement state. Crouching, walking, running, in-air.
• Velocity. Speed and direction per tick.
• Weapon events. Equip, reload, scope, switch.

Derived Metrics

These are computed from the directly observable signals above. They are not invented — they are deterministic functions of the underlying tick data — but reasonable people can disagree on the exact recipe:

• Clean shot percentage. Combines shot events with velocity at fire tick. See counter-strafe analysis.
• First-shot accuracy. Combines shot events with hit/miss outcome. See first bullet accuracy.
• Spray discipline. Compares the player's recoil compensation pattern to the weapon's expected curve.
• Sensitivity overshoot / undershoot. Compares flick endpoints to target angles. See sensitivity guide.
• Engagement summaries. Per-duel breakdowns assembled from positions, weapon events, and damage.

Confidence-Dependent Signals

Some metrics depend heavily on sample size and engagement type. NextFrag attaches a reliability indicator where this matters:

• Reaction timing. The interval between an enemy becoming visible (server-side) and the player's first shot. Useful in aggregate, noisy in individual cases.
• Recommendations from small samples. A sensitivity recommendation based on 12 flicks is not the same as one based on 80.
• Reconstructed duel context. Who saw whom first, who peeked into whom, how a trade developed. The demo gives strong evidence, not certainty.

What Demos Do Not Measure

• True click-to-photon latency. The full chain — mouse, OS, game, network, server, network back, GPU, monitor — is not in the demo.
• Monitor latency. Pixel response and refresh behavior live on hardware the demo never sees.
• Mouse sensor latency. Polling rate and sensor lag are local to the player's setup.
• Player fatigue, tilt, and mood. A demo can show a duel where you played badly. It cannot tell you whether you were tired.
• Full network truth. Lag compensation, interpolation, and packet loss can produce in-game outcomes the demo file smooths over.
• Every subtick nuance with perfect certainty. CS2's subtick model is more granular than the per-tick playback model used in many tools. Sub-tick details may be approximated.

Why Reliability and Confidence Warnings Matter

The point of an analysis is to change behavior. If the analysis is over-confident on weak data, the player changes the wrong thing. That is worse than no analysis at all. NextFrag attaches a reliability score to recommendations that depend on sample size, and warns when a metric is computed from too few engagements to drive a decision.

How to Read Your Result Without Fooling Yourself

• Trust patterns, not single values. Compare a metric across two or three demos before reacting.
• Match the metric to the context. Deathmatch flick data is great for sensitivity. Competitive engagement data is better for first-shot habits under pressure.
• Pick one priority. The point is to fix something, not to score yourself. See CS2 demo to training plan.
• Re-test. The honest measure of improvement is the next demo, not your perception of the next match.