Opinion: Phenotypes and Real-Time Enforcement (Race Categories, Part 2)

December 27, 2019

LAST UPDATED March 23, 2020

In part 1 of this series, I laid out the current Zwift race categorization situation. This included a discussion of the standard FTP-based categories, the insufficiency of enforcing rules post-race, and a look at some actual participation numbers to show how Zwift and ZwiftPower’s published race results are far from ideal.

But I’m not interested in dwelling on what’s wrong with Zwift. After all, I’m a huge fan, and I want to see Zwift become even better than it is today! So I wrapped up part 1 with some ideas for improving the race experience for everyone, including the simple solution of using a rider’s saved FTP to determine their race category. If you missed that first post, read it here >

You may recall I proposed taking a phased approach to improving Zwift’s race categorization setup. This would allow for significant improvements to be made quickly, while a more complete solution is developed over the longer term (6-12 months). Here are the proposed phases:

Now: simple categorization based on riders’ saved FTP (outlined in part 1)
Soon: categorize riders based on their phenotype
Later: results-based categorization

This post will discuss phase 2, which I believe is something Zwift could roll out in 3-6 month’s time if they gave it a high priority.

Phase 2 Goals

The second phase’s goals are to improve the weaknesses of phase 1 without wasting much developer time coding solutions which won’t be needed in phase 3.

Phase 2 could make the following improvements on phase 1:

Base rider category off a more complete rider phenotype, resulting in more accurate categorization
Real-time detection of category violations
Allow riders to “race down” a category or gracefully downgrade
Give race organizers the option to require heart rate and disallow zPower

Let’s talk about each of these improvements in more detail.

#1: Categories Based On Rider Phenotype

Phenotypes are a way of classifying riders based on their power bests (also known as “critical power”) over different time intervals. ZwiftPower includes a phenotype chart for all riders (read more here).

Typical phenotype intervals are 15 seconds, 1 minute, 5 minutes, and 20 minutes. Zwift’s FTP calculation (which we’re using for phase 1, if you recall) uses 95% of a rider’s best 20-minute power. So this phase 2 would be adding three additional shorter power metrics to the list.

This would provide a more accurate assessment of each rider’s ability to win a race, since your ability to climb short hills (1 and 5-minute power) can really determine whether you’re even in the mix for that final sprint (15-second power). Many riders have strong 20-minute power, but lack the sprint punch needed to finish at the front of the pack.

I won’t propose what the category breakdowns would be for each of the four time intervals, as I’m sure someone more qualified than myself could come up with sensible numbers. They could even be algorithmically determined based on population percentile to keep the categories properly sized.

And I’m not proposing that riders would be in different categories for different types of races–I think that’s much too complex. Each rider would still be in just one category, but those categories would be more accurate.

Examples: currently, a B rider with a 3.9 w/kg FTP and strong sprint can consistently podium in B races. They may get upgraded to an A. On the other hand, an A rider with a 4.1 w/kg FTP but weak 1-minute power probably doesn’t stand a chance in the A category. They could be downgraded to a B.

One side-benefit of this improvement over using the rider’s saved FTP from phase 1 is that riders can’t modify their stored power bests. Zwift would simply use the rider’s historic data in order to determine their category, intelligently upgrading or downgrading them based on their power numbers.

Note: riders could always race in a higher category if they’re looking for a challenge. If a rider wanted to quickly reduce their category due to injury, etc, there would be a new mechanism in place to allow for that (see #3 below).

#2: Real-Time Detection of Violations

Once each category had established critical power numbers in place for each time interval, Zwift could compute a racer’s critical power during their race and detect category violators in near real-time.

Looking at game logs we see Zwift is already calculating critical power curves mid-ride, so this step is already done. Zwift would simply need to match up the rider’s power curve with their category’s limits, then take action if the rider is over the limits.

Of course, there are lots of options when it comes to what actions might be appropriate. Do you give the rider an immediate cone of shame and artificially slow them if they go over the limit? Do you let them go a bit over the limit without penalty, knowing they’ll get automatically placed in the proper category after having a breakout performance?

The sensible solution is to have limits in place which will stop gross violators from affecting the race, while allowing those who may be legit but having a breakout race to perform at their best before they get upgraded.

#3: Racing Down a Category, Or Downgrading

We need a mechanism in place which allows a racer returning from extended sickness or injury to race in a lower category than they had previously joined.

Lower-category racers may cry foul at this idea, but we all need to understand two things:

It’s no fun entering an A (or even B) race when you’re recuperating and don’t stand a chance of hanging with a strong field.
Real-time detection of violations would ensure these downgraded racers couldn’t blow away the field, so their racing won’t adversely affect other racers’ experience.

A simple “downgrade” tool may be the way to accomplish this. This would be a simple button Zwifters could click to erase their power bests, letting them start like a “new rider” and race any category they choose.

Riders would be limited to using the downgrade tool only once every 30 (60? 90?) days, and after it’s clicked the normal power curve calculations and real-time detection would begin, ensuring the rider is placed in the correct category for their abilities without being able to sandbag other race categories.

#4: Requiring Heart Rate, Disallowing zPower

We know Zwift is already planning to let race organizers set their event up so that riders without heart rate and those using zPower are removed from the results. But hopefully in phase 2 that option could be used on the front end to prevent those racers from even entering the event.

In fact, Zwift wouldn’t actually have to block these riders from joining the race. Instead, Zwift could make it so these riders see everyone in the race, but the other racers don’t see them, and they’re hidden in the results. This would allow non-heart rate and zPower riders to enjoy the race experience, without allowing them to affect the race.

Keep Everyone Racing

Zwift has historically been hesitant to implement any system that prevents a rider from racing. And I don’t blame them! They want more people riding more often–and that’s what we all want.

Implementing phase 2 would require careful thought so Zwift racing remains inclusive. I would focus on a few key goals:

Simplicity: Make selecting the proper race category very easy (or even automatic).
Friendly Exclusion: Sandbaggers should be prevented from affecting the race, but in a friendly way that encourages them to race in the proper category. Always assume ignorance, not malevolence.
Fierce Competition: Category limits should be narrow enough that everyone feels they can compete. They should also be wide enough that field sizes stay large, allowing the pack to break up without stranding a lot of riders.

Hitting the Ground Running

Once phase 2 is in place, Zwift will have powerful tools which can be used to keep races fair even as the ranking system evolves. Because even with a results-based system (phase 3), gross violators need to be stopped before they can adversely affect a race.

Once phase 2 is in place, race categories should be working well enough that transitioning to phase 3’s results-based categorization requires no initial “seeding” races at all. Riders can be placed into proper categories at the beginning, then the new results-based system can begin to shuffle them around after each event. More on this in my next post!