🎯 CS2 Squad Stats

Each player is scored on seven attributes — Firepower, Entrying, Trading, Opening, Clutching, Sniping and Utility — that break down how a player contributes, rather than collapsing everything into a single number. Every attribute is scored from 0 to 100, where 50 is roughly an average player, higher is better, and the best and worst players sit near the extremes.

The scores are relative to this specific pool of players. A rating of 70 means "70 compared to these players," not an absolute measure of skill that would hold against any other group. Add or remove players and the scores shift, because every score is a statement about where a player stands within this field. This is deliberate: the ratings exist to compare these players to each other, and that is the only thing they claim to do.

The rest of this page explains, in order, how a single attribute score is built from raw stats, how the system handles players with very little data, what the 0–100 scale means, what each of the seven attributes measures, and — at the end — how to read the scores honestly, including the things they can't tell you.

Every attribute is built the same way, in five steps, from raw stats to a final 0–100 number.

Step 1 — Choose the stats. Each attribute draws on a small set of stats that measure it. Firepower uses kills and damage per round, multi-kill rounds, and so on; Utility uses grenade damage, flash assists, and flash time. The stats for each attribute are listed in the attributes section below.

Step 2 — Normalize each stat. Different stats live on different scales — kills per round runs from about 0.3 to 1.0, while damage per round runs in the tens. To combine them fairly, each stat is converted to a z-score: how many standard deviations above or below the pool average a player sits.

where x is the player's value, μ is the pool average for that stat, and σ is the pool standard deviation. A z-score of 0 is exactly average; +1 is one standard deviation above the field; −1 is one below. After this step, every stat is on the same footing — a +1 in kills means the same as a +1 in damage, regardless of the original units.

Step 3 — Adjust for sample size. Some stats are computed over rare events — a player might have faced only three 1v1 clutches all season. A rate built on three attempts can't be trusted the way one built on three hundred can. Before normalizing those stats, the system pulls uncertain values toward the average by an amount that depends on how little data there is. This is explained in full in the next section.

Step 4 — Combine the stats. The normalized stats are averaged into a single number for the attribute. Most attributes weight their stats equally; a few weight one stat more heavily where it clearly matters most (for example, Clutching leans on clutch points, since that is what actually winning clutches produces). The weighting for each attribute is noted in the attributes section.

Step 5 — Scale to 0–100. The combined z-score is stretched onto the 0–100 scale so the numbers are readable.

An average player (z = 0) scores 50. Each standard deviation is worth 30 points, so a player one standard deviation above the field scores 80. Scores are capped at 0 and 100 at the ends. The scale and the cap are covered in more detail below.

This is the least obvious part of the system, and the most important for trusting the numbers, so it gets its own section.

The problem: some stats are computed over rare events. A player might have taken only three opening duels, or faced two 1v1 clutches, in the entire sample. If one of those two clutches was a win, their 1v1 win rate reads 50%. If both were wins, it reads 100%. Neither number means the player is a good clutcher — there simply isn't enough data to say anything. Left alone, a player who went 2-for-2 on 1v1s would rank as the best clutcher in the pool, ahead of someone who went 180-for-320. That is obviously wrong, and it is exactly the kind of error that would make the whole system untrustworthy.

The fix is a technique called shrinkage. Before a rare-event stat is normalized, each player's value is pulled toward the pool average by an amount that depends on how much data backs it up. A player with a huge sample barely moves; a player with almost no data is pulled most of the way to average. The formula is:

where events is what the player actually did (say, 1v1s won), opportunities is how many chances they had (1v1s faced), p is the pool average rate for that stat, and k is a constant that controls how aggressively small samples are pulled in. In effect, every player is credited with k extra "average" attempts. If they have thousands of real attempts, those k fakes are a drop in the ocean and their true number stands. If they have three, the fakes dominate and they revert toward the average.

Which stats get this treatment. Only stats built on rare events are shrunk — 1v1 win rate, opening-duel success, the share of a player's kills that were with the AWP, and similar. Stats measured per round are left alone: every player has hundreds of rounds, so a per-round rate (kills per round, damage per round, flash time per round) already rests on plenty of data and needs no adjustment.

One honest consequence. When a player has no data at all for a rare-event stat — a player who never faced a 1v1 — shrinkage defaults them to the pool average. This is the correct thing to do, because the alternative is either an error or a fabricated number. But it means a score built partly on such stats can, for a no-data player, mean "we don't have enough information" rather than "this player is average." Where this matters, it is flagged in the how-to-read section at the end.

