4 VBStats scouting from video

This guide describes a particular set of conventions for scouting volleyball matches using the Perana Sports VBStats app. These conventions are intended to give consistent scouted files that work well with the peranavolley R package, but without requiring an overly-onerous scouting procedure. Scouts should be familiar with the VBStats User Guide, in particular the Actions and Results and “Coding from a video (both teams)” sections.

4.1 Skill evaluations

4.1.1 Passes (serve receptions) and digs

P3 = a good or perfect pass, giving the setter the option to set to any attacker (in DataVolley this would be scouted as “R#” or “R+”)
P2 = an “ok” pass (DataVolley “R!”), giving restricted attack options (but still more than one option). Often these are passes that force the setter to set from 3m or more from the net. The setter doesn’t have the option to set a true first tempo, but outside attacks can be made at normal medium/fast tempo. Note that some setters will still set their middle on these sets with a slower (low) quick ball. Mild overpasses or poorly positioned passes might also be rated as P2, if the setter only has two real options (say, the quick hitter and opposite on a low pass to position 2)
P1 = a negative pass or an overpass (DataVolley “R-” or “R/”), generally only giving the setter a single normal-tempo setting option (they might also have high ball options to other attackers) or even no attack at all (a freeball back to the opposition or an overpass)

Rotation error by the receiving team: there doesn’t seem to be a way of specifically recording rotation faults. But you can just adjust the team scores to give the serving team an extra point (click the scores in the middle of the top toolbar (button 6)).

4.1.2 Serves

Rate serves by pass quality, so that a poor serve (S1) is one that allowed a perfect pass (P3), an OK serve (S2) with an OK pass (P2), and a good serve (S3) was one that the opposition was only able to make a poor pass (P1) on.

On serve errors, enter the ball path and also indicate the reason (net/out long/out side).

Rotation error by the serving team: there doesn’t seem to be a way of specifically recording rotation faults. But you can just adjust the team scores to give the receiving team an extra point (click the scores in the middle of the top toolbar (button 6)), and also adjust the rotation of the receiving team (so that the correct player is next to serve (button 9 at the bottom of this page).

4.2 Entering ball paths

Enter the ball path for all serves and attacks, showing the start and end points of the serve or attack. It’s easiest to expand the court diagram to do this (this will happen automatically for attacks, but for serves you may need to use the small white square in the bottom-right of the court diagram). You can re-draw the ball path several times if you aren’t happy with it on the first attempt.

For attacks, the starting location is used to label the attack type, so it’s important that the starting location is behind the 3m line for back row attacks, and in front of the 3m line for front-row attacks. If it’s a front-row player making the attack, enter the starting coordinate in front of the 3m line, even if they actually attack from behind it. Similarly, if it’s a back row attack, make sure the starting coordinate is behind the 3m line (even though in reality the attack might be contacting the ball in the air in front of the 3m line). The only time you would enter a coordinate in front of the 3m line for a back-row attacker is if they put a freeball over from in front of the 3m line (starting coordinates aren’t used to classify freeballs, only actual attacks).

The coach/technical coordinator might also ask for ball paths to be entered for sets. The start point is the important piece of information in this case (so that we know where the setter made the set from). This information allows for setter choices to be examined according to where on court they made the set from, but this is not always needed.

4.3 Skill-specific conventions

4.3.1 Sets

Unless the coach/technical coordinator has asked for sets to be scouted, don’t scout setting actions except for set errors. Setter dumps are always entered (but these are entered as attack actions of type “dump”, not as set actions).

If we scout all setting actions, it’s extra work for the scout, but it allows some additional statistical insight. In particular, we can examine how a setter changes their set choice depending on where on court the pass goes (e.g. where does a setter tend to set given a poor pass to position 4, compared to a poor pass to position 2?). Thus, if the coach/technical director has asked for setting actions to be scouted, then all sets should be scouted, including the ball path of the set. The starting position of the ball path is where the setter sets from; the end of the ball path is where the set goes to (where the attacker makes contact with the ball, or where ball bounces/hits the net in those situations).

Do not select the “Record assists” option in the app settings. Doing this will cause a set action to be automatically inserted, but only on attack kills. Thus, we don’t get consistent scouting of setting actions.

4.3.2 Attacks

An attack that goes off the block these should be scouted as “off-block” by selecting that option in the detail screen and entering a ball path that goes off the block.

Enter the number of blockers on each attack.

4.3.2.1 Setting zones

Setting zones are used in VBStats to indicate particular attack types. When you scout an attack, you can optionally assign one of five pre-designated setting zones. You can also leave the setting zone un-assigned. We use the setting zone in conjunction with the attack coordinates to generate more meaningful attack descriptions.

Use the following setting zones:

Setting zone	Attack type	Equivalent DataVolley attack code
1	Quick ball in front	X1
2	Quick ball behind	X2
3	Quick ball at a distance in front of the setter, sometimes called a B-quick	X7
4	Slide attack	CF
5	High ball	V5, VP, etc

When we process the scouted file, the following rules are applied:

If the setting zone has been specified as one of the first four (i.e. not a high ball), the associated DataVolley attack code (X1, X2, etc) will be inserted into the attack_code column of the data.
If setting zone 5 (high ball) has been specified, the attack will be labelled according to its starting coordinate. For example, a highball attack from position 4 will be given the attack_code V5, and a back-row right-side highball (from position 9 or 1) will be given V8.
If the setting zone has been left empty, the attack will be given an attack code according to its starting coordinate, assuming a standard tempo attack. For example, an outside hit from position 4 will be attack_code X5 (this type of attack is also known as a “black” or “11”), and a back-row middle attack (from position 8 or 6) will be attack_code XP (pipe).

4.3.3 Freeballs

As of VBStats version 2.34.232, there isn’t a specific action for freeballs. A freeball over (i.e. an easy ball put over the net to the opposition when no attack is possible) should be scouted as an attack, with the attack type “Dump” and setting zone “High”. A freeball dig (the subsequent dig made on such a ball) should be scouted as a normal defense (dig) action.

If the freeball over happens to win the point, it is important to include a dig following it, with “error” evaluation. If no opposition player actually performed a dig, scout the dig anyway, and assign it to the player who should have made the dig (see the “Assigning errors” section below).

When the scouted file is processed, any “dump” attacks performed by a setter will be treated as setter dumps, but “high dump” attacks (by a setter) and “dump” attacks (by non-setters) will be treated as freeballs over. Additionally, any dig following a freeball over will be treated as a freeball dig. This allows us to examine freeball-specific statistics, if we wish.

4.3.4 Blocks

Scout any block errors or block kills. Block kills are most easily entered by scouting an attack of type “error” with reason “blocked” — when you select “blocked” it will pop up a list of opposition players and ask you to select the blockers. If it was a multiplayer block, only select one blocker (the one who actually blocked the ball. Some volleyball analytical software allows multiple blockers to be identified in this situation, with each blocker being credited with a “block assist”. However, not all software supports this.)

A player making a block touch can be entered as a “block control” action, but don’t bother unless the coach has asked for these to be scouted. Block touches aren’t generally used in match reports, and we have other analytical tools to help us assess block performance. Remember also that we scout attacks as “off-block” in this situation, so we will know during the analysis that a block touch occurred even though we don’t have an explicit action for it.

4.4 Assigning errors

Remember from our general principles that there is a distinction between the scouted data and the information that we generate from it. Sometimes we will scout something as an “error” even though we won’t consider it as one when we report the results. The converse can also be true: we might treat something as an error in our report even though it isn’t scouted as such in the data. Scouting errors can be confusing!

The following describes our conventions, from most straightforward to most confusing.

4.4.1 Serve

Any serve fault is scouted as an error (foot fault, serve out, serve into the net).

4.4.2 Reception

A serve ace should always be accompanied by a reception error, and vice-versa. For a serve ace, the reception error should be assigned to the player who had responsibility for passing that serve. If the ball lands between two receiving players, assign the error to the one that was most at fault. An extremely poor reception that gets a second touch but can’t be put back over the net should probably be considered to be a reception error.

4.4.3 Freeball digs

Freeball digs are treated the same as receptions. Any loss of point on a freeball dig should be scouted as an error, assigned to the player who had responsibility for the dig.

4.4.4 Attack

Direct errors by the attacker (net violation, reach, hit out, hit into the net, back-row attacker inside the 3m line, etc) should be scouted as attack errors.

Blocked attacks are not usually considered to be errors for the purposes of analysis, but with some scouting software they must be scouted as errors (e.g. in VBStats a blocked attack must be entered as an error, with reason “blocked”. These will not be treated as errors in our downstream analyses, though).

An error on a very poor set is probably not an attack error (e.g. an unhittable, mis-timed quick set), but this may be subjective.

4.4.5 Set

Any set fault that leads directly to the loss of a point (double-contact, net violation, reach, etc) should be scouted as an error, as should any poor set that directly leads to the loss of a point (e.g. an unhittable set).

Setting errors often have an unavoidable element of subjectivity, for example:

a poor (nearly unsettable) pass called for double contact (assign the error to whichever player you think was most at fault. It might reasonably be considered to be a set error if the setter chose to try and finger-set it rather than bump-set)
a poor set that the attacker tried to save, but contacted the net in doing so (assign the error to whichever player you think was most at fault)

Other subjective situations include tactical/decision mistakes, e.g.:

a set that goes to an attacker who is out of position and makes an error in attempting to hit it (probably scout as attacker error)
a set that goes to an attacker with 3 blockers when another attacker is entirely open, and the point is lost on that attack (do not scout as a set error).

4.4.6 Block

For blocking, only scout errors that are direct errors by the blocking player (net violation, reach, catch, back-row player blocking, etc). An attack hit that goes off the block for a kill is not scouted as a block error (recall that these should be scouted as “off-block” by entering a ball path that goes off the block and selecting the “off-block” option in the detail screen if it has not automatically been selected).

A blocker who is out of position and fails to block, leading to an attack kill is not scouted as an error, even though it might be considered to be one by many coaches. In our downstream analyses, we can get insights into blocker position by other means, so we keep the scouting of “block errors” for direct blocking errors.

4.4.7 Dig

Dig (defensive) errors are perhaps the least clear. Some defensive plays are clearly errors (defender out of position, or an easy ball that should have been dug, or an attack in that was not played because the defender incorrectly decided that the ball was going to land out). However, there are also many situations in which a defender makes a forced error — say, trying to dig a hard attack hit. There are two extremes here:

We could assign a dig error to every defensive touch that leads to the loss of a point (i.e. forced plus unforced errors). The advantage to this is that we would definitely capture all unforced errors, but the downside is that we will include a lot of forced errors as well. We will also potentially be assigning errors to a defender that were primarily another player’s fault (e.g. a blocker out of position, giving the opposition an attack against no block, leading to a dig “error”).

We can still extract useful information from this data, but it requires some level of analysis after collection. The raw dig error rates, for example, are probably not meaningful in the way that most coaches would interpret them (because they are an unknown mix of forced and unforced errors).
Alternatively, we can choose to only scout unforced defensive errors (e.g. defender out of position, a poor dig on an easy opposition attack that should have been defended, or a defender failing to play a ball at all because they decided it was going out).

The disadvantage to this is that it becomes subjective (e.g. the concept of an “easy opposition attack” will vary from scout to scout and competition to competition). It may also limit the range of analyses that we can later do with these data. In particular, different defenders may be difficult to compare (e.g. amazing defender A who successfully digs a lot of hard-driven balls, compared to poor defender B who makes errors on similar balls. A scout might very well not include the errors of defender B on the basis that they were forced errors, making defender B look better than they actually are in relation to defender A).

On balance, we recommend the first option: scout all defensive errors, forced and unforced. There will be some circumstances in which it is genuinely impossible to assign a defensive error to an individual player (e.g. an team’s defensive system deliberately leaves a certain part of the court undefended, and an attack lands in that open zone — it’s not necessarily going to be clear whose responsibility that ball was). Scout an attack kill with no corresponding error in these cases, but they should be relatively infrequent.