FAQ

One of the core features of strive.ai is branded Factors.  In layman’s terms, Factors are variables (X) impacting a target variable (Y).  The Factors we rolled out first are variables impacting your Threshold (heart-rate, bike power and run power).  A specific example is how does temperature impact your 5 minute heart rate?  For most of us it’s likely that higher temperatures lead to higher heart rate readings.  You probably don’t need machine learning analysis to determine this!

In technical terms strive.ai’s Factors are the coefficients for a regression that fits all of variables we collect from your Strava activities (e.g. temperature, cadence, altitude, activity type, gradient, velocity, heart rate, weight, FTP, etc) as X against a target threshold (e.g. 1 minute bike power) variable Y.  The coefficients can be perceived as a weights and each one has two noteworthy attributes:

1. Magnitude:  The larger the coefficient the bigger influence it has on the target variable.  The magnitude is displayed in the center of the donut graphic to give you a sense of how much force the variable is putting on your threshold.  We only display Factors that are material to the outcome (meaning they have a weight > 1).
2. Direction: Coefficients can have a positive or negative impact on a target variable (Y).  Positive direction variables are displayed in the donut in green sections while negative variables are displayed in red sections.  We have two shades of red and green to visually give a sense of magnitude.

Using the simple example of how does temperature impact your 5 minute heart rate?  For me it has a weight of ~2 in the positive direction meaning higher temp leads to higher heart rate over 5 minutes.   Some of the negative forces include FTP which also makes sense since the more fit I am (greater FTP) the lower my heart rate is likely going to be when doing hard efforts.

Another way to think of Factors is feature selection in machine learning terms.  The plan is to offer Factors across a wide spectrum of analysis across strive.ai.   Today we do it for your Thresholds and we’re currently working on Factors that drive Segment Performance target variables (e.g. how does wind speed and direction impact your ability to hit a PR on a segment)?

Another interesting thing is we include Activity Type in the Threshold Factors to see which activity types are pulling out your best performances.  For example for me, Run is a positive driver on 20 minute heart rate while Ride tends to be a negative force on heart rate over 20 minutes.

Here is a list of planned Factors as we march toward coming out of Beta:

1. Threshold Factors
2. Segment Performance Factors
3. Bio Marker Factors (blood glucose, blood oxygen, and muscle oxygen)
4. Body Geometry Factors (height, weight, BMI, fat %, hydration)
5. Bike Fit Factors (stack, reach, etc)
6. Weather Factors (temperature, pressure, humidity, etc)
7. Training Peaks Factors (IF, TSS, NP)

As we collect more and more data we’ll add more and more factors.  Our plan is to make the UI much easier to navigate in a mobile app allowing you to drill into a factor to see it mapped against the target variable to a visual sense of the relationship.  Right now we just show the biggest positive and negative variable.

After we pull over the 8 weeks of history when you sign up we start predicting the hours until your next activity based on the 8 week history.  Typically that means about 24 hours after your last activity but it starts to learn your patterns on when you have rest days, etc.  The sync process will try you every few hours for the first day, once a day for a week and then monthly until it finds an activity.

You can always ask the system to sync you in the next run by clicking the Queue Sync on the Dashboard page.  This overrides your next sync predicted date time with the current time and you’ll be picked up in the next 15-30 minutes.

Our plan is to work with Strava and have them tell us when our users have new activities in the future.  We’ll queue them up and try to pick them up a few hours after your done to make sure you’ve had time to add photos, select the proper gear, etc.  We refresh the data two weeks after the activity to capture some “observed” attributes that aren’t often available on the first day (e.g. number of people in a group ride).

We capture your email address used in your Strava profile for our communications.  We’ve noticed a fair number of users have invalid email addresses in their Strava profile.  You also need to make sure the email account has added bot@strive.ai to it’s safe or approved senders list to make sure our emails don’t get filed as JUNK:)

When we introduce the mobile app version of the solution we’ll likely move away from email to notifications.

This is pretty common at the start given we only pull over 8 weeks of history when you’re approved as a strive.ai user.  We’re capped at 30K hits against Strava / day and we’ve been routinely hitting 18-20K so we’re capping it at 8 weeks for now.  This history gets the machine learning started but doesn’t sufficiently allow it the accuracy out of the gate.  Every 2 weeks, we bring over additional activities and the algorithm gets better over time.

We have seen some athletes with multiple road bikes or MTB bikes which is difficult for the algorithm(s) to classify given the rides are often very similar.  We have a solution to this problem but can’t deploy it without help from Garmin or Strava as the key data elements to this solution aren’t currently available in the Strava API (sensor identifiers).

Give the process some time and let us know if it’s still not accurate after a month or two.  You can also turn off notifications for this should you get sufficiently annoyed with it:)

One cool feature we’re adding now is an accuracy test of each predictor in the system.  Each time we train a new predictor we’ll automatically test it and if it doesn’t achieve some threshold of accuracy we won’t use it.  This will prevent users from getting frequent Gear alerts until the system is good at predicting accurately.

Some have asked why focus on a bike prediction.  Like other data elements we’re capturing in the beta, gear_id is a foundational element for more interesting algorithms coming down the road.  For example, predicting when your tires or chain need to be replaced or predicting if you could top 10 a segment at a certain power will more than likely depend on knowing what bike was used to complete a segment in the past.

One of the most important settings is your weight.  We use weight to calculate average watts/kg on every segment effort.  The segment effort features are fun because you start to understand your watts/kg output over various periods of time based on all of your segment efforts.  We plan to use the segment efforts watts/kg data for some very interesting segment performance predictions near the end of the beta.  Ideally you can arrange to have weight regularly updated through Apple Health to Strava so you can see the impact it has on your peak threshold factors.

One important thing to consider about weight is we’re not seeking to know how much you and your bike weighs.  Our focus is on how much power you can generate for your body weight.

strive.ai leverages your FTP to compute a few variables related to intensity and normalized power.  We also assess your peak 20 minute power against what’s configured in Strava and provide feedback if you’ve exceed it or haven’t demonstrated the threshold is over 8 weeks.

Last but not least, strive.ai wants to know your starred segments for a variety of reasons.  Right now we display recent watts/kg achievements on your starred segments on your home page.  It’s not required but things in the future will likely depend on this nifty Strava feature.  For example, we’ll hoping to deploy the segment performance predictions on your starred segments to start.

Our beta software is primarily targeted at people who cycle or run with power.  The reason for for this is we’re testing algorithms that leverage power centric variables and we’re generating data that will be used in future product features that depend on power.  We also are interested in runners provided they train with heart rate or power.  If you don’t train with power or heart rate you won’t get much out of being part of the beta.  One exception is if you maintain multiple bikes within Strava and want to help test our bike prediction algorithms.

Users don’t need to be Strava Premium although we find our best end user candidates are those who see the value of Premium.