Feedback on Run Tags and Moving Time/Pace Calculation

Strava,

What is the difference in tagging a Run Activity as one of these Run Types?

1) Run

2) Race

3) Long Run

4) Workout

5) Treadmill

The one difference I see is that by tagging a Run as a Race, Strava modifies the Pace to be the actual Pace instead of the Moving Pace. On all other tagged Run Types, the Moving Pace is used for mile splits (but labeled as Pace). Also, the Elapsed Time is shown at the top of the overview in large vs small font and presumably calculates the pace from the Elapsed Time.

 

1) I don't see any KB Articles on Run Types, so please elaborate on them

2) Strava should not be using Moving Pace on Run mile splits - its misleading and not accurate. If Strava wishes to display the Moving Pace vs the actual Pace, then Strava should label it as such.

3) I should not have to switch my run to a Race just to see the actual Pace mile splits.

4) IMO Strava should not even use Moving Pace, its not useful. But if they wish to use it, it should be labeled so people are not confused if it is a Moving Pace or the regular Pace. By tagging a run as Race vs Run we are somehow suppose to know that the Pace has been changed from Moving Pace to Pace? Just label the Pace always and show both. For mile splits, GAP and Moving Pace (labeled as just Pace, misleadingly) are of no interest and the true Pace is not shown (unless the run is tagged as a Race)!

 

Strava - please straighten out your usage of Moving Pace. We need to see our real pace for mile splits - not a massaged # that looks great even if we stopped at every drinking fountain.

Also, on the Run overview page, the Moving Time shown is not the actual Moving Time, its the Time. Garmin defines the following times; Time, Moving Time and Elapsed Time. Strava is overloading the usage of Time and Moving Time. The label on the web page is Moving Time, but the value is Time. Change the label to Time. And in the mile splits, you do the opposite, label the pace as Pace when its really the Moving Pace. Both of these are misleading, and in the case of mile splits do not even have the actual Pace per mile. iPhone App displays Pace as Moving Pace with no option to see the actual Pace and does not label the Pace as Moving Pace either. This needs to be fixed too.

Quite simply - label the correct values - and show the real mile split Paces. Label Moving Time as Moving Time. Label Moving Pace as Moving Pace. Label Time as Time. Label Pace as Pace. And show the actual mile split Paces (not moving pace) despite how the Run is tagged.

 

connect.garmin.com labels these values correctly and includes both regular and moving times/paces.

 

 

 

96

評論