Every attribute is reported on the same 0–100 scale, and keeping it the same across all seven is deliberate. Recall from step 5 that the score is:

This does two things. It sets 50 as the average — a player who is exactly at the pool mean on every stat scores 50. And it sets the value of one standard deviation at 30 points — a player one standard deviation above the field scores 80, two above scores 110 (before capping), one below scores 20. The multiplier of 30 was chosen so that the realistic range of players spreads across most of the 0–100 band without everyone bunching into a narrow strip in the middle.

Why the same scale everywhere. Because every attribute uses the same conversion, a score means the same thing regardless of which attribute it comes from. An 80 in Firepower and an 80 in Utility both describe a player one standard deviation above the field in that attribute. This is what makes a player's profile readable at a glance — you can line up their seven scores and compare them directly, because they are all measured in the same units. If each attribute had its own scale, an 80 here and an 80 there would not be comparable, and the profile would be meaningless.

The cap. A truly exceptional player can land above a z of about +1.7, which would push their raw score past 100; a truly poor one can fall below 0. These are clamped to 0 and 100. This keeps the scale clean, but it has a consequence worth knowing: at the very top and very bottom, players can be tied at 100 or 0 even though their underlying performance differs slightly. The cap compresses the extremes. For the vast majority of players, who sit comfortably inside the range, this never comes into play — but it is why you will occasionally see two elite players both reading 100 in the same attribute.

Each attribute is described below: what it measures, the stats it draws on, and any notable decision in how it's built. Every stat listed is normalized and combined as described above; only the stats specifically noted as sample-size-adjusted are shrunk.

The ratings are built to be accurate about what they measure, which means being clear about what they don't measure. None of the points below are flaws to work around — they are direct consequences of how the system works.

Round Swing measures how much each player changed their team's chance of winning the round, added up across a match and averaged per round. It does not count kills, reward damage, or score good play in the abstract. It asks one question of every event on the server — did this move the round toward a win or away from it, and by how much — and assigns the answer to the players responsible. A kill that flips a coin-toss round into a near-certain win is worth a great deal. A kill traded back immediately, or taken when the round was already decided, is worth almost nothing. The metric prices impact on the one thing that actually matters at the end of a round: whether you won it.

The number is expressed as a percentage. A Round Swing of +5 means that, on average, the player personally added five percentage points of round-win probability every round. Across a match that compounds into the difference between winning and losing. The scale is small on purpose — round-win probability only ranges from 0 to 100, and a single player can only be responsible for part of each round's movement — so the values that look modest are not. Anything above roughly +8 is an elite, match-carrying performance; anything below roughly -8 means a player was actively costing their team rounds. Most players land between those bounds.

Everything below explains, in order, where the win-probability numbers come from, how a single kill is priced, how that price is split between the players involved, how the special moments of a round (the bomb plant, the clutch, the save) are handled, and — at the end — how to read the final number honestly, including the things it cannot tell you.

Every swing in this system is a difference between two probabilities, so the whole metric rests on one question: given the state of a round, how likely is each side to win?

The answer comes from data, not theory. For each map, every round played in a large sample is broken down into the situations it passed through, and the eventual winner is recorded. From that, the system builds a table of empirical win rates. The table is indexed by three things: how many Terrorists are alive, how many Counter-Terrorists are alive, and whether the bomb has been planted. Each cell holds the share of historical rounds in that exact situation that the Terrorists went on to win.

So a cell might say: with 5 Terrorists and 4 Counter-Terrorists alive and no bomb down, the Terrorists won 70.9% of the time. With 5 alive on each side and no plant, it is roughly a coin flip — 50%, as you would expect, since the sides are even. As players die, the number moves toward one extreme or the other. As the bomb is planted, the whole table shifts in the Terrorists' favor, because a planted bomb wins on its own timer unless defused.

There are two tables per map — one for before the plant, one for after — and each is a six-by-six grid running from five players alive down to zero. These tables are the reference against which every event is measured. They are specific to each map, because maps play differently: a 5-versus-4 situation is not equally winnable on every layout, and the data reflects that. The tool carries a separate pair of tables for each map and uses the correct one based on which map the game was played on.

See the probability matrices here → cs2_round_win_matrix

