Strava "average speed" inconsistencies
 

Maybe this has been covered before, but does anybody know how Strava calculates average speed in its different displays? The topline value seems to be consistently a little lower than the summary value displayed in the "Analysis" feature, and also lower than what my Wahoo will show at the end of a ride.

For example, this is the summary value for a recent ride: 17.9 MPH:


https://cimg4.ibsrv.net/gimg/bikefor...cbcbfaa0da.png

While the Analysis shows 18.1 MPH average:

https://cimg7.ibsrv.net/gimg/bikefor...837df159b9.png

This difference happens consistently on most all rides.

It's in the noise, I know, but the offset is systematic (always lower in the topline value), and I'm just wondering if anybody knows why this happens.

(I'm not asking why the Wahoo and Strava might be different - different processing of the raw gps data can definitely lead to small differences in averages- particularly in how the different algorithms process the time below the threshold speed (2 mph, 4 mph, etc.). But it seems that Strava itself is processing the same data differently for the two average speed calculations?)

Maybe/probably the average gets calculated for each page. And maybe the way they derive other data for that page affects what they show for an average.

I don't remember if the totals accumulated on the device are actually transferred in the data file. But also they might be sometimes using that value or basing their calculation on a device accumulated total that might well be different from the summed up GPS position data and timestamps in the file.

I’ve noticed the variation at times as well, however, looking back at recent rides, it is not consistent, and sometimes (usually, at least recently) the two averages (in Overview and Analysis tabs) match.

For me, it's always "faster" on the analysis page unless the ride is short, in which case they may be the same. Except of course, Zwift rides. Those are always the same - I assume because the differences in data processing are most important for stop/starts, and there aren't any of those in Zwift.

The effect might be device dependent.

Oh yeah, and Zwift "speeds" are pretty much meaningless to begin with.

Maybe so, though it seems computationally inefficient for Strava to recalculate the raw data for each different page display. Maybe their resource costs aren't much affected by optimizing CPU use.

Hmm. Yeah, I don’t know how to account for it at all, and I have recent rides of both long (e.g. 60mi) and short (e.g. 25mi) where the two values are the same, and I’ve not earlier noticed any breakdown along those lines.

I use a Wahoo Bolt, FWIW.

I wouldn't be surprised if the top number came from the data of the file, and the average you see next to the speed chart was the average of the values in the chart. You would expect that to be the same thing, but there may be some smoothing, ignoring of zeros, or summarization that happens before the numbers are converted into a graph.

It looks like you stopped several times during your ride. Could the difference be "moving average" vs. "trip average"? If you rode, say, 20 miles at 20MPH, but stopped halfway through for a 30 minute break, moving average is 20mph, but trip average is a bit over 13.

No, those are both moving average speeds.

If the x-axis is distance, rather than time, the graphically "averaged" velocity is nonsense. You know that. It's possible that the algorithm calculates a graphical average with elapsed moving time as the independent variable, And then maybe smoothing could introduce a difference, though I don't see why that difference would be systematic as compared to the mathematically rigorous quotient (total accrued distance/total moving time). "Ignoring zeros" would amount a different extraction of "moving time" as compared to another calculation, and though this is possible, one wonders why they would have two different methods for calculating moving time - which after all, has to be extracted from the same original data, whether they plot it or not.

Clearly *something* is different and smoothing is a good suspect, but again it's odd that it would result in a systematic bias.

I checked a bunch of my rides, and the numbers for average speed matched exactly in both places on every ride. No inconsistencies here.

Interesting. And thanks for checking.

it could be device dependent, but like Chaadster, I'm using a Wahoo Element Bolt. Could be different firmware versions or whatnot.
Here are a couple more examples

https://cimg3.ibsrv.net/gimg/bikefor...1c08664480.png

https://cimg7.ibsrv.net/gimg/bikefor...787480dd6b.png


https://cimg8.ibsrv.net/gimg/bikefor...bbc130b091.png

https://cimg0.ibsrv.net/gimg/bikefor...15d0182d73.png

I've had the Element Bolt for just over 4 years now and have noticed similar differences in what is displayed on the Bolt when I finish the ride vs. what is shown when uploaded to Strava. I don't think the difference has ever been more than 0.2 mph, which is pretty small, in fact 1% of 20 mph. 1% seems like a reasonable level of accuracy as that is what a typical power meter would give you as well. My guess is that it's either a rounding difference somewhere or due to more accurate elevation and/or route information that Strava has gathered. GPS is very good, but sometimes it misses a datapoint or two which could be added back in with some sort of path smoothing algorithm. I should add, I think I remember having the same discrepancy with my Garmin Edge 500.

Just thinking....if the "Analysis" is a time-based graphical average, and if the smoothing affects negative speed spikes (i.e., stopping) more than it affects accelerations (going down hill), because the former are more sudden, (have a higher Fourier frequency) then that would explain why smoothing has a systematic bias to make the graphical average "faster".

What this comes down to is in fact the same as differences between Strava and "average speeds" reported directly on the devices (Wahoo, Garmin, etc.). These are all affected by the way each algorithm deals with stop/starts.

I just find it odd that Strava has two ways of filtering stop/starts out of the "moving time" data that are internally inconsistent.

Programmers use many different buckets to hold values in. Over years as programs get modified, sometimes new buckets are made to hold similar but not quite the same info and a programmer incorrectly grabs the wrong field to use in the various calculations. Some times, the programmers have no idea what the information they are putting on the screen really means.

I'd just put it up to poor Q&A which actually is quite common from things I've been involved with. Sometimes it's a choice of economy because the changes required might actually mean the whole thing has to be tested again as they might break something else or just be too time consuming to re-test.

I once was part of a project that never went live to my knowledge because although the product we made worked perfectly to the best of our knowledge the company that was created for, never could test it completely before the next software release of the OS, databases, or other products used for the entire product. And this was just a IVR that you call in and talked too. But the complexities on the backend the user couldn't see were enormous.

It takes paid Strava to do, but I setup private segments along routes I do a lot to track the speed stuff better. I know where the stops/pauses are. Overall route average doesn't interest me due to the varying nature of it. It's only really useful in a plus or minus 5 to 10min kind of way for being able to choose a route to ride based on how long you have available to you.

The private segments are a better indicator as they auto list prior personal tries, with power used. So you can see how you do.

Average speed is an age old trapping of Strava to worry about. For needing it to plan routes, it's useful as-is without worrying about losing a couple tenths of a mph on a ride.

Funny story, used to have a guy in the A group set his autopause on a Garmin up in such a way it would ignore anything under like 8mph. No idea how you do that. Either way, several of the little hills on the route he'd be climbing slower than 8mph for 30 seconds at a time. His rides were always shorter than everyone else for this reason by an obvious amount. Excuse he gave was we weren't really doing anything if going slower than that.

One thing I do pay attention to for "good route" versus "bad route" is moving time versus total. If there was no cafe' stop but the delta there is large, bad route. If the delta is a few seconds, good route. More riding less waiting.

I don't really use Strava, in Garmin you can make the X axis time or distance, but that's not what I mean. What I mean is this. You have more data points in your file than you have pixels on the X axis on that chart. Each pixel in the chart represents some amount of time, it might just be the highest or lowest value. My suspicion as a developer who fixes bugs for a living is that the average speed shown next to the chart comes from the Y values and they're being summarized incorrectly. I don't have a way to test that hunch, but in terms of how software is put together, it feels pretty likely.

Yes, I got that, and I understand that you know what you are talking about. OTOH, my point, developed disparately across this thread, is that smoothing alone doesn't explain a *systematic* bias, unless "slow" data are preferentially filtered by the smoothing. There is reason (see post above) to suspect that this could be the case.

(Yes, I know I'm beating a dead horse, etc.)
One complication is that the numbers to the side of the plot always faithfully record the same maximum speed as the maximum speed in the summary. They are never smoothed or filtered out. AND, if one looks carefully at the trace of pixels in the plots, those maximum speeds are rarely and possibly never actually plotted. The plotted speeds are indeed filtered. But the values of Max and Avg that appear to the left of the plot don't seem to come from the plots themselve.

This is not what's going on for you, but misery loves company and sometimes birds of a feather... In Garminland there's a 24 hour HR chart, with your movement level and recorded activities superimposed over it. That info comes from your all day data, which they seem to store in 5 minute increments. So my daily max HR is always reported lower than what it actually hit going up the short but punchy hills around here.

What I would do personally if I really wanted to know is open the fit file in Golden Cheetah to get the raw data, bring it into Excel or SQL, and then try to come up with their numbers.

Yeah, I know I can do that. But ultimately, I'm really just doing two typical BF things - expressing curiosity and whining. The "average speed" is more or less a meaningless number, as others have said, and all the more so for rides with start/stops. You will always get different numbers if you don't have a universal method for establishing "moving time".

The summary value is the ones your friends see, and it's always lower than the one in the analysis section. NBD.

I see this too

https://cimg1.ibsrv.net/gimg/bikefor...992a601bfc.png
https://cimg2.ibsrv.net/gimg/bikefor...3b90c6cc8f.png

If I calculate my average speed based on moving time provided in summary (1:07:58) over 24.05 miles I get 21.2mph, remove 30s from moving time and it is 21.4.
The higher analysis value could be from removing movement recorded during full extended stops - a subset of what SF is suggesting.