Better understand and handle Strava segment spikes

[mattdsteele]

Every once in a while there are big spikes of rides recorded:

It appears to happen across multiple trails, which makes me think it's not just a batch upload of someone's Garmin. But I'm not sure what causes it, or how to smooth out the data.

We've also seen Strava's numbers actually go down when collecting measurements; I'm guessing they're cleaning up spammy data or something. We currently protect against that by filtering negative values out from the chart (https://github.com/mattdsteele/strava-segment-trends/blob/main/frontend/src/charts.js#L14)

[sbuscher]

Interesting. Will try to poke the interwebs to see if others having same issue.

[mattdsteele]

Discussed with someone else, here's his thoughts:

Had a friend with a subscription look at one of the segments and the rides were not showing up on Strava. I assume if rides were 'private' they wouldn't though. Wonder if there would be a way to 'validate' a segment ride based on looking up the full ride in which that segment was ridden.

[sbuscher]

Found some segment efforts that didn't get counted for the Swanson segment today (7/22/2022). App shows 1 ride total while the strava leaderboard for today shows 4 efforts. Each activity was public so I could confirm each one in strava by pulling it up. One of the riders actually did 2 laps so technically there should be 5 total for the day. The learderboard shown in the image will only show an athlete's fastest lap...

I wonder if these efforts will be forever lost in the count or be reported later, spiking the results?

Somebody posted on Stack about negative and spiking counts. Not confident there is a solution in there but there was a talk of retrying calls and something about a context_entry parameter bug.