Automatic generation of sports statistics: manual tracking can't keep up
A live match moves faster than a single operator can record events. A goal, substitution, card, change of possession — episodes pile up in seconds, and manual match tagging turns into a race against your own attention.
In fast stretches, events get lost: one action obscures the next, and restoring a missed one from video after the fact is more expensive than tagging it in the moment.
The second bottleneck is discrepancy between protocols. Two operators independently cover the same match and produce different pictures: the number of duels differs, a disputed episode is interpreted differently.
The accuracy of sports statistics suffers not from negligence, but from the lack of a unified recording rule and automatic reconciliation between taggers.
The cost of these errors shows up as a delay in the post-match report.
While data is being manually consolidated and reconciled, the coaching staff, analysts, and media receive the numbers hours later, and sometimes by the next day, when the decision on the game has already been made.
Add to this the ceiling on operator throughput: matches run in parallel in the calendar, and the existing team physically cannot cover them all without losing quality on each.
We break down how this is solved: where manual tagging ends and automatic generation of sports statistics begins. Below is what exactly needs to be recognized in the video and how to set up reconciliation so that numbers arrive at the moment an episode ends, not the next day.
What changes after implementation: accuracy, coverage, tagging speed
The effect of automation is measured not by "convenience," but by five quantities visible in the protocol and in the report release calendar. Below is what we record before implementation and recheck after, so that the comparison uses the same metrics.
- Completeness of the match protocol. Every episode is tagged, including those lost during manual review: rebounds outside the frame, defensive switches, touches on the periphery. The share of tagged events reaches 96–98% versus 80–85% for an operator working in real time.
- Repeatability of tagging. Two independent passes over the same recording produce a discrepancy below 2%: disputed episodes are resolved by a human according to a written rule, not by the mood of the shift.
- Report preparation time. From the final whistle to ready statistics — 10–15 minutes instead of 4–6 hours of manual reconciliation, because tagging happens during the recording, not after it.
- Match coverage per season. The limitation of "how many we managed to process" is removed: the report includes the entire calendar, including youth and reserve squads that were previously not reached.
- Elimination of the class of manual input errors. Mixed-up numbers, duplicated events, lost substitutions disappear as a class: data comes from a single source, and discrepancies are caught by automatic reconciliation.
We keep the data model compatible with open tagging standards such as StatsBomb — the protocol can be reconciled with external sources and connected to existing analytics marts.
The five quantities above are the acceptance criterion: if they do not move after implementation, the work cannot be considered complete.
Approaches to collecting statistics: from manual tagging to automation
The data collection scheme is determined not by the number of cameras, but by which events need to be extracted from the match and with what accuracy they will appear in the report.
Manual tagging gives full control over the meaning of an episode, but the volume of work grows linearly with the number of matches — over a long season this becomes a bottleneck.
Automatic tagging from a single stream removes this limitation, but loses quality on player overlaps and fast duels. A multi-camera scheme restores the position of objects in space and keeps tracking stable — at the cost of stream synchronization and field calibration.
Hybrid tagging with selective validation provides manual-level accuracy on disputed episodes with a multiple reduction in manual work.
Industry statistics providers have arrived at the same logic: Sportradar collects product metrics through a combination of automatic tracking and expert review.
| Option | When it fits | Limitations |
|---|---|---|
| Manual tagging | One-off tournaments, unique events, deep tactical reports | Volume of work grows linearly with the number of matches |
| Single-camera capture + automatic tagging | Mass amateur and youth leagues, basic statistics | Overlaps and loss of depth cause errors in duels |
| Multi-camera scheme | Professional leagues, spatial metrics | Requires stream synchronization, field calibration, stable infrastructure |
| Hybrid scheme with validation | Serial tournaments where manual tagging accuracy is needed | Requires a regulation for selecting disputed episodes and verification |
How we implement the system: stages of engineering work
The order of work is fixed, because the quality of the final statistics is determined not only by the model, but also by how unambiguously events are described and how representative the validation sample is.
If you skip the metrics definition stage or testing on "live" matches, the system produces plausible but incorrect numbers — and this is discovered already in reports that have gone further.
- Audit of video archive and sources. We look at what actually exists: camera angles, lighting, stream stability, recording duration, share of defective matches. Based on the results, we record which sources the system will process immediately and which require additional preparation.
- Flow scheme and metrics definition. We determine where video comes from, where the result is stored, who retrieves statistics and how. Here we also agree on target indicators: share of recognized events, accuracy for each type, processing time for one match.
- Setting up event tagging. We create an event dictionary with unambiguous criteria — what we consider a pass, a shot, a foul. Borderline cases are described separately so that two operators tag identically.
- Setup and training on the archive. The system learns on historical matches, and results are reconciled with existing protocols. We analyze discrepancies by event type, not "on average."
- Control sample of matches. We run pre-selected matches from different tournaments and filming conditions, compare with manual tagging. If accuracy for some event is below the agreed level, we return to the dictionary.
- Handover to operation. We hand over regulations, instructions, and operator training: how to start processing, how to check disputed episodes, what to do if a source fails.
After handover, a clear support loop remains: new event types and seasons are added without rebuilding the system from scratch.
Configurations, flow schemes, and tagging regulations
The solution is handed over together with a complete set of working documentation — using it, the client's team maintains the service on its own and develops it further without us.
- Working system configurations — parameters for collection, normalization, and calculation: which events are counted, how data gaps and signal delays are handled.
- Data flow schemes — the route from the source (official league stream, manual operator input) through processing to the mart, from which statistics go to the interface and integrations.
- Regulation for tagging disputed episodes — how ambiguous events are interpreted: disputed goal, disallowed result, change of possession; who makes the final decision and how it is recorded.
- Instructions for operators — scenarios for typical and emergency situations: source discrepancy, match cancellation, manual correction of a metric with mandatory attribution.
- Metrics passport — for each indicator: formula, source, permissible update delay, and the moment after which the value is considered final and is not recalculated.
- Access rules and roles — who can change calculation logic and who can change only data; separate rights for editor, operator, and integration service.
- Version log — reasons and content of changes to configurations and regulations, so that after an update it is possible to return to the previous working version.
This set is the handover point: after that, the service lives and is updated by your team, and we join in for new scenarios.
Case study: how statistics completeness grew at league matches
What was recorded before the start
Baseline measurements were taken before the first round — otherwise there is no way to prove the effect.
In ten matches of last season of the Единой лиги, three values were calculated: completeness of events in the protocol, share of discrepancies between video tagging, scout's record, and the official report, as well as time from the final buzzer to published data.
The baseline turned out inconvenient: completeness 61–68%, discrepancies on 9–14 events per game, 3–4 hours of manual work after the match, and corrections that were made after publication.
What was changed and what the measurements showed
We built a service for automatic generation of sports statistics: the camera stream is parsed into events, each action is tied to a timecode and receives a unified identifier across all protocols.
Discrepancies stopped accumulating until the end of the season — a disputed episode immediately goes to the operator's confirmation queue, mainly interpretations of duels under the basket.
After eight rounds, statistics completeness holds at 95–97%, protocol discrepancy has decreased to 1–2 events per match, and the report is assembled in 20–25 minutes instead of several hours.
The time for the report was freed up for analysis for the coaching staff, and game statistics are ready by the morning of the next day. The remaining discrepancies are disputed referee interpretations: automation only flags them, the decision still belongs to a human.
What to do if statistics are already collected manually?
Stopping manual collection and switching to automation overnight is the most expensive scenario: an error in player matching or event tagging resets a table already used by coaches, the press service, and partners.
Therefore, we introduce automation as a partial launch on top of the current process: the new loop calculates statistics itself, but does not replace the existing one — it runs alongside it.
The parallel loop works like this: automation and an analyst process the same matches, and results are written to a common schema with a source label.
Discrepancies in key metrics — possession, shots, duels — go into a reconciliation log tied to the match and the minute of the event, so that a specific episode can be analyzed, not just "the numbers don't match."
The switching criterion is not "looks right," but measurable thresholds: share of matches on mandatory metrics, number of analyzed discrepancies, absence of new ones over several rounds in a row.
Until the threshold is reached, the manual loop remains primary, and the automatic one is a control.
Accumulated data is preserved: we do not overwrite history, but load it through the same schema, reconciling entity keys with the team and player dictionary and filtering duplicates by match identifier and minute. Records from past seasons remain suitable for comparing dynamics.
If primary data comes from an external provider such as Opta, the mapping scheme is built once and reused by both loops — then the transition becomes a change of calculation source, not a data migration.
Technical questions: video quality, tagging, integrations
Before the start, the technical team usually checks four things: how the system behaves on real footage, what it does with dense episodes, how it delivers data to existing tables, and what happens with an event that was not in the training set. Below are short answers; on a project, these points are closed before the first line of code.
What if the source video is not shot perfectly?
Before the start, we run a fragment of your footage and show what share of episodes is recognized confidently.
The model tolerates lighting changes and camera shake; if quality is below the threshold, we say so right away and propose a second camera point or manual additional tagging.
How are dense episodes processed?
In saturated stretches, events overlap, so the decision is made based on the sequence, not on individual frames. Disputed episodes go to a separate queue for operator confirmation — statistics do not "stick" with an error, and discrepancies are visible.
How do statistics get into our tables?
We agree on the field schema in advance and deliver data in the structure where records are already kept: scheduled table exports or direct writes to your database. Analysts work in their usual environment, without manual transfer of values.
Can the system be additionally trained on a new event?
Yes, this is a standard procedure. A small corpus of tagged examples is enough — the new category appears in statistics without rebuilding the system, and the previous ones do not degrade because they remain in the set.
Where to start: task discussion and work plan
The project starts not with a contract, but with a task analysis: which tournaments are in scope, where match protocols come from, who currently consolidates tables manually and how much time it takes.
From the answers, it is clear what can be automated immediately and what requires a separate stage — for example, handling non-standard reporting forms or restoring missed events.
What to send at the start:
- 5-10 examples of protocols and exports in their current form — tables, event feeds, scans;
- list of metrics that should be included in statistics: goals, possession, substitutions, individual actions;
- league regulations and scoring rules, if they differ from standard ones;
- structure of current storage, if data is already collected somewhere;
- contact of the person responsible for data on the client's side.
Then — task discussion: an hour of analysis with an engineer and analyst, where we reconcile terminology, clarify source formats, and agree on acceptance criteria.
We return with an estimate and implementation plan: stages, timelines, scope of work, data flow scheme from source to ready statistics, and risks for each source.
A pilot on part of the matches — we take one tournament or a segment of the calendar and run the full cycle: protocol intake, event extraction, reconciliation with manual counting, publication.
The success criterion is the share of matches for which statistics are collected without manual correction. If it is close to complete, we scale the scheme to the entire calendar and connect the remaining tournaments.
