Building Activity Tagging With an Iterative Approach
By: Jason Van Der Merwe
Tags: Engineering, Mobile, Growth, iOS

Designing an MVP within time constraints

Before spending a lengthy development cycle building the ideal feature, we needed to rapidly validate our hypothesis in the real world. We only had two weeks of development time to build and ship an MVP (minimum viable product) before moving onto a larger project that was slated to begin at the end of October. The first step was designing a simple experience that we could build within these time constraints.

This feature has two audiences: there are the senders of the activity tags, which we call the inviters, and the recipients of an activity tag, which we call the invitees. There are two fundamental experiences for inviters: tagging another Strava athlete in your activity, or sending the activity tag to someone who isn’t on Strava yet to encourage them to join you on Strava. As a team, we decided to simplify the inviter’s experience and combine the experience of tagging within the Strava network and externally so that we would only have to build one inviter experience. To make this all work, we leveraged Branch Metrics link technology and relied on generating URL links that mapped to information about the activity tag. When an athlete wanted to tag their friend, we created one of these magic URLs and then that athlete sent that link to their friend with a message like “Hey we did this activity together, here’s a link so you can copy the activity to your own profile”. Those links would deeplink invitees on mobile to their friend’s activity and they would be able to accept the tag and copy that activity to their own profile. If an invitee wasn’t already a Strava athlete, they would be directed to the app store, and then on download, see a welcome screen encouraging them to sign up and accept the activity tag.

The inviter experience we built wasn’t very fancy. We leveraged the iOS and Android share trays and allowed athletes to send simple links that contained their activity tag. On the invitee side, we built a very simple banner on the activity pages when an athlete tapped on a link and wanted to accept an activity tag and a simple welcome screen for new users. The most complex software to build was the server side creation of the new activities when someone accepted an activity tag. Additionally, we reserved time to build security around the feature so it couldn’t be misused.

Analyzing the results of the MVP

While we were fairly certain that Strava athletes would use this feature to tag other Strava athletes, we really wanted to see whether this feature would drive new registrations. Our hypothesis was that activity tagging would drive more invites than regular invitations. We launched to 90% of athletes, with a 10% hold out group to ensure we understood the effect of this new feature (like whether it hurt other metrics like invites via other methods). Because the feature was accessible on a very popular screen in our applications, the activity screen, we quickly got a lot of athletes using it. The initial results were encouraging: athletes sent five times the number of activity tags than regular invites and none of our core metrics were hurt by this new feature. Since our goal was to build a feature that performed better than regular invites, we considered this a win.