RunKeeper Elite Affiliates program shutdown

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:
https://runkeeper.com/partner/affiliate/account

Thank you for partnering with RunKeeper!

Bill Day (@billday) is Platform Evangelist & PM for RunKeeper where he helps developers learn about and use the Health Graph platform.

Advertisements

Validating tracked versus manual fitness activities using the Health Graph API

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 ‘source‘, ‘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 “RunKeeper“, “API“, and “true” for the aforementioned fields, respectively.

Health Graph fitness activity documentation

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 ‘type‘ field.

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.

Bill Day (@billday) is Platform Evangelist & PM for RunKeeper where he helps developers learn about and use the Health Graph.


Launch RunKeeper on Android

In my last post, I showed you how to launch RunKeeper from your iOS mobile app using some Objective-C URI magic.

I also promised a similar capability when we released our next update to RunKeeper for Android. And now the time has come, RunKeeper is ready on Google Play, and away you can go a’launching it from your own Android apps!

To launch the RunKeeper app on Android:

  1. Present the user with a button in your app that they can click to launch RunKeeper.
  2. When the user clicks that RunKeeper button, start the RunKeeper activity using the Intent com.fitnesskeeper.runkeeper.intent.action.MAIN
  3. If the user has an up to date RunKeeper release installed, the RunKeeper app should launch and they can begin tracking immediately.
  4. If the user has an older copy of RunKeeper, or hasn’t installed the RunKeeper app yet, prompt them to install the latest RunKeeper release from Google Play and then they can begin tracking after installation.

We’d love to hear from you and see examples of how you will use this capability, on Android and/or iOS. Please contact us in the comments if you’re doing so.

We might even feature you in an upcoming blog post or our new Health Graph (@healthgraphapi) “Best Practices” guide. And we’d love to hear your feedback on that guide, too!

Bill Day (@billday) is Platform Evangelist for RunKeeper where he helps developers learn about and use the Health Graph.


Launch RunKeeper from your own iOS app

Are you a Health Graph (@healthgraphapi) partner with an iOS app of your own? And do you encourage your users to track their fitness activities using the RunKeeper (@runkeeper) app?

If you do and you want a way to ease their transition from your experience into RunKeeper tracking, we’ve got just the ticket!

We’ve added support for launching RunKeeper on-device from your app. To launch the RunKeeper app on iPhone (or iPad, if a user rolls that way):

  1. Present the user with a button in your app that they can click to launch RunKeeper.
  2. When the user clicks that RunKeeper button, attempt to open RunKeeper using the following Objective-C code:
                [[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"RunKeeperPro://"]];
              
  3. If the user has an up to date RunKeeper release installed, the RunKeeper app should launch and they can begin tracking immediately.
  4. If the user has an older copy of RunKeeper, or hasn’t installed the RunKeeper app yet, prompt them to install the latest RunKeeper release from iTunes and then they can begin tracking after installation.

Here’s an example of how you might implement this, taken from our partner GymPact (@gympact; learn more about GymPact from this previous partner profile).

First up, notice how GymPact places a prominent RunKeeper button on their app launch screen once a user connects their GymPact account to a RunKeeper account (connection is a one time only operation per user).

Once the user clicks that button, GymPact loads this RunKeeper screen to provide additional context before starting the RunKeeper app.

Clicking on the “Connected – Get Running!” button on the screen above tells the user they’re about to open the RunKeeper app if they have it, or that they need to install the RunKeeper app if they don’t already have it installed.

From here they can grab RunKeeper from the App Store if need be and then away they go!

We hope this will be useful for many of our iOS app partners. Please give it a try and let us know what feedback and requests you have.

And Android partners, fear not, we have you covered too: Similar support is coming in our next Android app release. This will be supported via Android Intents. More details once that release is available in the Google Play store.

Bill Day (@billday) is Platform Evangelist for RunKeeper where he helps developers learn about and use the Health Graph.


Health Graph API additions

We’ve made several recent additions to the Health Graph API (@healthgraphapi) based upon partner feedback and requests.

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 /team response 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.

Please let us know if you have any questions about these API updates by leaving a comment here or on this Health Graph discussion group thread (click here to access).

Bill Day (@billday) is Platform Evangelist for RunKeeper where he helps developers learn about and use the Health Graph.


Health Graph API Policy Update

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:

  1. Users should have control over their own data.
  2. 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.

Why change?
 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.

  1. For users, we didn’t provide an efficient mechanism for them to export their data out of our system.
  2. 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.
  3. 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.

What’s changing:
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!