App Campaigns
By the AdFlint research team · Last reviewed July 2026
Drives mobile app installs and in-app actions across Search, Play, YouTube, and Display, with Google assembling the ads from assets you upload.
You give Google text lines, images, videos, and HTML5 assets plus a bid and a goal; there is no keyword or placement targeting, and the system builds and places ads itself. Advertisers use them because it is the only route to Play Store install inventory. The misunderstanding is expecting manual levers, when the real controls are asset variety, bids, and in-app event tracking.
Key takeaways
- The only real controls are creative assets, the bid target, and in-app event tracking - there is no keyword or placement targeting to adjust.
- Wire conversion tracking through Firebase, GA4 for Firebase, or a mobile measurement partner before launch, or an in-app-action campaign will keep optimizing toward installs by default.
- Expect volatile early performance for roughly the first one to two weeks (longer at low volume) while the campaign accumulates enough conversions to exit the learning period; resist lowering the target bid during that window.
- Run separate campaigns per app store since creative quality, reviews, and tracking reliability differ enough between iOS and Android to make a shared campaign hard to diagnose.
In practice.
An App campaign starts from the app's store listing, not from a website. You point Google Ads at the app on Google Play or the App Store, choose an objective at creation - install volume, in-app action volume, pre-registration for Android, or engagement for re-engaging existing users - and that choice locks the campaign's optimization target for its life; changing objectives generally means building a new campaign rather than editing the old one. Instead of ad groups and keywords, you feed the campaign a pool of assets: a handful of short headline and description text lines, up to 20 images, up to 20 videos (Google will generate simple video variants from images if you supply none), and HTML5 assets for Display inventory. Google's machine-learning layer assembles these into ad combinations on the fly and rotates them across Search, Play Store search and browse, YouTube, Discover, Gmail, and the Display Network, deciding per auction which combination and placement to use. There is no ad group, no keyword list, and no manual placement report to review - the asset pool and the bid are effectively the only inputs.
Bidding runs entirely on Smart Bidding: target cost-per-install for install-volume campaigns, target cost-per-action for in-app-action campaigns, or target ROAS once enough in-app purchase value data exists. None of these work without conversion tracking wired to the app itself, which Google Ads cannot see natively the way it sees a website tag. Installs report automatically from the store connection, but in-app events - purchases, sign-ups, level completions - need either Firebase and GA4 for Firebase on Android, or a mobile measurement partner such as AppsFlyer, Adjust, or Branch posting conversion events back to Google. Skip that step and a campaign set to optimize for in-app actions or ROAS effectively still optimizes toward installs, because that is the only signal it is actually receiving, regardless of what objective you picked in the setup wizard.
Like other Smart Bidding strategies, App campaigns go through a learning period after launch or after a significant bid change, and the threshold to exit it is conversion volume, not time - Google generally wants somewhere around 50 conversions accumulated in the optimization window before performance stabilizes. Below that, cost per install or action swings well above and below target as the algorithm tests combinations. The instinct to lower the target bid the moment early CPI comes in high is usually the wrong move: it throttles the campaign's ability to compete in the auction and gather the data it needs to stabilize, and can leave a low-volume app stuck in a permanent learning state. Adding creative variety generally does more for early performance than adjusting the bid.
The remaining controls are blunt by design: languages, locations, a daily budget, and the bid target. You cannot exclude specific placements, but you can exclude app categories or individual apps and YouTube channels at the account level through content exclusions, and set broad content-suitability settings. Running one campaign per app is standard, and running separate campaigns per platform for the same app is usually worth the split, since store listing quality, review volume, and event tracking reliability commonly differ enough between iOS and Android to make a shared campaign hard to diagnose.
The most common mistake is expecting App campaigns to behave like a Search campaign or Display campaign with visible levers - checking for a search terms report that doesn't exist, or trying to exclude a specific placement that showed up in a delayed, coarse "where ads showed" report. The second is under-resourcing the asset pool: a campaign running on three images and one video has far less for the algorithm to test than one running near the caps. The third is editing bids or assets mid-learning-period out of impatience, which resets the clock. The fourth, and most expensive, is skipping in-app event tracking entirely and then judging in-app-action or ROAS campaigns on a metric they were never actually receiving.
In reporting, judge App campaigns on cost per install or cost per action against the target you set, and watch the conversion volume trend rather than day-to-day cost swings. Treat the in-platform numbers as directional - the real read on quality, retention, in-app purchase value, and lifetime value per install lives in the Play Store console, App Store Connect, or the mobile measurement partner dashboard, not in Google Ads, since Google Ads only reports what the connected event stream sends it.
Ramping a fitness app's install campaign
Suppose you launch an App campaign for installs with a $50/day budget and a $2.50 target cost-per-install. In the first two weeks, while the campaign is still in its learning period, Google delivers 140 installs at an average CPI of $3.10 - about 24% over target, which is typical volatility for this stage.
Rather than lowering the target CPI to force the number down, you add six more image assets and two more short videos to give the algorithm more combinations to test. By week four, average CPI settles to $2.60 - within 5% of target - as delivery stabilizes on the combinations that actually convert.
A month later you connect an in-app purchase event worth $15 average order value through your mobile measurement partner and switch bidding to a 250% target ROAS. On a $1,000 monthly budget, the campaign now needs to generate at least $2,500 in tracked purchase value to hit that target - roughly 167 purchases at $15 each - a number you can only judge once the purchase event is actually feeding the campaign.
App Campaigns compared with
The settings this gets confused with, and how to tell them apart.
Common questions.
How long does it take an App campaign to leave the learning period?
Google typically needs roughly 50 conversions - installs or in-app actions, depending on the objective - accumulated within its optimization window before performance stabilizes. Low-volume apps can take considerably longer to reach that threshold, and editing the bid or assets mid-period generally restarts the clock.
Can I target specific placements or exclude certain apps in an App campaign?
You can't target placements directly, but you can exclude app categories and specific apps or YouTube channels at the account level through content exclusions, and set language, location, and device-level scope. There's no per-placement bid adjustment or manual placement report.
Why does my App campaign only show installs and not in-app purchases?
In-app action and ROAS tracking require SDK-based conversion events wired through Firebase, GA4 for Firebase, or a mobile measurement partner postback. Without that connection, the campaign can only optimize toward the install event Google receives automatically, even if you selected an in-app action goal at setup.
Should I create separate App campaigns for iOS and Android?
Generally yes. Store listing quality, review volume, and event tracking reliability commonly differ enough between the two stores that a shared campaign makes it hard to tell which platform is underperforming, and separate campaigns let each accumulate its own learning data cleanly.
You should not need to know this to advertise.
AdFlint handles the settings for you, inside the Google and Meta accounts you already own.
Try AdFlint free