Learning From the Champions League First Round 2020

Oct 14, 2020

5 min read

Introduction

Being at the first round of the Champions League with IBB Polonia London in Trento, Italy was an amazing experience. We got to play against one of the best teams in the world in Trentino Itas (ITA) with some world-class players. I got to take a photo with one of my favourite setters, Simone Gianelli (see at end of the post). We also had a match against Vojvodina Novi Sad (SRB) and it was highly competitive. We had a chance to win but we have to be satisfied with being the first English team to win a set in the Champions League. Anyway, I learnt a few things along the way that will improve my performance analysis workflow.

Rebounded Attacks Directions

I was always taught that I should code rebounded attacks (attacks are blocked but play continues) as a compound code as follows: However, the rebounded attacks are not reflected in the attack directions. If the rebounded attack went back to zone 3, the attack directions would look like it went steep to zone 3 to the opposition court (see below, left directions charts). I found (again) that in the Trentino’s acout that it can be done – you simply code the block as a !, i.e. . This small change means the rebounded attack is reflected in the attack directions (see below, right directions chart). It also means I can easily code block touches (block touch but play continues on blocker’s side) as a compound code, since it was the original way that I did it.

Front, Back and Pipe Attacks

When I produce the attack/ setting distribution charts, the 10 attack (back row, right side attack) was always left blank (see below, left chart). It was quite annoying because I would want to know what that distribution is like when the setter is front row, i.e. how much does the setter spread the attack. I just thought it was the way it was and it couldn’t be changed.

However, when I analysed Trentino’s stats in preparation for our match against them, I saw that it could be done. I looked deeper and I found that it was beacuse they selected the “Target Attacker” for the 10 attack as “Back” rather than “Pipe” as I did. I always thought by selecting “Back”, it would get lumped in the front row back sets. This was why so I chose “Pipe” for back row. I made the small change and it worked (see above, right chart).

Defining High and Medium/ Tempo Sets

I know what a high set looks like and I know what a medium/ tempo set looks like but I always had trouble with where you draw the line, i.e. at what point does the high set become a medium/ tempo set? A lot of the sets in the Men’s Super League were in between and I didn’t have a good way to differentiate between the two. So in the end, I just coded everything as a high set unless it was clearly a medium/ tempo set.

I found in the Trentino and Novi Sad DataVolley scouts that this differentiation was actually quite simple and easy. The speed of the sets are so fast at this elite level that basically when the team is in-system and in good condition, the tempo set is the norm whereas out-of-system, the sets was sky high. There wasn’t that many in between sets.

Bench Versus End Line Statting

The advantage of statting from the end line/ back of the court is you get to see shirt numbers a lot easier, making coding a lot faster, and coding attack/ serve directions is a lot more accurate. However, my preference is to stat from the bench. While you can’t stat as fast, the big advantage is I can offer tactical changes to the coach or players based on the live stats. In close matches, this is where I feel I can have the biggest impact. This was reinforced in the match versus Vojvodina Novi Sad. I had to stat from the end line in the Champions League and it was a close match (we won the first set). There was two big changes I wanted to suggest to the coach and players that if followed, I felt it would have put us closer to winning the match.

Posting the DataVolley Report Straight After the Match

I always resisted posting the stats straight after the match. This is because I want to make sure the stats are as accurate as possible and I know there are always errors in the scout that I want to correct. You can’t produce inaccurate stats because any subsequent decisions to enhance performance based on those stats can’t be trusted. However, I find coaches and players do want that immediacy because when the official stats are printed off (usually at big events like the Champions League), coaches and players do look at them. It may be the only time that they look at the stats.

So I decided I would publish the DataVolley match report anyway, straight after the match via the team’s WhatsApp group chat. I reasoned that the stats are about 90-95% accurate without the accuracy checks and some errors, e.g. coding the wrong attack combination code, won’t show up in the match report anyway (it’s still an attack attempt regardless of what type of attack it was). Also, any decisions to enhance performance based on the stats would be based on the full report with the accuracy checks included and not this one. I did it and it was good to hear some players quoting the some stats on the bus ride home.

To Include Attacks Block Killed in the Hitting % or Not

I made a decision that for the upcoming season, attacks block killed and reception errors are not considered as a point lost (see blog post). This means that attacks block killed are not included in the Hitting Pct., which has a profound effect in how you calculate the Hitting Pct. and how it’s viewed.

The Champions League was the first time using this modified Hitting Pct. in practice. I found that it was still difficult to understand the level of performanec for the modfied Hitting Pct. I know it will take time for me and the players to understand so I thought it was best to include both the original Hitting Pct. (attacks block killed included) and modified Hitting Pct. (attacks block killed excluded) to ease everybody in this. It would mean a lot of work modifying all the worksheets to include both versions.

Using Nicknames to Include Playing Position

I noted before that it would be nice show the player’s first name and playing outside as it adds some colour to what their stats should look like (see link). This is especially true for players I don’t know, which was particularly pertinent in writing up the scout reports for Trentino and Novi Sad. Only their surnames are shown and I didn’t think there was a way around it.

This was until I saw the Trentino scout wrote the full name of the players in the Nickname section. DataVolley uses the “Nickname” is used instead of their standard surname if a player is known by another name, e.g. people will know Gilberto Amauri de Godoy Filho by the name of Giba. This meant Trentino’s full names were listed in the stat reports in DataVolley. I thought this was nice but I could take it further to include their playing positions also. This means their playing position would also be shown in the stat reports. I did this and it was a lot more helpful (see below GIF).