Slopes Diaries #27: Family-Friendly

Slopes Diaries is my ongoing journey to turn my indie app into a more sustainable part of my business. First time reading? Catch up on the journey so far.

What is Slopes? Think Nike+, Runkeeper, Strava, MapMyRun, etc for skiers and snowboarders.

So I rebranded my premium offerings and reworked my consumable in-app purchases leading up to this season, with the goal of making Slopes Premium as appealing and accessible as possible. Even still after all this work there is one large part of the market I'm still ignoring.

Families! A large portion of skiers just ride with their family when they go out.

Going after this part of my market is not without risk, but I have a a good feeling it'll be worth while. Any of you that offer in-app purchases in your app probably hate this little badge the App Store throws on your product page:

It's the bane of my existence. Customers get their hopes up that they can use the family sharing built into Apple's platforms to share the annual pass inside of Slopes. But alas, like the text (that no one reads) says, they can't. This leads to many emails every season asking how to enable family sharing for Slopes.

Since I control my own server code and store all purchases server-side, I've been able to do unofficial hacks on occasion to hook people up when they've emailed about this, but it has always been finicky and less than ideal.

But thanks to this little badge, and the confusion it causes, I've been able to verify demand for a family plan well before I was even thinking about offering it!

Fortunately I didn't have to look far to find inspiration on how to implement a family plan, conceptually speaking. Apple Music, Spotify, and now Headspace, all offer family plans that are pretty similar: 150% the price of the normal plan with room for 5 or 6 total family members. OK, so Slopes's family plan will be $29.99 and support 5 people, easy enough.

What I did have to spend a lot of time thinking about though was how to mitigate people abusing the plan (like a group of friends). And this part of the planning phase I actually found very interesting.

Only one of those three had an intrinsic way to put the account owner at risk if they over-shared their family: Apple. When joining a family inside of Apple's ecosystem, they make any family member use the family-owner's credit card for all iTunes / App Store transactions. Bloody genius! This means that if I invite Sue, a friend, to join my household as a "family member", I'm now at-risk of paying for her Clash of Clans addition (and have to chase her down for a reimbursement).

Other services, like HBO or Netflix, build in limitations based on usage. They limit people sharing an account by the number of simultaneous streams for any account. This puts the owner at-risk because if they over-share their access, they run the risk of having to miss the premier of The Chilling Adventures of Sabrina because their friends have already maxed out the streams for the account binging it, too.

Headspace and Spotify, however, have struggled to find a way to limit abuse of the family plan. Spotify tried to start cracking down in the US by having users verify their location using GPS and it wasn't received well. Not only did people not like Spotify asking for GPS data, they were also penalizing families that lived apart, like a son at college for the semester. Headspace has a similar household clause to Spotify, but their plan just came out over the Thanksgiving holiday so I've yet to see how they'll try to address abuse.

In the end, I think Slopes is in a similar situation to Headspace and Spotify: I have no real way to introduce risk to the account owner if they abuse it, minus some self-policing of my database. I could require that people on the family plan ride together at least 2/3 the time or something, but a group of friends could easily abuse that and my automated checker would fail. And I'm not about to go so far as to ask for a proof of address via ID or something.

With no clear way to introduce risk, the best I could do was word all my marketing to discourage abuse.  So the subscription in Slopes isn't called the "Family Pass", it is called the "Household Pass." I'll likely do some policing of who is using the household pass from time to time to weed out bad actors, but at this point I'm working under a net-positive assumption: the number of people that abuse the system will be less than the people that use it as it is meant to.

If this assumption proves false, I'll spend more time introducing risk later. Maybe something like the household owner has full permissions to view / delete members' days? We'll see.

Implementing household sharing required a bit of rework on my boot manager because of how I designed the invite system. I wanted to keep things as simple as possible: send a link to a friend (which expires after a few days), they tap it, it opens Slopes on their phone and prompts to confirm the join. All this needs to happen after any onboarding (incase they are just installing Slopes for the first time via the invite) or what's new screens, after any CoreData or code migrations, and then also after Slopes prompts them to register / sign in if they don't already have an account.

*that open button brought to you buy og:image meta tags ;)-

I did this because I want to avoid having anyone worry about asking "what email did you sign up with?" I don't think enough apps leverage universal links and existing web tech to simplify processes like this. I don't have to worry about forcing the users to know each others' account information, and I don't need to force some Slopes-specific process on it like some well-disguised QR code. If the household uses Whats App, iMessage, Hangouts, email, or whatever else to stay in touch, it'll just work. Everyone can send and receive a link.

(Fun fact: don't rely on deep links alone, make them universal. For two reasons. One: if the user doesn't have your app installed, you can still show them something and give them a download link. Second: Gmail un-links ones that don't start with http(s)://, so I had customers complain years ago that slopes:// links weren't tappable. Thanks, Google, for breaking my A tag 🙃.)