I would attribute this to a few main factors:

• An excellent introductory blog post that clearly explains the motivations, mechanisms, and applications of the model
• The provision of fitted parameters by Karun Singh (linked in the blog post)
• An excellent open-source implementation by the KU Leuven Machine Learning Research Group that can use the fitted parameters

Altogether, this makes it possible for hobbyists and practitioners alike to use xThreat relatively easily when compared with competing models.

Nonetheless, I think there’s a few areas where xThreat could be tweaked and potentially improved, without changing the core idea too much. (This post does assume some familiarity with the xThreat model, so if this is new to you it’s probably worth reading Karun’s introduction.)

I have attempted to credit prior work where relevant; if I’ve missed anything please let me know so I can add any links.

1. Using different pitch divisions…

In general, xThreat implementations divide the pitch into uniform grid, as in this graphic from the socceraction documentation:

However, there’s nothing in the xThreat model that mandates this way of dividing up the pitch. Perhaps there are other divisions that could help…

… to better reflect player behaviour

Pitch markings, the laws of the game, and team tactics alter player behaviour around the pitch. The way these factors interact to impact player behaviour is not uniform across the pitch. For example, teams will often set their defensive line just above the penalty area. So should we reconsider splitting the pitch up uniformly in xThreat?

Perhaps the Juego de Posición pitch divisions could be a decent starting point?

More granular divisions in the attacking half of the pitch might be desirable. Which brings us to…

… to increase the resolution of xT estimates

xThreat includes a simple xG model, whereby the probability of scoring from a given zone is estimated. xThreat uses the embedded xG model to propagate value estimates to all zones on the pitch.

Therefore, the precision of the xThreat estimates depends on the precision of the xG model.

In the 12 by 8 pitch division, the zones in the attacking penalty area encompass a large range of different xG values. Getting a shot to the penalty spot tends to be much more valuable than getting one to just outside the box, but uniform pitch bins in xThreat treat these shots the same.

In general, we want to define the pitch zones such that the events within each zone are as similar to one another as possible. Can we increase the precision of the xT model by decreasing the number of bins within high-value areas?

Maybe something like… this?

Granted, this is not the prettiest way to divide the pitch. But it would divide the area where most high value shots come from more equitably than uniform binning.

2. Use an xG model

As mentioned, xThreat embeds a simple xG model within it. But, we already have quite sophisticated xG models that work well. So why not use an existing xG model to assign the initial value of shots from a given zone?

There’s a few ways one could incorporate the information from xG models, but the simplest would be to take the average shot xG within a given location as the value of a given shot.

3. Introduce turnover states

The basic xThreat model estimates the probability of moving or shooting from each zone on the pitch. However, we could add an additional set of turnover states. In other words, we also estimate the chance of giving the ball to the opposition in each of the pitch zones.

This allows us to calculate xT for and against. The xThreat against (xRisk?) at a given location would be the probability of turning over the ball multiplied by the xThreat from that zone, for each pitch zone.

Having xThreat values for and against would bring xT closer to possession value models like OBV, VAEP, and G+.

Rob Hickman introduced the idea of incorporating opposition threat to xThreat in his 2019 talk, “Considering Defensive Risk in Expected Threat Models”.

Taking each of these ideas to their logical conclusions ultimately leads towards more sophisticated possession-value models like VAEP, G+, or OBV. However, these models are significantly more complex and are more difficult to develop and maintain than Expected Threat.

Small tweaks like the ones listed above may be able to improve xThreat while keeping the model complexity manageable, and keeping the benefits of all the public work that has gone into xThreat so far.

So, exactly how much do Newcastle need to improve to have a fighting chance of remaining in the Premier League?

What are Newcastle’s current relegation chances?

At the time of writing, things look pretty grim for Newcastle. Based on current form,538 give them a 75% chance of going down.Using the combined xG-and-goals model described here,we get a similar estimate of around 80%.

Of course, Newcastle are much better placed than their rivals to improve their team. With a new coach and an effectively limitless pile of cash, anything is possible… right?

The betting markets seem to think so. Odds on Betfair’s exchange give Newcastle an implied relegation chance of around 45%, significantly lower than the models.

Estimating relegation chance

To understand how team quality impacts relegation chance, we need to look at how I estimated Newcastle’s current, “naive” relegation chance.

First, I used a model to estimate the attacking and defensive strength of each team in the Premier League, based on both their expected goals for and against and their actual goals scored and conceded. I have written a few posts on these types of models if you are interested in more details on how exactly they estimate those strengths.

At the time of writing, the estimates for each team’s ability is like so:

The axes refer to each team’s predicted goals (for/against) per game when playing against a hypothetical league average team, without home advantage.

Newcastle aren’t in a great spot. They’re estimated to score about 1.0 and concede 1.6 goals per game against an average Premier League side.

Using these estimates, we make predictions for each unplayed match in the rest of the season. For example, the model might predict thatBrentford vs Leeds has a 5% of ending 0-0, a 6% chance of ending 0-1, … and so on for each possible scoreline.

With the predictions, we can simulate the remainder of the season by picking a random scoreline for each unplayed match, based on how likely that scoreline is to occur. Taking both the played matches and the simulated matches, we can work out what the table would look like at the end of this simulated season.

To get the relegation probability, we simulate the rest of the season over and over again and find the proportion of simulations that ended with Newcastle in the bottom 3.

How does team improvement affect relegation chances?

To understand how much Newcastle might need to improve (or how much the betting markets think they’ll improve), we can use the above method, but with a twist.

Instead of just estimating the relegation probability for Newcastle’s current ability, we estimate the relegation chance for Newcastle at a range of different abilities. In other words, before making the predictions, we modify Newcastle’s attack and defence estimates. This creates a set of “what if” scenarios, with associated relegation probabilities.

With this, we can see the probability of relegation at a range of different team strengths. The following heatmap shows the estimated probability of relegation if Newcastle played the rest of the season at a given level.

I have overlaid the current team strength estimates for all teams for context. Although, it should be noted that the colour of the heatmap at each point doesn’t refer to that team’s relegation chance. Rather it refers to the relegation chance that Newcastle would have if they instantly became as good as that team.

So, if Newcastle managed to become as good as Manchester City tomorrow, we would expect them to have almost no chance of being relegated. If they became as good as Arsenal or Tottenham, it would be more like 10-20%.

Betfair’s estimate of 45% puts implies an improvement in January to somewhere around the level of Aston Villa or Wolves. That would put Newcastle at an improvement of around 0.4 goals per game better in defence, and 0.1 goals per game better in attack.

Or, a (roughly) 0.5 GD per game improvement.

In the heatmap, the colour gradient is arranged diagonally. This implies that goal difference per game is more important to performance than the specific value of the team’s attack or defence.

Wolves, Southampton, Everton and Leeds all have similar associated relegation probabilities in the chart above. This is because their estimated goal difference per game is very similar, even though they achieve this through very different means. Wolves have solid defence but a poor attack. Leeds have a decent attack but a poor defence.

Some caveats

This method of season simulation is quite crude, and the resulting estimates are approximate. I can think of a few caveats which might shift the perception of the challenge facing Newcastle one way or another:

• New signings require time to gel and learn systems. The simulation method assumes that the change to Newcastle’s ability will be instant. But if there’s an adjustment period for new players, the team will actually need to overshoot in terms of player talent in order to get an average performance akin to the target. To get Leicester-quality performance over the rest of the season, you might need to bring in players slightly better than Leicester’s to account for the new signings settling in and gelling.

• Eddie Howe has only been head coach for a short while. The model is unlikely to fully account for any improvement to the team since his arrival, so the current estimate of Newcastle’s ability (and therefore relegation chance) might be a little pessimistic.

• The competition simulation assumes all other teams will remain at their current level. This is clearly untrue. Other teams could get better or worse throughout the season. New signings, injuries, and motivation will affect teams.

How might this impact decision making?

Having numerical estimates gives you a feel for the scale of the challenge that Newcastle are up against. According to this model, improving the team to Arsenal/West Ham/Tottenham’s level leaves you with a 10-20% relegation chance. Even after such a huge increase in quality, there’s still a very realistic chance of relegation.

With this in mind, I would argue that laying foundations that will function in either the Premier League or the Championship would be a better strategy than going all-out for Premier League survival.Crystal Palace’s last 2 years are an excellent example of good decision- and deal-making in the face of uncertainty. Brighton, Brentford and Wolves have also shown that it’s possible to build a competitive Premier League squad in the Championship.

Having a rough idea of the relationship between improvement (in GD per game) relegation chance helps plan how to minimise relegation chance. For example, if you can think you can attract players who improve the team by around 0.1 GD per game over the course of the season (compared to their counterparts), then you’d need to sign 4-5 of these players to get to 40-50% chance of relegation. To get down to 15-20%, that would be around 8 players.

We already saw that improving the defence has a similar effect to improving the attack. This should give decision-makers confidence to focus on whichever area they believe is easier to improve.

Decisions and strategy are hard, especially when the stakes are so high. Having empirical methods like this can help focus decisions and reduce the risk of mistakes, making them a valuable part of an executives’ toolkit.

Code for this analysis is available on GitHub.

What is bad about moving averages?

In short, when taking a moving average of a given metric, you end up estimating that metric for a date in the past.

Let me explain:

So, when using a rolling average, the time window should enclose the date of interest, not end at the date of interest.

However, this presents a problem when the date of interest is close to the current date:

What can we do to fix this?

Part of the problem is that all games within the window are given an equal weighting.To shift the center of the window towards the date of interest, matches close to that date should be given a higher weighting than those far away.

Once we start looking at this as a weighted average, I think it is a little more intuitive to weight things in this manner than it is to assign games a weight of either 0.0 or 1.0 depending on whether they fall into the time window.

So what exactly should this weighting look like?

Recently, I’ve been interested in how modelling can inform simpler, more heuristic approaches. In this case, I think we can learn from thetime-discounting methods that are used in modelling football teams’ strength.

Team strength models share a goal with moving averages: estimating something at a given date. The most common approach I have seenfor weighting input data in team-strength models is an exponential weighted average:

where “” is how long ago that game took place (e.g. in days or weeks) and “” (“epsilon”) is a hyperparameter that determines how strongly recent games are weighted compared to past games.

If we applied this to replace a moving average, the weighting would look something like this:

Note that with an exponentially decaying weight, the weight will never drop down to zero. In practice, picking a cutoff beyond which games aren’t included might be useful. This cutoff could be in the form of a time window (e.g. 6 months from the target date) or in the form of a minimum weight (e.g. “games where weight >= 0.01”)

So, what difference does it make?

For no particular reason, let’s look at the rolling non-penalty xGD of Manchester United:

Here, the blue line shows a 21-game moving average, centered on the match of interest. In other words,for each match, we take the 10 matches before and the 10 matches after, and construct an average.

The orange line shows the exponentially-weighted moving average. Here, I used an “” of 0.016,which gives matches from 6-months ago a weighting of approximately 5% (the target date will be weighted at 100%). This is a significantly more aggressive weighting than what is optimal for predictive purposes, but I think this is defensible as a rough comparison to the 21-game rolling average. I didn’t apply a cutoff, so all data between 2016/17 to present was used with the appropriate weighting.

In both cases, the moving averages use both past and future data where available. I haven’t shown the uncentered “last 20 games” style of moving average, since it is almost identical to the blue line but shunted 10 games to the right.

Although the overall shape of the curves is the same, there are 2 main differences between the 2 moving averages shown above.

The main difference is that the exponential weighting gives a smoother curve. This is because games in the past have incrementally less influence on the average, instead of going from being given equal weight to being not included at all.

I’m not entirely sure how many sharp changes we should expect to see in an abstract quantity like team ability (that xGD is serving as an indicator for). In general, I would guess that changes should be smooth, but I can see how things like player injuries and coach changes, for example, could reasonably cause discontinuities. However, I don’t trust that the sharp peaks and troughs we see in the moving average are anything other than noise. The whole point of a moving average is to smooth out the noise to more clearly indicate trends, and I think it’s reasonable to say that the exponential weighting is doing this a bit better.

The other difference we can see in this chart is that the exponential curve has much bigger jumps at the start/end of each season. This is because I calculated the weighting on the basis of time rather than on the basis of “how many matches ago”. At the start of the season, the matches from the end of last season took place a reasonably long time ago, so the current-season games have much more influence on the weighted average.

You could argue this makes for a slightly unfair comparison between the methods. Perhaps using a weighting function where “” is “number of matches ago” would be fairer. Or using a moving average over n months, rather than n matches. In the end, I chose this comparison because, I haven’t seen time-based moving averages used much in this context, and I think using a time-based weighting is more intuitive in this case (where matches aren’t evenly spaced) than a match-indexed one. That said, simple exponential smoothing is an option.

The biggest individual difference between the two methods can be seen towards the end of the 2019/20 season.

In this case, the moving average shifts to include two games from 2020/21 with large negative xGD tallies:

• Brighton 1.56 - 0.27 Manchester United
• Manchester United 0.16 - 2.91 Tottenham Hotspur

This results in the moving average sharply dropping down.

However, because those matches take place next season, and because of the Covid-induced mid-season break lowering the weight of earlier games, the exponentially-weighted average gives more influence to the stronger performances at the end of 2019/20.

I don’t think either of these approaches can be considered “correct” in any meaningful sense. But I do think that the exponentially-weighted average better reflects the performances of the team at the time in question. How much should our opinion of Manchester United at the end of 2019/20 be affected by a thrashing at the start of 2020/21? Probably a bit, but not as much as performances in 2019/20.

Not just team metrics

This approach doesn’t have to be restricted to just team-level metrics. We can easily apply the same logic toplayer stats.

Take Harry Kane’s xG scored from open play p90:

Again, the shape is basically the same, but the smoothing has improved.

Conclusion

I’ve suggested 3 changes to try and make rolling-averages better:

• Center the average on the date of interest, instead of using the last n games (or similar)
• Use an (exponential) weighting instead of a moving window
• Calculate weighting using time instead of match index (“how many matches ago”)

Ultimately, if you follow the logic of improving a moving average far enough, you’ll end up at statistical modelling. But this is a step up in complexity and is often harder to explain than a weighted average.An approach like this can yield some improvement without too much additional complexity.

It’s a little more work, but maybe it’s worth it?

What do you think?

But what is often available is xG totals. They are everywhere.

So, in this post, I’d like to present a method for building a match prediction model using xG totals. This uses data that is much more readily accessible to the average fan, while only sacrificing a little prediction quality.

How does it work?

First, we need to understand how the model using individual shot xG works. You can read in detail on a previous post, but in short:

1. The original D-C model estimates each team’s offensive and defensive strength, and home advantage from match scorelines
2. xG D-C simulates match scorelines using the xG values from each shot in the match (see also)

The key insight here is that we can look at this class of models as the composition of two distinct functions:

• A scoreline generation function
  • This is a function that, for each match, will give a list of match scorelines, with weights, for each match
  • In the classic case, this just returns the actual match scoreline (with a weight of 1.0)
  • In the xG-DC, this returns the simulated match scorelines (with a weight of probability)
• The Dixon-Coles model fit

We don’t need to be limited to goals, xG or resimulation, or… anything at all, really. All we need is a list of weighted scorelines for each match.^[1]

So, to make the model work for xG totals, we just need to find a way to make xG totals into weighted scorelines. I think the simplest way is to look back at the model assumptions.

The basic Dixon-Coles model is, at its heart, a modified Poisson model. The Poisson distribution takes a single rate parameter (in our example, this is the average goals scored per game) and gives back the probability of seeing 0 goals, 1 goal, 2 goals, and so on. So, if we assume the xG totals are equivalent to the average goals per game for that match (given the team’s performance on the day), then we can simulate match outcomes using the Poisson distribution.

We can then feed the simulated scorelines into the Dixon-Coles model, with the probability as the weight. In this way, we can get a model that predicts matches in terms of real goals, trained using xG totals.

What are the downsides?

