The technology needed to run mobile user acquisition campaigns at a high level of daily spend (with “high” here defined as in the tens of thousands of dollars or more per day) is myriad and complex. The mobile user acquisition space doesn’t lend itself to end-to-end solutions: each segment of the “stack” is comprised of solutions that require a significant amount of investment into development, in some cases with a specific set of expertise, and often in partnership programs that may not be available to everyone that wants to participate (for example, Facebook’s MMP program for attribution, which is now effectively closed).
Because of this, it’s valuable to map out the elements of a mobile user acquisition architecture to understand its component parts, especially in build vs. buy scenarios where a company is considering building some internal tool that could be outsourced from a third party. But this architecture is also important to behold in its entirety because each segment represents a cost to the developer (either outsourced or developed internally): companies that want to build a user acquisition function from scratch should understand the expense of doing so if their ambition is to reach the level of spend that necessitates the entire architecture.
Of course, some companies opt out, entirely or in part. Some companies choose to work with only a handful of traffic sources and thus don’t need much of the data warehousing portion of the architecture. Others work only with Facebook and are able to run their campaigns almost entirely within the Facebook toolset ecosystem. And some build large teams of data entry professionals in low-cost labor markets and compile all of their data — in some cases, across a large number of networks — into Google Doc files for analysis multiple times per week.
In a recent presentation I gave at the Online Marketing Rockstars festival, I included a map of how some of the component layers from above interact with each other (and how a marketing team interfaces with the infrastructure):
(for a very comprehensive review of the broader mobile growth ecosystem, I recommend the Mobile Growth Stack from Phiture)
Below I break each of these component layers down and provide examples of each:
Front End Analysis: This is the suite of tools that developers use to visualize their data and parse through KPIs. This layer might sit on top of a data warehouse and business intelligence logic engine, or it might encompass all three of those things. Examples here are Tableau for data visualization and simple manipulation and Amplitude for heavier analysis (Amplitude is powered by its own proprietary data warehousing solution). Many developers choose to build this layer of the stack in-house with a simple web-based dashboard interface using a graphical library such as D3.js.
Business Intelligence: This layer usually exists as a behind-the-scenes logic system that breaks down user behavior based on source channel and provides the marketing team with meaningful metrics to optimize its user acquisition campaigns around. The canonical example of this for mobile marketing teams is the automated LTV model, which often exists as an online, “real time” system for estimating LTV by source around various cohort dimensions (geography, device type, etc.). But other API-based services are emerging in this space to help developers estimate characteristics of cohorts based on behavior (eg. upselling, dynamically setting IAP prices, etc.). Examples in this space are Scientific Revenue, Gondola, and Agamemnon (disclaimer: I own Agamemnon).
Data Warehousing: This layer isn’t at all unique to mobile app user acquisition, but it bears representing in the stack given that its the central point of the map above. This is the storage layer in which marketing data (and, usually, in-app behavioral data) is archived and hoarded for analysis. One thing that is important to note about this layer is that marketing data needs a practical and straightforward link to in-app behavioral (read: monetization and retention) data in order for any of the layers above this one to produce actionable results. Behavioral and acquisition data don’t necessarily need to be stored in the same place, or in the same format, but if the layers above this one can’t easily pair these two types of data, building useful user acquisition models (like LTV models) is impossible.
One form of data warehousing specific to mobile advertising is advertising cost data aggregation: the process of connecting to various advertising sources via API and cataloguing account spend (and revenue) on some regular interval for the purposes of calculating per-campaign ROI. Some examples of companies in this space are Singular, Tenjin, and Libring.
Campaign Optimization: This layer includes the products that help companies automate and optimize their marketing campaigns: it includes PMDs (preferred marketing developers for Facebook advertising — software that helps to automate Facebook campaign bidding and management such as Nanigans, Smartly, Adquant, etc.), DSPs (demand-side platforms, which automate bidding on ad exchanges, such as Applift, Pocketmath, and Appnext), and DMPs (data management platforms, which assist developers in advertisement targeting, such as mParticle, Rocket Fuel, and Taptica). There is also an emerging marketplace for third-party data that will at some point in the future fit into this layer.
Attribution: This layer of the mobile user acquisition stack is probably the most mature (given that it is fundamentally oriented around mobile and so none of the products in the space were built to accommodate other forms of advertising) and the most hostile to new entrants, having been more or less conquered by the Big Four attribution platforms: Tune, AppsFlyer, Kochava, and Adjust. At this point, if a developer hasn’t built their own internal attribution system (and very few developers have been given the kind of direct access that is granted in Facebook’s MMP program, so proprietary attribution tools generally cannot cover Facebook), it makes little sense for them to not outsource attribution, especially given that most attribution companies now offer fraud protection products that require a gigantic amount of data throughput to operate properly.
Traffic Acquisition: This layer is the foundation of the stack as the single core function of mobile user acquisition. In the stack, it comprises sources of traffic — that is, companies selling impressions to advertisers — across three categories: Owned Inventory (Facebook, Twitter, Snapchat, Pinterest, Google AdWords, Apple Search Ads, etc.: inventory that is native to and exclusive for the mobile property in which it is sold), Ad Networks (companies that connect publishers and advertisers, such as Applovin, Unity Ads, Vungle, AdColony, etc.), and Mobile Exchanges (such as Smaato, Applift, AOL’s ONE, Twitter’s MoPub, etc.).
This stack construction and the accompanying map of dependencies is not exhaustive, and there are probably many more product and tool variants that can be utilized by mobile advertisers. But for most developers spending healthy budgets on mobile user acquisition, I believe this stack represents the core technological framework that supports and facilitates the identification, acquisition, and analysis of profitable traffic.
Recent