SaaS companies typically spend money upfront to acquire customers, then have to wait many months before recurring revenue makes up for the initial cost to acquire. Revenue from a customer is defined equally by the length of time they stay and the size of their monthly payment. This is a common problem: you spend a lot of money upfront to acquire customers who are only valuable if they stay for a long time. We are betting on our future product with our current cash. Anyone building a SaaS company faces this problem, but if growth erodes profit, how do we separate the viable businesses from the bottomless money-pits?

In this post we will explore the industry benchmarks for acquiring customers. I’m going to do this using Brett Victor’s Tangle library. Drag the blue numbers left or right, and adjust them until they reflect your company.

Monthly Average Revenue Per User (ARPU)

So let’s assume a simple case – you have a software company with 100 customers, and you make, on average $3000 recurring revenue per month. This means you have $30.00 Average Revenue Per User every month. That’s relatively straightforward. There’s also expansion revenue but we will bundle that into churn for simplicity.

Monthly Churn

Your churn is a measurement of how many customers leave your product. Let’s say that 90days ago you had $2000 monthly recurring revenue. If we ignore the new customers, those customers from 90 days ago now account for $1800 remaining monthly recurring revenue. This would mean you have 3.70% monthly churn and 45.06% yearly churn.[1]

Lifetime Value Calculation

We can divide 1 by the monthly churn rate to get an idea of how many months your customers would be expected to stay. So for our calculation, 1 / 3.70% monthly churn = 27.0 months of expected revenue. Earlier we calculated that the average customer spends $30.00 per month and now we see the average customer stays for 27.0 months. Multiply these two numbers together and we see that an average customer would have a $810 lifetime value.

Spend Less than 1/3 of LTV

A simple and prevalent model is spending 1/3 of your customer lifetime value [2]. Using the numbers we calculated above, we would have a $810 LTV divided by 3 for a $270 Maximum Customer Acquisition Cost. The idea here is to reserve 2/3 or your gross revenue for product development, operating expenses, taxes and profit.

Spend less than 12 Months of Revenue

Another common way to think about this to spend a set number of months income on customer acquisition, usually 12 months or less [2]. So if your customers spend an average of $30.00 per month, you spend 12 months income or less on acquisition. This would give us a $360 maximum CAC. This model forces you to think of acquisition costs as money that you recoup over time, and it re-frames churn as lost money. This can have a profound effect on the way you think about churn.

The SaaS Conundrum – Profitability is Elusive

If you spend 12 months income to acquire a customer, you are in the red for 12 months. Losing that customer any time in the first 12 months should be treated as a failure. In the last few years, we’ve seen an increase of SaaS companies offering discounts yearly pre-payment. This is for good reason, SaaS companies typically face a cash crunch as their growth accelerates. 12 months is a long time to wait for revenue to catch up with spending. Couple this cash crunch with the common expectation of exponential growth and you can see why startups are typically not profitable for many years.

Spending 1/3 of LTV and recouping the cost of acquisition within 12 months are just benchmarks. The reality is that you know your startup better than anyone. These benchmarks are meant to get you started but growth is unique for every SaaS business. Your model will grow in complexity as you learn more about your market and your best growth channels.

Get in touch in the comments if you have any feedback or additions.

[1] This is a simplified churn calculation, you should read Steven Noble’s Definition of churn , Jason Cohen’s post on the topic and Joel York’s analysis for more information. Churn changes as your product improves and competitors enter your market. Churn is a deep concept and building multi-year models around it is a risky way to run your business.

[2] Both the 12 month benchmark and the 1/3 of LTV benchmark come from from David Skok’s excellent article on Sass Metrics. They have become common benchmarks but every startup is unique. For a nuanced analysis of the topic take a look at David Kellog’s post on CAC ratio.

Apple recently announced that they will be releasing a new “Sources” tab in iTunes Connect. iTunes will now track the referring url and an optional campaign ID, passed in as a url param. This is a huge improvement, and it will work great for developers that build exclusively on iOS.

The problem is, iOS doesn’t dominate the market anymore. Most developers need to build for both iOS and Android. If you’re building on both platforms, having your data in an iTunes silo is hugely problematic. We’re going to explore how attribution works, why it’s a problem on iOS and what apple could do to solve it (hint: Android has already done it).

The problem with mobile attribution

If you sell things on a website, there are excellent ways to see what you’ve gained for all that effort you put into marketing. You can easily see where people came from. The web has HTTP referrers built right into the protocol, and in the cases where that doesn’t work you can use UTM tags or campaign-specific landing pages.

Knowing what works is critical. Even if you’ve built something people want, you still need to get their attention and show them what you’ve built. When resources are limited, dumping what little you have into the wrong channel or the wrong campaign can have real consequences. Knowing matters.

When you put something on an app store, you don’t have any say over the tracking data they give you. You don’t get to see where people came from or what params were appended to the url. It’s very difficult to know where you should spend the limited resources you have. Until recently, this was the plight of every app developer publishing to an app store.

How it works with Android and Google Play

Google has come up with a simple, open solution to this problem. They pass the params from the app store URL into the app when it is first launched. Developers can now see where their customers came from. It’s a simple solution that takes advantage of best practices on the web. It works for every ad platform, it doesn’t compromise our privacy, and it works for every use case we can imagine.

Apple’s closed garden approach