• You lose xG-per-shot information. Even when the total xG is the same it’s generally better to take high-quality shots (which the best teams generally do). The xG-totals method presented here lacks any information about the distribution of xG across shots. This makes the model perform worse when making predictions (more on this in a second).
• In the proposed model, we don’t actually need to go through the Poisson simulations to get the exact same result. The whole problem simplifies down to a simpler regression problem. There might be some benefit to doing everything through a common framework (it certainly made backtesting it easier for me). I think the main benefit of talking about this is to further our intuition of how these models works.
• The scoreline simulation assumes independence of home and away goals (which is not true in reality). The xG-resimulation approach has the same issue, but it’s worth being aware of. You can sort of get around this somewhat by “transplanting” the dependence parameter () from a “real” D-C model, but it is a hack. Short of designing a better class of model, that might be the best you can do. Let me know if you have any better ideas on this front.

What is the performance difference?

Exactly how much worse does the model perform compared to the xG-resimulation approach (i.e. without the xG per shot information)?

As before, I ran a backtest to evaluate model performance. In a backtest, we train each model for each matchday in the past. We then make predictions using those models and see how well they would have performed, using the information they had available at the time. The following chart shows the backtest results for the English Premier League between 2016/17 and 2020/21, inclusive.

When looking at outcomes (home/draw/away), the totals-only model performs very slightly worse than the model with full xG-resimulations. This makes sense; it has access to less information about teams’ shooting patterns. However, it still performs a lot better than using goals.

Interestingly, the xG-totals approach performs much worse relatively on total goals than on per-match goal difference. For each match prediction, I took each model’s average predicted home and away goals. I then calculated total goals (home + away) and goal difference (home - away). Over the whole backtest dataset, I took the mean squared error for these two quantities.

The xG-totals model performs almost exactly as well as the xG-resimulation model in predicting match goal difference. However, it performs markedly worse on total goals predictions (still much better than the goals-based model).

This suggests that the xG-totals method almost as good at estimating the relative strength of each team as the xG-resimulation approach. However, it is worse at predicting match outcomes because of some bias introduced; the xG-totals will underestimate the total number of goals being scored in any given match.

My hunch is that you could reduce some of this underperformance by using the number of shots in a game (also widely available) to get a mean xG per shot value. You could then use this xG per shot with the number of shots to simulate the match outcomes as though you had the individual shot data.

You could also gain some extra performance by ensembling a xG-totals model with a Goals model.

But at the end of the day, if this kind of performance drop is a big issue for you, it’s probably worth investing in a model with better foundations.

Conclusion

• You can make decent team strength models using only xG totals (but its predictions are not as good as with individual shot xGs)
• You don’t need the Dixon-Coles framework to do this (but it can be useful to have a common basis for comparison and model ensembles)
• You can apply this framework to incorporate many different data sets or information sources into a match prediction model. You just need a weighted-scoreline generation function.

Code etc

If you would like to reproduce this analysis, or dig a bit more into the technical details, the code can be found in my wingback repository.

This repo is built on top of understat-db, a project for pulling data from Understat.com into a database. It uses a Python library called mezzala for modelling team-strengths and match predictions.

I still have some Liverpool 2019/20 “data scarves” left for sale (shipping to the UK). If football+data is your thing, take a look

What is time-discounting?

Match prediction models tend to produce estimates of teams’ attacking and defensive strength. The more accurate these estimates are, the more accurate the predictions. Factors like teams’ performance levels (or even home-field advantage) are dynamic and change over time. New players come into the team, team tactics are tweaked, and so on. Because of this dynamism, data (matches) from, say, a year ago tends to be less relevant than data from last week.

Time-discounting is a way of weighting input data in match prediction models such that more recent matches are given a higher weight (and therefore more influence on the model’s parameter estimates) than those in the distant past.

Signal vs staleness

If the most relevant information is data from the last week, the ideal scenario would be to use only the latest match for each team. But, we know that in practice that’s unlikely to work. A single match is quite noisy; anything can happen.

So to combat the noise in a single game, we have to add more data from further back in the past. But that historical data isn’t quite as relevant as the data from last week. How a team played a long time ago doesn’t tell us that much about the team’s performance level now.

So there’s a tension between having more data, and each incremental bit of data being progressively more out of date. Too much old data, and you’re feeding misleading information into the model. Not enough data, and the model can’t separate the signal from the noise.

More signal = less data

If we use data that has less noise, we don’t have to use as much to extract a reliable signal. So instead of using more data, we can try to use better data.

This is broadly the logic of using expected goals (xG) instead of goals to evaluate teams and players. Goals are really noisy, so over the course of a season, there is still more signal in xG. To reliably evaluate teams on goals with the same confidence, you’d need years of data, at which point the coach has changed, the squad has changed… you’re comparing multiple different teams!

Exponential weighting

The most common form^[1] of time-discount is exponential weighting, where each data point is weighted according to the formula:

where “” is how long ago that match took place (usually in days) and “” (“epsilon”) is a hyperparameter.

Because of the nature of exponential decay, a high discount rate (yellow line) results in a very low weight for matches a long time in the past compared to a low discount rate (green line).

How do you find the right value of “”?

The simplest solution is to use backtesting. In short, this means training the model for a variety of different values of epsilon and seeing which one results in the best predictions.

Time-discounting with different models

If we backtest both Goals-based and xG-based models for a variety of “” values, we can compare results.

On the x-axis, I have plotted the weight at day 365 (), instead of just “” because think this is more intuitive. The raw “” values are shown in gray next to each point.

Both plots show the same overall shape: a very low weight at day 365 (i.e. a very high discount weight), leads to very poor performance followed by a sharp rise, a peak, and a slower decline as the discount rate increases (and old data is given more importance).

The peak model performance for the xG-based model comes at with a weight at day 365 of around 25%. On the other hand, the peak performance for the goals-based model comes at around 50% weight-at-day-365.

This goes back to what I mentioned earlier about signal-vs-noise. A goal-based model needs to give matches from the past a higher weight because goals are a noisy data source. Whereas the xG-based model performs best with a higher discount rate, because it’s able to extract more information from each match. Or, to put it another way, it requires less information before the staleness of additional data-points starts to harm the model’s performance.

We already knew xG was a better way to evaluate teams both intuitively and empirically, but I think looking at the comparison of goals and xG through the time-discounting is a nice way to develop our intuition about why xG is better.

Appendix I: A more entrenched elite?

EDIT (2020-07-19): Originally, I speculated that a change in “” since could be evidence of a more entrenched elite at the top of English football. However, in the original Dixon-Coles paper, they use half-weeks as their time unit (instead of days as I have). Once correcting for this, the difference in “” values is significantly reduced.

Thanks to Diogo for pointing this out to me on Twitter.

Appendix II: Code etc

If you would like to reproduce this analysis, or dig a bit more into the technical details, the code can be found in my wingback (because it’s concerned with back-testing models… I couldn’t help myself, I’m sorry) repository.

This repo is built on top of understat-db, a project for pulling data from Understat.com into a database. It uses a Python library called mezzala for modelling team-strengths and match predictions.

Appendix III: Data scarves

I still have some Liverpool 2019/20 “data scarves” left for sale (shipping to the UK). If football+data is your thing, take a look:

Some speculated that it was just random variation, and that Liverpool couldn’t be expected to maintain the over-performance. Others suggested tht their attacking patterns meant that they could create chances better than xG could capture.

This raises the question - how much does xG really tell us? Does it really tell us everything we need to know?

Formulating the question

Let’s start by looking at the two positions at either end of the spectrum:

If we had to choose one these two extremes, we already know that only-xG outperforms only-Goals. For a previous post, I created two team-strength models, one using xG data, the other using goals data. I then evaluated the models based on how well each one made predictions about future matches; the xG-based model came out on top.

But there’s a whole lot of space in between the extremes. As Ted Knutson said on Liverpool, “Part of [Liverpool’s 2018-2020 overperformance vs xG] is a little bit of luck. But I think there’s stuff Liverpool do that’s not in the expected goals model”.

So where does the truth lie? If it’s somewhere between the extremes, can we be more specific? And can we prove it?

Ensembles and composing models

The key for us is a technique called ensemble modelling. Ensemble modelling is a technique whereby multiple different models are used to create a single prediction. The intuition is similar to that of wisdom-of-the-crowd; as long as each model is bringing new information that the other model(s) don’t have, then they can improve the prediction accuracy. Thus, a diverse collection of models can perform better than any of the individual constituent models.

To answer our question, we can flip this logic around. We can create a bunch of models across the spectrum of xG-Goals:

Then, if there’s a combined xG+Goals model that performs better than either xG-only, then goalscoring must be adding information on top of what we already get from xG.

If we plot the model performance for each of these models, we should see one of two shapes^[1], depending on which hypothesis is correct:

In other words, the location of the best model will tell us where along the spectrum the “truth” lies. If the peak is somewhere in the middle, it would suggest that top performing teams like Liverpool do find some way to outperform the xG models.

Results

The method to evaluate the different models went as follows:

• For each Premier League matchday from the start of 16/17, fit an xG-based model and a Goals-based model on past data (i.e. not including the matchday in question).
• For each matchday, create the combined models, with varying degrees of mixing across the spectrum between xG-only and Goals-only.
• For each model (including the combined models), predict each match taking place on that matchday

This gives a set of 1,860 match predictions with which to evaluate our models. We can evaluate each model’s predictions to get an overall idea of the model’s quality:

Using log-likelihood as our metric, we get a peak in performance for models with a roughly 30% goals/70% xG component. The exact location of this peak varies depending on how you evaluate the model predictions, but 30% seems like the right approximate figure^[3]. Nonetheless, this suggests that teams with large differences between their xG tallies and actual goals are doing good/bad things that the xG models aren’t picking up on.

The ensemble approach cannot tell us what these unaccounted-for good/bad things are. My hunch is that it’s some combination of:

• Good teams creating more chances with low defensive pressure/clear sight of goal (and vice versa)
• Player finishing skill

Neither of which are included in the xG values used in this analysis.

I used xG data from Understat.com, as that seems to be the defacto public xG model. It’s likely that better xG models, like Statsbomb’s, squeeze the optimal mix of 30% down (more on this later). Although, I think it’s unlikely that it goes all the way to 0%.

What does this look like for individual teams?

Let’s look at the team-strength ratings for the top 6 at the end of 2018/19. This is right in the middle of Liverpool’s red-hot two-year stretch where they recorded the second and fourth-best ever Premier League points tallies.

The team strength ratings are presented in the form of “predicted goals versus an average Premier League team”. In other words, if you played each of these teams against a (hypothetical) perfectly average team over and over again, how many goals would they score and concede on average.

We can see that every one of the top 6 teams was out-performing their xG in attack this season; the goals-only estimate for goals scored (“Offence”) vs average is higher in every case. I think it’s unreasonable to suggest this is just random variation or “luck”. We’re seeing that there’s something missing from the xG values used in this investigation. This suggests that a better xG model (perhaps one built on more detailed data) that helps close the gap between the xG-only and Goals-only models, would have a smaller percentage of Goals-only in the optimal model ensemble.

This doesn’t tell us about whether individual teams are doing things that help them “beat” xG. It doesn’t take into account team tactics, or individual players’ finishing skill. However, it does shift our default expectation of a team’s quality to about 30% of the way between xG and goals.^[4]

2020/21 ratings

I don’t have anything clever to say, but it’s always fun to look at the most up-to-date ratings:

Conclusions

In general, our best estimate of PL teams’ quality is around 30% between their xG and their Goals, when using xG from Understat.com. Overall this strongly suggests that there is information contained within teams’ goalscoring performance that is not captured by xG totals alone.

On a technical note, this investigation presents a method for combining Poisson-based match prediction models, whilst preserving interpretability of the model parameters. This is useful because the parameter estimates, especially those of team attack and defence ratings, are often of particular interest.

With thanks to Marek Kwiatkowski, Tom Worville and Bobby Gardiner for providing feedback on an earlier draft of this piece.

If you enjoyed this article, I made some Liverpool 2019/20 “data scarves”, which you can buy (if you’re in the UK). I think they’re fun and you might too.

Code etc

If you would like to reproduce this analysis, or dig a bit more into the technical details, the code can be found in my wingback (because it’s concerned with back-testing models… I couldn’t help myself, I’m sorry) repository.

This repo is built on top of understat-db, a project for pulling data from Understat.com into a database. It uses a Python library called mezzala for modelling team-strengths and match predictions.

The design riffs on the classic striped scarf, but with an additional, data-driven twist. The colour of each stripe encodes the team’s record (win, lose, or draw) within a given season:

And here’s how it looks in the flesh:

These are available for sale here (the website only supports UK sales at the moment, but DM me on twitter if you’re non-UK and want to pick one up). Likewise, feel free to get in touch if you want to arrange for some custom scarves to be developed (min. 20 scarves).

As a result, tiny teams often need to be very productive, returning great slabs ofbusiness value in order to stick around (or gain further buy-in and influence). There’sbeen plenty of discussion of the strategies people can use to provide valueand win trust (see any one of the guest talks from the Opta Pro Forums,for example), and I don’t have much to add on that front. Instead,I’d like to talk about some of the tools that I’ve found useful when trying tocover a lot of ground quickly.

In general, a lot of the ideas here are covered more succinctly and eloquently by Dan McKinley in histalk/essay “Choose Boring Technology”. Hopefully, I can add some value by talking about some specific technologies and choices I’ve made.

Databases & SQL

I have found that having a database, even as a tiny team, is essential since it allows you to move from ad-hoc, manual processes to automated ones. This is important if you want to keep delivering new projects, rather than getting bogged down in manual and maintenance work.^[1]

And you can’t talk about databases without talking about SQL. SQL might be the most Boring Technology around. It’s everywhere, declarative code is really good, and when you use it, you’re standing on a giant heap of decades of accumulated knowledge. As a result, investing the time in learning to query and manage data with SQL can payoff massively.

In particular, I’ve gravitated towards two bits of software for managing analytics databases: Postgres and dbt.

Postgres

I’ve been using Postgres as my default choice for a few years now, and I haven’t ever felt the need to switch.

Here are some of the things I’ve been particularly pleased with:

• Inlined CTEs (requires Postgres 12 or later) allows you to prioritise readability without paying a performance penalty
• Good extensions
  • PostGIS for spatial queries (e.g. on x,y event data) is very cool and always leaves me looking for more excuses to use it
  • As an English-speaker, unaccent is a life-saver for searching accented player and team names
• The official documentation is really good. It’s very rare that I’ve had to resort to googling or stack-overflow instead of just navigating to the appropriate section of the docs.
• It’s supported by dbt (see next point)
• Easy deployment options - more or less every cloud provider has a managed Postgres offering.^[2]

I would consider moving to something designed specifically for data-warehousing (e.g. Snowflake) aspart of a merely small team, but advantages of Postgres make it more attractive to me in a tech team of 1-2.^[3]

dbt

The dbt docs are great, and state that:

dbt (data build tool) enables analytics engineers to transform data in their warehouses by simply writing select statements. dbt handles turning these select statements into tables and views.

dbt does the T in ELT (Extract, Load, Transform) processes – it doesn’t extract or load data, but it’s extremely good at transforming data that’s already loaded into your warehouse. [See this article for a breakdown of the difference between ETL and ELT.]

The role of dbt within a modern data stack is discussed in more detail here.

dbt also enables analysts to work more like software engineers, in line with the dbt Viewpoint.

In short, dbt enables you to manage your data using only SQL select statements with jinja templating.

I recommend investigating the links above for more detail and examples, but here are some of the reasons I love using it:

dbt…

• Leverages extremely common tech in the form of SQL, so it’s relatively easy to debug, get advice and onboard new people onto a project compared to an equivalent ETL pipeline
• Makes it easy to test your data, giving you confidence that your calculations are correct
• Has an active and helpful community - if you’re stuck on something, it’s likely that someone else has an answer
• Works with Postgres (but can be ported without too much hassle to a cloud data platform if you outgrow Postgres)
• Uses Jinja, which has nice synergy with Flask, where it’s used for HTML templating. A small win, admittedly, but nice nonetheless

But perhaps the most useful thing of all is how it flattens what I’ll call “the gradient of automation”^[4]. If you use SQL queries for all of…

• One-off queries and ad-hoc analyses
• Automated scripts, reports, etc
• Data transformations (ELT)

… it makes it very easy to move from a query “up” a level of automation. A query used to validate a specific question as a one-off might prove useful enough to add to a weekly report. The information might then prove to be worth staging as a pre-calculated table so that it can be used in other analyses, or joined to other data sources for more insights.

