Speed Tests: Rubberbanding (Keep Everyone Together) Mode on Climbs in Zwift Meetups

This is the final post in my series testing “Keep Everyone Together” mode in Club events and Meetups. So far, we’ve tested banded Club Events on flat ground, as well as Meetups. These tests showed us that Zwift is using two different banding algorithms: one for Club events, and one for Meetups. The Meetups algorithm seems to turn in more accurate (and faster) times on flat ground.

Next, I published tests for banded Club Events on a climb: Alpe du Zwift, to be precise. These tests showed that banded Club Events are giving riders unrealistically fast speeds.

All that remains is to test climbing in banded Meetups and compare those results to climbing banded Club Events. Let’s get to it!

Testing Banded Alpe Meetups

The core questions I want to answer are: Do rubberbanded Meetup speeds make sense, or are they too slow, too fast, or some strange mix of both? And how do they compare to banded Club Events?

The riders in these tests were 75kg in weight, 183cm tall, and rode Zwift Carbon bikes with 32mm carbon wheels. I timed the riders on the Alpe du Zwift climb segment since it’s steep and long enough to be a good representation of climb performance.

Test 1: A Pair of Bots

This first round of tests used just two riders in a Meetup with “Keep Everyone Together” mode enabled. Here are each rider’s power outputs, segment times, and average speeds.

Observations

When both riders held the same power the times are similar to banded Club Event times, although the Meetup test results are always a bit slower.

But the big thing that stands out here is that these times are significantly slower than the banded Club Event tests when the riders have differing power numbers. The times you see above are roughly in line with what we see from ZwiftPower’s historical data on the Alpe du Zwift segment, if we base the time on the stronger rider’s power.

So it appears that banded Meetups are delivering fairly accurate speeds, at least for the more powerful rider in the group. (The weaker rider in, say, a 300W and 75W pairing will, of course, have an unrealistically high speed.)

Getting a bit pickier, it’s odd that our test riders turned in the same time whether the pair was doing 300W and 225W, or they were doing 300W and 75W. Logically, you would expect things to be at least a bit slower when the group’s average power drops considerably.

Test 2: Solo Rider

Next, I wanted to test how a solo rider in a rubberbanded Meetup performs compared to the paired riders above. So I created a Meetup with “Keep Everyone Together” enabled, but only had one rider join. Here are the results:

Compare those numbers above to free ride times with a solo rider (which should, in theory, be the same):

Observations

First, notice that when there is just one rider in the rubberbanded event, their speeds closely match the tests when we had one stronger rider banded to a weaker one. This is also what we saw with the flat tests for banded Meetups. They don’t perfectly match a free riding solo rider, but they’re close, and much closer than our tests with a solo rider in a banded Club Event.

Secondly, our solo banded Meetup rider was significantly faster than the solo banded Club Ride rider. This is just further evidence that the algorithm for banded Club Rides needs fixing.

Concluding Thoughts

These test results clearly show that “Keep Everyone Together” mode in Meetups behaves very differently from “Keep Everyone Together” mode in Clubs. Specifically, banded Meetups are markedly slower on climbs than banded Club events.

This is the opposite of what we observed in our flat tests of banded Club Events and Meetups. In those tests, banded Meetups were markedly faster than banded Club events.

But here’s the good news: on both flats and climbs, banded Meetups appear, at least from my limited 2-rider tests, to perform fairly realistically, in a way that all participants can enjoy. So Zwift may have a simple solution available that will greatly improve the current banded riding experience: instead of running two different banding algorithms (one for Club events, one for Meetups) just run one, and make it the one currently in use for Meetups!

But I’ll add one more recommendation to that: mark all banded activities as “gamified” when uploading to Strava, so segment times don’t go on leaderboards or count for personal PRs. This fixes the issue of lower-power riders setting PRs in banded events that they can never break when riding in a non-banded environment. Going even further, banded event times should also be hidden from in-game leaderboards, and shouldn’t be saved for segments or HoloReplays.

There Is Good News!

Zwift HQ has noticed these speed tests… and they’re working to improve the banding algorithm! Just this week I chatted with a Zwift software engineer about it, and it sounds like a solution may be released very soon. I may even get to test it before it’s released. Ride on!

Questions or Comments?

Share below!