217 條評論
  • 正式評論

    There is a great, related discussion on specifying moving time or total elapsed time for activities. Please feel free to vote and leave your feedback there as well. 

    評論操作 永久連結
  • Strava Users - 

    To elaborate and test what I mean by point #2 above, that Strava is misleadingly displaying Moving Pace mile splits vs actual Mile Splits - try this experiment:

     

    1) Run 5 miles on level ground @ a 9:00/min pace for each of the 5 miles - exactly

    2) Keep watching your GPS watch to ensure you are running at a consistent 9:00/min pace

    3) For miles 1, 2 make sure the watch splits are at 9:00 min miles

    4) At 2.5 miles, stop, dead still in your tracks for 2 minutes, then continue and fniish the 3rd mile at a 11:00 pace according to your GPS watch

    5) Continue with a consistent 9:00 pace splits for miles 4 and 5.

    6) Upload to Strava and view your Mile Splits

    Strava will show your miles splits as ALL 9:00 paces even though you were stopped still for an entire 2 minutes. They should show, mile 1: 9:00, mile 2: 9:00, mile 3: 11:00, mile 4: 9:00, mile 5: 9:00.

    Now, change your type of Run to a Race. Mile Split 3 should now read 11:00 pace. Strava changed the splits from Moving Pace to Actual Pace when labeling the run as a race. Regardless, the splits are not labeled as Moving Pace or Actual Pace, leading to confusion.

    Odd - isn't it? Especially with ZERO labeling of using Moving Pace vs Actual Pace - and an inconsistency of using one or the other without notifying users!

    Strava, this is VERY bad, you need to SHOW AND LABEL BOTH ACTUAL PACE AND MOVING PACE! YOU ARE MISLEADING RUNNERS ON DATA FOR WHICH THIS SITE IS ENTIRELY BASED. NO DATA IS USEFUL IF IT IS NOT ACCURATE, CONSISTENT and LABELED.

    Strava - please respond...

    3
    評論操作 永久連結
  • I submitted a support ticket to Strava to respond to this thread and issue that Strava uses Moving Pace for Mile Spilts and NOT YOUR ACTUAL PACE.

    I escalated the issue to the Customer Support manager, Travis Robison, and this is his response:

    "At this time we have no plans to change the way we display pace. We feel that this the way the vast majority of our runners want pace to be displayed."

    - Travis Robison

     

    Obviously, based on this thread and another thread with customers responses, this is incorrect. people DO want their REAL PACE - Strava's response is to tell their customers essentially - "no that's not what you want." 

     

    Strava - listen to your customers. We want the REAL PACE MILE SPLITS, REAL TIME, AND REAL AVERAGE PACE - NOT MOVING TIME/PACE ALTERED BY A STRAVA ALGORITHM. 

     

    If you are reading this and agree Strava should supply the actual data of pace and time collected on your $400 Garmin watch, submit a customer support ticket and refer them to this thread.

     

    Again Strava users - unless you have marked your Run as a RACE, the MILE SPLIT PACES ARE INCORRECT! Repeating the same runs, there is no way to compare your pace as it has been altered by Strava. For those of us running beyond 10-20 miles and on trail hills, the Strava MOVING PACE ALGORITHM alters your actual pace - as it does any time you stop or slow down for any reason. Run a marathon, you don't get credit for for sitting on the side of the road at a drinking fountain - so why does Strava make your pace faster in your training runs???

     

    2
    評論操作 永久連結
  • This is a disgrace!
    Ow, my mistake, sorry. Let's not have pauses in our communication either.
    Thisisadisgrace!
    #movingtimeisuseless

    2
    評論操作 永久連結
  • Please listen to the comments of your users and make the changes requested.

    1
    評論操作 永久連結
  • Well given Elle's recent response, I think it's quite clear that as things stand the situation is not going to change.

    I think it's disingenuous of Strava to process data this way by default and it's only when I started to analyse the large discrepencies in my lap times between my Garmin and here that it all finally came to my attention. I would encourage everyone who has friends or clubmates that aren't aware of this process to enlighten them and encourage them to post their feelings on this thread. It's only when a support thread like this reaches several hundred responses that Strava will actually take any sort of notice.

    For the most part I think Strava works brilliantly, but this is such a catastrophic misappropriation of data analytics that it almost makes the whole run function unusable. For the meantime, I'm just going to be tagging the majority of my runs as races (even though they're not) just to get some comprehensible data out of the site.

    1
    評論操作 永久連結
  • Well, this still goes on. I have python code which takes a gpx file and calculates an improved estimate of moving time from that data so that it matches what both my Garmin and RideWithGPS app give me within seconds. Hence, avg speed is also aligned. I'm not sure why Strava cannot get this right. The code simply

    1. Parses the gpx file and converts (lat, lon, elev) to (x,y,z) in ECEF (earth-centered-earth-fixed coordinates)
    2. Computes distances based on the sampled times
    3. Interpolates the distances to a fine mesh using cubic spline interpolation (not-a-knot)
    4. Computes velocities based on the smoothed distance data
    5. Drops times where speed < stoppedMPH (I used 2.0 mph, similar to Garmin pause settings that I use)

    When doing this, the moving time and average speed matches my Garmin device and RideWithGPS within seconds. When I download the gpx file from RWGPS and upload to Strava (a service syncs my RWGPS, Strava accounts automatically this way), I get an extra ~5 minutes and avg speed drops accordingly by about 0.4 mph on Strava. I have observed this for years [as evident by this SUPER-LONG thread], which is why I just wrote this very simply python application. PLEASE, Strava, take my code and fix your moving time calculation. It aint rocket science. Here is a link to the 3 source files - run analyzeGPX.py to show how it works. Compare it to https://www.strava.com/activities/780133812, which only has a 17.2 mph average. I'll even let you use my code, although I usually charge a fee for mathematical consulting ;) You can access the code, examples, and figure below at this cloud link.

    1
    評論操作 永久連結
  • As a follow-up, since the python code I wrote worked off the .gpx files, I also put together the corresponding code for .fit files, which are saved in the Activities/ folder on my Garmin Edge 800. The source is in the same folder if anyone wants to grab the code and run analyzeFIT.py and compare for themselves. It was a little simpler as the .fit files contain a processed speed (m/s). Still, I interpolated that to a fine time mesh prior to thresholding by the cutoff speed. Compare that run to the .fit upload to Strava at https://www.strava.com/activities/781261972 and you will see that Strava overestimates the moving time by about 4 minutes and so avg speed is about 0.2 mph slower.

    1
    評論操作 永久連結
  • Strava got back to me with this "There is nothing else I can do at this time". Just give up on Strava and go to other platforms.

    Or you can try voting this thread up so we get some numbers up. Open up new bugs about this, all of you! Flood them about this issue. It is rather embarrassing how they cannot handle this very basic and simple issue.

    1
    評論操作 永久連結
  • Lawrence Jones

    You misunderstood. I didn't mean to suggest that WE run scripts. I just thought that STRAVA needed to see that it's pretty easy to improve their moving time calculation algorithm to match other algorithms (for example, the RideWithGPS app) and Garmin devices (like my Garmin Edge 800). They evidently need some help. The algorithm in my code, which STRAVA is free to adopt, works just like the auto pause function on some of my bike computers, where moving time is not incremented below a certain speed. We members "could" set that speed threshold in a Strava profile setting, just as I can on some bike computers. It helps to smooth the data onto a fine mesh using interpolation to provide finer time granularity in determining how much time is spent "at rest." Since GPS measurements have a stochastic component, the actual data is "never" at rest. I'm not sure how many folks at STRAVA even work on algoritms like this, let alone actually follow this thread. This unbelievable thread may be so long that any suggestions for improvement go unnoticed. It IS embarassing that I only spent a couple hours knocking out the code, though.

    1
    評論操作 永久連結
  • Seriously. http://www.strava.com/activities/85512003 I ran a1:30:06 1/2 marathon, which is a PR and all.... And my friends start flipping about the 6:23 pace that Strava showed. (Which would've won me the race.)
    0
    評論操作 永久連結
  • Agree completely.  Already wrote to Strava customer support about it.  Competing apps have auto-pause on.off settings.  Strava has nice features that could make it preferable to those competing apps but if it can't keep accurate time then it's altogether useless.  As it is, I use Runkeeper which has auto-pause setting.  Premium version costs less than half of Strava per year.  Get with it Strava—it's not rocket science to add an on/off switch in the settings.

    0
    評論操作 永久連結
  • I've given up waiting for Strava on this issue.  Maybe Strava's market is people who want to exaggerate their accomplishments.  I appreciate the above comment that 10 sec. in 1 hr. is not significant, but what's the point of adding any inaccuracy?  I can't use "race" because it's not on the free version and I won't upgrade if the free version doesn't work right.  So I've switched to RunKeeper and upgraded to the Elite version (which is only 1/3 the cost of Strava anyway).  Bye bye Strava.

    0
    評論操作 永久連結
  • It is all very disappointing, I have been setting any workout that has this incorrectly altered moving pace to race as a workaround.  But I shouldn't need to.

    It really should be just the device or app that pauses activities, that is what the pause button on the watch/app is for.  Not the website, or at least be an option to turn it on/off.

    0
    評論操作 永久連結
  • As a software engineer, it is a poor design strategy (simply wrong) to overload data fields, as Strava is doing with the use of the field for the "Pace" column under Splits (using the label "Pace" while populating it will data from either "Moving Pace" when the event is categorized as a non-Race, or populating it with data from "Pace" (the real/actual one) when the event is categorized as Race.) and with the "Moving Time" field in the top right of the web page labeling it "Moving Time" but populating it with different data based on if you had clicked the "Lap" or "Start/Stop" button on your device; if those buttons were not pressed, the data of Strava's Moving Time algorithm is used, if you do lap or auto-lap on your device then "Time" data is used, effectively making the label "Moving Time" obsolete and simply wrong (its not the Moving Time).

     

    So to re-cap: Strava - you use the "Moving Pace" DATA for the "Pace" FIELD, and use the "Time" DATA for the "Moving Time" FIELD. Wrong and bizarre. 

     

    The simple answer Strava is to NOT overload your field with different types of data. Data is data. Call it what it is. Label it correctly. In this case, to make everyone happen, don't overload fields, just include all the data. Why hide and change data and label it incorrectly?

     

    Simply do what Garmin does, include all 3 types of data/fields; Pace, Moving Pace and Average Pace. Time, Moving Time and Elapsed Time. Stop changing data of fields based on its categorization! Just label it what it is! Log into your account on connect.garmin.com to see how they include all data and do not overload fields.

     

    So everyone is clear on terminology, please refer to the proper definitions of pace and time supplied by Garmin:

    https://support.garmin.com/support/searchSupport/simpleCase.faces?caseId=%7Bb6dded60-28a4-11e0-d39a-000000000000%7D

     

    Quite simply, Strava is not displaying this basic data of pace and time correctly and confusing their paying customers as well as making them think they are running faster than they really are.

     

     

     

    0
    評論操作 永久連結
  • Was wondering why when my watch said I ran a 7:20, strava would say 7:40, I think I will use garmin connect for split data from now on.  Sometimes strava says you are faster and sometimes slower than the watch, which is useless.  Don't know if this was recent as with my 405cx, it seemed to line up with the watch but not on my fenix.  Overall distance is usually off a bit too.  I tried changing them to race and that didn't help either, still incorrect data.  I too am a software engineer and it wouldn't be hard to just show both moving and regular pace splits.  At least elevation is accurate.

    0
    評論操作 永久連結
  • I can confirm that what Strava displays is just simply wrong (I agree with the tech theory just above about the GPS points). I can confirm this because when I go for a run I never ever stop till the end of my run, and Strava always shows my "moving" pace as faster than I actually ran. I never stop because if I get to a road junction I will either run on the road and annoy the cars, or if the probability of getting run-over or dying is too high I will go round the corner instead and cross the road when its clear and then double back on myself.

    Strava - Please fix this... I'm so desperate to improve my PBs, sometimes I look back on my runs and actually believe the lies its telling me... I will of course get a nasty shock next time I actually do a race.

    0
    評論操作 永久連結
  • The default setting for running should be ACTUAL pace. I think defaulting to moving pace for cycling is sensible and safe to avoid encouraging bad behaviour at lights etc. Plus it means you can take the breaks you take over long rides without remembering to pause the Garmin. But for runners it is totally wrong.  This needs a fix. I came to Strava from Runkeeper because I cycle and run and would prefer to use a single app. Personally I will be looking elsewhere if a solution is not coming. 

    0
    評論操作 永久連結
  • I'm sick of asking Strava to correct my data. What is wrong with them? They clearly have something wrong with their algorithm. I'm a runner, when I run I simply what the elapsed time and splits, it's not difficult. OK, I can change to 'race' and it labels as elapsed time on the overview, but everyone else, facebook etc, still sees the incorrect moving time. I've just done a 5k race in which, according to Strava I must have had a complete blackout and sat down for a nearly a whole minute.
    0
    評論操作 永久連結
  • Thank you for sharing your feedback about our run analysis and calculations. We truly do appreciate your input, and I've already had a few conversations with our development team regarding this topic. 

    Unfortunately, similar to Travis's response in November, we don't have plans to modify how we display and analyze time for Strava runs. Of course, this is never set in stone, and seeing how this thread continues to gain support we may reconsider in the future. What we do hope to accomplish is to make the labeling of our Time fields more clear and provide more accessible glossaries and definitions for some of our data fields to help with any confusion. Documentation of this information is very important to us too. 

    If you have any specific questions about why we choose to analyze run data in this way, please post that here. I'd be happy to pass along a bit more about our design process around run time. 

    To help clear up any confusion, here are some notes I've worked on with our development team:

    - Runs tagged as a Race will default to Total Elapsed Time for all calculations; average pace, splits, total time, analysis charts, pace analysis, etc. Hopefully this is pretty straightforward and does not provide any data issues for those of you who wish to view the total time data. 

    - Runs tagged otherwise (Run, Long Run, Workout) will default to either Timer Time or Moving Time depending on what is available. There is no explicit labeling between the two, but based on the below information you should know which time analysis Strava is choosing:

    • Timer time represents moving time as calculated by the manual use of the stop/start button during recording whenever you are resting, or the pause button from the Strava mobile app. This also means that any auto-pause features are turned off. However, the only way Strava can read your timer data is if you upload from the Strava mobile app or via the native .FIT file from your GPS device (Garmin for example). GPX and TCX file formats do not contain timer time data. Strava will default to the time calculation if available. 
    • If you do not fall into the above bucket, Strava will calculate moving time based on GPS data. To note, if you find your Moving time splits confusing, remember that GPS data is not 100% accurate and can occasionally record short amounts of time that may appear as resting to the Strava algorithm. The support team has some behind-the-scenes analysis tools for this, so if you have a question about your GPS-calculated moving time please submit a direct support ticket. 

    Thanks, and hope this is helpful! 

    0
    評論操作 永久連結
  • Thanks Shawn, for adding your feedback here!

    0
    評論操作 永久連結
  • Adding one more in support of making pace based on "total time" instead of "moving time" the default. Or maybe having it that way for something other than "race". At the very least, can you bring back the "pace vs. time" display (like how you can still get in rides) instead of only the "pace vs. distance" display? It makes intervals or track runs not make any sense if I can't view it with time as the x axis.

    0
    評論操作 永久連結
  • I would prefer Strava to use whatever was used on the device recording the activity so if I tell my Garmin to not use auto pause, Strava should follow this. The workaround of labelling an activity a race so elapsed time is used is a method to use in the meantime but my major problem with this is the web based page of Strava now shows my correct race time but the mobile app still shows moving time and is displaying to my followers an inaccurate time. Please, please at least make all the versions of your product the same. Thanks
    0
    評論操作 永久連結
  • Hi Neil - we're not aware of this problem: If a run is tagged "Race" the same time data should appear on Web and Mobile. Do you have the most updated version of the App? Can you confirm that you're seeing this problem? Thanks

    0
    評論操作 永久連結
  • Hi Elle. I have version 4.0.1(1631) showing on my iphone. The activity in question is the one on Saturday 5th April and I tagged it as a race on the web version and this is showing on my iphone app but still it it is moving pace being shown on the app vs elapsed time online.

    0
    評論操作 永久連結
  • I don't think it's Strava's responsibility to be adding in functionality to cater for everyone's individual devices, or to copy Garmin's nomenclature with regards to Time/Elapsed Time/Moving Time/Timer time etc etc etc.

    What is their responsibility to do is to present data in a way that is both accurate and consistent between activities and the current system fails in both regards. With regards to accuracy, the current widespread use of 'Moving Pace' is woefully inaccurate as Guillaume explained nice and succinctly above; this is particularly evident in lap splits and basically makes them completely useless. With regards to consistency between activities, whilst the algorithm 'Moving Time' used to process sets of data may be consistent, the data being fed to them is not; the use of different devices, quality of GPS signal, amount of time spent in poor signal areas (e.g. under tree cover) all have a drastic effect on how much of your run is calculated as 'Moving Time' and thus on your pace.

    The use of 'Moving Pace' is ideally suited to workouts such as intervals, NOT to every single activity, where actual pace is far more appropriate. It should be the exception not the default and thus, in my opinion, moving pace should be applied when you tag an activity as a workout and actual pace used as the default for every other run type.

    0
    評論操作 永久連結
  • Is this a joke? Uploaded Garmin foreunner 110 from 5k race today. True time, i.e. elapsed time, was 19:31, moving time 18:46 (moving time is shown when sharing, even when labelled race). Unless I had a complete black-out, I don't think I stopped. Totally agree with last comment, moving pace should not be the default, particularly when it is always calculated woefully incorrect.....I DONT CARE ABOUT MOVING TIME WHEN I'M RACING......although a time of 18:46 would be nice!

    0
    評論操作 永久連結
  • Unlike some of the other posters, I have no problem with moving time being used as a basis for calculating paces etc.  You can always flag a run as a race to get round this  Unfortunately, I think the calculation that Stava uses for moving time is flawed. 

    An example to illustrate.

    Roy who I follow did this run recently:-

    http://www.strava.com/activities/132139104.  He currently has it flagged as a race and it shows an average pace of 18:17 mins per mile.  This is because he is returning from an injury and had to walk parts of the course.  If he changes the the run so that it is not a race,  It now shows 7:44 a mile and gives him a world record beating pace of 40 seconds for 400m!!

     

    The reason for this (I believe) is twofold. 

    1) Walking should still be classed as moving time so the threshold for moving is set too high in the Strava calculation.  I have a Garmin Forerunner and I set auto pause to kick in whenever I drop below 20 minute mile pace as this seems sufficient to record stops correctly.

    2)   If walking is not included in the moving time then it should not be included in the moving distance. Taking the time out without taking out the distance results in sections being done in 0 seconds which results in overall world record pace calculations!

     

    As I have not seen Strava's calculation, this is pure guesswork on my part but it seems like the most likely reason for all the discrepancies.

     

    It would nice if Strava could have another look at the calculation and see if there is indeed a bug here. 

    Other than this, keep up the good work, I am really enjoying using this site and may upgrade to Premium in the future.

    0
    評論操作 永久連結
  • I believe Strava were on the brink of removing the 'Best Estimated Efforts' (such as the 400m WR you mention here) altogether. They're inherently inaccurate because of the (sometimes poor) quality of GPS data being fed into Strava and they highlight in a very obvious way the limitations of such analysis based on dodgy raw data. That is fair enough. I think everyone takes the 'Best Estimated Efforts' with a pinch of salt, especially so for the shorter distances.

    But what your case highlights so well is the absolutely woeful manner in which Strava calculates moving pace. I very much doubt there is a bug in their formula. Again it's a complex situation having to deal with with variable types and quality of data being fed to it, that come from a variety of scenarios, all of which have to be accounted for. This is why it is so unsuitable for routine analysis of run data, it is neither accurate nor consistent.

    0
    評論操作 永久連結
  • I am now flagging all my runs as races so I can see the actual pace/time. And I agree this is not ideal. So I'm yet another user who supports a change to using Total Elapsed Time.

    0
    評論操作 永久連結

登入寫評論。

不是您要找的?

新貼文