Like Postgres, dbt is open-source, but there is a hosted service that you can use to manage your dbt deployment (scheduling and monitoring jobs, etc).

Overall, I have found dbt to be an incredibly productive tool that Just Works, and I am very happy using it.

Records/PugSQL

Remember how I said I liked using SQL for everything? That extends to using SQL for querying within apps, reports, and so on.

There’s a family of libraries out there that enable you to expose SQL queries as functions within your programming language of choice. In Python, there’s PugSQL and the more minimalist Records.

I appreciate it may not be everyone’s cup of tea, but maximising the use of SQL reduces the number of different things I need to know while being productive.

Learning SQL

If you’re looking for a place to start learning SQL, Execute Program has a course (first 16 lessons are free, after that there’s a paid subscription) which incorporates spaced repetition. I haven’t used it (yet!), but other people seem to like it.

I’ve also developed a small project for creating a database of Understat data, that might be worth checking out if you want toget a bit more experience querying and working with relational databases. This project uses both Postgres and dbt, and is designed to be altered, extended, and remixed.

Web applications

Being able to deploy to the web is extremely useful. Having a platform to expose reports, models, or input data, even if it’s just for your own use, can go a really long way.^[5]

However, I think web development can be a bit of a trap for non-experts (like me). For this reason, I tend to be extremely Javascript-averse and choose the least exciting options when developing anything web-related^[6]. While my web apps will never have the sickest UIs, I can keep the maintenance cost manageable, and get more work done overall.

Flask/Django

As part of my Boring Web Apps, I tend to develop server-side rendered applications. In Python, the ones I have most familiarity with are Flask and Django.

Both are extremely widely used which means there’s lots of support and documentation available online.Both use HTML templating, which is another old/Boring technology. Having decent knowledge of HTML can also come in handy with any web-scraping projects.

There are also many managed hosting options for app deployment that I have found very useful.

Bootstrap

Bootstrap is “the world’s most popular framework for building responsive, mobile-first sites”.

I might not mind a website looking like it’s from 2010, but I would at least like it to look like a nice website from 2010. That’s what I use Bootstrap for.

While I’m sure there’s myriad other options available that fill the same niche, Bootstrap is the one I’ve been using for years, and I haven’t felt a burning need to switch. If you think I’m really missing out on something let me know!

General themes

I think there are a few themes running through the decisions I’ve made on these types of teams:

• As part of a tiny tech team, time is likely to be your biggest constraint
  • Paying attention to the time required to maintain your work if essential to remaining productive beyond the short-term
• Embrace frameworks for high-reward given time/effort
  • Tools that are good enough (even if not perfect) can allow you to spendmore time on your core work
  • Using popular frameworks can also make it easier to hand-off to and/or integrate new team members
• Invest in core skills/tools that can be applied widely and robustly
  • Established tech is more likely to be well tested, and is easier to find learning resources,documentation, and help online ~if~ when something goes wrong
  • Being comfortable with boring, ubiquitous tech like relational databases and simpleweb-applications allows you to have a big impact across a range of domains
  • Or, to steal from Dan McKinley, choose boring technology. There’s so much good stuff in this talk/essay.
• Learn to love problems, not solutions
  • Focusing on problems to solve (as opposed to a specific solution)enables you to iterate effectively and not get stuck on getting anelegant idea to work, or endlessly refining a product that’s good enough for now

I think these things amount to okay advice. But I am still early on in my career, and the trade-offs for small, medium and large teams can be quite different. In an industry where lots of people are trying to get hired, we don’t often talk about the boring stuff. I think that’s a shame, because the boring stuff is often what makes you productive.

As the industry matures, and more organisations build enough trust to invest in full tech and data teams, I think we’ll see these kinds of “tech+data generalist” roles start to die out. However, for the time being, these roles exist and these are some of the bits and pieces I’ve been using to get (some) things done.

If you think I’m missing out on something great that you’ve been using, or if your experiences in a similar role have been different, you can reach me on twitter - I’d love to hear from you!

understat-db is a project for creating your own database of football (soccer) datafrom understat.com.

You can find the project’s source code on Github.

Why should you use it?

This project isn’t prescriptive, so there’s no “correct” (or “incorrect”) way to use it. But there are two main ways in which I think it might be useful:

• As a project to create a standalone database of football data
  • For example, using the data to create one-off visualisations in a separate project
  • Or, as a way to get started with learning SQL, without having to create a database
• As a base project to modify and extend to suit your needs
  • For example, if you wanted to store additional data or views in the database

Why did I make it?

There are a few blog posts/experiments I’d like to write up, and I generally like to make my posts/projects repeatable. This means including any code + data required to reproduce the results. In the past, I’ve tended to embed the code inside the post notebook-style. However, this has 2 drawbacks for me.

Firstly, it makes it difficult to build upon previous work - you have to go overany required code again, or ask the reader to refer back to a past post. Neither of these strike me as great options.

Secondly, the linear format of a blog-post or notebook isn’t always the clearest way to communicate. Especially when dealing with concepts in code, which doesn’t necessarily have a clear start, middle, and end.

Hopefully, having some form of packaging/code distribution will help separate the blog content from the code. One or two of these future projects will build on top of understat-db, but I thought it would be useful enough to release as a standalone project.

(I also wanted to try out nbdev and this seemed like a good fit (see “nbdev”).)

What’s next?

If this project is useful to enough people, I’d like to flesh out the documentation and write one or two tutorials. If this sounds good to you, or (even better), you’d like to help - let me know!

I’d also like to release something similar for working with Statsbomb’s public data, but that’s a little further down my list at the moment. In any case, if that sounds interesting to you, watch this space.

Other info

This project uses a few different bits of software:

• Python (3.6+)
• Postgres (12+ recommended)
• nbdev
• dbt
• Docker (optional - used for the database)

You don’t necessarily need to know each of these tools to use the project, but it’s worth being aware of them if you want to extend or fork the project.

Charles William used a more thoughtful approach when experimenting with using CNNs to derive xG estimates. This approach yielded much better results, and represents a much better starting point for anyone wanting to pursue these ideas seriously.

Nonetheless, I had some fun exploring these ideas and I thought it was worth throwing the results up here in case anyone else is interested.

Background

Recently, I’ve been working through the fastai book. The iterative, application-focused style of the book gives it a smooth learning curve, and if you have an interest in deep learning I would happily recommend it.

The fastai approach aims to be pragmatic and falls more on the side of “ML for product development” (as opposed to what I’d call “ML for insight”). In particular, it takes an end-to-end approach to teaching machine learning that frequently leverages transfer learning:

Transfer learning (TL) is a research problem in machine learning (ML) that focuses on storing knowledge gained while solving one problem and applying it to a different but related problem. For example, knowledge gained while learning to recognize cars could apply when trying to recognize trucks.

The book stresses that this can be a good choice for real-world applications and that you don’t need a PhD to achieve excellent (even state-of-the-art) results with creative applications of transfer learning. For example, using image classifiers on spectograms to classify sounds.

This got me thinking - could we use transfer learning to train an xG model?

Motivation

Part of my motivation (the main part) for this project was to try out some elements of the fastai library that I’ve read about in the book.

However, I think there are the kernels of a few ideas that might be interesting, too:

Training on small datasets

I am often asked about xG models by practitioners in under-served areas (for example, lower-leagues). In many cases, people want (or have been asked by their boss) to calculate xG values for their games, where the only data they have is manually coded by themselves.

I’m generally reluctant to advise use of a specific xG model. The dynamics of goal-scoring (and the game more generally) in the Premier League are going to be different to those in the lower leagues. Furthermore, hand-collected data will be very different to that of a major data provider (the major data providers can’t even agree amongst themselves). For these reasons, a model trained on industry-standard top-league data may not generalise well to these domains^[1].

But maybe being able to fine-tune a pre-trained xG model on your hand-collected data could be useful?

Sharing and extending models

Similar to above, if xG models had a common interface, then maybe we could share/compare/etc xG models more easily? This would make fine-tuning easier, too. The idiomatic way to do this with fastai seems be to use images as that interface, and so that is what I did.

An alternative solution might be to agree a standard schema for representing shots like the folks at KU Leuven have done with event data and SPADL. However, images do have one advantage as a model input that a more structured input lacks.

Perhaps, using images would enable you to add new features to the images before fine-tuning? Since images are a shared representation of sorts?

Yeah, this makes me cringe a bit, too. But, like I said, kernels of ideas that might be interesting.

Method

At a high level, the method went something like:

• Generate images representing shots
• Train a classifier (fine-tuned resnet34) for whether the shot resulted in a goal or not (xG)
  • I ended up training on 4000 shots for this experiment. This strains the “small dataset” point a bit, but I figured I’d see if it worked on a larger dataset, and then see how dataset size affected performance as a second step.
• Test xG on out-of-sample images

The code is on GitHub if you want to give it a spin for yourself.

I experimented with a few image types to feed into the model. For this initial experiment, I thought it would be fun to keep the images as “human-readable” as possible, and ended up with the following:

• “Triangle” plot - taking the triangle made between the shot location and the goalposts:
• Minimal voronoi - A voronoi chart using only the goalkeeper and shooter’s location:
• Basic freeze-frame - a simple pitch-plot with each opposition player and goalkeeper shown as a single point. The shot triangle is overlain as well:
• Voronoi freeze-frame - A voronoi chart using the location of all opposition players and the shooter, with shot triangle overlain:

Results

Root Mean-Squared Error

Let’s look at the Root Mean-Squared Error (RMSE) of the various models. The RMSE is calculated as sqrt(mean( (xG - is_goal)^2 )), where is_goal is 1 for a goal, and 0 for no goal. Lower is better.

The RMSE for each of the image models, an “ensemble” (the average of the xG estimates from the minimal_voronoi and triangle models), and Statsbomb’s own xG is shown below.

I also added a benchmark “model”, which uses the average conversion rate of all shots as its xG estimates. This represents the no-information scenario, which all models should beat.

There are a couple of things that jump out immediately:

• All the models do much worse than the Statsbomb xG
• The simpler images (triangle, minimal_voronoi) performed better than those that used the full freeze-frame data
  • The more “complex” images were prone to over-fitting on the training data before reaching the accuracy of the simpler models

However, I don’t think the results (for simple models) are terrible. An RMSE of about 0.29 is around the same ballpark as a couple of other models (logistic regression, random forest) that I threw at the same dataset, trained on “simple” (non freeze-frame) features.

Distribution of predictions

Looking at the distribution of predicted xG, we can see that the “complex” models (basic, voronoi) tend to be much more conservative than the simple models (triangle, minimal_voronoi); they refrain from making very low and very high xG estimates.

Although the simple models are better in this respect, their xG distributions still show some clumping when compared to Statsbomb’s estimates.

For the simple models, I think this is understandable on the grounds that they don’t actually have access to more advanced features. However, it’s disappointing to see from the complex models which could (in theory) pick up on this.

So overall, not great.

Perhaps the clean, geometric nature of the shot images was too different from the type of images it was trained on (imagenet)? Could more idiomatic (i.e. computer-friendly, rather than human-friendly) images help close the gap to Statsbomb’s model?

Further developments

Is it worth taking this idea further? I’m on the fence.

On the one hand, the top-level results for “simple” images are relatively promising. Maybe there’s a better representation of freeze-frames that the model can more effectively learn from?

On the other hand, there are so many practical pitfalls and flaws with this method. Without state-of-the-art results, I don’t see why you’d persist with this over a more reliable, easily explainable method^[2]. For serious applications, I think careful, methodical investigations are going to be more appropriate. One such case is Charles William’s work, “Evaluating the Performance of Convolutional Neural Network Based xG Models”.

So I’m not sure. I think I’ll leave it for the time being, but if I might revisit it if I can think of a better way to show the full freeze-frames in image format. It would be fun to get somewhere close to Statsbomb’s error rate with a relatively wacky idea like this.

Code etc

The code for this project is available on GitHub.

I used the cookiecutter data science template for this project. I used this partly out of curiosity, but also in the hope it might make it easier for people to modify or experiment with.

What do you think? let me know.

In short, the video states that you can “[use] an algorithm glitch to gain … thousands of subscribers” by uploading Shorts (vertical format, <1min long Youtube videos).

I would probably call this “promoting Youtube’s latest new feature” rather than a “glitch”. It seems a bit like calling Netflix giving preferential treatment to its Original series, “gaming the algorithm”.

But still, I was curious. Could it really be that easy?

The plan?

• Autogenerate clips of spectacular goals and woodwork strikes (that is, from shots with the lowest xG). I already had some code that I could re-purpose to this end from Fully Automated Luxury Commentary.
• Upload them to Youtube in Shorts format
• ???
• Profit

The results

It went terribly! Didn’t work at all!

I uploaded 28 videos (scheduled at a rate 1-2 per day) which received 101 views total.

Some things which seemed to have some (positive) effect on the number of views:

• Watching the video back on Youtube after uploading - I’m guessing that the initial boost to the views number is favourable to the algorithm
• Videos with household name players or top teams in the title
• Clickbaity titles - unsurprisingly ambiguous ones tended to result in more views than ones which clearly stated what the video was about

Some things which didn’t seem to have an effect (for me):

• Manually picking thumbnails (in fairness, I put very little effort into the custom thumbnails)
• Uploading 2 videos in a day (vs 1 video)

So far, pretty unsurprising and pretty uninspiring.

So what did I learn?

This project had little intrinsic value to me; I don’t tend to watch short-format videos on any platform. And if I’ not that interested in my videos, I’m not sure why I could persuade anyone else to be interested^[1]. Perhaps if my primary motivation was fame or money, it would be different?

On reflection, I think the project was sort of doomed to fail from the start. The idea that short football clips might have widespread appeal was misguided; it wasn’t based on any theory or understanding of why we like the sport. Sure, some moments of football may have an intrinsic aesthetic appeal, but the clips I used fell completely flat when stripped of context and culture.

Ultimately, I think the values of what I created was at odds with the values of football. I think it’s very difficult to make something like that succeed (we don’t have a European Super League yet, for instance), and I don’t particularly want to try.

So, lesson learned^[2] - stick to making things I don’t hate.

Correct me if I’m wrong here but, if you’re a low quality side in a league, you’d actually prefer a dozen long shots (lets say each of 0.05 xG) to one great chance (0.6 xG) because there would be a higher variability of outcomes, which would mean you’d have a higher expected points from a given match.

That teams should prioritise high-quality shots has been a common refrain in the public analytics sphere for years. The fact that fewer, high-quality shots can increase win % is even the default example in Danny Page’s Match Expected Goals Simulator.

Over time, there’s been an increasing number of counter-arguments that poor-quality shots (long-shots especially) may have some utility. For example, by keeping a team’s attack from being too predictable, or being a generally positive expected-value way to dispose of a possession.

However, Kees’s hypothesis is particularly interesting because he’s saying that, under certain circumstances (a very bad defence), teams should prefer lots of poor-quality shots, for the same reason that analysts were arguing for high-quality shots: it gets you more points.

What’s the intuition behind this idea?

Let’s say we have two teams, who both create 0.95 xG. One of those teams takes 32 shots at about 0.03 xG each (i.e. a 3% chance of scoring each shot). The second team takes just 3 shots (0.32 xG each, 32% chance of scoring each shot). How many goals is each team expected to score?

library(tidyverse)

total_xg_for <- 0.95

shot_quality <- tibble(
  label = c("Very bad", "Bad", "Okay", "Good", "Very good") %>%
    paste("chances") %>%
    as_factor(),
  xg = total_xg_for,
  n_shots = c(35, 20, 10, 5, 3),
  xg_per_shot = xg / n_shots,
)

get_goal_probabilities <- function(n_shots, xg_per_shot) {
  tibble(
    goals = 0:n_shots,
    prob  = dbinom(0:n_shots, n_shots, xg_per_shot)
  )
}


shot_quality_goals <-
  shot_quality %>%
  mutate(probs = map2(n_shots, xg_per_shot, get_goal_probabilities)) %>%
  unnest(cols = c(probs))

