App user acquisition
An install is the cheapest thing an app campaign can buy, and on its own it tells you almost nothing. We build acquisition around what happens after the install, then send activation, retention and revenue signals back to the platforms deciding who sees the ad.
- App campaigns
- Value signals
- Cohort economics
- Store listing
ADVERTISE
Digital advertising & media
A working advertising practice: strategy, media planning, campaign management, creative testing and reporting across search, social, video and app platforms — run against your own conversion data rather than platform defaults.
App user acquisition is the discipline of buying installs while being judged on something else entirely. The bidding systems on every major platform optimise towards whichever event you feed them, so an account trained on installs will find people who install cheaply and do nothing afterwards. That is not the platform failing. It is the platform succeeding at the instruction it was given, which is why the instruction is the first thing we change.
Mobile measurement does not work the way web measurement does, and pretending otherwise is how app budgets get wasted. Attribution on iOS arrives aggregated, delayed and subject to privacy thresholds; on Android it depends on install referrer data and SDK events that have to be implemented correctly inside the app itself. Neither gives you a clean user-level ledger. Decisions are therefore read at cohort level, against ranges rather than exact figures, and stated with the uncertainty attached.
The levers are also different from web acquisition. A store listing sits between the ad and the install, and a listing that fails to convert quietly taxes every campaign above it. Geography changes the economics more than any bid adjustment will, because price, payment methods and competition vary enormously by market. And the strongest lever is often inside the app: an onboarding step that loses people, a paywall shown too early, a slow first load.
What usually brings people here
These are the states an app and its campaigns are normally in when someone decides the current arrangement is not working.
- Installs arrive, revenue does not follow
- The campaign hits its install target and the revenue line stays flat. Almost always the account is bidding towards the install itself, or towards an event that fires for everyone who opens the app once. The system optimises for volume at the cheapest price, finds users with no intention of paying, and reports a healthy cost per install the whole time.
- Users open the app once and never return
- Acquisition gets blamed for a retention problem. The traffic may be reasonable while the first session is not: a signup wall before any value is shown, a permission prompt with no explanation, an empty state that gives a new user nothing to do. Paid spend then multiplies a leak that already existed, and that leak gets more expensive with every budget increase.
- Platform, store and revenue numbers disagree
- The ad platform reports one install count, the store console reports another, the analytics SDK reports a third, and the billing system recognises fewer paying users than any of them. Each measures a different thing at a different moment, with modelling and privacy thresholds in between. Without a written reconciliation, every review turns into an argument about whose number is real.
- Raising budget breaks what was working
- Performance holds at a modest daily spend and falls apart the moment it is raised. Usually the campaign was living on a narrow pocket of cheap inventory, or the increase was large enough to push the bidding system back into learning while several other things changed at once. Nobody recorded the steps, so the account cannot be walked back to the state that worked.
What the engagement covers
The work runs across the app, the store listing and the ad accounts, because acquisition quality is decided in all three. Scope is agreed in writing; nothing below is assumed.
The in-app value model
Before any campaign is built we decide which in-app actions represent value, where they fire and what they are worth. That model is what the bidding systems will be trained on, so it is written down and agreed rather than assembled from whatever events the app already happens to send.
- Event names, parameters and value definitions agreed before implementation
- Activation defined as a specific in-app action, not a first open
- Purchase and subscription events carrying real currency values
- Trial, renewal and cancellation states modelled separately
- Events verified in a debug view on a physical device before release
- A written map of every event, where it fires and which campaign consumes it
Attribution and platform links
Mobile attribution has to be assembled deliberately from several partial sources. We configure the links, conversion imports and postbacks each platform needs, then check that a real install performed on a real device shows up where it should, once, with the right campaign attached.
- Firebase and Google Analytics 4 linked to the ad accounts that need the data
- SKAdNetwork and AdAttributionKit conversion values mapped to the value model
- Play Install Referrer and deep link parameters handled inside the app
- A mobile measurement partner integrated where one is already in use
- Deduplication between store-reported, SDK-reported and platform-reported installs
- A documented reconciliation your finance side can actually follow
App campaign structure and bidding
Campaign structure decides what can be learned later. We separate by operating system, by geography tier and by the action being bid towards, and consolidate anywhere splitting would starve a campaign of the signal it needs. Bid strategy is chosen per campaign and the assumptions are recorded.
- Android and iOS separated, because their economics and measurement differ
- Install-focused, in-app-action and value-based campaigns kept apart
- Geography tiers split so a strong market cannot mask a weak one
- Asset groups built to give the system every format it is able to serve
- Naming conventions that still make sense to whoever inherits the account
- Budget and bid changes logged with their date and their reasoning
Store listing and conversion rate
The listing converts or the campaign pays for it. We treat the store page as part of acquisition: the screenshots a browsing user sees first, the short description, the preview video, the localised text for each market being bought, and the ratings and release notes that carry more weight than most teams expect.
- Icon, screenshots and preview video briefed against the campaign message
- Store listing experiments run where the platform supports them
- Localised listings for the markets actually receiving spend
- Title, subtitle and keyword fields written for search as well as browse
- Rating prompts placed after a value moment rather than on launch
- Release notes and update cadence treated as conversion surface
Creative built for app inventory
App inventory is mostly video and mostly portrait, served across search, display, video and the store itself. We brief assets from a stated angle, produce variants that isolate one idea, and keep a record of what each retired asset achieved so the same idea is not rediscovered next quarter.
- Portrait, landscape and square variants supplied for every angle
- Opening seconds built to state the app's job immediately
- Screen-recorded product footage rather than stock abstraction
- On-screen text and voiceover localised for the markets being bought
- One idea per variant, so a winner can be explained afterwards
- A creative inventory with results attached to retired assets
Cohort economics and reporting
Cost per install is a shopping receipt, not a result. Reporting is built around cohorts: what a group of users acquired from a given source and market went on to do, how long they stayed, and what they paid once refunds are netted out. The raw data lands somewhere you own.
- Retention curves by campaign, geography and operating system
- Payback read at cohort level rather than on a blended average
- Refunds, chargebacks and cancellations netted out of reported revenue
- Firebase and BigQuery exports into a warehouse under your control
- A written read each cycle, including what the data cannot yet support
How the work runs
The order is deliberate. Spending before the app can report what a user did with it produces expensive data nobody can act on.
- 01
Read the app before the account
We install the app, run the onboarding as a new user would, and look at where the existing funnel loses people. Alongside that we read the store listing, the current SDK implementation and whatever campaign history exists. If the first session is the constraint, we say so before proposing a budget, because paid spend applied to a leaking funnel simply buys the leak more traffic.
- 02
Build the signal path
Events, values and platform links are implemented and verified end to end: fired in the app, visible in the analytics debug view, arriving in the ad account with the right value attached. Where the app needs code changes to emit an activation or purchase event properly, we make them. Nothing scales until an install performed on a physical device can be traced the whole way through.
- 03
Prove in a narrow set of markets
Spend starts in a small group of geographies chosen for signal quality rather than for cheapness, with one campaign type and a hold period agreed in advance. Efficiency is not the goal at this stage. A readable answer is: does this app retain and monetise the users these platforms can find, and in which markets does that hold.
- 04
Expand one layer at a time
Geographies, campaign types and creative angles are added separately, each with a stated expectation and a read-out point. Markets that hold move up a tier and earn their own creative and localisation. Markets that produce installs and nothing else are held flat or closed rather than quietly subsidised by the ones that work.
- 05
Scale with stop conditions written first
Budget rises in steps, with the bidding system given time to settle between them and one meaningful change per step. Every step carries a stop condition agreed before it begins, expressed in retention and post-install value rather than install cost alone. When a step fails its condition we return to the previous state instead of arguing with it.
What happens after the install decides everything before it
An app campaign is a chain of conversions, and every link after the install governs what the platform learns about the links before it. Wherever a step in this chain goes unmeasured, everything upstream of it is bidding blind.
- 01
Impression to store visit
Someone sees the ad on search, inside a partner app, on video or in the store itself. Format, placement and the opening seconds decide whether the tap happens at all, and each surface behaves differently enough to be read on its own.
- 02
Store listing to install
The store page now has to finish the job the ad started. Screenshots, description, video, ratings and download size all sit between spend and installs, and a listing that converts poorly raises the effective cost of every impression bought above it.
- 03
First session and activation
The install is worth nothing until the user reaches the moment the app is actually for. Permissions, signup, first load and empty states either carry them there or lose them, and activation is the first event genuinely worth optimising towards.
- 04
Return visits and day-N retention
Whether a user comes back is the clearest early read on acquisition quality, and it arrives long before revenue does. Retention markers by day, split by source and market, separate the campaigns buying users from the campaigns buying installs.
- 05
The monetisation event
A trial start, a subscription, a purchase, or advertising revenue the user was worth serving. This is where the value model earns its keep, because an event carrying a currency amount lets a bidding system tell a large customer from a small one.
- 06
The value signal returned to the platform
The event goes back to the ad platform as a conversion with its value, inside the window the platform can still use it. That return trip changes who gets shown the ad tomorrow, which is why the last link in the chain governs the first.
How we tier geographies
Markets are not interchangeable, and a blended average hides the ones that are failing. Every geography sits in one of three states, and moving between them is a decision with a written reason attached.
Prove
- A small set of markets where the app already retains something
- One campaign type, one bid strategy, one question being asked
- Localised listing and creative in place before spend, not after
- Held untouched for a full conversion window before it is judged
- Read on activation and retention rather than on install cost
Expand
- Retention and post-install value hold when budget is raised
- Creative angles and localised assets produced for the market itself
- Campaigns split out so the market can be judged on its own terms
- Budget raised in steps, with a settling period between them
- Further campaign types introduced one at a time, never together
Hold or exit
- Installs are plentiful and activation stays flat
- Pricing or available payment methods do not suit the market
- Install profile shows incentivised or fraudulent traffic patterns
- Support and localisation cost more than the market returns
- Closed deliberately, with the reasoning recorded for whoever revisits it
Signals worth sending back to the platforms
These are the events that make a bidding system useful. Each one has to fire in the app, carry the parameters that make it meaningful, and reach the platform inside the window where it can still act on it.
- First open, attributed to the campaign and creative that produced it
- Activation: the specific in-app action showing the user understood the product
- Onboarding or tutorial completion, distinguished from onboarding abandonment
- Use of the key feature the product is genuinely installed for
- Trial start, with the plan and market recorded on the event
- Subscription start, kept separate from trial start so the two can be read apart
- Purchase carrying its real currency value, rather than a flat count
- Renewal, so recurring revenue is not credited entirely to acquisition
- Refunds, cancellations and chargebacks handled so reported value is corrected
- A retention day marker, sent as its own event, for cohorts still active
Tools we work in
These names are descriptive references to products we work with day to day. They imply no partnership, sponsorship, certification, authorisation or endorsement of any kind, and no relationship with the companies that own them.
- Campaign and store platforms
- Google Ads App campaigns
- Apple Search Ads
- Meta Ads Manager
- YouTube Ads
- Google Play Console
- App Store Connect
- Measurement and attribution
- Firebase Analytics
- Google Analytics 4
- SKAdNetwork
- AdAttributionKit
- Play Install Referrer
- Android App Links and iOS Universal Links
- AppsFlyer
- Adjust
- In-app instrumentation
- Kotlin
- Swift
- Google Play Billing
- StoreKit
- Firebase Remote Config
- Crashlytics
- Data and reporting
- BigQuery
- Firebase BigQuery export
- Looker Studio
- SQL
- Python
- Google Sheets
What you are left holding
- A value model the platforms are trained on, written down and verified
- Campaigns structured so a single market can be judged on its own
- A store listing treated as acquisition surface rather than as artwork
- Cohort reporting that follows installs into retention and revenue
- Ad, store and analytics accounts owned by you, with access you control
What people ask before starting
01Can you promise a cost per install?
No, and any figure quoted before we have seen your app, your listing and your markets is invented. Cost per install moves with geography, category, season, competition and the quality of your store page, none of which we control. What we commit to is a value model the platforms can learn from, structured tests, and an honest read of whether the users being bought are worth their price.
02Our app is not instrumented yet. Can you still run campaigns?
We can, but not for long. Campaigns can start on installs while the event work is done, mostly to check that the listing and the creative function at all. Running that way permanently trains the platforms on the wrong outcome. If the app needs SDK or code changes to emit activation and purchase events properly, that work can sit inside the same engagement.
03Why does iOS reporting look so different from Android?
Because it is measured differently. iOS attribution arrives aggregated and delayed, with privacy thresholds that suppress detail when a segment is thin, so campaign-level clarity is limited by design rather than by effort. Android reports install referrer data and SDK events with more granularity. We report the two separately, state what each can and cannot tell you, and never blend them into one tidy figure.
04Who owns the ad accounts, the store listing and the data?
You do. Ad accounts, the Play Console and App Store Connect entries, analytics properties and conversion history sit under your business identity, and we work inside them with the access the job requires. If the engagement ends we remove our access and everything stays where it is: the event implementation, the listing assets, the reporting and the accumulated learning history.
05What drives the cost of this work up or down?
The state of the app's instrumentation, the number of platforms and markets being run, and how much creative and listing work is needed. An app already emitting clean activation and purchase events costs less to acquire for than one where the event model has to be built first. Each additional market adds localisation, creative and review time rather than only a budget line.
06What if users cannot be acquired profitably for this app?
We tell you, and we recommend stopping. Some apps cannot pay for paid installs at their current retention, pricing or monetisation model, and no bid strategy fixes that arithmetic. When the evidence points there, the useful next move is usually inside the product: the first session, the paywall placement, or the reason people stop opening it. We will say so rather than keep spending.
What this work usually connects to
Talk about acquiring app users
Send us the app, the markets you want to reach and whatever campaign history exists. We will read the funnel and the store listing first, then tell you plainly what is worth spending against.
Directcontact@mnfinfotech.com