(2014 Update: Just as a heads up that on January 6th, 2014 Strava remedied many of the items I discussed here. While many changes/reverting came sooner in that six month gap since initial publishing of this post, it all became official above.)
I’ve long argued for unfettered access to your data. If you created the data, you should own it. In the case of sports technology, this means that if you upload data to a platform or application, then you own the right to export that data later down the road and interact with it as you please. In the last few years I think the industry has made great progress in this area. Device manufactures have gone to great lengths to largely standardize on just a few file format standards, and in turn, platforms have not only streamlined supporting those platforms, but allowing you to freely and easily move your data down the road.
At the same time, I’ve also argued that sports technology companies should be as open and interoperable as possible. This means that they should offer 3rd party developers the ability to take that data with your permission (at your request) and effectively ‘do cool things’ with it. Hundreds – if not thousands – of applications have done that thus far across a wide range of platforms, resulting in amazingly innovative ideas across the sports technology genre. Even some of the most isolated companies within the space have done that, for example, the walled garden of the Nike+ platform has opened up in the last year to allow more friendly operability.
For those not familiar with Strava, the hugely popular platform has been primarily targeted at cyclists, and enables analytics of your training and racing data. It focuses on allowing you to upload from your own device (or the Strava app) to the site, where it shows you your performance against others within a given ‘segment’ – or basically a small chunk of a course or route.
As we turn to look at Strava and the integration I talked about above, we’ve seen probably the most unique innovation coming out of these 3rd party companies leveraging Strava activities in the form of people taking ‘big data’ style approaches to analytics of data. For example the heat maps and ride analytics coming from RaceShape that I posted about nearly a month ago.
Except, all that great work has pretty much come to a screeching halt for Strava users over the last two weeks with one sweeping change, and then a series of smaller changes over the proceeding months. Let’s dive into what exactly this means for you.
Strava decides 3rd party partners are no longer friends, kills app access
Effective July 1st, Strava disabled access for 3rd party apps to connect to Strava data for the vast majority of 3rd party apps on the market. What are 3rd party apps? Simply put, they are ones developed by other companies to interact with Strava services. For example, the ability for Wahoo Fitness to upload directly to Strava, or for various Android apps to upload to Strava. Applications do this through what’s called an API (Application Programming Interface), or essentially a way to communicate with Strava as a site from a programming standpoint. Virtually every technology platform on earth has API’s (or similar methods) to connect to them, be it Strava, Garmin, Apple, or Microsoft. Everyone. The degree to which API’s are offered varies from company to company.
Over time API’s tend to evolve, like any other bit of technology. Typically features are added over the course of a platform, but occasionally features are removed (deprecated is the fancy industry term for that). When features are deprecated, companies tend to give significant notice as to allow other companies to update systems in time. Depending on the size of the user base, this ranges from months to years (yes, years). That’s simply recognition of the fact that other companies have software release cycles that may not be immediate (after all, quality software takes time).
In the case of Strava, they’ve previously had what they refer to as v1 and v2 (version 1 and version 2) of their API. As many Strava application developers will tell you, this API was far from perfect, but it did the trick. That was until the trick stopped working. Back on May 3rd, Strava posted to their engineering blog that they’d be disabling access to their platform via the v1/v2 API’s (the only way you could access the platform), and in turn, they’d put in place a v3 variant. That disablement would happen less than 30 days later on June 1st.
The trick was, that unlike the past, they’d now be limiting access to who could talk to Strava by requiring applications to register. Requiring applications to register is hardly unheard of, in fact, many other applications do so. Strava reasoned they had to do it to control flow of data, as CTO (Chief Technology Officer) Mark Shaw explained:
“We’ve learned supporting an API takes work and requires commitment from teams across the company. We also knew we had to change the very structure of our V1/V2 API – what began as an internal, hidden “feature” back in early 2010 was being widely used yet we had no good way to measure or control its usage. In some cases it was even being abused, e.g. data was being gathered indiscriminately in bulk. With V3 we’re requiring that applications register and identify themselves, allowing us to properly gauge and meter usage.”
At first, application developers figured this was a good thing – perhaps an improvement to Strava access. So they went ahead and applied for access to the v3 API. Except, nobody heard anything. As June 1st neared, there was still silence from Strava’s side. On May 28th, Strava decided to give everyone breathing room by pushing disablement back to July 1st. Except, in that same blog post came more detail that wasn’t previously there. Strava started off with (bolding mine):
“We strive to provide athletes with the most motivating and fun environment for training and sharing activities. To keep this focus, we’ve had to make a hard choice this year between investing in our features and making the API broadly available….This means that as we roll out our latest version of the API, version 3, we will have to limit the amount of developers who have access to it, as well as discontinue V1 and V2 APIs on June 30, 2013. Libraries, sites, and applications that use V1 and V2 endpoints will cease to work as the underlying API endpoints will no longer be available. By delaying the retirement of V1 and V2 of the API until June 30, we hope to give you sufficient time for you to make alternative arrangements should you be impacted.”
In other words, they’re making a list, and if you’re not on it – tough luck. Now, the second half of the engineering team post included one final line of what would be allowed or not allowed:
“What we can’t allow: Replicating Strava functionality”
Except, there was little clarity on what this meant exactly. After all, there’s bound to be some overlap in any applications in order to enhance the experience. For example, would including the display of a users segment time be considered replicated functionality? I asked Strava for clarity on how they made this determination, and received the following:
“We encourage applications that enrich and enhance the Strava community, not take the community somewhere else. Once we have a team in place around our API program we’ll provide clear guidelines and the right level of support to our developer community (one of the reasons we’re rolling V3 out slowly, so that we can better comprehend its use cases).”
To put this in simple English: They have no idea yet.
Ok, no worries, surely they would be allowing access to all of the developers who have thus far gotten Strava to where it is today. Turns out no so much. Many developers started to get worried as June wore on, and only a handful of applications had received instructions for using the new v3 API. The rest of the applications instead received the sound of silence. When these applications inquired and/or posted questions to the Engineering team blog they were selectively deleted, and then ultimately, comments were turned off entirely. Clearly a case of “Don’t call us, we’ll call you.”
And that message couldn’t come any clearer. On July 1st, applications were cutoff. This impacted almost every application out there except RaceShape and Veloviewer. Even major companies like Wahoo Fitness and CycleOps (PowerTap) were caught up in the denied access front. Wahoo was lucky in that they were able to sort out their access issue within a few days. Unfortunately, other companies weren’t – some with tens of thousands of installs. Here’s the list as I know it of apps that broke on July 1st:
– ipBike (Android)
– Golden Cheetah (Mac/PC)
– iSmoothRun (iPhone)
– Cycling Analytics (Web)
– Chaser (Windows Phone 8)
– PerfPro (Windows)
– DigitFit (iPhone)
– CycloMeter (Windows Phone 8)
– LogMyTraining (iPhone)
– Strava Integrator (Web)
– Giro Your Strava (Web)
– Strava Bulk Exporter (Web)
– Cycling Weekly (iPhone)
– Bryton GPS units (Desktop)
– Fit Leagues (Web)
Now you’d think that these applications would have been notified ahead of time, but indeed, that wasn’t the case. They received an e-mail two days later letting them know their request for application was denied. This would be akin to receiving your University Application rejection later weeks after the school year started.
Here’s what the unlucky companies received:
“Hello (Name),
As of July 1, 2013, V1/V2 API endpoints have been retired. Libraries, sites, and applications using these endpoints will cease to work.
In previous blog updates, we’ve discussed status and access to V3 of our API. As mentioned then, we had to make difficult decisions this year about where to invest time and resources – feature development or a full-fledged API program. We have chosen to focus on feature development at this time and so access to V3 of our API is extremely limited.
Any developer who has been granted access to V3 of the API has been contacted. We will revisit our API program and applications from time to time, but for the time being, we have no plans to grant further access in 2013.
If you have questions or comments, please send an email to developers@strava.com. Given our limited resources, you should not expect an immediate response.
Thanks for your understanding,
Your Friends at Strava”
Yet those were actually the lucky ones. Many apps didn’t get any response back from Strava at all – just further silence. In fact, in some cases users of apps have contacted Strava and asked why the app doesn’t work, only to have Strava tell them (but not the app developer) that they’re app had been cutoff. For example, see this support ticket response that was forwarded to me by a reader when they asked about why they couldn’t upload from the app they were using (the interwebs are full of confused and upset users):
“Unfortunately, at this time we cannot grant the iSmoothRun application access to our V3 API. I apologize for any inconvenience this may cause.The iSmoothRun team has been made aware of the API retirement and should be updating their app to remove the Strava sync functionality. Best, Sarah” – Jul 03 03:48 pm (PDT)
I asked Strava why applications were notified after the disablement, and didn’t really get a good answer, only clarifying that:
“As far as warning, we again were constrained by the nature of V1/V2 as we had no good way to communicate directly with developers who were using it, or accurately gauge the end-user impact of shutting it down, therefore our outreach wasn’t as widespread as we would have liked. Where we did have contacts, we began communicating the changes in January, and later posted updates to our engineering blog starting in early May. Initially we were going to cut-off V1/V2 at the end of May, but extended the deadline to beginning of July.
We felt we had been clear about when V1/V2 was going to switched off, and that V3 access would be limited (see blog posts). Unfortunately, we realized this would put some developers in the painful position of no access to V1/V2 or V3. We aren’t happy about this, but it is our only viable option until we can properly grow our the V3 program.”
No doubt they had contacts for developers, since many submitted applications requesting access – but to say they were clear with developers is pretty injudicious since they didn’t respond to those requests. I then asked as to how they selected which apps would get the magic ticket and which wouldn’t:
“As mentioned above, we have commitments to specific partners and beyond that V3 access is limited to a handful of developers with whom Strava was already actively working. Unfortunately we weren’t a position to accept all requests or even draw a bright line, since so many requests were compelling.”
But even more strange is the stance that they had to even disable the v1/v2 API’s to begin with. Especially given, as Strava explained to me, they don’t even have a team to deal with the v3 API’s that they’ve now put in place:
“When we researched what it would take to offer a fully supported V3 API, we found we didn’t have the resources to do it competently without sacrificing important product features, and business realities dictated we couldn’t do that. Once we have a team in place to support V3 we intend to open access to more developers. Unfortunately, without that team in place, we don’t have a timeline.”
Which really begs the obvious question: Why go to all this trouble to tick off partners and paying customers? The very partners and customers who got you where you are today.
Well, that answer may come from Strava’s plans for being the “number one sports brand of the 21st century”, as they told a magazine focusing on venture capitalists earlier this year. Yet, when you look at all of the worlds best and most widely used web platforms, few of them got there or stayed there by becoming closed to applications.
Even within the sports technology world there’s the clear recognition that interoperability with devices and applications is what drives the ecosystem. In talking with Ben Pryhoda, the Director of Engineering at TrainingPeaks about their API access, they are notably far more receptive to 3rd party developers – even in the face of their own plans to update their API.
“We see 3rd party access to our API as a benefit to our users and is something that we are fully committed to maintaining. 3rd party developers add value in innovative ways, which we encourage. We have been working on an entirely new API that we’re planning to release later this Summer. The new API will require registration and approval, but we believe that our existing business model is sufficient to allow sustainable growth of 3rd party users.”
RunKeeper, the biggest mobile computing fitness brand out there feels the same way, as Bill Day, their head of platforms explained to me:
“RunKeeper is committed to an open Health Graph platform. We welcome third party developers of apps, devices, sensors, and services to integrate with RunKeeper and the rest of the Health Graph community (more than 120 published partners and counting) via the Health Graph API.”
In many ways Strava is very similar to both RunKeeper and TrainingPeaks. All three platforms ultimately depend on user data from other devices, be it phones, or cycling/running computers like Garmin’s.
In fact, when I asked RunKeeper about allowing access to apps that they deemed “competitive” to RunKeeper itself, bill noted:
“In fact there are a number of competitive apps integrated with the Health Graph platform today, for examples please see the various activity trackers listed in our app directory including iSmoothRun, Caledos Runner, and many others. So long as partners respect the user’s right to control the access and flow of their data and abide by the API Policies and ToS meant to ensure that, all are welcome.”
Even what is the likely the biggest sports tracking platform on the web – Garmin Connect (by Garmin), maintains open API’s that allow relatively unfettered access to the platform.
Strava cuts off access to bulk exporting of your data
Perhaps one of the most troubling changes out of all of them is actually the removal of the ability to bulk-export your data. This means that in order for you to remove data from Strava (such as down the road if you want to change to another platform), you’d need to manually export each and every activity manually, one at a time. Obviously, this would take rather long.
While Strava didn’t previously offer this capability natively, other 3rd parties did. This is somewhat similar to how it works on Garmin Connect, where Garmin Connect doesn’t offer bulk export, but does allow applications to do it for users with permission. Some platforms like TrainingPeaks do however offer bulk export within the site.
In talking with Strava, it doesn’t sound like this is a function coming back to the API’s anytime soon:
“We’re looking at ways to introduce bulk activity export functionality, independent of our API, e.g. as a tool on our website. We don’t yet have a specific timeline for its introduction.“
This is concerning because effective last week, you’re realistically dependent on Strava to make good on a promise with no timeline if you want to take your data somewhere else down the road.
A look at changes made to the running side of Strava
While cycling may be where the majority of Strava’s users are, it has been slowly becoming more and more popular with runners. It offered a good set of features to allow the runner to analyze segments against other runners and then dive into their own runs and perform some baseline analysis. No doubt the site always lagged in features compared to the cycling site, but it was by and large, ‘just fine’.
Well, that was until April 11th anyway, four months ago today, when Strava redesigned the running side of the site. In doing so they flat out removed more than half a dozen features, then made another set of features harder to find, and then as the pièce de résistance they changed up the user interface in what I can only describe as the most compelling way to make something more difficult to navigate. No doubt that the look and feel of a given site can be entirely subjective – but even four months later I find myself shaking my head at using the running site versus the quite perfectly functional cycling side.
Of course, it’s not just me – endless numbers of Strava runners have voiced their dislike of the new updates. Strava employees interjected early on to try and defect and clarify all the changes, but since then have been absent in the discussions. To match that, most runners that have given me feedback (virtually every day since) on the running side have matched Strava’s plans and pretty much ignored the new running functionality.
For me, I may upload the occasional run there, but I find any ‘fun’ to using the running side of the site now largely gone. They’ve taken away any of the enjoyment in looking at runs through Strava. For example, why is it that segments aren’t shown on the main page any longer. That’s quite arguably the only reason folks use Strava over other platforms for running (especially now), and somehow, now they’re shoved off to a side page. Somehow, segments aren’t even listed amongst my ‘Top Results’ section. In this particular run I bested a given segment – which is a notable achievement in Strava – yet it doesn’t appear at all here.
Now, this isn’t to say everything is bad. For example, I like the way on the running side I can ‘pop-down’ the Segment mini-dashboard of sorts next to a given segment:
Some of the things are little, but taken in total, are annoying. For example – elevation as displayed within the lap page. Why is the scale 800ft, when I never go anywhere near 800ft? It’s arbitrary and otherwise makes everything pretty much unusable within the chart.
Ultimately I suspect that many of the features will ultimately return, as some already have. But everything to me seemed half-baked. Why push out a surprise new user interface unless it’s done? Nobody was sitting around saying “Wow, I can’t wait for the interface I don’t know existed but will take away most of the run features.” No, instead, users would have been quite happy with how it was with a new interface and associated new features once everything was ready.
In many ways, this seems like it was ultimately just a preview of exactly the sort of “act now and don’t say sorry later” behavior that was seen within the 3rd party/API side.
A kerfuffle on recumbent and aerodynamically friendly bicycles
In what appeared to be another group of users upset with Strava, there’s recently been issues with Strava marking certain segments as invalid if the cyclist was using a recumbent bicycle (the ones were you sit more like a chair). At the time Strava was proactively flagging these rides for removal, with support personal responding to inquiries from confused users saying:
“The reason your activity was flagged is that you are riding an untraditional bicycle. I checked with my manager and we unfortunately have to draw the line at recumbent bicycles. This is in order to keep the leader board as level of a playing field as possible.”
This seemed pretty wonky to me, given they would permit time-trial and triathlon bikes yet somehow disallow recumbent bikes. Even further when you think about it, it’s perfectly fine to organize 100 of your friends into a peloton and cruise along at 40MPH to snipe a segment, but not OK to do so in the lawn chair position. In looking at Strava’s official rules here, there was nothing prohibiting use of recumbent bicycles:
“The Segment Leaderboards for cycling are a place for conventional bicycles only, so that the top Segment rankings are not taken by unattainable, motor-assisted times or from bicycles with modifications including wind fairings or other means of minimizing drag.
Uploading data from a car, motorcycle, e-bike, motor-assisted bike, motor-paced ride or any bicycle that includes any non-human propulsion or pedal-assisted force, and categorizing the activity as a “Ride” displaces data uploaded from a human-powered bike, thus conflicting with the fairness and integrity of the Segment Leaderboards.”
Now, the only nebulous term was the use of “other means of minimizing drag” (which I’ve bolded above). Given that’s what the vast majority of bicycling advancements are designed to do these days, I’m not sure exactly what that statement is attempting to allude to. Perhaps it’s sorta like Supreme Court Justice Potter Stewart’s famous quote on pornography – “I know it when I see it.”
In any case, I asked Strava for clarification on why recumbent bicycles were being banned, and received the below:
“Recumbent bicycles are permitted on Strava as long as they aren’t motorized (there was some confusion within support on this issue).” -Strava CTO Mark Shaw, July 8th, 2013
Since poking Strava on the issue earlier this week and receiving the above answer for this post, it appears that users are no longer having segments removed, nor having issues with support recognizing recumbent bicycles.
(Note: The image I used in this section was just the closest I could find to a recumbent bike within my archives, yet, it somehow sorta makes a point here…obviously, it’s not the type of recumbent bicycles most are upset about.)
The Future
Every company and platform goes through growing pains, and in many ways, it seems Strava is going through similar pains. However, most companies tend to struggle with meeting demand, finding quality employees, or matching competitors. Strava, for all its recent problems – doesn’t really seem to be struggling with any of those issues.
Instead, Strava seems to be struggling by axing relationships with supporting partners and companies, removing functionality from existing users, and upsetting paid users. These problems aren’t ones that immediately cause an upheaval of users, instead, they act as slow catalysts towards migration to other services. An underlying migration that seems to be visibly apparent across a vast array of forums and social media outlets. Like most migrations, it starts small – one group at a time.
It is perhaps almost ironic that one of Strava’s own key major investors talked about future changes in direction this past March, and the potential impact it may have on the user base:
“We haven’t gone down that path yet because it kills some of the brand trust between us and our audience.” -Greg Gretsch (primary Strava investment backer)
If Strava does indeed wish to have its most recent venture capital round be its last, then it’s going to have to stop going down the waterslide of upsetting the only people who will be giving them money: Their paid users who are cancelling subscriptions. Otherwise, it’ll eventually join the ranks of other sports technology companies who ignore user feedback and fail to understand industry partnerships. Few of which are around today in any growing capacity, nor popular any longer.
FOUND THIS POST USEFUL? SUPPORT THE SITE!
Hopefully, you found this post useful. The website is really a labor of love, so please consider becoming a DC RAINMAKER Supporter. This gets you an ad-free experience, and access to our (mostly) bi-monthly behind-the-scenes video series of “Shed Talkin’”.
Support DCRainMaker - Shop on Amazon
Otherwise, perhaps consider using the below link if shopping on Amazon. As an Amazon Associate, I earn from qualifying purchases. It doesn’t cost you anything extra, but your purchases help support this website a lot. It could simply be buying toilet paper, or this pizza oven we use and love.
