What you are building
A useful transfer engine should do more than return the five players most similar to a selected name. It should help a recruitment team answer a specific question: which available players fit this squad, role, budget, competition, and tactical model?
For an Indian Super League (ISL) or I-League workflow, the engine can combine player performance, role, age, availability, wages, market value, passport and registration constraints, injury history, and adaptation risk. Scikit-Learn is well suited to the first production version because it provides reliable preprocessing, similarity methods, ranking models, and pipelines without requiring a large deep-learning stack.
This is also a strong portfolio project. If you are learning the fundamentals, compare it with other machine learning portfolio projects for beginners in India, but treat football recruitment as a decision-support system rather than an automatic signing tool.
Define the recruitment decision first
Start with a written product specification. A club might want to:
- Find Indian or overseas defensive midfielders who can play as a single pivot.
- Replace a departing winger with a similar output at a lower total cost.
- Identify undervalued U-23 players with room to improve.
- Rank centre-backs who fit a high defensive line and progressive build-up.
- Compare realistic targets who are available during a particular registration window.
These are different tasks. A similarity engine finds players with comparable profiles. A fit-ranking model scores candidates against a club and role. A forecasting model estimates future performance or resale value. Build the first version around one narrow use case and add complexity only after the evaluation process is credible.
Build an India-relevant dataset
Use data only when you have permission to collect and use it, and record the source, update date, competition, sample size, and definition of every field. Possible inputs include official competition data, licensed providers, club records, match event data, scouting reports, and manually verified availability information.
Useful tables include:
- Player-season table: minutes, starts, position, age, nationality, foot, height, and competition.
- Event table: progressive passes, pressures, recoveries, tackles, carries, shots, assists, and expected goals or assists where available.
- Contract table: contract end date, estimated wage band, transfer fee, loan status, and availability.
- Team table: formation, possession, pressing intensity, build-up preference, defensive line, and squad gaps.
- Context table: league strength, match state, teammate quality, role, and minutes played.
Do not compare raw totals from a regular starter with a substitute. Convert production to per 90 minutes, but retain minutes as a reliability feature. A player with 300 minutes and excellent numbers should not outrank an established player solely because of a small sample.
Indian football data is often incomplete or inconsistent across leagues. Preserve missingness indicators, standardise competition names, map positions to a controlled vocabulary, and document whether a value is observed, estimated, or unavailable. Never silently convert missing wages or market values to zero.
Engineer features that reflect football roles
A single overall rating hides the reason a player is useful. Create role-specific feature groups instead:
- Centre-back: aerial duel rate, defensive actions, errors leading to shots, progressive passing, and recovery speed proxies.
- Full-back: carries, cross quality, final-third actions, pressures, defensive duels, and availability.
- Midfielder: progressive passes, receiving under pressure, ball recoveries, turnovers, and chance creation.
- Winger: carries into the box, take-ons, shot quality, assists, and pressing actions.
- Striker: non-penalty goals, expected goals, shot locations, hold-up actions, and defensive work.
Adjust for league and team context where possible. A simple standardisation approach is to calculate percentile ranks within position and competition. You can then create a weighted role score, but keep the component metrics visible to analysts.
Add practical recruitment features such as age curve, injury availability, language or relocation considerations, contract situation, visa and registration eligibility, and expected total cost. These should inform the ranking, not become hidden penalties that users cannot audit.
Create a baseline with Scikit-Learn
A content-based baseline is a good starting point. Scale numeric features, encode categorical fields, and calculate cosine similarity between a target role profile and candidate players. A Pipeline or ColumnTransformer keeps transformations consistent between training and inference.
import pandas as pd
from sklearn.compose import ColumnTransformer
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import OneHotEncoder, StandardScaler
from sklearn.impute import SimpleImputer
from sklearn.metrics.pairwise import cosine_similarity
players = pd.read_csv("players.csv")
numeric = ["age", "minutes", "progressive_passes_p90", "pressures_p90",
"non_penalty_xg_p90", "duels_won_pct"]
categorical = ["position", "competition", "foot"]
preprocess = ColumnTransformer([
("num", Pipeline([
("impute", SimpleImputer(strategy="median")),
("scale", StandardScaler())
]), numeric),
("cat", Pipeline([
("impute", SimpleImputer(strategy="most_frequent")),
("onehot", OneHotEncoder(handle_unknown="ignore"))
]), categorical)
])
matrix = preprocess.fit_transform(players)
similarity = cosine_similarity(matrix)For a real engine, filter candidates before calculating the final ranking. Exclude players who fail hard constraints such as position, registration eligibility, availability, minimum minutes, or budget. Then apply soft weights for tactical fit, age, cost, upside, and data confidence. A simple transparent score might be:
final_score = 0.45 * role_fit + 0.20 * performance + 0.15 * availability + 0.10 * value + 0.10 * data_confidence
Store each score component so a sporting director can understand why a player ranked highly.
Move from similarity to ranking
Similarity is not the same as suitability. Once you have historical recruitment outcomes, define a target such as minutes achieved after signing, contribution above replacement, retention beyond one season, or analyst-approved fit. Train a supervised model such as HistGradientBoostingRegressor, RandomForestRegressor, or a ranking approach using labelled shortlist decisions.
Avoid leakage. Features must reflect what was known before the transfer decision. Do not use a player’s post-signing minutes, later market value, or end-of-season rating when training a historical recruitment model. Split evaluation by time: train on earlier seasons and test on a later season. If the same player appears in several rows, use group-aware splits to prevent identity leakage.
For a small dataset, a well-calibrated baseline and strong domain review are usually better than an elaborate model. Use permutation importance or simpler feature reports to check whether the model is relying on sensible variables rather than league, club, or nationality shortcuts.
Evaluate the shortlist, not only prediction accuracy
A recommendation engine should be assessed at the point of use. Track:
- Precision@K: how many of the top candidates are considered suitable by experts.
- Recall@K: how many suitable candidates appear in the shortlist.
- NDCG@K: whether the strongest candidates appear near the top.
- Coverage: whether the system recommends more than already famous players.
- Calibration: whether confidence scores match observed outcomes.
- Stability: whether small data changes produce wildly different rankings.
Use a blind review with coaches, scouts, and analysts. Give reviewers the same role brief and ask them to rate fit, evidence quality, and missing information. Log overrides rather than treating them as model failure; they may reveal an unmeasured feature, such as dressing-room fit or tactical instruction adherence.
Deploy a usable internal tool
Package preprocessing and scoring together so production data follows the same transformations as development data. Expose a small API with inputs such as position, formation, budget, age range, passport constraints, minimum minutes, and tactical priorities. Return ranked players with evidence, source dates, confidence, and clear caveats.
A dashboard should support filters, side-by-side comparisons, radar charts used cautiously, video or scouting links, and an explanation panel. Add access controls because contract information, medical data, and internal assessments are sensitive. Schedule data refreshes, monitor stale records, and create an audit trail for every generated shortlist.
The product should work under Indian operating constraints: uneven data coverage, limited analyst capacity, multilingual notes, and changing squad rules. If you later add natural-language search for scouting notes, review approaches used in low-resource Indic natural language processing. For broader club workflows, principles from building AI apps for the next billion users in India can help with reliability and accessibility—but do not replace football-specific validation.
Common mistakes to avoid
- Ranking raw goals or assists without position and minutes context.
- Mixing ISL, I-League, reserve, and youth data without competition adjustment.
- Scraping data without checking terms, consent, or redistribution rights.
- Treating market value as an objective transfer fee.
- Using nationality as a proxy for ability or adaptation.
- Presenting probabilistic recommendations as certain scouting decisions.
- Building a dashboard before establishing reliable data definitions.
A practical build roadmap
Week 1: define the role brief, data dictionary, sources, and hard constraints.
Weeks 2–3: clean historical player-season data and create per-90, percentile, and reliability features.
Week 4: launch a transparent similarity baseline with analyst review.
Weeks 5–6: add time-based evaluation, shortlist metrics, explanations, and feedback logging.
After validation: introduce supervised ranking, availability integrations, monitoring, and role-specific models.
The strongest result is not a flashy prediction. It is a reproducible shortlist that saves analysts time, exposes overlooked options, and makes every recommendation traceable to data and football reasoning. For students, the project also demonstrates practical skills covered in best machine learning projects for computer science students.