As part of our ongoing review of internal programs, RunKeeper (@runkeeper) has determined that our Elite Affiliates program has not generated enough new RunKeeper Elite memberships to justify the ongoing support and engineering effort required to continue the program. Because of this, we have decided to shut down the Elite Affiliates program.
If you are not an existing participant in the Elite Affiliates program, this does not affect you and no additional action is required on your part.
If you are an existing participant in the program, you can continue to accrue Elite Affiliates earnings for one more week, until Friday 4 October 2013, at which time new earnings will cease. We want to ensure you are able to remove any outstanding earnings you have accrued in your Affiliates account. Therefore we have removed the $50 USD minimum balance requirement (i.e. you may withdraw any amount of money you have accrued). Please withdraw your accrued earnings to your PayPal account within the next thirty days, by 27 October 2013, via:
Thank you for partnering with RunKeeper!
One question we receive fairly often from Health Graph (@healthgraphapi) partners is how to validate that fitness activities (runs, walks, bike rides, etc.) read out of the Health Graph platform were GPS-tracked versus manually entered by the user. Rewards partners a la Earndit and GymPact, corporate wellness providers like Virgin HealthMiles, and forward-thinking brands are often keen to differentiate between tracked versus manually entered activities as part of their programs’ anti-fraud efforts.
So how do you tell the difference between GPS and manual activities?
Each item in the Fitness Activity feed has ‘
entry_mode‘, and ‘
has_path‘ fields. These let you determine whether the activity was originally submitted as a GPS-tracked activity. For example, a RunKeeper (@runkeeper) mobile app GPS-tracked run should have values of “
API“, and “
true” for the aforementioned fields, respectively.
If you are interested in including GPS-tracked sources from other Health Graph partners’ activity trackers, you can include them in your ‘
source‘ filtering. In addition, if you need to differentiate by type of activity (i.e. running, walking, cycling, etc.) you can use the ‘
Using these fields should let you skip any activities for which the user simply entered statistics, or originally entered the route map (path) via the Web. For more details on these fields and their usage, please refer to the Health Graph fitness activities documentation, especially the array structures section.
Caveat: The only reliable way to verify whether a user has subsequently edited the map associated with a saved GPS-tracked activity is to manually check each point’s ‘
type‘ (a value of “
manual” means it has been edited). For efficiency’s sake, we don’t save that information anywhere else in the Health Graph platform and we retrieve points only when full data for the activity is requested. That said, we have found that most users do not edit maps after the fact.
Recently added fields include:
source– string added to Fitness Activities, Background Activities, Nutrition, Sleep, Diabetes Measurements, and Weight portions of the Health Graph API; this provides the name of the application that last modified the given activity or measurement; see documentation for details.
is_live– boolean added to Fitness Activities to indicate whether the activity is currently being tracked via RunKeeper Live; note that this field will report ‘
false‘ until at least one GPS point for the Live activity is received (this should occur immediately upon beginning the Live activity, but may be delayed up to several seconds if it takes longer than normal for GPS hardware to acquire a sufficient GPS signal).
userID– integer added to each team member entry from Street Team
GET /teamresponse to allow developers to more easily access team member account details (assuming member has authorized the calling app).
- past activities are now available in a summary form that is more conducive to bandwidth-constrained environments; search for ‘summary’ in the Fitness Activities docs to learn more.
- blood markers – a number of additional markers have been added to the General Measurements portion of the Health Graph API; for the complete list of what’s now available, please refer to documentation for General Measurements and Diabetes portions of the API.
It’s been almost a year since we launched the Health Graph API. We’ve learned a lot, and based on that learning, we’re making some changes to our API policy to make it more user-friendly and more partner-friendly as we continue to grow.
A bit of history
The goal of the Health Graph is to give consumers one place to store, correlate, and understand their Health and Fitness data. Two of our core beliefs around achieving this goal:
- Users should have control over their own data.
- Data integrity is paramount to providing meaningful insights.
As a part of our implementation of these beliefs, a core tenet of our existing API policy has been that when a user disconnected their account from a third party partner application, service, or device, that partner has been required to remove all data that had previously been read from the Health Graph on that user’s behalf. The idea being that by requiring partners to remove that data, we were insuring that user data didn’t become siloed somewhere against their wishes.
While our core beliefs around data control (users should be empowered) and data integrity (everything should be kept in sync) haven’t changed, we’ve learned that our execution on them wasn’t perfectly aligned with the needs of users or partners.
- For users, we didn’t provide an efficient mechanism for them to export their data out of our system.
- For partners, the relationship wasn’t reciprocal – data written to the Health Graph was stored until a user explicitly deleted it, while data read from the Health Graph could only be cached as long as a user maintained a partner app’s authorization.
- For both parties, the policy meant that disconnecting from the Health Graph had the potential to destroy the experience for users with the partner’s application.
We recently addressed the first user concern by providing an easy mechanism for users to export data from their RunKeeper account. We’ve been receiving and implementing great user feedback on the export functionality; please keep it coming!
Now we’re addressing the additional concerns around data retention through an updated API policy and new functionality to support these updates.You can read the entire policy here, but the primary update boils down to this: If a user gives a partner permission upon disconnecting their service from the user’s Health Graph account, that service can retain any Health Graph data they have previously cached on that user’s behalf, indefinitely.
How this change works in practice:
When a user goes to disconnect a service from the Health Graph, they are now prompted to confirm this disconnection in a modal window (see below). As part of this confirmation, they are also given a choice of allowing the partner to keep data previously obtained through the Health Graph.
The user’s choice is passed through as part of the deauthorization callback described here.
What about my (Existing) integration?
Nothing has to change with your application. If you had previously requested permission to read data from the Health Graph, you can cache Health Graph data and remove it when a user disconnects. However, if you would like to take advantage of our updated terms around data retention, you’ll need to make a couple small changes to understand a user’s data retention request via the updated callback, or new deauthorization service mentioned in the previous section. You’ll also need to update your application settings to enable this data retention request.
One more thing…
We also totally revamped our Health Graph support docs. While the aesthetic changes are great, we’re really happy to be including basic search functionality, improved readability, and better access to our developer resources. Stay tuned, because a functional developer console is coming soon as well.
Thank you for all of the great feedback you have provided, which led to these improvements. Feel free to provide any additional feedback in the comments below. We can’t wait to see all of the great integrations that are to come!