A common pattern of progression for a user acquisition team at an app developer is to start with one person who handles everything, grow the team as revenues increase and / or the company increases the number of products in its portfolio, and build out an analytics architecture to streamline reporting and analysis. The general idea behind this course of evolution is that the team's analytics infrastructure will make people more productive and decrease administrative overhead, and as more and more money is spent on mobile user acquisition, more can be invested into developing tools, making every additional dollar spent more productive than the previous.
This sounds reasonable in theory, but it often doesn't work out this way: mobile user acquisition tends to suffer from diseconomies of scale, meaning, after some point, each dollar spent generates less utility than the one before it; in other words, rather than decrease through improved efficiency, the average cost of spending money on user acquisition increases as the team's budget and headcount scale. Note that this is different than margin on spend; it's the carrying cost of the team and the budget spent on user acquisition combined, as a percentage of revenue.
This diseconomy of scale -- which is the opposite of an economy of scale, which is a cost advantage due to size -- tends to happen for a few reasons. The first is the most prevalent: at some budget size, user acquisition teams have to diversify their traffic outside of the top tier networks and into far less wholesome points of supply. The less-prestigious sources of mobile traffic introduce operational challenges that decrease team efficiency: they're much more susceptible to fraud, they tend to not feature robust APIs for data collection, and they often don't allow for self-service campaign management (meaning everything is run through an AM). All of these issues make working with them tedious and sluggish: campaigns are slow to be optimized and have to be heavily scrutinized for fraudulent installs.
The second reason that this diseconomy of scale emerges is that the diverse range of inputs that an analytics infrastructure needs to accommodate as the team grows and reporting becomes onerous creates highly fragile dependencies that are prone to breaking down. With a one person team spending a budget in the hundreds of thousands of dollars per month, reporting is a one day process: the user acquisition manager logs into their networks once per week, downloads the relevant performance data, compiles it into a workbook, and evaluates spend. But as the budget and team scale and the company builds out infrastructure to automate this, given the state of the mobile marketing services and tools ecosystem, it runs the risk of creating a frail system that breaks down and / or produces incorrect data regularly.
This generates more overhead for the team, not less: now the team, which has become reliant on their proprietary system for managing campaigns, has to not only frequently wait for their analytics system to be fixed, but they have also been tasked with staying in constant communication with the analytics team in order to stay abreast of downtime, errors, and updates.
And a third cause of the diseconomy of scale relates to hiring and team churn (which I also discussed in Why mobile marketing teams fail): there can only be one team lead, and the mobile user acquisition labor market is extremely active, meaning junior team members are very easily poached. This creates a level of recruiting overhead which can be dramatic: constant interviews and CV evaluations can eat up a substantial amount of time. The fairly high level of churn in the mobile user acquisition field at the moment means as a budget scales to require a bigger team, more and more of the team's time must be spent on recruiting -- not just for hiring new headcount but also for replacing churned headcount.