Guess what? More integrations! Just the usual π But also more heart rate-related information and more developer-friendly logic for large requests.
Heart rate zone information β€οΈ π©Ί
What?
We've made it easier to capture & analyze heart rate zone information by adding these to our data models, so that workout summaries can contain more meaningful training information, used to power workout insights, and help adapt athletes' training intensity.
How?
Harmonizing heart rate zone data isn't as straightforward as it may seem. WHOOP provides standard heart rate zones 1β5, in 10% increments starting from 50%, but Fitbit provides its own three custom zones, namely "Fat Burn", "Cardio", and "Peak", ranging from 50β70%, 70β85%, and 85β100% respectively. This means that we needed to somehow account for this. We decided to include start and end heart rate % in each possible heart rate zone value to account for this and provide the five standard ones by default. For all providers who don't give these calculations, we go ahead and make the calculations ourselves where possible.
Why?
Our users have been asking us if we could provide more fields beyond "training intensity" that they could use to feed their algorithms to optimize athlete training. We're always aiming to provide as much data as possible. This addition falls right in line with our vision in terms of data access and helps provide richer data.
Get the latest Terra Research reports and insights every week as soon as they're published.
By continuing, I agree to the Privacy Policy and Terms of Service.
Wow, more integrations! π π€
What?
Christmas is coming near π so Terra comes bearing more integrations to all! We've added Cardiomood, Rouvy, and Technogym integrations to satisfy all your connection needs π we made yet another cycling-focused integration with Rouvy, added more gym-specific focus with Technogym, and got more highly accurate data insights with Cardiomood.
How?
Speaking with a few of these companies & figuring out the way around others' APIs, we've built out the infrastructure needed to support the above. We're looking at adding both more integrations & more data types, so check out the other changes this month π
Why?
A lot of our focus has been on diversifying the range of integrations we have in our repertoire and delving deeper into the genres we already have. Rouvy fits in with our cycling integrations, such as our Zwift API integration, Cardiomood with our clinical-grade data ones, such as the Biostrap integration, and Technogym branches off into a new category of gym-focused integrations.
Better processing for large queries γ°οΈ
What?
Whenever a query was made for a period spanning over a month, we would break that request up into one-week segments π & send that to developers' webhooks, regardless of whether there was any data for each given week. Instead, we now aggregate all the data queries internally and send requests to developers' webhooks based on the total amount of data, chunking it by segments of a maximum of 10MB or ten objects within the data list.
Why? π€
We realized our previous system didn't make any sense π€― the initial algorithm meant that many of the payloads sent to developers could be empty and would create unnecessary load & noise on their servers for no reason. Instead, the new data chunking system works around potential limitations on data sent by having a cap on the total number of bytes in one request. This is arbitrarily set at the moment but is something that can be customized on a per-developer basis down the line to suit different needs.
How?
By clever use of multi-threading and spawning separate processes, we create all the data requests in parallel and provide a callback to our task manager, to be executed when all these requests are complete. This way, we aren't hanging any threads while waiting for the data requests to be completed, and we can process the entirety of the data once it eventually gets fetched. Result? Happy developers and happy lambda functions which can get data under 10MB per request π
