I spent an evening adjusting football statistics for how much of the ball each
team had. The correction was obvious, took ten minutes, and made the result
measurably worse.
The mistake is not specific to football. It happens any time you normalise a
count by an exposure variable — requests per user, errors per deploy, sales per
visit — and it is invisible unless you measure the thing you were trying to fix.
The setup
I have a vector space of 1,419 footballers built from 5.3 million events across
four leagues. Each player is 17 dimensions: passes per 90 minutes, progressive
carries per 90, share of aerial duels won, and so on, each converted to a
percentile against every other player. Cosine similarity between two vectors is
"these two play alike".
Position is never given to the model. That the eight players nearest a centre
back turn out to be eight centre backs is the evidence that the space captures
playing style at all.
It worked, with one obvious flaw. Gerard Piqué's nearest neighbour was Jérémy
Mathieu — his own centre-back partner at Barcelona. Sergio Busquets sat next to
two other holding midfielders from Spanish possession sides.
The reason is not subtle. Barcelona had 67% of the ball that season. Carpi had
38%. A Barcelona player touches it 1.74 times as often as a Carpi player, so
every per-90 count is partly a measurement of his employer rather than of him.
The obvious fix
If a player sees 1.74× as much of the ball, divide his counts by his team's
possession share. Restore everyone to a level playing field. One line of numpy.
To check whether it worked I needed a metric for the defect itself. I used the
correlation between a player's team possession and the mean team possession of
his eight nearest neighbours. If the space is contaminated by possession, the
players nearest you will come from teams that hold the ball like yours.
no correction 0.695
divide by possession 0.572
chance baseline 0.000
Better. But nowhere near fixed, for a correction that should have removed the
effect almost entirely. Something was wrong.
The arithmetic
The relationship between a metric and possession is affine, not
proportional:
metric ≈ a + b · possession
There is an intercept. A player makes some passes regardless of how much his
team dominates — he receives it, he plays it, the game happens.
Divide that by possession and you get:
(a + b · possession) / possession = a/possession + b
That first term is a hyperbola. It decreases steeply as possession rises.
So dividing does not remove the possession signal — it removes one and injects
a new one of the opposite sign. Overcorrection, dressed up as a fix.
Division is only correct when the relationship passes through the origin. It
almost never does.
The right operation is to subtract the fitted line and keep the residual:
b = np.polyfit(possession, metric, 1)
adjusted = metric - np.polyval(b, possession)
That removes exactly the linear component and nothing else. No intercept
smuggled into a denominator.
no correction 0.695
divide by possession 0.572
residualise 0.450 ← adopted
chance baseline 0.000
Role coherence, meanwhile, was unaffected — 76.3% to 76.8% — so the correction
cost nothing in the thing I actually wanted the space to do.
The other thing I got wrong
Before any of that, I had a different theory: replace counts with ratios.
A pass completion percentage cannot scale with possession the way a pass
count does. Ratios should be immune by construction.
They are not. Here is the share of variance in each metric explained by which
club a player belongs to:
carries per 90 34% ← a count, as expected
ball receipts per 90 28%
passes per 90 24%
pass completion 21% ← a ratio, and just as contaminated
completion under pressure 19%
...
touches in final third 3.2% ← clean
shots per 90 3.6%
aerial duels won 3.9%
Ratios split into two families. Completion ratios inherit team style, because
in a dominant side the passes available to you are easier ones. Shape ratios —
where on the pitch you touch the ball, how often you shoot, whether you win
headers — are clean.
The hypothesis was half right, which is worse than being wrong. Half right
survives a casual look.
Measure the defect, not something near it
The part I find most useful in hindsight has nothing to do with football.
I originally tracked the contamination as the share of a player's eight
nearest neighbours who are his own club teammates. It read 3.0% against a 1.3%
chance baseline. Barely more than twice random. It looked like a blemish.
The possession correlation on the very same vectors was 0.695 against 0.000.
The defect was enormous. My metric simply could not see it, because teammates
are a tiny slice of any neighbour list and the statistic had almost no room to
move.
I nearly concluded there was nothing to fix.
If you are going to correct something, pick a measurement of the thing itself,
not of a symptom that correlates with it. A proxy that cannot move will tell
you your problem is small.
What it bought
Mathieu dropped out of Piqué's top eight entirely. Piqué's nearest neighbour
became Samuel Umtiti — who signed for Barcelona that summer, which is a
pleasant coincidence rather than evidence, but a good sign.
And the players nearest Lionel Messi stopped being other superstars and became
Lorenzo Insigne, Hatem Ben Arfa and Papu Gómez. Who plays like this at a club
that does not have 67% of the ball is a scouting question. Who else plays for
Barcelona is not.
It is still a partial fix — 0.450 against a 0.000 baseline. What remains is
tactical style, which possession does not capture: a side that defends deep
makes all of its defenders resemble each other regardless of how much they have
the ball. I have written that down as a limitation rather than rounded it away.
A note on how this was built
All of it was written with Claude Code,
including the parts where it was wrong and I had to say so.
The workflow turned out to be the surprising bit. I deployed the app early,
behind a domain, and drove Claude Code by remote control from my phone. Which
meant I could go for a walk, open the site on mobile, look at a real chart
built from real data, and ask for a change from the trail. No laptop.
That is also how the best bug of the project got found.
The plain-language search lets you type "a centre-back good with her feet who
keeps the ball under pressure". It returned eight centre-backs, under a
summary that described the request accurately, and they looked completely
reasonable. I glanced at a radar chart on my phone and noticed the second
player's line sat low on exactly the axis I had asked about.
Checking the numbers: the fourth result was in the 41st percentile for pass
completion. Below average — for a query asking for high pass completion. The
players who actually topped both requested dimensions were not in the list at
all.
The cause was the same shape of error as the one this whole post is about. The
language layer names two or three dimensions and leaves the other fourteen at
0.5, and that full vector was going into a cosine search. Fifteen dimensions at
0.5 and two at 0.7 put about 79% of the vector's norm in the dimensions
nobody asked about, so the ranking was mostly measuring "closest to average
overall". It now ranks only on the dimensions the request actually named.
No test caught it. The output was plausible, and plausible is what a test suite
is worst at. It took a human looking at a picture.
The code is at github.com/canalenguillem/scoutvec,
built on StatsBomb's open data. The
longer write-up in that repo covers the rest of what the data taught me,
including why percentiles have to be computed globally rather than within
position, and why StatsBomb records an aerial duel lost as one kind of event
and an aerial duel won as something else entirely.
