What you actually control

Google App Campaigns takes almost every manual lever away. There is no keyword list, no placement targeting, no audience layer. What remains is budget, geography, the bid target you choose, and the pool of text, image and video assets the system assembles ads from.

This makes the account deceptively simple to set up and unusually easy to run badly. Two accounts with identical budgets and identical products can differ by a factor of two on cost per paying user, entirely because of asset variety and which event the bidding optimises towards.

Choosing the bid target

The single most consequential setting in the account. Optimising for installs buys installs – cheaply, in volume, and disproportionately from people who will never pay. Every step you move the target down the funnel raises the visible cost and lowers the real one.

Which bid target to use, and when
TargetUse whenWhat it buys youSignal needed
Target CPINo downstream events exist yetVolume, mixed qualityInstalls only
tCPA – trial startTrials are instrumented and firingThe usual sweet spot~10 conversions/day
tCPA – first paymentEnough paid volume to feed itHighest quality per user~10/day at that event
tROASPurchase values genuinely varyRevenue weightingStable value data

Source: Conversion-volume thresholds are Google's own published guidance for leaving the learning phase.

Assets are the creative strategy

Since you cannot target, the assets do the targeting. The system decides who to show your app to partly based on what your creative implies about the audience. A pool of near-identical variants gives it nothing to work with, which is the most common cause of a campaign that plateaus and never recovers.

What works: several genuinely distinct video concepts rather than fifteen cuts of one, headlines that describe different reasons to want the product rather than rephrasing the same one, and a deliberate refresh cadence, because asset fatigue in App Campaigns arrives faster than most teams expect.

The iOS problem

On iOS everything above runs through SKAdNetwork. Conversion data is aggregated, delayed by up to a few days, and coarse – you are working with a conversion value of limited resolution rather than an event stream. Campaign counts are limited too.

Practically this means fewer and larger iOS campaigns, longer decision windows, and a conversion-value schema designed to answer one specific question rather than to capture everything. It also means Android and iOS have to be separated completely: same product, different measurement reality.

Questions people actually ask

What can you actually control in App Campaigns?
Budget, bid, bid target type, geography, language, and the asset pool. That is it – no keywords, no placements, no audiences. Which means the asset pool and the choice of bid target are close to the entire job, and accounts that treat them casually underperform for months without an obvious reason.
tCPI, tCPA or tROAS?
Start on target CPI only if you have no downstream data at all. Move to target CPA on a meaningful in-app event as soon as you have roughly 10 conversions a day, and to target ROAS only when purchase values vary enough for it to mean something. Most subscription apps should live on tCPA against trial start or first payment.
How many assets does a campaign need?
Google will ask for the maximum of everything. The useful answer is enough variety for the system to have something to combine – several distinct video concepts rather than fifteen cuts of one, plus real headline variety. Ten near-identical headlines give the algorithm nothing to learn from.
Why did performance collapse after an edit?
Almost any significant change – bid, budget, target, asset pool – restarts the learning phase. Changing several at once means you never find out which caused what. We change one thing, then wait out the learning period, which is usually five to seven days.
How does this work on iOS?
Through SKAdNetwork, which means aggregated, delayed and partial data. Campaign counts are limited and conversion values arrive coarse. In practice that means fewer, larger iOS campaigns and decisions made on longer windows than you would use on Android.
Should Android and iOS be split?
Always. Different attribution, different economics, different conversion behaviour and different creative response. Blending them produces an average that describes neither.

Free

Get your App Campaigns audit

What are you after

One of these. Whichever you pick, no call is required to get an answer.

What should we look at

Pick one or more. Each audit is done by hand, not by a tool.

We cannot audit anything without it.

Genuinely useful to us – half our traffic is impossible to attribute otherwise.

Free · one reply within a working day · no call needed

How this compares to Meta for apps.

Different strengths, different failure modes, and the honest answer for most subscription apps is that you need both. We wrote up where each one wins.