Overwatch League Data Analysis

Final group project for SFU's Business Analytics capstone. A multilinear regression to predict OWL player prize earnings from in-game performance data — and a clear-eyed answer about what public stats can and can't tell you.

Context

This was the final group project in my Business Analytics capstone at SFU's Beedie School of Business. The brief: pick a real-world problem, source the data ourselves, and conduct a Root Cause Analysis on a continuous response variable using whatever statistical tools we'd learned in the course. The point wasn't to solve the problem — we didn't have the time or resources for that — it was to do the kind of superficial first pass an analyst would do before scoping a full investigation.

I pitched the Overwatch League (OWL) angle and the team and prof both liked it, despite the ambitious scope. The question I wanted to answer was one any esports org would care about: which publicly available player performance metrics predict the players most likely to grow their team's profitability through prize earnings? If you're a decision-maker scouting talent, that's a meaningful question to put to data.

Approach

We collected player prize-money data from the esportsearnings.com API and in-game performance data from the official OWL Stats Lab (since deprecated when the OWL was dissolved and replaced by Overwatch Esports). The response variable was career prize earnings; the candidate explanatory variables were every per-game performance metric the Stats Lab exposed — damage dealt, damage taken, healing, eliminations, deaths, ultimate economy, and so on (there were dozens).

The modelling was done in SAS Enterprise Guide, with a KNIME regression tree used in parallel to identify which variables actually mattered before they went into the SAS multilinear regression. Python handled the data preparation: scraping, cleaning, joining the earnings table to the performance table on player ID, and reshaping the per-match data into per-player aggregates.

Process flow diagram in SAS Enterprise Guide showing data import, query builder steps, file processing, and the linear regression node connected together. — Overall process flow in SAS Enterprise Guide — data imports, query builder steps, file processing, and the regression node wired together.

Close-up of the linear regression pipeline in SAS Enterprise Guide, showing the input dataset feeding into the linear regression task. — The linear regression pipeline in SAS EG, isolated from the broader process flow.

KNIME workflow with nodes for CSV reading, partitioning, regression tree learner and predictor, and scoring nodes connected in a regression modelling pipeline. — The KNIME regression-tree pipeline, used to surface which performance variables were worth including in the SAS regression.

Regression tree visualization from KNIME, with branches splitting on player performance variables and leaf nodes showing predicted prize earnings values. — The regression tree itself — splits driven by Damage Taken, Ultimates Earned (Fractional), and Ultimates Used dominated the upper branches.

Results

The best model we landed on identified Damage Taken, Ultimates Earned (Fractional), and Ultimates Used as the most predictive metrics for player earnings. Intuitively that maps to high-engagement frontline players — tanks and aggressive supports who are in the fight, soaking damage, and cycling ultimates — which lines up with the kind of player who tends to be a team's centerpiece.

The headline number was less flattering: an R² of around 0.27. The model explained roughly a quarter of the variance in prize earnings. Useful as a directional reference, not nearly enough to actually scout from.

SAS Enterprise Guide linear regression output tables, showing parameter estimates, p-values, and overall model fit statistics including R-squared. — SAS EG linear regression output — parameter estimates, significance, and the model-fit statistics that pinned R² at ~0.27.

Histogram of regression residuals from SAS Enterprise Guide, with the residual distribution overlaid against a normal curve to assess model fit. — Distribution of residuals against a normal curve — one of the diagnostic plots used to sanity-check the regression assumptions.

Observed-by-predicted scatter plot from SAS Enterprise Guide, with predicted prize earnings on the x-axis and observed earnings on the y-axis, scattered around a diagonal reference line. — Observed prize earnings against predicted — visibly diffuse around the diagonal, which is what a 0.27 R² looks like in practice.

The conclusion we wrote up was that public-data scouting models like this should be treated as reference, not signal. The limiting factors weren't statistical — they were structural: significant missing values across the Stats Lab dataset, inconsistent collection over the league's lifetime, the inherent complexity of role and meta dependencies, and the fact that the game itself fundamentally changed mid-dataset (Overwatch 1 to Overwatch 2, 6v6 to 5v5). To do better, an org would need experienced scouts in the loop, internal earnings or salary data, or substantially more sophisticated models accounting for role, meta, and patch effects.

Reflection

What I took from the project, beyond the grade, was reps on the unglamorous half of analytics: scoping a question against the data you can actually get, choosing tools for the size of the problem (SAS for the regression, KNIME for variable selection, Python for everything in between), and being honest about what a 0.27 R² means before someone less careful tries to scout from it. The negative result was the result. That's a useful thing to internalize early.