Google Ads App Campaigns in 2026: Structure, tROAS and Honest Measurement on iOS and Android
Google Ads App campaigns are the least familiar campaign type in the platform: no keywords, no auction-level bids, no placement selection and almost no targeting controls. You hand the system assets, an optimisation event and a cost or return target — everything else is decided by the algorithm. That is exactly why they burn budget so easily: the levers you are used to do not exist, and the ones that do live in your analytics stack rather than in the ads interface.
Below is the working logic for 2026: which campaign goal to pick, how structure works without keywords, when to move to tROAS, which events to instrument first, why iOS and Android data are fundamentally different, and the mistakes that most often break scaling.
What you actually control in Google Ads App campaigns
A search campaign gives you a dozen levers. An App campaign gives you five, and every other decision derives from them.
| Lever | What it decides | Cost of getting it wrong |
|---|---|---|
| Campaign goal | What the algorithm optimises toward: installs, actions, value, pre-registration | Critical — the wrong goal cannot be fixed with settings |
| Optimisation event | Which signal counts as success | Critical — a rare event means permanent learning |
| Target CPI / CPA / ROAS | Your buying economics | High — an aggressive target strangles delivery |
| Assets | What the system assembles into ads | High — a thin asset set cuts you off from inventory |
| Geo, language, budget | The boundaries of the buy | Moderate |
Everything else you do is work on those five variables and on the quality of the data your app sends back into Google Ads.
Four goals and when each one fits
App installs
The simplest objective: the algorithm looks for users likely to install. It fits the launch phase, before you have any behavioural data. The risk is quality — you will get installs, and a meaningful share of them will open the app once and delete it.
Within the goal there are sub-modes: optimise for install volume, or optimise for installs likely to perform an in-app action. The second costs noticeably more per install but delivers a far more alive audience, and with any monetisation at all it is usually the better buy.
In-app actions
Optimisation toward a specific event: registration, first purchase, tutorial completion, trial start. This is the main working mode for any app that does not monetise installs themselves. It requires working event instrumentation and enough event volume.
In-app action value (tROAS)
The algorithm optimises not event count but total value generated in a defined window, typically 7 or 30 days. For subscription and gaming apps this is the only mode that produces real economics, because the spread in user value is enormous.
Pre-registration (Android)
A separate pre-launch scenario for building an audience before release. Useful for games and seasonal launches, but it provides no optimisation signal up front — learning only begins once the app ships.
Google Ads App campaigns structure when there are no keywords
With no semantics to organise around, structure is built on three axes — and only three.
- Operating system. iOS and Android always live in separate campaigns. Different attribution, different economics, different assets, different stores. This is a technical requirement, not a preference.
- Optimisation goal. One campaign, one goal. An install campaign and a purchase campaign do not share a container even when they share a budget.
- Market. Split on economics, not on geography. Tier-1 and emerging markets in one campaign means the entire budget drifts to wherever installs are cheapest.
A working blueprint for a monetising app looks like this:
| Campaign | Goal | Role |
|---|---|---|
| Android — Installs (Tier-1) | Installs likely to act | Fills the funnel, gathers data |
| Android — In-app actions | Key event (signup / purchase) | Core volume of qualified traffic |
| Android — tROAS | Value over 7–30 days | Profitable scaling |
| iOS — Installs (Tier-1) | Installs | Separate economics and measurement |
| iOS — In-app actions | Key event | Launched once data accumulates |
| App engagement (re-engagement) | Return to the app | Retention and reactivation |
The data density logic from ordinary accounts applies here, only harder: the algorithm needs enough weekly events per campaign. We covered the general principles in Google Ads account structure for Smart Bidding — for apps the thresholds sit higher still, because the event is often delayed by days.
Events: what to instrument before launch
An App campaign without configured events is blind install buying. The minimum set to pass into Google Ads, via Firebase/Google Analytics or a third-party MMP:
- first_open — the app was actually opened after install; your basic traffic-quality check;
- sign_up — first real engagement step, usually the event you start optimising on;
- tutorial_complete / activation — the user reached the product’s value moment;
- purchase / subscribe with value and currency — without value, tROAS will not run;
- trial_start and trial_converted as separate events — for subscriptions these mean very different things.
The rule for picking an optimisation event is blunt: it should fire at least 10 times a day per campaign and sit as close to revenue as that allows. If purchases happen three times a week, optimise toward registration and watch purchases as a control metric. The same signal-separation logic as on web is covered in primary versus secondary conversions.
A frequent and expensive failure is double counting, where the same action arrives from both the SDK and a server-side import. The algorithm sees inflated conversion volume and reports a CPA that is not real. How to catch it is covered in duplicate conversions and deduplication.
Moving to tROAS: when and how
In apps, tROAS is not an advanced setting — it is the only honest mode for any product where users are worth different amounts. Turning it on too early, though, kills the campaign.
Readiness markers:
- a value-bearing event has been reporting reliably for at least 30 days;
- at least 50–100 non-zero-value events a month per campaign;
- you know your distributed LTV, not just day-one revenue.
The sequence: let an in-app-action campaign accumulate data first, then launch a dedicated tROAS campaign with a modest target, roughly 20–30% below your actual achieved ROAS for the period, and only raise it in 10–15% steps after the strategy exits learning. Jumping a target by 50% almost always collapses delivery.
On conversion windows: for subscriptions, a 7-day window nearly always tells an incomplete story because trials convert later. The window-selection logic is identical for web and apps and is laid out in conversion windows and conversion lag.
Why iOS and Android never reconcile
This is the main source of friction between media buyers and product teams. The cause is not misconfiguration — the platforms use fundamentally different measurement models.
Android. Deterministic attribution by device identifier works in most cases, data arrives quickly and nearly complete. Variance between Google Ads and internal analytics usually sits in the low single-digit percentages and comes down to time zones and attribution models.
iOS. Since ATT, the main data flow runs through the platform’s aggregated reporting. The practical consequences:
- some conversions arrive a day or more late;
- data is aggregated, so campaign and creative breakdowns are limited by privacy thresholds;
- conversions are modelled, meaning part of what you see is an estimate rather than a counted fact;
- at low volume, detail simply is not returned at all.
What follows practically: never compare iOS campaign numbers one-to-one with internal analytics, and never make iOS decisions on a week of data. The decision horizon on iOS is 14 days minimum.
We covered the equivalent web problem — ad platform versus analytics — in Google Ads and GA4 conversion discrepancies; the “numbers are not obliged to match” logic is the same.
Where Google Ads App campaigns actually serve — and why it matters
A single App campaign buys across five distinct surfaces, each with a different kind of user. Understanding this explains why one blended CPI tells you nothing.
| Surface | Intent type | What it demands from you |
|---|---|---|
| Google Search | Actively looking for a solution — the hottest traffic | Strong text assets and a relevant store listing |
| Google Play | Already in the store, browsing for an app | A strong listing: icon, screenshots, rating |
| YouTube and Shorts | Cold but engaged attention | Vertical 9:16 video; the first three seconds decide everything |
| Discover and Gmail | Passive content consumption | Bold imagery and an offer that reads without context |
| App network (AdMob) | Interrupting someone else’s session | Large visuals and an extremely simple message |
You cannot allocate between surfaces directly — the algorithm decides based on where it finds your conversions cheapest. You influence it indirectly through assets: no vertical video means no Shorts; a weak store listing lowers click-to-install conversion across every surface at once.
Which metrics to watch and which to ignore
The default column set for app campaigns is misleading: clicks and CPI say almost nothing about whether the buy makes money. The working metric set looks like this:
- Install-to-open rate — the share of installs where the app was opened at least once. Below 80% signals low-quality or invalid traffic.
- Activation rate — the share of installs reaching your key event (registration, tutorial). This is the real conversion rate of the buy.
- Cost per activated user — spend ÷ activated users. The metric that lets you compare campaigns and sources honestly.
- Retention D1 / D7 — first- and seventh-day retention. A sharp D7 drop at a stable CPI almost always means the algorithm found a cheaper, worse audience.
- Cohort ROAS — revenue from an install cohort at 7, 14 and 30 days. The only metric scaling decisions should rest on.
What not to do: judging App campaigns by CTR or average position — neither concept meaningfully exists in this campaign type. And do not compare CPI across geographies: a Tier-1 install is more expensive by definition, and the question is always return, not entry price.
Building cohort reporting requires an export from your app analytics rather than the ads interface. The principle matches raw-data work on web, covered in GA4 BigQuery export for paid traffic.
Assets: the one thing you genuinely control
With no targeting controls, creative is your targeting. The system assembles ads from what you upload and serves them across Search, Play, YouTube, Discover and the app network. A thin set means less inventory available to you.
The minimum worth maintaining per campaign:
- 5 headlines and 5 descriptions that differ in message, not just in wording;
- at least 10 images across the main ratios (1:1, 1.91:1, 4:5);
- at least 4 videos including vertical 9:16 and square — without vertical you forfeit all Shorts inventory;
- HTML5 assets where you can produce them; they frequently deliver a noticeably cheaper action.
Review the asset report and replace weak items, but no more than two or three at a time — a bulk swap restarts learning. The creative testing logic matches Performance Max asset experiments.
App re-engagement: the underused channel
Engagement campaigns bring back users who installed but went quiet or never reached the key action. For subscription products this is usually the cheapest revenue available — you are not paying for the install twice.
What you need: audiences from Firebase or your MMP (for example “installed but never registered in 7 days”, “has not opened in 30 days”, “cancelled subscription”), deep links into the right screen, and a separate return event. Without deep links the campaign dumps users on the home screen and conversion falls off a cliff — the mechanics are in deep links and Web-to-App Connect.
Seven mistakes that break scaling
- Optimising toward a rare event. Three purchases a week is noise, not signal. Move one step up the funnel.
- Mixing iOS and Android in one Google Ads App campaign. Impossible to compare, impossible to manage.
- Daily target edits. App campaigns react more slowly than search; every target change is a new 5–7 day learning phase.
- An aggressive target CPI at launch. The algorithm needs headroom; a target set too low means no spend and therefore no data.
- Judging quality by installs. An install is not a result. Measure day-1 and day-7 retention and activation rate.
- Swapping all assets at once. A self-inflicted learning reset.
- Ignoring traffic quality. Incentivised and invalid traffic poisons the model. The general budget-protection principles are in invalid clicks and budget protection.
In App campaigns you do not manage impressions — you manage signal quality. Anything that improves what the system knows about your users improves the buy; anything that adds noise costs money.
Launch sequence from zero: 8 steps
- Connect Firebase or an MMP and verify events actually arrive (test device, real log).
- Link analytics to the Google Ads account and import events as conversions.
- Pick the optimisation event by the “≥10 a day and as close to revenue as possible” rule.
- Build the asset set: text, images, vertical and square video.
- Launch an installs campaign optimised for likely actions, with a daily budget of at least 20–30 target CPIs.
- Do not touch the target for two weeks. Watch retention and activation, not CPI.
- Once you have 100+ events, launch a dedicated in-app actions campaign.
- With stable value and 50+ monetised events a month, add a tROAS campaign.
If the app sits in a category with elevated requirements — finance, health, gambling — advertiser verification joins the technical steps. For teams that need an account with history for those launches, agency Google Ads accounts from PPC Rebels are one route. Before taking over someone else’s app account, run through the Google Ads account audit checklist — most problems surface in event instrumentation, not in campaign settings.
FAQ: Google Ads App campaigns
Can I set keywords in Google Ads App campaigns?
No. Search inventory is matched automatically from your store listing, your assets and user behaviour. You can influence it indirectly through ASO — the title and description in Google Play feed into query matching.
How much budget does an App campaign need?
A workable reference is a daily budget of at least 20–30 target CPIs, or 10 target CPAs. Below that the campaign never gathers enough events to exit learning and you end up making decisions on random data.
Why is my campaign not spending?
Most often the target price is too low or the optimisation event too rare. The second common cause is a thin asset set — the system has nothing to serve on part of the inventory. The third is restrictive geo or audience settings.
What is the difference between optimising for installs and for actions?
The first predicts install probability, the second predicts a specific post-install event. The second mode costs more per install but delivers better retention and revenue. Switch as soon as event volume supports learning.
How often can I change the target CPA or ROAS?
No more than once every 5–7 days, in steps of 15–20% at most. Every change starts a new learning phase; a run of sharp edits keeps the campaign unstable for weeks.
Why is iOS data always lower than in my MMP?
Aggregated attribution and privacy thresholds: some conversions arrive late, some are modelled, and detail is withheld at low volume. Compare trends and ratios, not absolute numbers.
Do I need a third-party MMP if I already have Firebase?
For a single acquisition channel, Firebase is usually enough. An MMP earns its keep once you run several channels and need unified cross-channel attribution and partner-level fraud protection.
Installs come in but activations do not — what now?
Check the technical side first: is the activation event firing correctly, and is it lost on some devices? If the data is sound, it is a traffic-quality problem — move to in-app action optimisation and rebuild assets around the real use case.
Can App campaigns send traffic to a web landing page?
No. The destination is the store listing or a screen inside the app. A combined web-plus-app funnel is handled with deep links and separate web campaigns.
How does re-engagement work on iOS without identifiers?
Audience reach on iOS is limited and volumes will run well below Android. Re-engagement campaigns still work, but plan for smaller scale and evaluate them over a longer window.
How long before I can judge a new campaign?
At least 14 days on Android, and 14–21 days on iOS given reporting delay. Anything read on day three to five is a reading of the learning phase.
Does ASO affect my paid cost per install?
Yes, indirectly but materially. The store listing is your landing page: icon, screenshots, rating and description drive click-to-install conversion. A weak listing makes every paid buy more expensive.