Apple’s solution looks similar on the surface, with one important exception. Apple passes the params to their own tracking system but doesn’t make them available to the developer. Let’s take a look at how it works:

https://itunes.apple.com/us/app/twodots/id880178264?pid=facebook-ads&cid=spring-blast

This is a great start but without the raw params, developers can’t see where actual users came from. Without the ability to tie the data together, developers cannot do a few really critical things. Let’s explore what those things are and why they are important.

Advantage to passing params: Deferred Deep Links

Here’s a scenario: you’re browsing Amazon.com on an iPhone looking at a fancy new coffee grinder. A message pops up, letting you know that Amazon has an app. You download the app, open the app, and get dumped into a blank slate. There is no reference to coffee grinders. “That’s foolish,” you say “shouldn’t Amazon know I was looking at porlex coffee grinders?”

Amazon doesn’t know because there is no (supported) way for developers to pass data through the App Store. If we could append params to the App Store links and load those params at app launch, we could simply pass through the porlex grinder product ID and load it when the app was first launched. Apple has done a great deal to support deep linking, but they’ve ignored the critically important first link.

Advantage to passing params: Discount links and app sales

Here’s another scenario: you have a successful company, and you’re launching an iOS app with in-app purchases. You want to offer a discount to you mailing list. Maybe you want to give them 50% off in app purchases. Great idea, but it’s not possible. There’s no (supported) way to identify which users came from your email blast on iOS.

Advantage to passing params: See ROI across devices
Let’s looks at a common scenario for people who sell the same app across multiple app stores. Maybe you sell a productivity app on iOS and Android. You’re in the middle of a Christmas promotion and you want to see how your campaign is doing on Twitter versus Facebook. There’s no way to merge the data, the iTunes half is locked in a silo.

iOS Attribution Approaches

As engineers, having a problem means we build a solution. The solution, in this case, is for ad networks to fingerprint every device that clicks an ad. This can be done using the Apple-regulated IDFA (ID For Avertisers) or by fingerprinting the device using a combination of browser information and the IP address.

Attribution Method: Using the ID For Advertisers (IFDA)

When you click an app ad on Facebook, your unique IDFA is stored on Facebook’s servers along with a reference to which ad was clicked. You include the Facebook SDK in your app so that your app can send Facebook the IDFA of every user that opens your app. When Facebook sees a match, they will respond with “yes, we sent them.” This is a very reliable method, because it’s based on a unique ID that rarely ever changes.

Limited platforms caveat: Because IDFA’s require an integration with each advertising platform, it is unlikely that you will find an SDK that is integrated with industry specific ad platforms, affiliate sites, or any custom ad deals you’ve made.

Waste caveat: Identifying users by IDFA requires requires an unruly amount of code. There are SDK’s on top of other SDK’s and any app advertising on more than one platform ends up with megabytes of unnecessary code. Spread across hundreds of apps on millions of phones, this adds up to colossal waste. A phone’s storage space should be reserved for music, photos, and code that provides value.

Privacy caveat: IDFA’s should not need to exist. This is a unique identifier – specific to your iPhone – that is the same across every app. This ID is passed around an entire ecosystem of analytics providers, ad networks, and individual apps. In many cases is is saved along with geographic information, photos, and other personal information. Unique ID’s don’t exist on desktops and they shouldn’t need to exist on phones. If we passed the params through the app store we could get rid of IDFA’s. That’s a huge win for privacy.

Attribution Method: Fingerprinted Redirect with URL Parameters

Tracking with UTM params is great. What if we could somehow pass an arbitrary list of params from the app store into our app? Well, you can. It’s just not as reliable. The way to do this is to set up a link redirect service, similar to bit.ly. Every time you link to the app store, it goes through this redirect service. When a request hits the redirect service, it stores the IP address of the request along with the user agent making the request and any other identifying information available. That information is used to create a semi-unique device fingerprint.

If the user downloads the app, that same fingerprint data is sent from the app on first launch. If a match is found, the params from the app store listing are passed back into the app, along with the referring URL. This can be used to identify anything you want to track about the source – including discount codes, affiliate markers, and cross-platform campaign names. This concept is further explained in Implementing Deferred Deep Linking on the URX blog and it has been productized by Tapstream. We’re working on a similar methodology at Attribution that we hope Apple will make obsolete.

Reliability caveat: Fingerprinting can break down if many people in the same place download an app at once. Imagine launching an iOS app at SXSW. When a throng of people with the same iPhone, running the same iOS, all download the app from the same cell towers, there’s no way to tell them apart. Compared to desktop computers, iPhones are less unique and hence they are harder to fingerprint. In most cases this is not problematic but it can break down at conferences and events.

There’s also a speed/accuracy tradeoff. Additional fingerprinting information is available via javascript, but loading an actual page and executing javascript code may noticeably slow the re-direct. Nobody wants that.

Apple: just pass us the params

All of this would just go away if Apple passed the params from App Store url’s into apps. No more privacy issues, no more heavy SDKs, and no more developers pulling their hair out. As a bonus, app developers would have the ability to privide a much better first launch experiences with deferred deep links. Everybody wins.

We can’t think of any reason why Apple would choose not to pass the params. Maybe an oversight, or maybe a conscious decision. Either way, we hope they change it.

Apple, please, Just pass the params.