Two properties of these tables matter for reading the numbers later. First, they are empirical, so they inherit the sample they were built from — a situation that occurred thousands of times gives a trustworthy number, while a situation that occurred a handful of times gives a noisy one. Second, some situations essentially never happen — a bomb planted while all five Counter-Terrorists are still alive, for instance — and those cells have no data at all. The system treats a no-data cell as undefined and refuses to compute through it, rather than inventing a number. That refusal is deliberate and is discussed later.

With the tables in place, pricing an event is simple in principle: look at the win probability before the event, look at it after, and take the difference.

Concretely, suppose the round is 5-versus-5 with no plant, and your team is on the Terrorist side. The table says your win probability is 50%. One of your players kills an opponent. Now it is 5-versus-4, and the table says 70.9%. The kill moved your team from 50% to 70.9% — a swing of +20.9 percentage points. That swing is the value of the kill, and it is credited to the player who made it.

The same logic runs in reverse for deaths. If instead one of your players had died, taking the round to 4-versus-5, the table says your win probability drops to 29.1% (the mirror of the opponents' 70.9%). That is a swing of -20.9, and it is charged to the player who died. Every death costs the victim the probability the team lost by their dying. This is intentional: dying is the single most consequential thing a player does to a round, and the metric holds them accountable for it in exact proportion to how much it hurt.

There is one wrinkle that has to be handled carefully: sides. The tables are always written from the Terrorists' point of view — every cell is a Terrorist win probability. But your team is only on the Terrorist side for one half of the match; after the switch, you are the Counter-Terrorists. When your team is on the Counter-Terrorist side, the metric flips the table read: your win probability is 100 minus the Terrorist number. A Terrorist kill that the table prices as good for Terrorists is, from your Counter-Terrorist perspective, bad — and the sign of the swing flips accordingly. The tool determines which side you are on for each round directly from the match data, so this is automatic, but it is the reason the same event can be worth +20 to one team and -20 to the other. Every point one team gains, the other loses. At the level of a single kill, Round Swing is zero-sum between the two teams.

A kill is rarely the work of one player alone. Someone may have dealt damage or thrown the flash that set it up; someone may have died a moment earlier, and this kill is the revenge that trades them back. The metric does not hand the entire swing to the player who happened to land the final bullet. It splits the swing among the players who contributed, using a fixed set of rules. The splits are the same for every kill of a given type, so the system is consistent and never makes a judgment call in the moment.

There are four cases.

A plain kill, with no assist and no trade, gives the entire swing to the killer. If the kill was worth +20.9, the killer gets +20.9.

An assisted kill splits the swing between the killer and the assister, 76.9% to the killer and 23.1% to the assister. The killer did most of the work — they won the duel — but the assist mattered, and the roughly three-to-one split reflects that. On a +20.9 kill, the killer receives +16.1 and the assister +4.8. Only assists from your own team count; an assist credited to an enemy player is irrelevant to your team's numbers and is ignored.

A trade kill splits the swing between the killer and the teammate whose death is being avenged, 76.5% to the killer and 23.5% to the traded teammate. A trade is defined precisely: the player you just killed had, within the previous five seconds, killed one of your teammates. When that condition holds, the teammate who died gets a share of the trade, because their death created the opportunity — the opponent was exposed, out of position, or reloading, and your kill capitalized on it. If more than one teammate was recently killed by that opponent, the trade is attributed to the most recently killed one. The five-second window is the standard convention for what counts as a trade, and the split rewards the teammate's sacrifice without pretending it did as much as the kill itself.

A kill that is both assisted and a trade divides the swing three ways. If the assister and the traded teammate are different people, the killer takes 76.5%, the assister takes 17.65%, and the traded teammate takes 23.5%. If the assister and the traded teammate are the same person — the teammate who died is also the one who assisted the revenge — that person's two shares combine, and the split is 58.85% to the killer and 41.15% to the combined contributor. In every case the shares sum to the full swing; the credit is redistributed, never created or lost.

These percentages are a chosen convention. They are not derived from a deeper truth about how much a flash "really" contributes versus a bullet; no such truth exists to derive them from. They are a consistent, defensible rule for dividing shared credit, applied identically to every kill, so that the system treats every player the same way. That consistency is what makes them fair, not any claim that 76.9 is the cosmically correct number.

The plant is not a kill, but it changes the round's win probability sharply, because it switches which table applies. Before the plant, a 2-versus-3 situation with your team on Terrorists might be worth 23.5%. The instant the bomb goes down, the same 2-versus-3 is read from the plant table, which might value it at 63.9% — the bomb now wins on its timer unless the Counter-Terrorists both defuse and survive. That is a swing of more than +40 percentage points, and it happens the moment the plant completes.

The metric recognizes this jump and prices it, but credits it to no one. The plant is a team action — it depends on the player who planted, the players who cleared the site, the players who held the flanks — and attributing forty points of swing to whoever happened to press the plant button would badly misrepresent it. So the plant's swing is real, it moves the running probability that later events are measured against, but it appears in the calculation as belonging to nobody. This is the honest choice: the metric knows the plant mattered, and it declines to pretend it can say which single player deserves the credit.

When the round ends, there is usually a gap between the last win probability the table showed and the actual outcome. The table might say your lone survivor had a 42% chance in their 1-versus-1, but they won — reality delivered 100%, not 42%. That leftover 58 points has to go somewhere, and how the metric assigns it is what lets it value clutches and saves correctly.

The rule is one formula, applied to every round the same way: take the final outcome (100 if your team won, 0 if it lost) and subtract the last win probability the round reached. The difference is the resolution, and it is assigned to the players who were still alive at the end.

Consider a clutch win. Your last player is alive in a 1-versus-2, which the table values at, say, 16%. They win both duels and take the round. The resolution is 100 minus 16, or +84, and it goes entirely to that surviving player. They earned it — they converted a situation the data said they should lose most of the time — and the metric rewards them with the full gap between expectation and result. This is on top of the swings from the two kills themselves, so a clutch is valued richly, as it should be.

Now consider a clutch loss, or a save. Your last player is alive in that same 1-versus-2, and this time they lose, or they choose to save their weapon and not contest. The round ends with your team losing. The resolution is 0 minus 16, or -16, charged to that last player. This is the honest counterpart to the clutch win: if surviving players get the full credit when they beat the odds, they must take the debit when they fail to, or choose not to try. A player who saves repeatedly in winnable situations will accumulate these small negative resolutions, and the metric will show it.

The same formula handles the case where your whole team is wiped. If nobody survives, there are no survivors to assign the resolution to, so it falls on the last player to die. And when your team wins by eliminating the opponents entirely, the final probability is already 100 and the resolution is zero — there is nothing left to assign, because the kills already told the whole story. One formula, final outcome minus last probability, covers the clutch win, the clutch loss, the save, the wipe, and the clean elimination, without any special cases.

Each round produces a set of per-player awards: swings from kills and deaths, splits from assists and trades, and the end-of-round resolution. These are summed within the round to give each player's round total, and the round totals are summed across the match. The match total is then divided by the number of rounds played to give the final Round Swing — the average probability the player added or cost per round.

The divisor is the actual number of rounds in the match, not a fixed number. A game that ends 13-7 has twenty rounds and divides by twenty; a game that goes the full distance divides by twenty-four; a game that reaches overtime divides by however many rounds overtime actually ran. Dividing by rounds played, rather than a constant, keeps the metric comparable across games of different lengths: it is always "probability added per round," whatever the round count happened to be.

To see the whole system at once, follow a single round. Your team is on Terrorists, 5-versus-5, no plant, win probability 50%.

Add up every award in the round, and you have each player's contribution to a round that started as a coin flip and ended as a win.

The metric is built to be accurate about the one thing it measures, which means being clear about what it does not measure. None of the points below are flaws to work around; they are direct consequences of how the system works.

Every player is given a single number for each map they play — a rating where 1.00 is an average performance in this pool, higher is better, and the best and worst maps sit near the extremes. It is built in the mould of HLTV's Rating 3.0: five performance sub-ratings plus a context term called Round Swing, combined into one figure. It is not a copy of HLTV's rating — the exact weights and the economy adjustment that HLTV keeps private are not reproduced here — but it is built on the same skeleton and reads on the same familiar scale.

The scores are relative to this specific pool of players. A rating of 1.20 means "20 percent above the average of these players," not an absolute measure of skill that would hold against any other group. Add or remove players and the baselines shift, because every score is a statement about where a map stands within this field. This is deliberate: the rating exists to compare these players to each other, and that is the only thing it claims to do.

The rest of this page explains, in order, how a single map rating is built from raw stats, how each of the six components is defined, how they are combined, and — at the end — how to read the numbers honestly, including the things they cannot tell you.

Every map rating is built the same way, in three stages, from raw stats to a final number.

Stage 1 — Turn totals into per-round rates. Rounds are the unit of Counter-Strike, so every raw total is first divided by the rounds played on that map. A player's kills become kills per round, damage becomes damage per round (ADR), and so on. This puts a 16-round blowout and a 30-round overtime marathon on the same footing — a player is judged by their rate, not by how long the map happened to run.

Stage 2 — Express each rate relative to the field. A rate on its own means little until you know what average looks like. So each component is divided by the pool's average for that stat, producing a number centred on 1.00. A player with a kills-per-round of 1.03 against a field average of 0.72 gets a Kill sub-rating of about 1.43 — they are landing 43 percent more kills per round than the typical player here. An exactly average player scores 1.00 on every component. This is the core idea the whole rating rests on: every component is a ratio to its own baseline, so 1.00 always means "average."

Stage 3 — Combine the components with weights, then recentre. The six components do not matter equally. They are blended with fixed weights that follow HLTV's published structure — roughly a 60/40 split between output (kills, damage, multi-kills) and the cost paid for it (survival, KAST) — with kills carrying the single heaviest weight, and Round Swing layered on as a reduced context modifier rather than a co-equal term. The weights are not secret here: they can be changed, and everything downstream recalculates. After combining, the population average is nudged back to exactly 1.00 by a single divisor, so the average map in the pool reads as exactly 1.00 and the scale means what it says.

Each component is a per-round rate expressed relative to the field, centred on 1.00. Five of them describe what a player did; the sixth adds the context of when they did it.

Kill Rating. Kills per round divided by the field average. This is the backbone of the rating and carries the most weight — how much a player frags, relative to everyone else in the pool. It is the closest thing to "how hard does this player hit." One simplification is worth naming: HLTV discounts kills where the player personally dealt very little damage (cleanup taps on an enemy a teammate already broke). That discount needs per-kill damage data, which these aggregates do not contain, so it is omitted. The backbone — kills per round against the field — is intact.

Survival Rating. Built from how often a player stays alive, but refined the way HLTV refined it. A raw survival rate would flatter a player who saves every lost round and punish an entry fragger who dies usefully. So two adjustments are made: surviving a lost round (a save) counts for only half of a normal survival, and a death that a teammate immediately traded counts for only half of a normal death — because the team recovered the man, so the death cost little. This rewards dying usefully and stops treating cowardly saves as elite play.

Damage Rating. Average damage per round divided by the field average. It captures the contribution that does not always show up as a kill — the shots that soften enemies for teammates, the spread damage across a site hit. Because damage and kills are correlated but not identical, this rewards players who do work the scoreboard's kill column misses.

KAST Rating. The share of rounds in which a player got a kill, an assist, survived, or was traded, divided by the field average. It is a consistency stat: it asks whether a player contributed something useful most rounds, rather than going missing. Because almost every player lands somewhere between 60 and 85 percent, KAST is naturally compressed and pulls everyone toward the middle.

Multi-kill Rating. Multi-kill rounds per round divided by the field average. This is an explosivity measure — the player who takes over rounds with 3Ks and 4Ks rather than trading one-for-one. It has the widest natural spread of the five, because multi-kills are volatile from map to map.

Round Swing. The one component that is not a simple rate. Swing measures how much each kill actually changed the outcome of the round, using round-win-probability: a kill in a tense 3-on-3 counts for far more than an anti-eco tap in a round the team already wins 96 times out of 100. It is converted from raw win-probability points into a modifier centred on 1.00 and blended at a deliberately moderate weight. HLTV originally released Swing heavy, found it overshadowed raw fragging, and dialled it back to an impact modifier — this rating follows that corrected, current form rather than the first version.

The six components are combined into one number, then a single adjustment fixes the scale.

Recentring. Because Swing carries a small residual offset and ratios do not average perfectly to 1.00, the combined figure is divided by its own pool average. This pins the average map in the pool to exactly 1.00, so the scale means what it says: a player above 1.00 was above the field on that map, a player below it was below, and the distance from 1.00 is the size of the gap.

The rating is built to be accurate about what it measures, which means being clear about what it does not. None of the points below are flaws to work around — they are direct consequences of how the system works.