Start with the research task
Choose data by the question it can answer. Event data can support shot, possession-sequence and match-level features. Tracking data can support spatial questions but is much larger and usually covers fewer public matches. Final match records can teach modelling mechanics, but they may not reveal what was available at a historical forecast cutoff. StatsBomb's open repository and Metrica Sports' sample repository show the differing public structures and coverage.
Inspectable public starting points
| Resource | Public material | Suitable learning use | Important boundary |
|---|---|---|---|
| StatsBomb Open Data | Selected matches, events, lineups and some 360 data | Event features and match datasets | Selected coverage and repository licence apply |
| Metrica Sports sample data | Synchronized sample tracking and event files | Tracking coordinates and event alignment | Sample rather than broad competition history |
StatsBomb documents its open repository structure and terms. Metrica Sports publishes sample tracking and event files with format information. These first-party repositories establish what is supplied, not that every third-party model built from them is correct.
Repository acceptance test
Before relying on a project, answer these questions:
- What exact target and match period does it predict?
- Which dataset version and competition IDs does it use?
- Does each feature have an availability timestamp or defensible lag?
- Are preprocessing and feature selection fitted inside the training period?
- Is the split chronological?
- Are raw test probabilities published, not only a headline metric?
- Can one documented command reproduce the result from a pinned environment?
- Does the licence permit the proposed reuse and publication? scikit-learn's common-pitfalls guidance supports the preprocessing and leakage checks; the first-party dataset repositories supply the current coverage and licence evidence.
Common-pitfalls guidance covers leakage and reproducibility risks that apply even when all code is visible.
Reproducibility bundle
| Artifact | What to preserve |
|---|---|
| Data manifest | Provider, files, hashes, retrieved date, coverage and licence |
| Target contract | Label, period, exclusions and cutoff |
| Environment | Runtime and locked dependency versions |
| Pipeline | Feature, imputation, model and calibration code |
| Split manifest | Fixture IDs assigned to train, validation and test |
| Predictions | Fixture ID, timestamp, model version and full probability vector |
| Report | Metrics, calibration, coverage, uncertainty and baselines |
Model cards need denominators
A statement such as “65% accurate” is incomplete without the class rule, fixture count, period, exclusions, class balance and comparison. Peer-reviewed football benchmark work illustrates that model ranking depends on features and evaluation design. Reproducing code on a changed dataset is a new experiment, not confirmation of the original number.
Safe adaptation workflow
Fork a project, pin the original state, reproduce its documented test first, then change one element at a time. Keep the original baseline and test both pipelines on the same later fixtures. If the original cannot be reproduced, document that outcome before adapting it.
Separate reproducible from maintainable
A repository can reproduce an old paper and still be unsuitable for a maintained service. After reproducing the published result, inspect update ownership:
| Maintenance area | Question |
|---|---|
| Data ingestion | Can new fixtures be added under current terms? |
| Identity mapping | How are promoted, renamed and duplicate teams handled? |
| Dependencies | Are runtime and package versions pinned and supported? |
| Evaluation | Can later fixtures be scored without changing the test? |
| Licensing | Can models, data and derived outputs be redistributed? |
| Security | Are tokens, downloads and deserialization controlled? |
The StatsBomb Open Data repository and Metrica Sports sample repository publish their own structures and terms. A third-party repository may add a separate licence without gaining permission to redistribute its input data.
Record adaptation as a new experiment
Changing league coverage, provider fields, target labels or forecast cutoff means the original score no longer describes the current system. Preserve the reproduced baseline, make one adaptation, and evaluate it on a later aligned set. Publish failed adaptations as well as successful ones.
An abandoned repository can still be valuable educational material when the code and data remain inspectable. Describe that role accurately instead of presenting it as a current prediction service. The StatsBomb Open Data repository is an example of a first-party inspectable data resource whose stated scope can be checked directly.
Continue the workflow
Follow the football model build guide after a repository passes the reproducibility and licence checks in scikit-learn's common-pitfalls guidance and the applicable first-party dataset terms.
Continue learning
- Next guide: The Future of AI in Football Prediction
- Related guide: Using ChatGPT for Football Analysis
Assumptions and limitations
This page identifies evaluation criteria and public starting points, not a ranked directory. Repository contents, licences and availability can change, so verify the current first-party terms before reuse. Open code cannot repair unavailable historical timestamps or undocumented source data.
GambleAware
GamCare
Gambling Therapy
GAMSTOP