Oftentimes, mobile SaaS solutions will tout the number of apps using their platform as a point of validation. The implication, of course, is that more is better.
If you’re a potential customer of one of these solutions, this should be your sign to proceed with caution. Accept the rationale that the number of installs demonstrates a platform’s fitness to meet your business needs — including your scalability and stability requirements — and you may be in for a big surprise.
What these platforms neglect to mention is that the mobile app economy has a very, very long tail. And it’s not always true that companies built for little fish will satisfy much bigger ones.
A much better proxy for a platform’s ability to handle scale — rather than how many developers are using its SDK — is the number of installs among highly-used, successful apps.
To understand why let’s start by having a look at this graph from our friends at Branch Metrics:
This chart shows how the top 1,000 apps stand relative to Facebook, the most used-app. The 1000th most popular app (Pixable) has just 0.2% of the adoption that Facebook does. Heavily-used apps are used exponentially more than long-tail apps. The point, as tautological as it may be, is that people don’t actually use long-tail apps.
But that’s just the beginning of the difference. The gap between big apps and little apps is even more dramatic when you consider what happens to most little apps after the initial install.
Consumers are fickle, even promiscuous when trying out new apps. They may experiment with a new app, but if it isn’t significantly better than the one they had before, they will quickly default back to the original. The stat commonly thrown around is that 75 percent of apps downloaded are only used once. While churn impacts both big apps and little ones, these charts from our friends at Quettra show that small apps are disproportionately more susceptible.
The chart on the top shows retention rates over time fromDay 0 to Day 90. The bottom chart highlights retention rates across the various cohorts of apps broken out by size. Notice that day 1 retention for the top 10 apps is 3x that of the apps ranked 101-5000. Day 90 retention for top apps is even more pronounced at nearly 50 percent while the longer tail apps are <10%. The biggest apps not only attract more users but also keep users longer.
As a result, little apps have exponentially less data volume and complexity than the top apps. Not only are their audiences small to begin with, these audiences are way more likely to completely disappear after a single session. A solution built for little apps (and scores upon scores of them) will not be able to handle the spikiness, repeat volumes, and lifecycle engagement scenarios associated with bigger apps — and the volume of data bigger apps demand.
In fact, the difference between minnows and whales in the app world is not just one of degree but also one of kind. They are, in a lot of cases, different species entirely.
Unlike big apps, little apps tend to be the sort (mostly gaming and utility-related) that produce relatively limited customer data. Their signal-to-noise ratio is very low, making it tough to go really deep on any particular customer interaction. How rich are the insights that can be gleaned from someone’s use of a flashlight app, or their interactions with the seventh biggest Taiwanese casual gaming app, for example?
The operating environments (and associated business and technical requirements) surrounding large apps are also of a decidedly different kind from those of their long-tail counterparts. Independent developers who produce these long-tail apps are either just trying to keep the lights on or engaged in a passion project that’s passively managed. On the other hand, enterprise customers not only require security features such as single sign-on, roles-based permissioning, and encryption but also require a completely different platform architecture.
Systems built for the long tail almost always combine lots of small datasets across multiple clients into a single database, primarily to solve for efficiency. Enterprise data solutions have to be architected to physically segregate customer data at the client level and support multiple levels within the account.
For example, once an account is created you need to support the hierarchy of Organization, Account, and App. (The “organization” being the outermost bounds; within the “organization” there can be multiple “accounts,” and “accounts” can have multiple “apps”). For platforms serving the long-tail apps, these are all one and the same.
It’s nearly impossible to build a platform with a bottoms up go to market while trying to meet the needs of the enterprise at the same time. Part of the reason is inherent platform architectures. But also, catering to the needs of big apps vs small apps attracts different types of people (as engineers, data scientists, sellers, customer success managers) and breeds different muscle memories. Just because you are successful with one group of customers does not make you successful with another.
So when choosing whether a data platform can meet your needs, the nature of apps on the platform is the proof point that really matters most. Does the platform in question work with customers whose data is of a similar shape, size, and velocity as yours? Because the way data needs to be accessed is different, and so is the way it gets operationalized.
An old investment saying puts it well: “If you want to know where a herd of cattle is going, you need not interview every steer, only the lead steer.” The same rules can be applied to data platforms.