shot_quality_goals %>%
  filter(label %in% c("Very bad chances", "Very good chances")) %>%
  ggplot(aes(x = goals, y = prob)) +
  geom_col() +
  geom_vline(xintercept = 2.5, linetype = "dashed", colour = "red") +
  scale_x_continuous(limits = c(-0.5, 5.5), breaks = 0:10) +
  scale_y_continuous(labels = scales::percent_format(accuracy = 1)) +
  facet_wrap(vars(label, xg_per_shot),
             labeller = labeller(
               label = label_value,
               xg_per_shot = as_labeller(function(x) {
                 paste0("xG per shot: ", scales::number(as.numeric(x), accuracy = 0.01))
               })
             )) +
  labs(title = "Bad chances are better if you're guaranteed to concede 3 goals?",
       subtitle = str_glue("Probability of _ goals from {total_xg_for} xG"),
       x = "Goals scored",
       y = NULL) +
  theme_minimal() +
  theme(plot.title = element_text(face = "bold"),
        panel.grid.major.x = element_blank(),
        panel.grid.minor.x = element_blank())

The very bad shots have a greater chance of scoring no goals, and a lower chance of scoring 1 or 2 goals than the very good shots. However, they also have a greater chance of scoring 3 or more goals.

In matches where they concede 2 goals, the first team has a better chance of winning than the second team, despite being less likely to draw. And in matches where 3 goals are conceded, the second team would never do better than a draw! At the bottom end of the table, those extra points can be vital.

So, we can see that there are extreme scenarios where this argument does hold water.

At this point, I should point out that this scenario is adapted from a point that Kees himself made in a follow-up to the original tweet:

One 0.6 xG shot can yield at most one goal, whereas 12 0.05 xG shots can yield many goals but also are more likely to yield none.

But this isn’t an entirely realistic scenario, is it?

In real life, even bad teams keep clean sheets occasionally. This is because thenumber of goals conceded in a given match follows a distribution. No team consistently concedes 3 goals per game, and even very bad teams keep clean sheets occasionally.

Can we test in a more realistic setting?

I think so! My idea for investigating these dynamics further looks like this:

• Take 5 chance quality scenarios, where the total xG generated is a constant 0.95 per game:

  Chance quality	xG per shot
  Very bad chances	0.03
  Bad chances	0.05
  Okay chances	0.10
  Good chances	0.19
  Very good chances	0.32

• And 5 defence quality scenarios, assuming goals conceded per game follow a Poisson distribution:

  Defence quality	Avg. goals conceded
  Very bad defence	2.50
  Bad defence	1.80
  Okay defence	1.30
  Good defence	0.90
  Very good defence	0.70

• Then, see how teams’ chances of getting a result vary for each combination of defence/chance quality, by simulating the goals scored and conceded.

This is, of course, a gross simplification of what the real world looks like. In particular:

• Goals conceded over a season doesn’t actually follow a Poisson distribution. This is driven by variation in the goalscoring rate from match-to-match and within matches.
• We have assumed that goalscoring and goal concession occur independently. In real life, teams’ tactics and motivation is influenced by the scorline.

However, I think this rough approximation is good enough to improve our understanding of the trade-off between attacking chance-quality and results. A more sophisticated model of shot generation developed by Marek Kwiatkowski can be found here, and could form the basis of a more thorough analysis of these trade-offs.

Results

With these assumptions, we can see a very slight uplift to win chance for teams creating 0.95 xG across lower quality chances, when their defence is expected to concede more than about 1.8 goals:

# NB: continues from previous code section

defence_quality <- tibble(
  label = c("Very bad", "Bad", "Okay", "Good", "Very good") %>%
    paste("defence") %>%
    as_factor(),
  xg = c(2.5, 1.8, 1.3, 0.9, 0.7)
)

defence_quality_goals <-
  defence_quality %>%
  mutate(probs = map(xg, function(x) {
    tibble(goals = 0:20,
           prob  = dpois(0:20, x))
  })) %>%
  unnest(cols = c(probs))

results <-
  full_join(
    shot_quality_goals,
    defence_quality_goals,
    by = character(),
    suffix = c("_shot", "_defence")
  ) %>%
    mutate(prob = prob_shot * prob_defence) %>%
    group_by(label_shot, label_defence) %>%
    summarise(w = sum(ifelse(goals_shot > goals_defence, prob, 0)),
              d = sum(ifelse(goals_shot == goals_defence, prob, 0)),
              l = sum(ifelse(goals_shot < goals_defence, prob, 0)),
              pts = w*3 + d) %>%
    ungroup()

results %>%
  ggplot(aes(x = label_shot, y = label_defence)) +
  geom_tile(aes(fill = w), width = 0.75, height = 0.75) +
  geom_text(aes(label = scales::percent(w, accuracy = 0.1)), colour = "white") +
  labs(title = "Bad chances could provide a (tiny) uplift to results,\nfor very bad defences ",
       subtitle = "Win probability",
       x = NULL,
       y = NULL) +
  scale_fill_continuous(guide = NULL) +
  theme_minimal() +
  theme(plot.title = element_text(face = "bold"),
        panel.grid.major = element_blank(),
        panel.grid.minor = element_blank())

However, the uplift to win and draw chance is very small; it is only worth about 0.02 additional expected points. If you’re conceding 3 goals a game, you’re still getting relegated no matter how many long-shots you take.

And, as initially noted, there is an advantage gained from having fewer, high-quality chances when generating more xG than your opponent.

This advantage appears to be much more pronounced than the inverse effect (where low-quality chances have the advantage). Teams who are better than their opponents get much more of an uplift from high-quality chances than bad teams get from increasing their variance with low-quality chances.

annotate_background_text <- partial(
  annotate, geom = "label", size = 6, fontface = "bold", colour = "gray",
  label.size = 0
)

results %>%
  pivot_wider(
    id_cols = label_defence,
    names_from = label_shot,
    values_from = w,
    names_repair = janitor::make_clean_names
  ) %>%
  left_join(defence_quality, by = c("label_defence" = "label")) %>%
  mutate(uplift = very_good_chances - very_bad_chances) %>%
  ggplot(aes(x = total_xg_for - xg, y = uplift)) +
  geom_hline(yintercept = 0, colour = "dimgray", linetype = "dashed") +
  annotate_background_text(
    label = "High quality chances are better",
    x = -1.75,
    y =  0.02,
    hjust = 0
  ) +
  annotate(
    "segment",
    x = -1.75, xend = -1.75, y = 0.0125, yend = 0.0275,
    colour = "gray",
    arrow = arrow(type = "closed", angle = 20, length = unit(0.02, "npc"))
  ) +
  annotate_background_text(
    label = "Low quality chances are better",
    x = 0.5,
    y = -0.01,
    hjust = 1
  ) +
  annotate(
    "segment",
    x = 0.5, xend = 0.5, y = -0.005, yend = -0.015,
    colour = "gray",
    arrow = arrow(type = "closed", angle = 20, length = unit(0.02, "npc"))
  ) +
  geom_point() +
  geom_text(aes(label = label_defence), vjust = 1.5) +
  scale_y_continuous(
    expand = expansion(add = 0.0025),
    labels = scales::percent_format(accuracy = 1)
  ) +
  labs(
    title = "Swing in win % is much bigger when xGD is positive",
    subtitle = "Absolute change in win %, between very good and very bad chances",
    x = "xGD",
    y = NULL
  ) +
  theme_minimal() +
  theme(plot.title = element_text(face = "bold"))

How should this affect teams decisions?

I don’t think this effect should be a major factor in weak teams’ tactics. The theoretical advantage to weak teams taking low-quality, high-variance shots is very small (maxes out at around 1%). The assumptions made in the above test are rough enough that I don’t think we can sure that such a small edge would even translate into real life.

Moreover, in real matches, you don’t get to distribute the xG of your chances like a character-creation slider in a video game. The strongest case for favouring high-quality chances has always been that, in many cases, playing the right pass will result in a better chance than taking an early shot (even accounting for the fact that the move may break down before a shot can be taken). Does anything we’ve learned here suggest we should move away from a heuristic of “maximise the total xG of each possession sequence”?

For all but the most dominant teams, I would say that it does not.

In matches where a team is dominant, there may be a slight, real advantage gained by prioritising high-quality chances, even at a slight cost to total xG. The method above returns an approximate increase around 4-5% for dominant teams (+1.5 xGD) prioritising very good chances (~0.3 xG per shot), so I think there’s a slightly stronger case to tweak your approach in these circumstances, especially in matches where you’re going to spend a lot of time facing an organised defence.

What is it?

Automatically generate commentary for football matches, using clips fromGary Bloom’s Sega Worldwide Soccer 97 and Statsbomb’s event data.

Why is it?

The idea that you can generate commentary purely from event data is relatively mundane (it has been implemented in basically every soccer video game for the past 20+ years), but has always seemed fun to me. The increasing desire to package football up as a clean entertainment product, along with the addition of synthetic crowd noise to closed-doors games brought it back to the forefront of my mind over this past Summer.

Alongside this, the various releases of Stasbomb’s free event data finally made it possible to make a widely accessible auto-commentary tool, rather than making something only for the small number of people with access toofficial data streams.

How does it work?

At a high level, the implementation is as follows:

• For a given match, we can get the event data from Statsbomb as a list of events
• We also have a set of audio clips from Sega Worldwide Soccer 97
• Each audio clip can be linked to a set of conditions that must be true for theclip to be relevant. For example:
  • Clip X is a goal
  • Clip Y is a pass and the pass is successful and the pass ends inside the penalty area
  • (etc…)
• For each event in the list:
  • We can check the audio clips to find any that are relevant. In other words, clips where the event in question passes all the linked conditions
  • And then pick one at random
• Once we have the clips, we can stitch them together at the appropriate timestamp to create a single synthetic audio track

If you want a lower-level look, you can find the code on github.

There’s loads of potential improvements that could be made both to the code and to the tool, but I’ve been sitting on this for a few months, running out of motivation. I figured releasing something was better than having it languish on my computer at home.

Is it really fully automated?

Not entirely. I had to bring the clips, footage and crowd noise in a video editor to make the video at the top. Mostly, this name sounds better than “pypundit” or “AI McCoist”, which was all I had before.

Can I try it out, too?

Sure! The code is all on github here, so you can clone, run, and submit issues or improvements.

However, this is a missed opportunity. In certain cases, using nonstandard gridlinescan enhance the legibility of a graphic and its take-home message. In this post, I willlook at a couple of different ways that diagonal gridlines can be used to this effect.

1: For ratios (HFA disruption plot)

The first example comes from a previous post, investigating potential disruption to homeadvantage pre/post-covid:

(See the end of the previous post for the ggplot2 implementation.)

In general, this kind of approach can be useful when the ratio between the x- and y-measuresis meaningful.

Another potential place to apply this is the “p90 scatter” charts that are commonon social media. These charts often consist of a scatter plot showing a set of football players’score in 2 correlated metrics (for example, xGp90 and Goals p90), with the outliers annotated (these being noteworthy players).

In many cases, the ratio of y/x is useful information. For a scatter of xGp90 against Goals p90, the ratio would be a measure of over/underperformance against xG. On other charts, it may be a success or conversion rate.

This technique can be applied broadly, as long as the ratio of y/x is meaningful.For instance, see how adding diagonal lines to this plot highlights that Adama Traoréand Allan Saint-Maximin had almost the same rate of progressive distance per carry in 2019/20:

library(tidyverse)
library(rvest)

# Fetch the FBref data from acciotables
epl_possession_data <-
  read_html("http://acciotables.herokuapp.com/?page_url=https://fbref.com/en/comps/9/3232/possession/2019-2020-Premier-League-Stats&content_selector_id=%23stats_possession") %>%
  html_table() %>%
  .[[1]] %>%
  janitor::row_to_names(row_number = 1) %>%
  filter(Rk != "Rk") %>%
  readr::type_convert()


selected_players <- c(
  "Adama Traoré",
  "Allan Saint-Maximin"
)

selected_player_data <-
  filter(epl_possession_data, Player %in% selected_players)


epl_possession_data %>%
  # Get the midfielders with at least 900 minutes played in 19/20
  filter(`90s` > 10,
         str_detect(Pos, "MF")) %>%
  ggplot(aes(x = Carries/`90s`, y = PrgDist/`90s`)) +

  # Add the diagonal guidelines and their labels
  imap(seq(1, 8, by = 1), function(slope, i) {

    # Calculate the position of the labels, such that
    # they run along the top horizontally, beyond a
    # maximum y value
    max_x <- 70
    max_y <- 350
    label_x <- ifelse(slope*max_x <= max_y, max_x, (max_y / slope))
    label_y <- slope*label_x

    # Only show the full label for the first annotation
    label <- str_glue("{slope} yds")
    if (i == 1) {
      label <- str_glue("{slope} progressive yard per carry")
    }

    # Return the layers
    list(
      geom_segment(x = 0, y = 0, xend = max_x*2, yend = slope*max_x*2, linetype = "dashed", colour = "lightgray"),
      annotate(geom = "label", x = label_x, label_y,
               label = label, hjust = 1,
               colour = "dimgray", label.size = 0)
    )
  }) +

  geom_point(colour = "lightskyblue") +
  geom_text(aes(label = Player), hjust = 1.05,
            data = selected_player_data) +
  theme_minimal() +
  coord_cartesian(xlim = c(0, NA), ylim = c(0, NA)) +
  scale_x_continuous(labels = scales::number_format(1)) +
  scale_y_continuous(labels = scales::number_format(1)) +
  labs(title = "Adama and Saint-Maximin are more direct with the ball than anyone else",
       subtitle = "You probably didn't need stats to tell you that",
       x = "Carries p90",
       y = "Progressive distance carried p90",
       caption = "Data by StatsBomb via fbref.com")

Diagonal gradients

This specific technique has been extended by Ben Mayhew (@experimental361) quite distinctively by augmenting the diagonal gridlines with a colour gradient, like so:

