3 reasons to automate your Unity, Applovin, Ironsource, and Vungle user acquisition
Author: Paul Bowen
Mobile app user acquisition is being automated. Facebook and Google have invested heavily in ML-based tools that remove control from user acquisition managers and entrust the data science to figure it out. On Google and Facebook, there are still levers to pull, and if pulled correctly can deliver a significant increase in returns. As growth teams scale spend on Facebook and Google, they see diminishing ROAS returns as CPI increases and the marginal cost of continuing to invest in the platform becomes too high.
It’s at this point, especially as a mobile game that you might look to other ad networks for incremental scale and quality. A recommended source to prioritize that next group of ad networks is the Appsflyer 2019 Power Ranking. This ranks ad networks by the retention that advertisers see after advertising on these ad networks. Given this ranking, it would make sense for gaming advertisers to focus on Applovin, Ironsource, Unity and Vungle.
These ad networks operate two-sided market places connecting sellers (normally mobile games) with buyers (usually but not exclusively mobile games).
Let’s dig into why it’s so important to automate UA on these networks.
- More sub-publishers than you can handle
These four ad networks are each made up of tens, or hundreds of thousands of apps. These ad networks don’t have access to the same first-party data that ad networks such as Facebook and Google own and so their ability to target the right ad at the right user to maximize ROAS is limited.
This means the cost of exploring sub-publishers (subpubs) on their vast networks is borne by the advertiser. This can be extremely challenging for a UA team to manage manually and generally results in an advertiser bidding on a limited whitelist versus trying to manage bidding on thousands of publishers. This significantly limits the scale an advertiser is able to achieve on a specific ad network.
2. It’s hard to bid correctly at the subpub level
All four of these ad networks support subpub level bidding. This means it’s possible to apply a CPI bid to a sub-publisher for users in a specified geography. Below is an example of how that looks.
This gives UA managers the control to modulate bids to hit a defined payback window, eg: day 180 100% ROAS payback. This is extremely hard to do without automation because it’s almost impossible to know what bid to apply at the sub-publisher level. Cohort sizes may be too small and it’s impossible to make sense of prior data with manual tools.
Leveraging user-level LTV projections, it’s possible through automation to generate a sub-publisher level CPI bid. This can be achieved by aggregating the user-level projections at the sub-publisher level. The CPI bid is based on LTV forecasts for users that have historically installed from a specific subpub.
For subpubs with low install count, an automated system can supplement the estimate with a prior LTV forecast composed of users from the same source (eg. Unity), platform (eg. iOS) and geos (eg. US). An intelligent exploration vs exploitation strategy can also be deployed to try periodically try out new subpubs by using the average LTV of all users from that channel, platform and geo as an “exploration” CPI bid.
This automated bid suggestion opens up the ability to bid on significantly more publishers than previously manageable. AlgoLift has seen examples of advertisers scaling from bidding on one ad network from 2,000 publishers to 17,000 publishers within a week period whilst still hitting the ROAS target. This would be unmanageable with a manual process.
3. It’s a complete waste of the UA team’s time
Managing sub-publisher bids is a hugely time consuming and inefficient activity. It’s hard to do manually and generally, the approximations for the subpublisher CPI’s have significant errors that either result in overbidding and wasted spend, or underbidding resulting in a squandered lack of scale.
More articles on the topic: