What CS2 demo analysis can (and cannot) measure

What a demo actually contains

The server samples the game state around 64 times per second: every player’s position, view angles, movement, and every event — shots fired, damage dealt, kills, flashes. Crucially, it stores where your camera pointed at each tick, not what your mouse did between ticks, and it has no idea what your DPI, sensitivity or hardware are.

What can honestly be measured

• Flick size per kill — the angle between where you aimed before the engagement and where the kill landed.
• Overshoot / undershoot bias — comparing your first ballistic movement against the angle the kill required. Systematically long or short first movements are the strongest sensitivity signal a demo contains (this is the core of the AimFinder report).
• Correction time — how long you spend in small corrective movements between the initial flick and the kill shot. More corrections = more 150–250 ms penalties per fight.
• Crosshair placement — how far, in degrees, your crosshair sat from the eventual target when the fight started, vertically and horizontally. Great placement makes fights look like micro-adjustments; poor placement forces hero flicks.
• Movement state at the shot — whether you were still (properly counter-strafed) or moving when you fired, which decides rifle accuracy in CS2 regardless of aim.
• Time-to-kill patterns — from first sight or first shot to the kill, per weapon class.

What cannot be measured (by anyone)

• Your actual mouse movement. The demo sees the camera, sampled at tick rate. Sub-tick hand motion, grip, and micro-tremor are invisible; any tool claiming to read them from a demo is interpolating.
• Your settings. DPI and sensitivity leave no trace in the file. A report can only convert angles into recommendations once you tell it what you currently play at.
• Intent. Was that big swing a flick at an enemy or a repositioning of the camera? Analysis has to reconstruct engagements from context (damage events, sightlines, timing) — good heuristics get this right most of the time, not always.
• Context of form. Whether you were warmed up, tired, or tilted in match three is outside the file. One bad demo is a data point, not a diagnosis.

Why sample size decides everything

Every kill’s bias measurement is noisy: enemy movement, spray transfers and panic all add variance. Averages only stabilise across dozens of kills, which has two practical consequences. First, upload two or three recent matches rather than one highlight game. Second, be suspicious of any per-category number built on a handful of samples — AimFinder, for example, refuses to build its headshot-only precision segment from fewer than 8 headshot kills, and flags every figure with the sample count behind it.

The right way to use demo analysis

Use the demo to find your systematic errors — a consistent overshoot (see why you overshoot), a placement sitting half a head too low, shots fired while still moving. Then validate any sensitivity change under controlled conditions: the in-browser finder replays the same measurement with CS2-exact camera math and finishes with a blind A/B check, so the match data and the controlled test confirm each other. The full pipeline is documented on the methodology page.

Need the file first? Here is how to download your CS2 demos.