EPL Predict: Premier League Match Analytics and Prediction

Overview

EPL Predict was developed as a complete Premier League analytics product rather than an isolated modelling exercise. The system combines historical match analysis, binary outcome classification, live score and fixture data, user authentication, match comments and detailed statistics in one browser based application.

The project followed a research and product development process covering existing football forecasting approaches, legal and ethical constraints, model comparison, API integration, interface design, testing and evaluation. Its central product goal was to make predictive analysis accessible to football supporters while keeping current match context visible alongside the model output.

Research context

The initial research reviewed statistical models, machine learning classifiers, probabilistic graphical models and rating systems used in football forecasting. It also compared the product approaches behind FiveThirtyEight's Soccer Power Index, the BBC Sports Analytics Machine, market informed Betfair models and broader AI systems that combine structured and unstructured sports information.

The literature review highlighted a recurring engineering tradeoff. More complex models can represent richer relationships, but their usefulness still depends on feature quality, realistic evaluation and the availability of reliable data before a prediction is made. This informed the decision to compare several conventional classifiers before increasing model complexity.

Development methodology

The work was organised through an agile process spanning research, requirements, model development, live data integration, interface implementation and system evaluation. User stories, a prioritised product backlog, a roadmap, a Gantt chart and a risk assessment were used to structure the delivery process.

Model development

The prediction problem was framed as binary team outcome classification: win or loss. Data preprocessing converted categorical variables into one hot encoded features, while numerical inputs were standardised before model fitting.

1. Step 01

   Historical data

   Match and team information

2. Step 02

   Preprocessing

   Clean · scale · encode

3. Step 03

   Data split

   80% train · 20% test

4. Step 04

   Model training

   4 classifier families

5. Step 05

   Hyperparameter search

   Pipeline · 5 fold GridSearchCV

6. Step 06

   Evaluation

   Confusion matrix · report · ROC

The tuned logistic regression workflow combined StandardScaler and the classifier in a single pipeline. GridSearchCV evaluated parameter combinations with 5 fold cross validation and accuracy as the optimisation metric. Model assessment then used confusion matrices, precision, recall, F1 score, support, accuracy and ROC AUC.

Evaluation findings

Data split

80 / 20

Training and holdout evaluation

Cross validation

5 fold

GridSearchCV for model tuning

Best accuracy

71%

Logistic regression · leakage free

Models compared

4

Distinct classifier families

Evaluation views

3

Reports · confusion matrices · ROC

Outcome classes

2

Win and loss

The classifiers were assessed as a comparative modelling study rather than through a single headline metric. Classification reports and confusion matrices exposed class specific behaviour, while ROC analysis provided a threshold independent view of discrimination. This made it possible to compare predictive quality, interpretability, computational cost and generalisation before selecting the strongest leakage free model. Logistic regression produced the best validated result with 71% accuracy.

The result was also benchmarked against established football prediction systems identified through the literature review, spanning statistical, tree based, probabilistic and deep learning approaches. Differences in datasets, feature availability, outcome definitions and validation strategies were considered, so the comparison was used to contextualise performance rather than imply a direct like for like ranking.

Application architecture

1. Step 01

   Historical data

   Training and evaluation

2. Step 02

   Prediction model

   Win · loss

3. Step 03

   Flask application

   Routes · forms · sessions

4. Step 04

   LiveScore API

   Scores · fixtures · statistics

5. Step 05

   SQLAlchemy

   User and comment data

6. Step 06

   SQLite

   Application persistence

7. Step 07

   Web interface

   Live · upcoming · recent · prediction

Python provides the shared implementation layer across modelling and product logic. Flask renders the web experience and handles navigation, forms and authentication. SQLAlchemy manages user and comment data in SQLite, while the Requests library retrieves current football information from LiveScore API.

The live integration supports ongoing matches, upcoming fixtures, score updates, match events, detailed statistics, player information and lineups. This makes the application useful as a match information product as well as a prediction interface.

Product experience

Users enter through registration and login flows before reaching a homepage that combines live scores, upcoming fixtures and recent results. A match can be opened to inspect team form, player information and detailed statistics, then submit the prediction inputs and view the resulting classification.

• Live, upcoming and recent match views organised around a single football workflow.
• Date filtering for historical match discovery.
• Detailed match pages covering score state, cards, possession and other match statistics.
• Prediction forms returning a win or loss outcome.
• Authenticated comments to support discussion and product feedback.
• Flask WTF form handling with CSRF protection.

Testing strategy

The dissertation describes testing at component, integration and system levels. Individual checks covered predictive algorithms with controlled data, mocked API responses, database CRUD behaviour, interface logic, form validation and security controls. Integration testing then exercised the data flow between these modules.

Performance testing simulated concurrent access to assess responsiveness during high traffic periods such as live matches. Test execution details, environments, results and anomalies were documented as part of the evaluation process.

Responsible engineering

The project considered legal, social, ethical and environmental risks alongside model performance. GDPR and user privacy shaped the handling of account and external data. The dissertation also recognises the risk that football predictions can encourage harmful gambling behaviour and argues that outputs should be presented as analytical insights rather than certainty.

Fair treatment of teams and users, transparent limitations, computational cost and energy use were included in the professional assessment. The work refers to BCS and ACM principles around privacy, competence, public interest, avoiding harm and responsible technology development.

Limitations

• The dissertation uses a conventional random 80/20 split. A football forecasting system should evaluate chronologically so future matches never influence training or model selection for earlier prediction periods.
• The binary target combines draws and away wins, reducing the usefulness of the output compared with calibrated home, draw and away probabilities.
• Accuracy, classification reports and ROC AUC do not establish probability calibration or performance stability across seasons and teams.
• The live product depends on an external API, creating consistency, latency and availability risks that need explicit operational controls.
• The project encountered overfitting and substantial local training cost, showing the need for more disciplined feature selection and reproducible compute.

Production roadmap

1. Define the exact prediction timestamp and enforce a leakage safe feature contract containing only information available at that point.
2. Replace the random split with rolling season backtests and compare every model with simple historical and market informed baselines.
3. Produce calibrated home, draw and away probabilities and evaluate log loss, Brier score, calibration error and performance by season.
4. Version raw data, features, model artifacts and evaluation reports so each prediction is traceable and reproducible.
5. Add API timeouts, retries, caching, schema validation and graceful fallbacks, then instrument feed freshness, scoring latency and endpoint health.
6. Automate component, integration and end to end tests through CI/CD and harden authentication, secrets management and production deployment.