We’ve shared our opinions of dedicated mobile apps previously. Maybe large brands get away with it, but consumers don’t want an app per business. It’s why aggregators like Google, Yelp, and others exist: engage in useful commerce from one app for tens of thousands of locations.
Yet merchants remain convinced that they should be in the app game. Since it’s impossible to avoid all flavors of tomfoolery, we thought to share some insights.
A passable reason to build an app is to offer a unique experience. For some businesses this has come in the way of exclusive offers – and we don’t mean the promotional kind. Everyone (should) know that In-n-Out has a secret menu. Those who use the app might be privy to unique items, or be aware of something special. This can give customers the feeling of exclusivity.
Another unique experience could be the ability to skip the line or order ahead, but these experiences are now being usurped by any number of third party aggregators so there’s little reason to build an app for this in and of itself. At least no logical reason.
Because really, the point of building an app is to increase revenue or profits, right? We keep saying that’s the only reason companies are in business, but then we watch merchants make decisions we’re convinced they forget this.
So the only reason to build an app needs to be rooted in economics.
There are a few ways to go about calculating the ROI for building an app. First we should understand the cost of our app. Many times tech-illiterate merchants will overpay a huckster to build something for a lump sum. The merchant discovers they want to make changes, and lo and behold, they’re back at the mercy of some provider who will spend 30 minutes making changes but charge the merchant thousands of dollars. So the direct cost of development, plus maintenance and server costs, need to be included in the cost equation. There are a number of ways to build apps – from HTML5 to native, so do your homework.
Now let’s think about the value they create. Apps need to fall into one of these two categories to be successful:
- Increase revenue
- Increase profitability
If your app doesn’t achieve either of these goals, ditch it ASAP. No excuses.
Now, there are a number of ways to skin that first cat. The app could increase customer frequency, create new customers, or increase check averages. Increasing profitability requires merchants to understand COGS and find ways to cross sell higher margin items when customers come in. (This can be appropriately done with some solid machine learning but is outside the scope of apps as merchants consider them.)
How do merchants know if the app is succeeding? Glad you asked.
Merchants should be using the app to collect customer data. This would be emails and contact information. This information should be added to a CRM so the merchant can run marketing campaigns. Campaigns should be traceable, with each of your customers getting a unique code so you can see if they redeemed it. Here are instructions for determining the success of your app endeavors.
Increasing customer frequency
You need to determine if your app customers are coming in more often. The best way to accomplish this is to build two cohorts: customers who are app users, customers who are not. By tracking credit card data, you can determine the average frequency for non-app customers. Newer POS companies are collecting this data and making it available. In fact Upserve (now with Breadcrumb) makes this a selling feature of their software. Any payments processor should be able to do this by the way, but most don’t care to put in the time to add the value.
For app users, either give them redemption codes to track visits or allow them to enter their credit card credentials in the app. From here it’s as straightforward as seeing if app customers are patroning your establishment more frequently than non-app customers. At a high level you should know your check average and be able to determine gross revenue increases from your app users.
As an example, if your check average is $10, and the non-app customer visits once per month they’re worth $120/year ($10 x 12 months). If app customers visit twice per month, that’s $240/year. The difference, $120/year, should be multiplied over the number of app users you have. Let’s say you have 1,000 customers on the app who are showing this level of increased visitation. 1000 * $120/year = $120,000 in new revenue. You can compare this with your annual cost to build and maintain the app to see if it’s worthwhile, but do remember this is only measuring top line growth, not profitability growth.
Creating new customers
Analyzing this is a little trickier. To start, we’d recommend capturing the information of app users, specifically their credit card information. From here you can search through old purchases to see if these customer card numbers have shown up before. If not, there’s a chance the app might be creating new customers.
To be more confident in the answer, you should turn to machine learning. Did sales increase after the app program was created? You’ll never know with 100% certainty (anyone who tells you so is full of hot air), but you could see if sales are increasing with reasonable confidence.
If so, we’d undertake the same analysis as above: how much revenue are these incremental customers driving? Sum this value over a year and determine if it’s larger than the annualized cost of your app efforts.
Increasing check averages
This is very much like the first approach: establish two cohorts and see if there’s a difference in check size between app users and non-app users. However, normalization is more important here. By that we mean you need to take into account the time of the sales relative to a baseline. An example from the restaurant industry will make this clear.
Restaurant check averages at dinner are usually greater because there’s alcohol and higher priced items (steak is more expensive than a BLT sandwich). If all your app users were, for whatever reason, only dining during breakfast, you’d conclude that your app users had lower check averages than your non-app users (which would be an average check from breakfast, lunch and dinner – which we already agreed would skew the check average higher).
This would yield a conclusion based on bad data. So you should use machine learning to appropriately normalize the data to make an apples-to-apples comparison. Find the difference between the check averages of your two cohorts and multiply that by the number of checks from your app users. Over an annualized period, this should be compared to your yearly app costs.
We’ll add one last caveat because merchants struggle to understand the difference between revenue, and profit.
The money you pay to build and support your app comes directly out of your bottom line. When a customer buys something from you, you cannot take that full dollar amount and pay it to an app developer. You have to pay for the item you sold, the labor to produce that item, and additional overhead.
So when you build an app to “increase revenue”, you must be acutely aware that you can generate lots of revenue that still won’t cover the cost of your app:
only profits can be truly written against your app expenses.
You’d think one wouldn’t need to explain this, but merchants struggle with understanding how to calculate the ROI for daily deals, or end up believing they can afford paying third parties 20%+ commissions on orders. It’s these sorts of realities that lead us to wonder why we even bother.
Hope this helps.
Add comment