StatGol

Methodology

Every number in StatGol has arithmetic behind it. This page is that arithmetic — including the parts where we would rather show no number at all.

What is ours and what comes from the source

Not every number here is calculated by us, and blurring the two would be the first way to mislead without lying. Here is the split:

The formulas

Tempo per minute
Both teams' dangerous attacks added together, divided by the minutes of play elapsed.
Pressure graph
The provider sends a dominance index every 30 seconds, one value per team. We take the per-minute mean of (home minus away) and draw that: the bar rises when the home side is on top and falls when the away side is. Above 6 the bar saturates on purpose — the graph is there to read the match, not to record records.
Pressure over the last 15′
The mean of that same index, per team, over the last 15 minutes of the match clock. Half-time does not count towards it.
Acceleration
The tempo of the recent window divided by the tempo of the whole match. On both sides of that division, activity is counted as dangerous attacks plus 3 times the shots on target — one shot on target weighs 3 dangerous attacks, and that number is a choice of ours, not a constant of nature.
1.0 means the team is holding its own tempo; 1.5, fifty per cent above; 0.6, forty per cent below.

When a number does not appear

A dash instead of a number is not a glitch. There are three cases, and in all of them we would rather show nothing than show something that does not hold up.

  1. The league does not carry that statistic. Smaller leagues arrive without xG, without dangerous attacks or without shots. When the source sends a zero for a league with no coverage, we turn that into a dash as well — zero and "not measured" are different things.
  2. Little has happened in the match so far. Below 8 of accumulated activity the acceleration index is not published: dividing by a very small number produces enormous swings from a single passage of play.
  3. The window has just crossed half-time. This is the case that needs a longer explanation, and it is the subject of the next section.

The rule at the start of each half

Besides the match totals, the provider delivers "last 5 minutes" and "last 15 minutes" versions of some statistics. Those are what feed the acceleration index, and those are what the scanner hides in certain minutes.

The reason: those windows are cut off at the start of each half. The reference point never reaches back past that half's kick-off. So at minute 47 the 15-minute window does not hold fifteen minutes — it holds the two that have run since the break, exactly like the 5-minute one.

This is not our deduction. It is the provider's own description, quoted with their permission:

“The reference point can never go back before the start of the current half. (…) Clock 46:00–50:59: both the 5-minute and the 15-minute window start at the beginning of the second half, so d_5 and d_15 are equal by construction. 51:00–60:59: d_5 is a true 5-minute window, while d_15 is still limited to the second half only. From 61:00: both windows are full.”

The same holds in the first half, in extra time, and for every pair of these statistics: attacks, dangerous attacks, shots on target, shots off target and corners. That is why the scanner publishes no metric derived from these windows before 6′ and 16′ in the first half, and before 51′ and 61′ in the second — the thresholds the provider gave as safe.

How we got there — and what we got wrong on the way

We noticed the acceleration index came out absurdly low just after half-time. We started logging one reading per minute, per match, and measuring how often the two windows returned the same number. The table is the current measurement, 251 matches, with the ranges already cut at the boundary the provider described — and with what the rule says to expect stated beside each range:

Range Matches Readings Windows equal Expected by the rule
1st half, 25–40′ 226 3610 0% distinct
2nd half, 46–50′ 204 651 98% equal
2nd half, 51–60′ 227 2219 9% partly
2nd half, 70–85′ 229 3578 0% distinct

Counting only the readings in which the 15-minute window registered anything. The partial overlap at 51–60′ is the low-activity matches: there the 5-minute window is already full and the 15-minute one is not, but when there was nothing more to count both return the same number. In the ranges where both windows are full, the overlap disappears — that is the behaviour the rule describes, and it is why the rule can be proved wrong.

The measurement was right. Our explanation of it was wrong. We concluded that the windows were counted against the wall clock and that the break was being included, and we wrote in the code that this had no alternative explanation. It did.

It was the provider who pointed out the flaw in the reasoning: a break of about fifteen minutes produces exactly the same coincidence under either hypothesis. Our test could not tell them apart, and we claimed it could. The difference between the two would only show up with a break shorter or longer than usual — which does not happen.

The practical rule in the scanner barely changed, but the reason did, and with it its scope: it now applies to the start of the first half too, which previously went unguarded. Asking cost one email and corrected a claim that was shipping in the product.

We leave the mistake written here on purpose. A methodology page that shows only what it got right is not methodology; it is advertising with a table in it.

What we keep watching

The description above is testable, so we test it: the collector logs the readings and a command checks, against real matches, whether the ranges still behave as described. If the source changes the calculation without saying so, it shows up there before it shows up on your screen.

Two caveats the provider added, which we pass on: while the clock still reads 45-something, the reference can fall back into the first half; and there is no special handling for VAR, injuries or stoppages — the window follows the source's clock, and stops when it stops.

How much delay there is

There are two numbers, and publishing only one would be a half-truth. We re-read the source every 30 seconds. The screen asks the server every 3 seconds, so a new reading appears within about 3 seconds of arriving.

On top of those two sits the time the provider takes to register the event on the pitch, which we neither control nor measure. In practice, between the event and your screen there is anything from a few seconds to a minute. The scanner is not a live broadcast and is no substitute for watching the match.

When the source fails we back off: the wait doubles with each attempt, up to eight minutes between tries. During a back-off the scanner says the source is fluctuating and shows when the last valid reading was taken.

What StatGol does not measure

A list as important as the formulas, and rarely published:

What we do not do, by choice

The measurements on this page were taken up to 2026-10-08. Found an error? Write to us — being corrected here is worth more than being right.