(Taken from https://twitter.com/experimental361/status/1287746116721795074)

library(tidyverse)
library(regista)

# You may need to
# devtools::install_github("torvaney/footballdatr")

epl_match_results <-
  footballdatr::fetch_data("england", division = 0, season = 2018) %>%
  factor_teams(c("home", "away"))

model <- dixoncoles(hgoal, agoal, home, away, data = epl_match_results)

team_parameters <-
  broom::tidy(model) %>%
  filter(parameter %in% c("off", "def")) %>%
  mutate(value = exp(value)) %>%
  spread(parameter, value)

team_parameters %>%
  ggplot(aes(x = off, y = def)) +
  # THIS IS THE IMPORTANT BIT!
  # Add the "gradient" by layering translucent polygons
  # NB: This has to go before any plot elements that we
  #     actually want to see, so that we don't draw over them...
  purrr::map(seq(0, 3, length.out = 10), function(m) {
    annotate("polygon",
             x = c(0, 5, 5, 0),
             y = c(0, m*5, 5, 5),
             alpha = 1/5,
             # Official brand colours from https://www.color-hex.com/color-palette/44426
             fill = "#e90052")
  }) +
  # We need to manually set the axis limits
  coord_cartesian(c(1/2, 2), c(1/2, 2)) +
  # No source for the official brand font - I guess Roboto will do?
  ggrepel::geom_text_repel(aes(label = team),
                           colour = "#38003c",
                           family = "Roboto") +
  geom_point(alpha = 0.5, colour = "#38003c") +
  theme_minimal() +
  theme(panel.grid = element_blank(),
        text = element_text(family = "Roboto")) +
  labs(title = "Team strength estimates",
       subtitle = "Premier League 2017/18",
       x = "Attack",
       y = "Defence")

2: For comparable units (NPG+A plot)

In rarer cases, the x- and y-measures have comparable units. That is, you could meaningfully add the x and y values together. For example, goals and assists are often counted together to create overall “goal contribution” (likewise shots, key passes, and “shot contribution”).

In cases where the sum of the x and y values is useful, a different kind of diagonal grid can be drawn:

The diagonal gridlines here show the overall expected goal contribution (npxG + xA).Two players on the same line will have the same npxG + xA, despite having differentnpxG or xA figures.

This stratifies the plot elements more meaningfully than standard gridlines and helps readers draw useful comparisons between players.

If we compare to the same plot without gridlines, it is easy to see Di María and Mbappéas outliers and put them in the same tier.

However, this is not true. Mbappé’s goal contribution is a level above that of Di María,Neymar, Slimani, or Icardi; referring back to the first plot, we can see that the latter group all sit withinthe same tranche.

There is a minor injustice here that xA is harder to come by than xG. Di María’s achievementis rarer and thus perhaps more impressive than Neymar’s (likewise Payet:Cardona, and so on). However, I think that on-balance, the benefits to plot legibility are worth it.

library(tidyverse)
library(rvest)


format_colnames <-
  . %>%
  str_to_lower() %>%
  str_replace_all("\\s+", "_")


get_fbref_colnames <- function(data, row_number = 1) {
  row_data <- unlist(data[row_number, ])

  imap_chr(row_data, function(col_name, parent_name) {
    if (parent_name == "") {
      return(col_name)
    }

    paste0(parent_name, "_", col_name)
  })
}

fbref_row_to_colnames <- function(data, row_number = 1) {
  new_colnames <- get_fbref_colnames(data, row_number)

  data %>%
    magrittr::set_colnames(new_colnames) %>%
    # Rownames are recycled periodically. Remove these
    filter(Rk != "Rk")
}


l1_player_data <-
  read_html("http://acciotables.herokuapp.com/?page_url=https://fbref.com/en/comps/13/3243/stats/2019-2020-Ligue-1-Stats&content_selector_id=%23stats_standard") %>%
  html_table() %>%
  .[[1]] %>%
  fbref_row_to_colnames() %>%
  rename_with(format_colnames) %>%
  readr::type_convert()

l1_player_data %>%
  filter(playing_time_min >= 10*90,
         `per_90_minutes_npxg+xa` >= 0.2) %>%
  ggplot(aes(x = per_90_minutes_npxg, y = per_90_minutes_xa)) +

  # Add the diagonal gridlines, bounded by the x- and y- axes
  map(seq(0, 2, by = 0.1), function(intercept) {
    geom_segment(x = 0, y = intercept, xend = intercept, yend = 0, linetype = "dotted", colour = "lightgray")
  }) +

  geom_point(colour = "lightskyblue", alpha = 0.9) +
  geom_text(aes(label = player), check_overlap = TRUE, vjust = 1.05, size = 3) +
  theme_minimal() +
  theme(panel.grid.major = element_line(size = 0.2),
        panel.grid.minor = element_blank()) +
  coord_cartesian(xlim = c(0, 1.1), ylim = c(0, NA)) +
  scale_x_continuous(breaks = seq(0, 2, by = 0.1), labels = scales::number_format(0.1)) +
  scale_y_continuous(breaks = seq(0, 2, by = 0.1), labels = scales::number_format(0.1)) +
  labs(title = "Mbappé contributes goals like nobody else in Ligue 1",
       subtitle = "Again... it maybe didn't need stats to convince you",
       x = "xG p90",
       y = "xA p90",
       caption = "Data by StatsBomb via fbref.com")

Minor algebraic aside (you can skip this bit)

The formula of a straight line is y = mx + c. Given an x-coordinate, you can find the corresponding y-coordinate on that line by multiplying it by m (the slope) and adding c (the intercept).

You can therefore view the first set of examples as diagonal gridlines where the slope is of interest.In other words, we set gridlines with varying values of m, and a fixed intercept (generally, c will be 0).

In the second category, we are looking at varying the intercept (c), while keeping the slope constant.In our example, m is fixed to -1. This is because we are taking the sum of the x- and y- measures,and re-arranging the formula y + x = c gives us y = (-1)x + c.

If you were interested in the difference between the y- and x- measures, you would draw diagonal gridlines with varying slope and a gradient of +1.

Conclusion

You can use diagonal gridlines liek these to highlight key features of your data in a couple of different cases:

• When the ratio between x and y is meaningful, you can draw gridlines with varying slope
• When the x- and y-axes have comparable units, you can draw gridlines with a varying intercept

Despite this, the format of football coverage in the UK has largely stayed the same for years.While I would welcome more radical experimentation, I have three specific suggestionsthat I think would improve football coverage in the UK.

1. No more close-ups and replays while the ball is in play

Or replays for that matter. As far as I can tell, no-one who actually likesfootball would rather watch close-ups and replays when we could bewatching the actual match being played.

I don’t have an issue with replays themselves. It’s just that there’s plenty oftime to show any key highlights at half-time or full-time.

As for close-ups, you don’t have to go full tactical-cam for the whole match. However, keeping the pitch and match context visible helps to understand what’s going on. Much of the vaunted beauty of football happens in the interaction between the players and spaces throughout a given play. You don’t have to be a mathematician to see that with 22 players and 1 ball, some of this must happen off-the-ball.

Finally, when I say “in-play”, I am including the run-up to set pieces. Just because the ball hasn’t been thrown/kicked yet, doesn’t mean we’re not interested in what’s happening on the pitch.

So why does this happen? In 2017, I had a chance encounter with a sports cameraperson (is thatthe right terminology?) that could shed some light on this/be an entirely unrepresentative anecdote (delete as appropriate). They said they were increasingly being asked to shoot sports more like an action film. While I cansee the appeal of this as a technical challenge, as a sports viewer I don’t want to see anaction film. I want to watch the sports. It’s literally what I’m here for. Just show the sports,please.

2. Give us the option of no commentary

For matches with no crowds, BT have offered coverage the option of coverage with/without fakecrown noise on separate channels. I have appreciated having this option and am grateful for BT’sflexibility. I miss the organic crowd noise and for me, the canned stuff is a poor substitutethat I’d rather do without.

With the ever-increasing digitisation of well, literally everything, having limited channels to broadcast on is surely becoming less of an issue. So why not take advantage of that and give us the option of watching without commentary at all?

This wouldn’t have to be available on a TV channel, per-se. As a niche option, this could be offered only as an option on BT’s streaming service (i.e. via the website and through their apps).

3. No more discussion of refereeing decisions

I would love to see broadcasters outlaw discussion of refereeing incidents. Yes, it’s an important part of the game. But all too often it turns the entire half-time and/or post-match discussion into a quagmire of unsubstantiated back and forth. These discussions tend not to be based on any hard evidence, which means that they have no clear end point. and if you’vewatched more than about 10 matches in the last few seasons you’ve probably seen anextremely similar incident (and ensuing discussion) once or twice already. In my view, the result is that talking about refereeing decisions in the studio adds very little to the viewer’s experience or understanding.

The opportunity cost of these debates is high. Particularly after the first half when there’snot a huge amount of time available. Couldn’t we use that time to talk about how the team’s set ups left their defenders more isolated in the box, instead of arguing about whether the defender’s challenge was poorly timed enough to be a penalty?

Recent experiments in this area have not helped matters. The addition of celebrity referees to the broadcast team to have the final word was an extremely reactive decision that to me points to a lack of a clear direction in matchday football coverage. In short, the decision to add referee-pundits attempts to find an answer to any given argument, rather than asking whether the argument is a worthwhile part of football coverage at all.

Tying it all together

I think what brings these points together is that they all address problems that (in my opinion) stem from a lack of vision from the major UK matchday broadcasters at the moment.

This has become especially clear since the mid-pandemic season restart. While this has lead to increased experimentation in sports coverage, much of the experimentation has simply been to try and recreate the 2019 sports experience. With a specific direction and viewer experience in mind,this could be a time for more radical innovation (for UK broadcasters, at least. I’m relatively unaware of what has/n’t been tried elsewhere - but I would love to find out).

So how does such an expensive product end up so bland? I don’t have any personalexperience in sports media, so I could be wrong, but my guess is something like this:

The key decision makers, even if they like and follow football, don’t have enoughexecutive control and/or aren’t opinionated enough to make bold choices. Instead,they lean heavily on market research and the like to understand what people wantfrom their coverage. As a result, they end up with a wide array of perceived needsthat they feel they have to meet. Some people want to have a debate, others want analysis.Others want something bombastic. So what we get is something like death-by-focus-group.

This would also explain why smaller football programmes have no problem fitting into aspecific niche. TalkSport and radio call-in shows might not be for everyone, butthey have a clear vision that they try to execute.

I appreciate that football’s popularity makes it hard to meet everyone’s preferences.However, I believe that by having a clear strategy executed well, broadcasters canalso work to shape demand. For inspiration, look no further than Michael Cox’swork in the early 2010s, or the rapid expansion of analytics contentover the past 3-4 years.

Heck, maybe we don’t even have to choose? As with providing coverage both with and withoutcrowd noise, new forms of media could enable a single broadcaster to target many differenttypes of fan. Sure, that would split the budget, but by increasing focus perhaps you reduce theneed for big name stars to paper over the cracks.

Apart from James Milner, who are the most positionally versatile players in football atm?

Many of the responses to the inital tweet are very good, and it’s interestingto see the slightly different interpretations of “positionally versatile” filteredthrough the lense of player suggestions. If you haven’t already, I suggest you takea look at both the thread and Mark’s newsletter, Get Goalside.

If we take a very simplistic interpretation of “positionally versatile”,the question becomes well-suited to a simple, large-scale search like a databasequery.

Defining the search

To perform a search like this, we need to ~crudely misinterpret~ hammer out aclear-cut definition for the term “positionally versatile”, as used in Mark’sinitial question.

I think it’s reasonable to say that someone who’s versatile can be expected toactually play in a large number of different positions, each requiring multipleskillsets. Therefore, we should be able to find some of the most versatile playersby looking at who has played in the most different positions.

Some positions require rather similar skillsets, and so might not count stronglytowards any measure of versatility. For example, it is relatively common for playersto move between left back and left wing back in different teams or systems.Whereas few players play both as a left back and as a number 10; not everyone canbe Marc Mateu.

To get around this, I have re-categorised the playing positions marked by Statsbombinto the following groups:

• Full back (including wing back roles)
• Centre back
• Central defensive midfielder
• Central midfielder
• Central attacking midfielder
• Wide attacker
• Striker

Now, this grouping smooths over all manner of different roles, particularly incentral midfield. For example, according to this grouping, both Jorginho andRani Khedira play in the same position. However, Jorginho is clearly quite a different player from Khedira. In spite of this, I think it’s probably good enough for a first pass, but this is something to bear in mind in case we want to iterate on this idea at a laterdate.

Another flaw in this method is that we’ll miss out on some players who have the abilityplay in many different positions, but that haven’t actually been deployed there.I think it would be very interesting to approach the problem from this angle. Butin order to do so, I think you’d need a trustworthy model to evaluate each differentskill for each player, along with some mapping of skills to playing roles.Whether that model is just sitting on Wyscout for a few ~days~ months, churningthrough players, or a statistical model, it’s way beyond the time I’mwilling to invest for this one blog post. So you’ll have to bear with me and my simple method for now.

Putting all this together, we can look for the most versatile player, being the onewho has played in the most distinct position groups, with a minimum of 270 minutesin position. 270 minutes is an entirely arbitrary cutoff. It’s the equivalent of about 3 full matches, which felt about right to me, and the results don’t change too much if youincrease or decrease the threshold.

Most versatile players

Using this to count the “versatility” of each player in the top 5 Europeanleagues over the past 3 seasons, we find that the top 3 most versatile playersare Weston McKennie, Julian Brandt, and Leonardo Bittencourt. Each of whom hasplayed at least 270 minutes in 6 different position groups:

I have to say, out of these 3, McKennie feels like the ‘winner’ in spirit.Brandt’s minutes at wing back counting towards FB feels a little bit generous.And both Brandt and Bittencourt benefit from wide attacking roles being countedseparately from central attacking midfield ones, when the required skillset may notactually be all that different, depending on the tactical setup.

Furthermore, McKennie comes very close to meeting our abitrary 270 minutes cutoffin a wide attacking slot (and in fact does, if you include European, cup and international minutes), which would put him into the #1 slot undisputed.

As it happens John Muller got to the same answerjust an hour after the original tweet was posted. So, I suppose we never needed all this analysis, after all!

Honourable mentions go to Saúl Ñíguez, who would draw level with these 3 withEuropean and cup minutes included, but narrowly misses out as it is,and Jonny Howson, who wasn’t initially counted because he plays in the Championship:

Thanks in part to the lower number of games in the dataset, there aren’t any playersfrom the WSL or NWSL who come out at quite the same level of versatility as McKennie et al;however, Giorgia Stanway and Gunnhildur Yrsa Jónsdóttir both come close:

Most versatile… league?

You may have noted already that all of the top 3 most versatile players by themeasure we’ve created play in the Bundesliga. Is this a blip or a trend?

The distribution of our versatility measure across the top 5 leagues combinedlooks like this:

Most outfield players (around 55%) play in only one position group. A reasonableproportion (a bit under 30%) have significant minutes in two position groups, and so on.

Let’s compare the league-specific distributions (gray) to this benchmark (blue):

Sure enough, the Bundesliga comes out as the league in which footballers are mostlikely to be positioned in various different roles. La Liga comes out at the oppositeend of the spectrum, with the rest of the Big 5 somewhere in-between.

Is this because Bundesliga players are genuinely more versatile, due to coaching andrecruitment practices? Or are the tactics of the league such that the range of requiredskills is somehow narrower (not in a disparaging way) than in the other leagues?

I would like to go for the coward’s answer of “a bit of both”, but this isn’t aparticularly informative answer. So, if pushed, I would lean towards the latter. My hunchis that the tactical inclinations of Bundesliga teams, especially when attempting to winthe ball back, allow players with good physical attributes and tactical awareness tofulfil a broader variety of roles without the team’s structure being compromised. In general, this is a nice strategy, as it broadens the pool of players you caneffectively bring into the first team. This hunch could be an interesting route for some further investigation and validation.

If you have any thoughts or questions the ideas presented here, please don’t hesitate toreach out.

How much has home-field advantage (HFA) been affected by theclosed-doors games post-restart?

There have been a few good articles looking at how HFA has been affectedin different competitions since returning without crowds. For example,this article in theEconomistshowing some analysis by 21st Club. Thearticle shows some charts showing the % of total league points won byhome teams before and after the restart. These charts are repeated forshots, fouls and some other metrics, with the conclusion:

[T]he lack of help from referees has merely reduced home sides’advantage, rather than eliminating it… With crowds watching, hometeams gained 58% of points; without them, hosts have still earned 56%.In other words, three-quarters of home overperformance remains intact.

In this post, I want to show how to perform a similar analysis using aDixon-Coles model and the regista R package.

The core of a Dixon-Coles model looks like this:

where

You can read more about it in theseposts.

We can make a simple adjustment to this model to capture the HFA beforeand after the seasons’ interruption: using two separate home advantageparameters. One for pre-interruption, and another for post-interruption.

This requires adjusting the above model to something like

where is the home advantage parameter for pre-interruption games.For post-restart games, this parameter is fixed to 1, and thus has no effect. Theinverse is true for .

Loading the data

First off, we need some data from before and after the COVID-enforcedbreak. I am using data for the 2019/20 season in the Premier League,Serie A, Bundesliga, and La Liga.

In this post, I’m using a modified approach to the standard Dixon-Colesmodel that allows the use of xG as an input to teamstrengths.To do this, we need to load in xG value of each shot in any relevantmatches.

The data used in this post comes from Understat. Since obtaining thisdata is not the core message of this post, I have left the code for thispart out. However, you can find the R code used to scrape the data atthe thislink.

If you have access to a broader dataset, or data from a differentprovider, I encourage you to experiment with re-running the analysis onthat data. The only code chunk you should need to edit is the followingone. The rest of the chunks should be plug and play, provided the columnnames of the shots dataframe remain the same as the ones below.

library(tidyverse)

shots <-
  # EDIT HERE
  # Each row of this CSV refers to a single shot
  read_csv(here::here("data", "understat-shots.csv")) %>%
  # If using your own data source, select and rename your own column names
  # below for the rest of the analysis to run
  transmute(
    match_id,
    league_name,
    match_date = lubridate::as_date(datetime),
    is_home    = h_a == "h" ,
    home_team  = h_team,
    away_team  = a_team,
    home_goals = h_goals,
    away_goals = a_goals,
    xG
  )

# Preview the data
sample_n(shots, 10)

## # A tibble: 10 x 9##    match_id league_name match_date is_home home_team           away_team      home_goals away_goals     xG##       <dbl> <chr>       <date>     <lgl>   <chr>               <chr>               <dbl>      <dbl>  <dbl>##  1    12702 Bundesliga  2020-06-27 TRUE    Borussia M.Gladbach Hertha Berlin           2          1 0.110##  2    13246 Serie A     2019-12-15 FALSE   AC Milan            Sassuolo                0          0 0.0128##  3    13194 Serie A     2019-11-03 TRUE    Lecce               Sassuolo                2          2 0.108##  4    12336 La liga     2020-06-28 FALSE   Espanyol            Real Madrid             0          1 0.469##  5    13252 Serie A     2020-02-05 TRUE    Lazio               Verona                  0          0 0.0684##  6    12705 Bundesliga  2020-06-27 FALSE   Werder Bremen       FC Cologne              6          1 0.422##  7    11818 EPL         2019-12-21 FALSE   Newcastle United    Crystal Palace          1          0 0.0456##  8    11842 EPL         2019-12-28 FALSE   West Ham            Leicester               1          2 0.761##  9    11838 EPL         2019-12-28 FALSE   Newcastle United    Everton                 1          2 0.528## 10    13344 Serie A     2020-02-29 TRUE    Napoli              Torino                  2          1 0.0753

Preparing the data

The next step is to split the shots taken by the home and away team intoseparate groups:

match_xgs <-
  shots %>%
  group_by(match_id, league_name, match_date, home_team, away_team, home_goals, away_goals) %>%
  summarise(home_xgs = list(discard(ifelse(is_home, xG, NA), is.na)),
            away_xgs = list(discard(ifelse(!is_home, xG, NA), is.na))) %>%
  ungroup()

match_xgs

## # A tibble: 1,407 x 9##    match_id league_name match_date home_team         away_team               home_goals away_goals home_xgs   away_xgs##       <dbl> <chr>       <date>     <chr>             <chr>                        <dbl>      <dbl> <list>     <list>##  1    11643 EPL         2019-08-09 Liverpool         Norwich                          4          1 <dbl [15]> <dbl [13]>##  2    11644 EPL         2019-08-10 West Ham          Manchester City                  0          5 <dbl [5]>  <dbl [14]>##  3    11645 EPL         2019-08-10 Bournemouth       Sheffield United                 1          1 <dbl [13]> <dbl [8]>##  4    11646 EPL         2019-08-10 Burnley           Southampton                      3          0 <dbl [10]> <dbl [11]>##  5    11647 EPL         2019-08-10 Crystal Palace    Everton                          0          0 <dbl [6]>  <dbl [10]>##  6    11648 EPL         2019-08-10 Watford           Brighton                         0          3 <dbl [12]> <dbl [5]>##  7    11649 EPL         2019-08-10 Tottenham         Aston Villa                      3          1 <dbl [31]> <dbl [7]>##  8    11650 EPL         2019-08-11 Newcastle United  Arsenal                          0          1 <dbl [9]>  <dbl [8]>##  9    11651 EPL         2019-08-11 Leicester         Wolverhampton Wanderers          0          0 <dbl [16]> <dbl [8]>## 10    11652 EPL         2019-08-11 Manchester United Chelsea                          4          0 <dbl [11]> <dbl [18]>## # … with 1,397 more rows

From here, we can generate the features for an “xG-Dixon-Coles” model.This involves “re-simulating” each match based on the shots taken withinit, to get a set of weighted scorelines. For more on this method, seethispost.

We also generate two new variables corresponding to the two homeadvantage parameters: pre_restart and post_restart.

simulate_shots <- function(xgs) {
  tibble::tibble(goal = 0:length(xgs),
                 prob = poisbinom::dpoisbinom(0:length(xgs), xgs))
}

simulate_game <- function(home_xgs, away_xgs) {
  home_probs <- simulate_shots(home_xgs) %>% dplyr::rename_all(function(x) paste0("h", x))
  away_probs <- simulate_shots(away_xgs) %>% dplyr::rename_all(function(x) paste0("a", x))

  tidyr::crossing(home_probs, away_probs) %>%
    dplyr::mutate(prob = .data$hprob * .data$aprob)
}


simulated_games <-
  match_xgs %>%
  mutate(simulated_probabilities = map2(home_xgs, away_xgs, simulate_game),
         pre_restart  = match_date < "2020-05-01",
         post_restart = !pre_restart) %>%
  unnest(cols = c(simulated_probabilities)) %>%
  filter(prob > 0.01)

simulated_games

## # A tibble: 20,694 x 16##    match_id league_name match_date home_team away_team home_goals away_goals home_xgs away_xgs hgoal  hprob agoal  aprob##       <dbl> <chr>       <date>     <chr>     <chr>          <dbl>      <dbl> <list>   <list>   <int>  <dbl> <int>  <dbl>##  1    11643 EPL         2019-08-09 Liverpool Norwich            4          1 <dbl [1… <dbl [1…     0 0.0556     0 0.398##  2    11643 EPL         2019-08-09 Liverpool Norwich            4          1 <dbl [1… <dbl [1…     0 0.0556     1 0.405##  3    11643 EPL         2019-08-09 Liverpool Norwich            4          1 <dbl [1… <dbl [1…     1 0.230      0 0.398##  4    11643 EPL         2019-08-09 Liverpool Norwich            4          1 <dbl [1… <dbl [1…     1 0.230      1 0.405##  5    11643 EPL         2019-08-09 Liverpool Norwich            4          1 <dbl [1… <dbl [1…     1 0.230      2 0.158##  6    11643 EPL         2019-08-09 Liverpool Norwich            4          1 <dbl [1… <dbl [1…     2 0.328      0 0.398##  7    11643 EPL         2019-08-09 Liverpool Norwich            4          1 <dbl [1… <dbl [1…     2 0.328      1 0.405##  8    11643 EPL         2019-08-09 Liverpool Norwich            4          1 <dbl [1… <dbl [1…     2 0.328      2 0.158##  9    11643 EPL         2019-08-09 Liverpool Norwich            4          1 <dbl [1… <dbl [1…     2 0.328      3 0.0337## 10    11643 EPL         2019-08-09 Liverpool Norwich            4          1 <dbl [1… <dbl [1…     3 0.241      0 0.398## # … with 20,684 more rows, and 3 more variables: prob <dbl>, pre_restart <lgl>, post_restart <lgl>

Estimating the home advantage

For each league, we are going to fit the aforementioned model with twoseparate home advantage parameters.

Because we are extending the core Dixon-Coles model, we must use themore flexible dixoncoles_ext function. This function allows us to specifycustom formulas for the home (f1) and away (f2) goals estimates withextra parameters, such as our pre_/post_restart HFA parameters.

library(regista)

fit_model <- partial(
  dixoncoles_ext,
  f1 = hgoal ~ off(home_team) + def(away_team) + pre_restart + post_restart + 0,
  f2 = agoal ~ off(away_team) + def(home_team) + 0,
  weights = prob
)


models <-
  simulated_games %>%
  group_by(league_name) %>%
  nest() %>%
  mutate(model = map(data, fit_model)) %>%
  ungroup()

models

## # A tibble: 4 x 3##   league_name data                  model##   <chr>       <list>                <list>## 1 EPL         <tibble [5,456 × 15]> <dixoncls>## 2 La liga     <tibble [5,110 × 15]> <dixoncls>## 3 Bundesliga  <tibble [4,804 × 15]> <dixoncls>## 4 Serie A     <tibble [5,324 × 15]> <dixoncls>

We can extract the parameter estimates from the models withbroom::tidy. While the model will estimate attack and defencestrengths for each team too, we specifically care about the estimatesfor pre_restart and post_restart.

So, let’s take these and compare the before and after estimates:

model_parameters <-
  models %>%
  mutate(params = map(model, broom::tidy)) %>%
  select(league_name, params) %>%
  unnest(params)

hfa_comparison <-
  model_parameters %>%
  mutate(value = exp(value)) %>%  # Get the value out of log space...
  filter(str_detect(parameter, "(pre|post)_restart")) %>%
  pivot_wider(id_cols = league_name, names_from = parameter, values_from = value)


hfa_comparison %>%
  ggplot(aes(x = pre_restart - 1, y = post_restart - 1)) +

  map(seq(0, 1, by = 0.25), function(slope) {
    list(
      geom_segment(x = 0, y = 0, xend = 1.5, yend = slope*1.5, linetype = "dashed", colour = "lightgray"),
      annotate(geom = "label", x = 0.45, y = slope*0.45,
               label = str_glue("{scales::percent(1 - slope, 1)} reduction"),
               colour = "lightgray", label.size = 0)
    )
  }) +

  ggrepel::geom_text_repel(aes(label = league_name)) +
  geom_point(aes(colour = (post_restart / pre_restart) < 0.97)) +
  scale_x_continuous(limits = c(0, 0.5), labels = scales::percent_format(accuracy = 1)) +
  scale_y_continuous(limits = c(0, 0.5), labels = scales::percent_format(accuracy = 1)) +
  scale_colour_manual(values = c("gray", "red"), guide = FALSE) +
  theme_minimal() +
  theme(panel.grid.major = element_line(linetype = "dotted"),
        panel.grid.minor = element_line(linetype = "dotted")) +
  labs(title = "How much was HFA reduced in closed-door games?",
       subtitle = "HFA measured by % increase in goalscoring at home",
       x = "HFA before the restart",
       y = "HFA after the restart")

It may seem like a trivial task, but it’s also a fundamental task whichunderpins both basic and sophisticated analytics. Mistakes in minutes played calculations can be particularly perniciousbecause:

• They aren’t always obvious
• They propagate to downstream calculations (e.g. p90 stats)
• They can be difficult to identify automatically and debug

With this in mind, when I recently has a chance to revisit some minutes played calculations, I wanted to take the time to find The Right Way to do it.I am happy with the solution I have found; although I would love to hear feedbackfrom other sports analytics practitioners to see how this method might be improved.

The method

Let’s say we want to calculate minutes played for each player, with subtotals fortime played in each position. The basic outline of the proposed method goessomething like this:

First, arrange the events from a given match in sequence order:

I have shown diagrams in both a “schematic” and “tabular” view. These areequivalent views on the same idea. In the schematic diagram I am trying to conveythe basic concept. In the tabular form, I am trying to show something alittle closer to how you might do such a transformation in a relational database,or with pandas, dplyr, or such like.

Next, identify any events that result in a change to one of the relevant match conditions.For example, a change in formation, or a goal.

…And filter out any irrelevant events

Then, construct time-windows, using the successive events as start and end points

In practice this will probably require you to infer some information from precedingor following rows. For example, you may have to infer that a player started thesecond half from the fact that they started the match and were not substitutedor sent off.

Finally, aggregate the time within each window (grouped by player and match condition).Window #5 is ignored (duration is NULL) because it takes place after the player was substituted.

This method can be extended to calculate minutes played according to anymatch condition you might be interested in. For example, each player’s minutesplayed in a certain position, or minutes played while the team is losing.

What’s so good about this method?

You may still think that minutes played is a trivial calculation; just find the differencebetween the time a player came off the pitch, and the time a player came onto the pitch.And yes, this is basically true. However, going through the hassle of calculatingtime windows like this has a few significant benefits:

• We can slice minutes played to any grain that we want
• The intermediate time windows are useful - they allow you to get all the eventsfrom those windows, too
• It works with any event-data provider and isn’t beholden to the quirks of any oneparticular data collection process

An additional nice feature of this method, is that if you feel comfortable withwindow functions, it can be expressed relatively cleanly in pure SQL(if that’s your thing).

Let’s explore these in a little more detail.

Slicing to any grain

Counting minutes played is good because it allows you to rate-adjust your countingstats. Going from goals per game to goals per 90 is a nice improvement. However,inevitably, you will want to go further.

For example, we know that teams set up differently when they are winning or losing,compared to when the scorelines are level. So perhaps you want to adjust for this.Well, to do any adjustments, you need to know how much time was spent at winning,drawing, or losing.

The “find the difference” approach struggles to do this elegantly, and is difficultto extend to multiple such conditions. For example, time played in a given positionand while winning.

The windowed approach, on the other hand, can extend to any level of detail justby adding a new condition to divide windows by.

Using the windows

Another nice properties of this approach is that the windows created are a usefulasset in their own right.

We already have a way to find the minutes played in a given position. However,what if you wanted to get the individual actions the player made in said position.Or calculate the actions per 90.

Handily, you can use the intermediate windows to fetch the events within them, too.

Easy to translate across data providers

Even if we just wanted to use the simple difference method, there are a few thingswe need to pay close attention to:

• Injury time
• Extra time
• Red cards and dismissals
• Substitutions and injuries
• Players leaving the field temporarily for physio treatment (if this is recorded at all)

These are are pretty standard concerns, but there are differences between themajor providers in how they are represented as part of the event stream. Any methodclaiming to be the right one for calculating minutes played cannot betightly coupled to any one provider’s specification.

For this reason, I have talked about this method in rather general, conceptual terms.The key part of applying this method to your specific dataset comes in step 1 and 2(collating and ordering the events; tagging specific events) when reshaping thedata; the operations applied remain the same.

Because the reshaping keeps the data in an event-first structure, itis (in my opinion) both less onerous and more similar across providers than thereshaping required for the simple difference method.

Are there any downsides?

I think any downsides are far outweighed by the benefits of using this method; however, thereare a couple of sticking points that you will need to navigate when implementingsomething like this:

• Inferring missing info (e.g. position) when tracking multiple matchconditions. For example, when grouping by player position and scoreline, you willneed to infer the players’ positions for events which change the scoreline, since thisisn’t part of the base event data. In Postgres, window functions likefirst_value to handle this very well, but it is something to be aware of nonetheless.
• Multiple potential start and end-points within the match for each player.In our worked example we had to ignore window #5 because it took place after theplayer was substituted off. Likewise, if a player leaves the match for whateverreason in the first half, we shouldn’t infer their presence in the second half.Again, window function can handle these permanent entrance/exits well.

That’s all, folks

If you can see any improvements to this, or if you have any better ways of gettingthe same result, I’d love to hear it. You can let me know on twitteror by email ([at]protonmail.com)

The method will be largely the same as the previous post, so I’m goingto keep comments on the code relatively light. If anything remainsunclear, I’d suggest running through the code yourself (it should bereproducible on your computer - let meknow if it’s not), or referring to theprevious post.

Fetch the data

I’ll be using from understat (pasted onto GitHub), which you can access via the shortlink below:

library(tidyverse)
library(regista)

data <-
  read_csv("https://git.io/fhsnd") %>%
  nest(side, xg, .key = "shots") %>%
  factor_teams(c("home", "away")) %>%
  rename(hgoal = hgoals,
         agoal = agoals)  # Use names consistent with the previous post...

data

## # A tibble: 210 x 9##    match_id date                home  away  hgoal agoal league season shots##       <dbl> <dttm>              <fct> <fct> <dbl> <dbl> <chr>   <dbl> <lis>##  1     9197 2018-08-10 22:00:00 Manc… Leic…     2     1 EPL      2018 <tib…##  2     9198 2018-08-11 14:30:00 Newc… Tott…     1     2 EPL      2018 <tib…##  3     9199 2018-08-11 17:00:00 Watf… Brig…     2     0 EPL      2018 <tib…##  4     9200 2018-08-11 17:00:00 Hudd… Chel…     0     3 EPL      2018 <tib…##  5     9201 2018-08-11 17:00:00 Fulh… Crys…     0     2 EPL      2018 <tib…##  6     9202 2018-08-11 17:00:00 Bour… Card…     2     0 EPL      2018 <tib…##  7     9203 2018-08-11 19:30:00 Wolv… Ever…     2     2 EPL      2018 <tib…##  8     9204 2018-08-12 15:30:00 Sout… Burn…     0     0 EPL      2018 <tib…##  9     9205 2018-08-12 15:30:00 Live… West…     4     0 EPL      2018 <tib…## 10     9206 2018-08-12 18:00:00 Arse… Manc…     0     2 EPL      2018 <tib…## # ... with 200 more rows

Again, this next code block is copied verbatim from another post, DixonColes and xG: together atlast,and generates simulated scoreline probabilities from individual shotxGs.

add_if_missing <- function(data, col, fill = 0.0) {
  # Add column if not found in a dataframe
  # We need this in cases where a team has 0 shots (!)
  if (!(col %in% colnames(data))) {
    data[, col] <- fill
  }
  data
}

team_goal_probs <- function(xgs, side) {
  # Find P(Goals=G) from a set of xGs by the poisson-binomial distribution
  # Use tidyeval to prefix column names with the team's side ("h"ome or "a"way)
  tibble(!!str_c(side, "goal") := 0:length(xgs),
         !!str_c(side, "prob")  := poisbinom::dpoisbinom(0:length(xgs), xgs))
}

simulate_game <- function(shot_xgs) {
  shot_xgs %>%
    split(.$side) %>%
    imap(~ team_goal_probs(.x$xg, .y)) %>%
    reduce(crossing) %>%
    # If there are no shots, give that team a 1.0 chance of scoring 0 goals
    add_if_missing("hgoal", 0) %>%
    add_if_missing("hprob", 1) %>%
    add_if_missing("agoal", 0) %>%
    add_if_missing("aprob", 1) %>%
    mutate(prob = hprob * aprob) %>%
    select(hgoal, agoal, prob)
}

simulated_games <-
  data %>%
  mutate(simulated_probabilities = map(shots, simulate_game)) %>%
  select(match_id, home, away, simulated_probabilities) %>%
  unnest() %>%
  filter(prob > 0.001)  # Keep the number of rows vaguely reasonable

simulated_games

## # A tibble: 5,030 x 6##    match_id home              away      hgoal agoal    prob##       <dbl> <fct>             <fct>     <int> <int>   <dbl>##  1     9197 Manchester United Leicester     0     0 0.00222##  2     9197 Manchester United Leicester     1     0 0.00946##  3     9197 Manchester United Leicester     2     0 0.00832##  4     9197 Manchester United Leicester     3     0 0.00227##  5     9197 Manchester United Leicester     0     1 0.0414##  6     9197 Manchester United Leicester     1     1 0.177##  7     9197 Manchester United Leicester     2     1 0.155##  8     9197 Manchester United Leicester     3     1 0.0424##  9     9197 Manchester United Leicester     4     1 0.00539## 10     9197 Manchester United Leicester     0     2 0.0378## # ... with 5,020 more rows

Predict the unplayed games

Work out the unplayed games

teams <- factor(levels(data$home), levels = levels(data$home))

unplayed_games <-
  crossing(home = teams,
           away = teams) %>%
  filter(home != away) %>%
  anti_join(data, by = c("home", "away"))

unplayed_games

## # A tibble: 170 x 2##    home              away##    <fct>             <fct>##  1 Manchester United Watford##  2 Manchester United Southampton##  3 Manchester United Liverpool##  4 Manchester United Cardiff##  5 Manchester United West Ham##  6 Manchester United Chelsea##  7 Manchester United Manchester City##  8 Manchester United Burnley##  9 Manchester United Brighton## 10 Newcastle United  Huddersfield## # ... with 160 more rows

Make predictions for those unplayed games

models <- list(
  obs_goals = dixoncoles(hgoal, agoal, home, away, data = data),
  exp_goals = dixoncoles(hgoal, agoal, home, away, weights = prob, data = simulated_games)
)

models

## $obs_goals#### Dixon-Coles model with specification:#### Home goals: hgoal ~ off(home) + def(away) + hfa + 0## Away goals: agoal ~ off(away) + def(home) + 0## Weights   : 1###### $exp_goals#### Dixon-Coles model with specification:#### Home goals: hgoal ~ off(home) + def(away) + hfa + 0## Away goals: agoal ~ off(away) + def(home) + 0## Weights   : prob

Compare the team attack and defence parameters:

get_team_params <- function(model) {
  broom::tidy(model) %>%
    filter(parameter %in% c("off", "def")) %>%
    mutate(value = exp(value))
}

bind_rows(
  get_team_params(models$obs_goals) %>% mutate(type = "obs"),
  get_team_params(models$exp_goals) %>% mutate(type = "exp")
) %>%
  spread(type, value) %>%
  ggplot(aes(x = exp, y = obs)) +
  geom_point(alpha = 0.5) +
  ggrepel::geom_text_repel(aes(label = team)) +
  geom_abline(slope = 1, intercept = 0, linetype = "dotted") +
  theme_minimal() +
  labs(title = "Team strength estimates",
       x = "Expected Goals",
       y = "Observed Goals") +
  facet_wrap(~ parameter)

The big changes seem to be Arsenal’s attack, and Lverpool’s defence bothlooking a lot worse by xG.

unplayed_scorelines <- imap_dfr(models, function(model, name) {
  broom::augment(model, unplayed_games, type.predict = "scorelines") %>%
    unnest() %>%
    mutate(model = name)
})

unplayed_scorelines

## # A tibble: 37,662 x 6##    home              away    hgoal agoal     prob model##    <fct>             <fct>   <int> <int>    <dbl> <chr>##  1 Manchester United Watford     0     0 0.0304   obs_goals##  2 Manchester United Watford     1     0 0.0435   obs_goals##  3 Manchester United Watford     2     0 0.0602   obs_goals##  4 Manchester United Watford     3     0 0.0468   obs_goals##  5 Manchester United Watford     4     0 0.0272   obs_goals##  6 Manchester United Watford     5     0 0.0127   obs_goals##  7 Manchester United Watford     6     0 0.00492  obs_goals##  8 Manchester United Watford     7     0 0.00164  obs_goals##  9 Manchester United Watford     8     0 0.000477 obs_goals## 10 Manchester United Watford     9     0 0.000123 obs_goals## # ... with 37,652 more rows

Simulate the rest of the season

played_scorelines <-
  data %>%
  select(home, away, hgoal, agoal) %>%
  mutate(prob = 1.0) %>%
  crossing(model = unique(unplayed_scorelines$model))

scorelines <- bind_rows(
  played_scorelines,
  unplayed_scorelines
)

simulate_games <- function(scoreline_probabilities) {
  scoreline_probabilities %>%
    nest(hgoal, agoal, prob, .key = "scorelines") %>%
    mutate(sampled = map(scorelines, ~ sample_n(., 1, weight = prob))) %>%
    select(-scorelines) %>%
    unnest()
}

# Show 1 simulation as an example
single_simulation <- simulate_games(scorelines)
sample_n(single_simulation, 5)

## # A tibble: 5 x 6##   home         away              model     hgoal agoal    prob##   <fct>        <fct>             <chr>     <dbl> <dbl>   <dbl>## 1 Southampton  Everton           obs_goals     1     0 0.0555## 2 Leicester    Burnley           obs_goals     0     0 1## 3 Huddersfield Manchester City   exp_goals     1     3 0.0605## 4 Watford      Tottenham         exp_goals     2     1 1## 5 Arsenal      Manchester United obs_goals     1     5 0.00711

Calculating the league table

calculate_table <- function(games) {
  games_augmented <-
    games %>%
    mutate(
      hpoints = case_when(
        hgoal > agoal  ~ 3,
        hgoal == agoal ~ 1,
        agoal > hgoal  ~ 0
      ),
      apoints = case_when(
        hgoal > agoal  ~ 0,
        hgoal == agoal ~ 1,
        agoal > hgoal  ~ 3
      )
    )

  games_home <-
    games_augmented %>%
    select(
      team   = home,
      gf     = hgoal,
      ga     = agoal,
      points = hpoints
    )

  games_away <-
    games_augmented %>%
    select(
      team   = away,
      gf     = agoal,
      ga     = hgoal,
      points = apoints
    )

  bind_rows(games_home, games_away) %>%
    group_by(team) %>%
    summarise(w  = sum(gf > ga),
              d  = sum(gf == ga),
              l  = sum(gf < ga),
              gf = sum(gf),
              ga = sum(ga),
              gd = gf - ga,
              points = sum(points)) %>%
    arrange(desc(points), desc(gd), desc(gf)) %>%
    mutate(position = row_number())
}

Running the simulations

n_simulations <- 1000

simulated_tables <-
  rerun(n_simulations, simulate_games(scorelines)) %>%
  # We need to nest the data so that we can calculate tables for
  # xG and G separately
  map(~ nest(., -model, .key = "scoreline")) %>%
  bind_rows(.id = "simulation_id") %>%
  mutate(table = map(scoreline, calculate_table)) %>%
  unnest(table, .drop = TRUE)

simulated_tables

## # A tibble: 40,000 x 11##    simulation_id model team      w     d     l    gf    ga    gd points##    <chr>         <chr> <fct> <int> <int> <int> <dbl> <dbl> <dbl>  <dbl>##  1 1             exp_… Live…    29     7     2    79    24    55     94##  2 1             exp_… Manc…    29     5     4   100    31    69     92##  3 1             exp_… Tott…    25     4     9    78    41    37     79##  4 1             exp_… Chel…    20    10     8    60    32    28     70##  5 1             exp_… Arse…    20     7    11    73    54    19     67##  6 1             exp_… Manc…    19    10     9    79    62    17     67##  7 1             exp_… Ever…    17     8    13    60    51     9     59##  8 1             exp_… Wolv…    16    10    12    41    37     4     58##  9 1             exp_… Watf…    12    12    14    53    59    -6     48## 10 1             exp_… Bour…    14     6    18    53    69   -16     48## # ... with 39,990 more rows, and 1 more variable: position <int>

Results

Position probabilities

n_teams <- length(teams)

simulated_tables %>%
  count(model, team, position) %>%
  mutate(p = n / n_simulations) %>%
  select(model, team, position, p) %>%
  spread(model, p) %>%
  arrange(desc(abs(exp_goals - obs_goals))) %>%
  ggplot(aes(x = position)) +
  geom_segment(aes(xend = position, y = obs_goals, yend = exp_goals), colour = "dimgray") +
  geom_point(aes(y = exp_goals)) +
  facet_wrap(~ reorder(team, position)) +
  scale_x_continuous(breaks = 1:n_teams) +
  scale_y_continuous(labels = scales::percent_format(),
                     limits = c(0, 1)) +
  labs(title = "Position probabilities",
       subtitle = "xG vs Goals",
       x = NULL,
       y = NULL) +
  theme_minimal() +
  theme(title       = element_text(size = 30),
        strip.text  = element_text(size = 25),
        axis.text.y = element_text(size = 15),
        axis.text.x = element_text(size = 10),
        panel.grid.major.y = element_line(linetype = "dotted"),
        panel.grid.major.x = element_blank(),
        panel.grid.minor   = element_blank())

## Warning: Removed 29 rows containing missing values (geom_segment).## Warning: Removed 1 rows containing missing values (geom_point).

Liverpool’s chances of winning the league, look much more realistic(lower, sorry Liverpool fans) when we use xG, rather than just goals:

simulated_tables %>%
  group_by(model, team) %>%
  summarise(p = mean(position == 1)) %>%
  filter(p > 0.01) %>%
  spread(model, p) %>%
  arrange(desc(exp_goals))

## # A tibble: 2 x 3##   team            exp_goals obs_goals##   <fct>               <dbl>     <dbl>## 1 Liverpool           0.65      0.829## 2 Manchester City     0.346     0.166

There are fewer big changes in the relegation probablities, but Cardiffand Southampton are probably the biggest winners, while things look moreprecarious for Burnley and Newcastle:

simulated_tables %>%
  group_by(model, team) %>%
  summarise(p = mean(position >= 18)) %>%
  filter(p > 0.01) %>%
  spread(model, p) %>%
  arrange(desc(exp_goals))

## # A tibble: 6 x 3##   team             exp_goals obs_goals##   <fct>                <dbl>     <dbl>## 1 Huddersfield         0.993     0.994## 2 Fulham               0.829     0.882## 3 Burnley              0.505     0.469## 4 Newcastle United     0.386     0.164## 5 Cardiff              0.216     0.308## 6 Southampton          0.06      0.177

We can look at the race for the Champion’s League, too:

simulated_tables %>%
  group_by(model, team) %>%
  summarise(p = mean(position <= 4)) %>%
  filter(p > 0.01) %>%
  spread(model, p) %>%
  arrange(desc(exp_goals))

## # A tibble: 6 x 3##   team              exp_goals obs_goals##   <fct>                 <dbl>     <dbl>## 1 Liverpool             1         1## 2 Manchester City       1         1## 3 Tottenham             0.893     0.953## 4 Chelsea               0.882     0.776## 5 Arsenal               0.164     0.239## 6 Manchester United     0.06      0.032

Points totals

We can see how the distribution of points totals changes. The whitedistribution represents the estimates based on goals, while the grey onerefers to those based on xG.

ggplot(data = simulated_tables, aes(x = points, y = reorder(team, points))) +
  ggridges::geom_density_ridges(data = simulated_tables %>% filter(model == "obs_goals"),
                                bandwidth = 1.0,
                                rel_min_height = 0.01,
                                scale = 0.75,
                                fill = "white") +
  ggridges::geom_density_ridges(data = simulated_tables %>% filter(model == "exp_goals"),
                                bandwidth = 1.0,
                                rel_min_height = 0.01,
                                scale = 0.75,
                                alpha = 0.5) +
  labs(title = "Predicted points total distribution",
       subtitle = "Grey = xG, White = Goals",
       x = NULL,
       y = NULL) +
  theme_minimal()

The xG-based model is less keen on Liverpool’s chances of meeting 100points. The goal-based model’s dropped its probability by about 10%points since before the Man Citygame

simulated_tables %>%
  group_by(model, team) %>%
  summarise(p = mean(points >= 100)) %>%
  filter(p > 0.01) %>%
  spread(model, p) %>%
  arrange(desc(exp_goals))

## # A tibble: 1 x 3##   team      exp_goals obs_goals##   <fct>         <dbl>     <dbl>## 1 Liverpool     0.077      0.31

In practice, this just means:

• Predicting the unplayed games,
• Sampling from those individual game predictions over and over again(“simulating” the rest of the season)
• Aggregate simulated games to get outcome probabilities

If the Dixon-Coles model is new to you, there are some previousexplorations of the model on thissite, and the originalpaper isvery approachable.

Fetch the data

I’ll be using the data provided byfootball-data.co.uk.

To do this I have created a (very) minimal R package for downloading thedata from the site, calledfootballdatr.

You can install it from github like so:

devtools::install_github("torvaney/footballdatr")

It’s still very early, and so probably (definitely) has some bugs. Ifyou do find anything, please don’t hesitate to let me know ontwitter or onGitHub.

Nonetheless, we can use this to get the data for the 2018/19 EnglishPremier League season.

library(tidyverse)
library(regista)

data <-
  footballdatr::fetch_data("england", division = 0, season = 2018) %>%
  factor_teams(c("home", "away"))

data

## # A tibble: 200 x 23##    competition date       home  away  hgoal agoal result hgoal_ht agoal_ht##    <chr>       <date>     <fct> <fct> <int> <int> <chr>     <int>    <int>##  1 E0          2018-08-10 Man … Leic…     2     1 H             1        0##  2 E0          2018-08-11 Bour… Card…     2     0 H             1        0##  3 E0          2018-08-11 Fulh… Crys…     0     2 A             0        1##  4 E0          2018-08-11 Hudd… Chel…     0     3 A             0        2##  5 E0          2018-08-11 Newc… Tott…     1     2 A             1        2##  6 E0          2018-08-11 Watf… Brig…     2     0 H             1        0##  7 E0          2018-08-11 Wolv… Ever…     2     2 D             1        1##  8 E0          2018-08-12 Arse… Man …     0     2 A             0        1##  9 E0          2018-08-12 Live… West…     4     0 H             2        0## 10 E0          2018-08-12 Sout… Burn…     0     0 D             0        0## # ... with 190 more rows, and 14 more variables: result_ht <chr>,## #   hshot <int>, ashot <int>, hshot_on_target <int>,## #   ashot_on_target <int>, hfoul <int>, afoul <int>, hcorner <int>,## #   acorner <int>, hyellow <int>, ayellow <int>, hred <int>, ared <int>,## #   closing_odds <list>

Predict the unplayed games

Work out the unplayed games

Fortunately, the Premier League’s schedule is relativelystraightforward. Each team plays every other team at home and away.There are no playoffs, league splits or whatever they do inBelgium.

This means that we can find the unplayed games pretty easily. We canjust take all combinations of teams, and filter out ones that have beenplayed, or that feature a team playing itself.

teams <- factor(levels(data$home), levels = levels(data$home))

unplayed_games <-
  crossing(home = teams,
           away = teams) %>%
  filter(home != away) %>%
  anti_join(data, by = c("home", "away"))

unplayed_games

## # A tibble: 180 x 2##    home        away##    <fct>       <fct>##  1 Man United  Watford##  2 Man United  Liverpool##  3 Man United  Southampton##  4 Man United  Cardiff##  5 Man United  Chelsea##  6 Man United  West Ham##  7 Man United  Brighton##  8 Man United  Burnley##  9 Man United  Man City## 10 Bournemouth Fulham## # ... with 170 more rows

Make predictions for those unplayed games

First, we have to fit a model that we can use to estimate how good eachteam is, and the effect of home advantage.

We can do this with regista’s implementation of the Dixon-Coles model.For the purposes of this post, we will just fit the model on the gamesplayed so far this season. However, a more comprehensive model mayinclude matches from previous seasons, time-discounting, or evenexpectedgoals.

model <- dixoncoles(hgoal, agoal, home, away, data = data)

model

#### Dixon-Coles model with specification:#### Home goals: hgoal ~ off(home) + def(away) + hfa + 0## Away goals: agoal ~ off(away) + def(home) + 0## Weights   : 1

We can sense-check the model by looking at the team attack and defenceparameters:

team_parameters <-
  broom::tidy(model) %>%
  filter(parameter %in% c("off", "def")) %>%
  mutate(value = exp(value)) %>%
  spread(parameter, value)

team_parameters %>%
  ggplot(aes(x = def, y = off)) +
  geom_point(alpha = 0.5) +
  ggrepel::geom_text_repel(aes(label = team)) +
  theme_minimal() +
  labs(title = "Team strength estimates",
       y = "Attack",
       x = "Defence")

It’s tempting to just calculate the match outcome (Home win/Draw/Awaywin) probabilities and go from there. It’s pretty easy to do withregista as well:

match_probabilities <-
  broom::augment(model, unplayed_games, type.predict = "outcomes") %>%
  unnest() %>%
  spread(outcome, prob)

match_probabilities

## # A tibble: 180 x 5##    home        away        away_win  draw home_win##    <fct>       <fct>          <dbl> <dbl>    <dbl>##  1 Man United  Watford       0.232  0.220   0.549##  2 Man United  Liverpool     0.770  0.165   0.0659##  3 Man United  Southampton   0.124  0.166   0.710##  4 Man United  Cardiff       0.0976 0.153   0.749##  5 Man United  Chelsea       0.522  0.239   0.240##  6 Man United  West Ham      0.208  0.209   0.582##  7 Man United  Brighton      0.201  0.236   0.562##  8 Man United  Burnley       0.0843 0.136   0.780##  9 Man United  Man City      0.676  0.177   0.147## 10 Bournemouth Fulham        0.152  0.206   0.642## # ... with 170 more rows

This is enough to simulate match outcomes, and points scored. However,in cases where point totals at the end of the season are equal, we needgoal-difference too.

Fortunately, this is something the Dixon-Coles model can handle. We canpredict the probability of each scoreline for the unplayed games.

unplayed_scorelines <-
  broom::augment(model, unplayed_games, type.predict = "scorelines") %>%
  unnest()

unplayed_scorelines

## # A tibble: 19,563 x 5##    home       away    hgoal agoal     prob##    <fct>      <fct>   <int> <int>    <dbl>##  1 Man United Watford     0     0 0.0348##  2 Man United Watford     1     0 0.0468##  3 Man United Watford     2     0 0.0634##  4 Man United Watford     3     0 0.0475##  5 Man United Watford     4     0 0.0267##  6 Man United Watford     5     0 0.0120##  7 Man United Watford     6     0 0.00448##  8 Man United Watford     7     0 0.00144##  9 Man United Watford     8     0 0.000404## 10 Man United Watford     9     0 0.000101## # ... with 19,553 more rows

Simulate the rest of the season

Join played game and unplayed games

There’s an added benefit to looking at the unplayed games like asscoreline-probabilities. We can look at the played games in exactlythe same way. Any game that has already been played is simply a gamewhere there is a single scoreline with 100% probability. This simplifiesour simulation step, since we can treat both played and unplayed gamesthe same.

played_scorelines <-
  data %>%
  select(home, away, hgoal, agoal) %>%
  mutate(prob = 1.0)

scorelines <- bind_rows(
  played_scorelines,
  unplayed_scorelines
)

scorelines

## # A tibble: 19,763 x 5##    home         away           hgoal agoal  prob##    <fct>        <fct>          <int> <int> <dbl>##  1 Man United   Leicester          2     1     1##  2 Bournemouth  Cardiff            2     0     1##  3 Fulham       Crystal Palace     0     2     1##  4 Huddersfield Chelsea            0     3     1##  5 Newcastle    Tottenham          1     2     1##  6 Watford      Brighton           2     0     1##  7 Wolves       Everton            2     2     1##  8 Arsenal      Man City           0     2     1##  9 Liverpool    West Ham           4     0     1## 10 Southampton  Burnley            0     0     1## # ... with 19,753 more rows

Simulate games by Monte Carlo

We can simulate the result of each game by picking a potential scorelineat random, where each pick is weighted by the estimated probability.

This gives us a single instance of a simulated season. We can repeatthis over and over again to estimate the overall season probabilities.This is the Monte Carlomethod of simulation.

simulate_season <- function(scoreline_probabilities) {
  scoreline_probabilities %>%
    nest(hgoal, agoal, prob, .key = "scorelines") %>%
    mutate(sampled = map(scorelines, ~ sample_n(., 1, weight = prob))) %>%
    select(-scorelines) %>%
    unnest()
}

# Show 1 simulation as an example
single_simulation <- simulate_season(scorelines)
sample_n(single_simulation, 5)

## # A tibble: 5 x 5##   home        away      hgoal agoal   prob##   <fct>       <fct>     <int> <int>  <dbl>## 1 Bournemouth Liverpool     0     4 1## 2 West Ham    Arsenal       2     1 0.0610## 3 Newcastle   Everton       0     2 0.0987## 4 Liverpool   Watford       4     0 0.0959## 5 Wolves      Liverpool     0     2 1

There are a few flawed assumptions being made in this simulation. Ithink it’s worth acknowledging a couple of them quickly:

• There’s no accounting for the possibility team-strengths changing
  • From transfers
  • From injuries
  • Coaching changes
  • etc
• There’s no accounting for motivation effects towards the end of theseason
  • Teams with nothing to play for are less likely to perform aswell as others

These kinds of sources of model error should be considered whenevaluating the model’s predictions, and when thinking about how youmight improve the simulation method.

Calculating the league table

We care much more about overall table outcomes (Champion, Relegation,Top 4) than we do about individual results. So we need a way tocalculate the table from a set of games:

calculate_table <- function(games) {
  games_augmented <-
    games %>%
    mutate(
      hpoints = case_when(
        hgoal > agoal  ~ 3,
        hgoal == agoal ~ 1,
        agoal > hgoal  ~ 0
      ),
      apoints = case_when(
        hgoal > agoal  ~ 0,
        hgoal == agoal ~ 1,
        agoal > hgoal  ~ 3
      )
    )

  games_home <-
    games_augmented %>%
    select(
      team   = home,
      gf     = hgoal,
      ga     = agoal,
      points = hpoints
    )

  games_away <-
    games_augmented %>%
    select(
      team   = away,
      gf     = agoal,
      ga     = hgoal,
      points = apoints
    )

  bind_rows(games_home, games_away) %>%
    group_by(team) %>%
    summarise(w  = sum(gf > ga),
              d  = sum(gf == ga),
              l  = sum(gf < ga),
              gf = sum(gf),
              ga = sum(ga),
              gd = gf - ga,
              points = sum(points)) %>%
    arrange(desc(points), desc(gd), desc(gf)) %>%
    mutate(position = row_number())
}

We can check that this works as expected by checking the current table:

calculate_table(data)

## # A tibble: 20 x 9##    team               w     d     l    gf    ga    gd points position##    <fct>          <int> <int> <int> <int> <int> <int>  <dbl>    <int>##  1 Liverpool         17     3     0    48     8    40     54        1##  2 Man City          15     2     3    54    16    38     47        2##  3 Tottenham         15     0     5    43    21    22     45        3##  4 Chelsea           13     4     3    38    16    22     43        4##  5 Arsenal           11     5     4    42    30    12     38        5##  6 Man United        10     5     5    41    32     9     35        6##  7 Wolves             8     5     7    23    23     0     29        7##  8 Leicester          8     4     8    24    23     1     28        8##  9 Watford            8     4     8    27    28    -1     28        9## 10 Everton            7     6     7    31    30     1     27       10## 11 West Ham           8     3     9    27    30    -3     27       11## 12 Bournemouth        8     2    10    28    37    -9     26       12## 13 Brighton           7     4     9    22    27    -5     25       13## 14 Crystal Palace     5     4    11    17    26    -9     19       14## 15 Newcastle          4     6    10    15    27   -12     18       15## 16 Cardiff            5     3    12    19    38   -19     18       16## 17 Southampton        3     6    11    21    38   -17     15       17## 18 Burnley            4     3    13    19    41   -22     15       18## 19 Fulham             3     5    12    18    43   -25     14       19## 20 Huddersfield       2     4    14    12    35   -23     10       20

Which also works on the simulated table:

calculate_table(single_simulation)

## # A tibble: 20 x 9##    team               w     d     l    gf    ga    gd points position##    <fct>          <int> <int> <int> <int> <int> <int>  <dbl>    <int>##  1 Liverpool         32     6     0   102    10    92    102        1##  2 Man City          28     5     5    97    31    66     89        2##  3 Tottenham         27     5     6    83    36    47     86        3##  4 Chelsea           25     4     9    69    33    36     79        4##  5 Arsenal           22     7     9    84    54    30     73        5##  6 Man United        18     6    14    75    65    10     60        6##  7 Everton           13    13    12    52    50     2     52        7##  8 Leicester         14     9    15    41    47    -6     51        8##  9 Wolves            14     7    17    41    43    -2     49        9## 10 Bournemouth       12    10    16    55    65   -10     46       10## 11 West Ham          13     7    18    52    62   -10     46       11## 12 Brighton          12    10    16    40    51   -11     46       12## 13 Cardiff           14     4    20    48    68   -20     46       13## 14 Watford           12     9    17    48    56    -8     45       14## 15 Newcastle         12     8    18    32    53   -21     44       15## 16 Crystal Palace    10     9    19    31    51   -20     39       16## 17 Southampton        9     9    20    42    71   -29     36       17## 18 Fulham             7     7    24    32    86   -54     28       18## 19 Burnley            6     8    24    30    78   -48     26       19## 20 Huddersfield       4     9    25    24    68   -44     21       20

Running the simulations

Now we have everything we need to generate as many simulated leaguetables as we want.

n_simulations <- 1000

simulated_tables <-
  rerun(n_simulations, simulate_season(scorelines)) %>%
  map(calculate_table) %>%
  bind_rows(.id = "simulation_id")

simulated_tables

## # A tibble: 20,000 x 10##    simulation_id team       w     d     l    gf    ga    gd points position##    <chr>         <fct>  <int> <int> <int> <int> <int> <int>  <dbl>    <int>##  1 1             Liver…    35     3     0    96    12    84    108        1##  2 1             Man C…    27     6     5   101    32    69     87        2##  3 1             Totte…    26     4     8    94    48    46     82        3##  4 1             Chels…    21     9     8    67    31    36     72        4##  5 1             Arsen…    22     5    11    82    61    21     71        5##  6 1             Man U…    20     9     9    82    58    24     69        6##  7 1             Leice…    18     8    12    52    43     9     62        7##  8 1             Evert…    13    13    12    62    63    -1     52        8##  9 1             Wolves    13    12    13    45    46    -1     51        9## 10 1             West …    15     6    17    55    66   -11     51       10## # ... with 19,990 more rows

Results

With the results in hand, we can move onto the fun parts. That is,sifting through our model’s predictions of the future.

Position probabilities

n_teams <- length(teams)
plot_colour <- "#1a4990"

simulated_tables %>%
  count(team, position) %>%
  ggplot(aes(x = position, y = n / n_simulations)) +
  geom_col(fill = plot_colour) +
  facet_wrap(~ reorder(team, position)) +
  scale_x_continuous(breaks = 1:n_teams) +
  scale_y_continuous(labels = scales::percent_format(),
                     limits = c(0, 1)) +
  labs(title = "Position probabilities",
       x = NULL,
       y = NULL) +
  theme_minimal() +
  theme(title       = element_text(size = 30),
        strip.text  = element_text(size = 25),
        axis.text.y = element_text(size = 15),
        axis.text.x = element_text(size = 10),
        panel.grid.major.y = element_line(linetype = "dotted"),
        panel.grid.major.x = element_blank(),
        panel.grid.minor   = element_blank())

It turns out the model is extremely bullish on Liverpool’s chances ofwinning the league:

simulated_tables %>%
  group_by(team) %>%
  summarise(p_win = mean(position == 1)) %>%
  filter(p_win > 0.01) %>%
  arrange(desc(p_win))

## # A tibble: 2 x 2##   team      p_win##   <fct>     <dbl>## 1 Liverpool 0.948## 2 Man City  0.052

I think this is partly a reflection of the flaws in the simulationmethod. However, I think a bigger factor is using goals as our onlyinput to team strength. As we know, the table does sometimeslie,and sometimes goals can deceive, too.

Both of these factors result in Liverpool’s chances being overestimatedby the model. For comparison, the bettingmarkethas Liverpool at around 60% to win the league at the time of writing.

At the other end of the table, things are a bit more interesting;although Huddersfield and Fulham don’t look great.

simulated_tables %>%
  group_by(team) %>%
  summarise(p_rel = mean(position >= 18)) %>%
  filter(p_rel > 0.01) %>%
  arrange(desc(p_rel))

## # A tibble: 7 x 2##   team           p_rel##   <fct>          <dbl>## 1 Huddersfield   0.981## 2 Fulham         0.866## 3 Burnley        0.569## 4 Cardiff        0.24## 5 Southampton    0.21## 6 Newcastle      0.12## 7 Crystal Palace 0.014

We can look at the race for the Champion’s League, too:

simulated_tables %>%
  group_by(team) %>%
  summarise(p_top4 = mean(position <= 4)) %>%
  filter(p_top4 > 0.01) %>%
  arrange(desc(p_top4))

## # A tibble: 5 x 2##   team      p_top4##   <fct>      <dbl>## 1 Liverpool  1## 2 Man City   0.998## 3 Tottenham  0.944## 4 Chelsea    0.872## 5 Arsenal    0.178

Points totals

simulated_tables %>%
  count(team, points) %>%
  ggplot(aes(x = points, y = reorder(team, points))) +
  geom_tile(aes(alpha = n / n_simulations),
            fill = plot_colour) +
  scale_alpha_continuous(range = c(0, 1)) +
  labs(title = "Points total probabilities",
       x = NULL,
       y = NULL) +
  theme_minimal() +
  theme(legend.position = "none")

The model even seems to think that Liverpool’s chances of breaking 100points are pretty good:

simulated_tables %>%
  group_by(team) %>%
  summarise(p = mean(points >= 100)) %>%
  filter(p >= 0.001) %>%
  arrange(desc(p))

## # A tibble: 1 x 2##   team          p##   <fct>     <dbl>## 1 Liverpool 0.545

And even that they’ve got a solid chance of going unbeaten!

simulated_tables %>%
  group_by(team) %>%
  summarise(p = mean(l == 0)) %>%
  filter(p >= 0.001) %>%
  arrange(desc(p))

## # A tibble: 1 x 2##   team          p##   <fct>     <dbl>## 1 Liverpool 0.386

Wrap-up

This is one simple way of getting season-level predictions from a simplematch-level model, using a relatively small amount of new code. Beingable to quickly generate and investigate predictions is an importantpart of the dataexploration process. Havingboth game and season-level views onto your model’s predictions, allowsfor increased insight into a model’s shortcomings and how it might beimproved.

There are a few simple extensions to this analysis that could be nicejumping off points for improving the model.

• Time-discount factor
  • What do the predictions look like if you incorporate more datafrom the past, with a time-discounting factor? (See theweights argument to regista::dixoncoles.)
• Other leagues
  • How does this analysis look when you try other leagues avaliablefrom football-data.co.uk? (Hint: change the first code chunk andtry re-running the notebook)
• xG/Dixon-Coles
  • How do the predictions look when you estimate team strength fromxG rather than just goals? (See Dixon Coles and xG: together atlast.)