A More Accurate NBA Usage Rate
TL;DR: calculating usage rate by tracking current players on the floor and plays made, play by play.
Usage Rate
The usage rate (usage percentage) is often quoted by the talking heads of ESPN and Fox Sports as an advanced metric to an NBA player’s impact on the floor. According to basketball-reference.com,
“Usage percentage is an estimate of the percentage of team plays used by a player while he was on the floor.”
And the formula behind the metric is:
I had two initial qualms with this formula.
- First, the formula assumes that a team’s shot attempts, free throw attempts and turnovers are evenly distributed throughout a game, very much contrary to the popular coaches’ saying that basketball is “a game of runs.”
- Second, the formula does not account for other important metrics including assists which would also indicate a player’s involvement in team plays.
Both qualms are reasons why usage rate is caveated as “an estimate” and not a precise measure and I will explore my first qualm by calculating a non-estimated usage rate.
A Non-Estimated Usage Rate
The NBA has over 100 open endpoints where developers and fans can pull just about any data imaginable, related to the NBA (documentation here). The two endpoints we will need to calculate a non-estimated usage rate is playbyplay and boxscoreadvanced. I will use the Hawks at Spurs game on April 1st as the example throughout this demonstration.
The playbyplay endpoint returns a data frame that contains the details of each play including: shots, misses, and even substitutions.
To calculate a non-estimated usage rate, we need to track which players are on the floor at any given time. However, players that end a quarter are not always the same players that start the next, and playbyplay does not contain these details. To circumvent this, Ryan Davis has already developed a technique using boxscoreadvanced to find the starters for each quarter.
I’ll pick up after Ryan’s contribution.
First we need to do some data preparation by separating players to their respective teams, converting columns of interests into lists (for faster recall), and initializing a dictionary of dictionaries to store information about each player’s FGAs, FTAs, and TOVs as well as TmFGAs, TmFTAs, and TmTOVs taken while the player was on the floor.
Next we will need a few tracking functions. The updateLineup function is called when a substitution occurs from playbyplay and removes or adds a player to the current_lineup. The statsTracker function is called whenever a FGA, FTA, or TOV occurs and updates the respective player’s dictionary as well as the team statistics for each player that is represented on the respective team’s current_lineup.
The calculateUsageRate function will be called at the end of the process to calculate the usage rate given the values in each player’s dictionary.
To fill in the tracking dictionary of dictionaries initialized previously, we will need to loop by quarter, as the starting lineup changes each quarter. For each play, we check if there is a substitution, FGA, FTA, or TOV, for both the home and away team, and call the updateLineup and statsTracker functions, respectively.
When all the quarters have been looped through, we can calculate the non-estimated usage rate using calculateUsageRate. The equation the function uses is simplified down to: (FGA + 0.44*FTA + TOV)/(TmFGA + 0.44*TmFTA + TmTOV) as minutes are no longer a factor after tracking the possession details play by play and accounting for players on the floor.
Comparing the normal (actual) usage rate to our non-estimated (new) usage rate, we find there is minimal discrepancy between the two metrics. The average percentage point change, for this game, was a decrease of 0.36.
In conclusion, the method of tracking plays, play by play, to calculate usage rate is a more accurate operationalization of the usage rate definition as we are getting a better measurement of what the usage rate was designed to measure. However, operationalization is dependent on conceptualization, and the conceptualization of usage rate (my second qualm) may also need to be examined.