Busting the Silos of Personal Fitness Data
The good folks over at the Locker Project ran a quick survey, asking participants about their most important personal data. The top answer was Photos, an answer which made the OpenPhoto people happy.
Notably missing from the survey list was personal fitness data.
Fitness Data
The growing popularity of iPhone and Android smartphones has placed a reasonably capable GPS device in the hands of millions. With the download of a smartphone app, users can now easily tap the power of orbiting satellites to track their movement. The ease and low cost of this type of personal tracking has made it easily one of the most popular methods of self tracking.
With the growing popularity of both smartphones and fitness tracking apps, I believe that many users will soon consider this data to be one of their most valuable digital possessions.
I’ve been using an app called Endomondo to track my cycling, and it couldn’t be easier to use. I run the app while I’m on my bike, and seconds after I hit the ‘stop’ button, my ride is ready for viewing online, complete with a map, statistics, and even an elevation profile. I can even compare my rides to other friends in Endomondo, and even compete in the contest we have going in the office.
The Problem
There is one glaring problem though. My brother also uses a smartphone to track his rides, but he uses an app called MotionX. He and I can’t easily compare our rides or compete with each other. This problem exists because of what we in the data world like to call a silo. Data silos (named after grain silos) are used to gather and safely store data in a single location. My fitness data is in the Endomondo silo, and my brother’s is in the MotionX silo.
I ran into another silo problem when I tried a new app called Strava. When I used the Strava app, my data ended up in Strava instead of Endomondo. Endomondo has my data from the beginning of last year, so using Strava meant that I was missing all my historical data. While it is possible to download a ride from Strava and add it on the Endomondo website, this process is too cumbersome for me to do very frequently.
This silo problem is huge. In a quick review of the Android and Apple app stores, I quickly found over 20 separate popular apps for tracking fitness data. I’m sure the total app count is much higher, should a full survey be completed.
The silo problem is a result of users choosing an app first and ignoring the data management behavior of that app. In a silo busted world, the data itself becomes more important, and we will choose an app with a data management behavior acceptable to us.
Silo Busting
Fitness data is incredibly valuable. Let’s explore some examples.
Imagine being able to try a new personal fitness app, and giving it access to your existing fitness data collected by other systems. The new program would be able to produce reports, graphs, and valuable information for all your past data, making the app easy to evaluate and instantly useful. Imagine switching back to your previous app, and not loosing the rides you tested with.
Imagine opting into a program that releases your fitness data to local organizations. Your city could see aggregated information about which roads are popular with cyclists and runners, and immediately know where to spend money improving sidewalks and adding bike lanes. A local bike advocacy group could compare aggregated usage data against current road safety markings to target those areas most in need of improvement.
Imagine sharing and comparing your rides and statistics with anyone, even someone using a different app to record the data.
Our Current Sorry State
In recent years, data silos have been adding APIs that allow programmatic access to the data they contain. APIs help, but they operate in a ‘pull’ model. Any access to the data requires a trip to the API. Apps needing timely data are forced to poll the API frequently.
Currently only a few of the fitness tracking apps have APIs. Even those that have an API have no way to push that data to any other connected systems. Only one has the ability to have data added to it. None of the systems implement webhooks or any form of event publishing for real-time messaging to other systems.
Two Promising Possibilities
At the beginning of this post, I mentioned both the Locker Project and OpenPhoto.
The Locker Project strives to give people a way to collect their online data into their own personal locker, then give access to it as they see fit. Data of nearly any type can be stored in your locker, and fitness data would certainly fit there as well. The Locker Project’s connector architecture is well positioned to enable extraction of data from fitness silos, via APIs or scraping the information from the site.
OpenPhoto is a project focused on giving users control over their pictures, and even stores the images in a user’s own Amazon S3 or DropBox account. A fitness variant of the OpenPhoto project would likely offer features specific to fitness data. This approach might be able to gain support from fitness silos directly. Because of it’s focus on fitness data, I think an ‘OpenFitness’ system would gain traction faster among the fitness community.
Either of these options will enable innovation in how we gather and use our fitness data.
I should also note here that RunKeeper, one competitor in this space, has created what they call the Health Graph API. While this API is a good start, their attempt is unlikely to gain traction among their competitors. For this reason, I don’t consider it to be a likely solution.
So What?
Think about your fitness data. Choose apps with good data management behavior. Chose open systems. If you see a new system that strives to solve these problems, support it and request support from your favorite fitness apps.
