World Snowboard Points List (WSPL)

Since the end of season 2022/23 we (Wyldata) have the pleasure to host the World Snowboard Points List (WSPL). In this post, we will give an overview of how such a global action sports ranking system at large works.

Generally, the WSPL is trying to be as automatized and autonomous as possible. That means that there are integrations with other systems in the ecosystem that are automatically handling a range of different tasks. The following graphic depicts a high level view of the tech stack and the interactions with the involved third party systems. For non-technical readers, the colorful logos just indicate which programming languages and frameworks certain components are running with.

The important point to recognize is that there is the FIS and the LiveHeats (LH) system which are communicating with the Wyldata server to supply all the initial data the WSLP ranking is running on. This happens automatically through something called webhook. Think of a webhook as a phone number like 911. If you call it, it triggers a certain emergency response protocol within the emergency service. Depending on what you say to the emergency service, the actions taken may differ.

Similarly FIS and LH both have received a “phone number” from us where they can call our system to trigger a response. The webhook is automatically called if certain conditions and events occur, for example, in LH when an event is created or its status is changed. Then the message sent to us is something like “Hey, event updated with ID xyz". The event ID would obviously change from case to case.

Based on this event ID our system in response fetches the full event data from their database. This exchange happens through so called application programming interfaces (APIs) There is puplic documentation on what is availble from FIS and LiveHeats.

But it's not as simple as that because there are many different cases which can occur when the webhook is called. The WSPL also needs additional information like the WSPL event category, which are not generally collected data points in LH. Furthermore, there is a big difference between the two data sources. FIS results only ever contain FIS licensed athletes, while LH results can contain any competitor. Worst of all, an event can be double sanctioned (World Snowboard Federation (WSF) and FIS endorsed). In that case, we need to figure out which results are supposed to be accepted to count towards the WSPL. And finally, another difference that makes things tricky on the LH side is that the athletes in that system don’t have a unique identifier, whereas FIS athletes have a FIS license code, something similar to a passport number. The following graphic explains the logic that runs in response to the webhook being called to handle these circumstances.

Lots of stuff going on here but all pretty straightforward, the main point is to always check for double sanctioned events via the FIS codex and give priority to the ones from LH as we want to include non licences athletes. Another quirk about the results is that we have to temporarily saves results from LH. Because of the mentioned issue with the missing unique athlete identifier, a Wyldata admin has to manually look over the results to make sure the scores are assigned to the correct athlete in our system (at least for now). That is also why Wyldata always needs at least the athlete nationality and birthday infos, otherwise there are too many athletes with similar names and assigning the scores to the wrong athlete would be likely.

Ok, at this point the event and result data is in our system, now how does the ranking get created? Logically, the ranking is just an ordered list of athletes based on their average collected ranking points in a respective freestyle discipline (Half Pipe, Big Air, Slopestyle). Whenever a new result enters the Wyldata database the according ranking points have to be determined case by case for each result. There are 10 ranking point levels (100, 200… to max 1000). How many points are awarded depends on the following factors:

 

1. Quality of participating athletes, measured by the average WSPL rank (r value) and the average WSPL points (p value) of the top 5 (womens) or 8 (mens) WSPL ranked athletes in the competition at that point in time. Every season, the thresholds for the points level based on these p and r values is adjusted. the graphic below depicts the thresholds from the 23/24 season. For example, if the r value is above 25 and the p value for a mens slopestyle result is 500, then it would be a 600 points level category since the lower bound is at 437.65 and the upper bound is at 525.17. If a mens result has a r value below 25 we would be placed somewhere in the top range of 700-1000.

2. Competition category (one out of Grassroots, Amateur, Challenger, Pro, Elite)

Each category has a minimum and maximum ranking points level to avoid having strongly ranked nations being able to boost each of their events with many well ranked local athletes, leading to a run away effect. The caps are as follows (min/max):
 

- Grassroots: 100/300

- Amateur: 100/400

- Challenger: 200/600

- Pro: 300/800

- Elite: 600/1000

 

3. Field size measured by the number of participating athletes. The more athletes compete, the higher the reward per rank except the first which is fixed. The exact points for each rank is determined by a formula that defines a descending points per rank curve, which is steeper the fewer participants the competition has. Obviously, a third place in a competition with 5 participants should be worth less than a third place in a competition with 30 riders. Depicted below an example points distribution for a 100 point result with 10, 15, 25, 50 and 100 participants (curves left to right).

That’s where the ranking points are coming from, now we just have to run a simple computation which is done every Monday and Thursday 14:30 CET where we look at each athlete's results in the past 52 weeks, add the ranking points of the best three results and finally rank them by their average ranking points. That’s the list that is then visible through Wyldata’s web client here, the part of the Wyldata system also usually referred to as the Frontend (all the visible stuff that runs in the browser) compared to the Backend (all the logic stuff that runs on the server).

But wait, of course there are exceptions. Let’s bring into the picture the injury protocol. In an injury prone sport like snowboarding, it makes sense to introduce certain rules to protect athletes from dropping out of the ranking immediately if one suffers an injury. That’s why every WSPL athlete has a status which is considered during the ranking calculation allowing to carry ranking points over a injury period. As soon as someone is injured, he/she can apply for the injury status at FIS and FIS will confirm to us whether we can manually add the injured status. As soon this status is added, the average ranking points are not touched anymore in the recurring ranking updated. Change of the injured status is happening according to the following protocol. One will move through a recovered status to finally became active again allowing to carry results for up to 3 years. This protocol automatically runs every day once with the Celery background worker. Yes, tech people like to name their stuff after fruits and veggies!

And depending on this injury status the ranking calculation is simply the this.

Finally, all these components and protocols are playing together to power the WSPL ranking and calendar. A typical scenario with interactions between all the discussed elements looks something like the following.