How to Scale a Mobile App With Google App Campaigns: Measurement, Bidding and LTV

What are Google App Campaigns and how do they work?

A Google App Campaign is an automated Google Ads campaign for app installs, in-app actions or pre-registrations: you supply text, images, videos and a bid, and Google Ads assembles the ads and places them. Google Ads Help states that the system tests combinations of your ad text, images, videos and store listing assets and serves the best-performing ads. There is no keyword list and no placement targeting. What you control is measurement, structure, assets and bids, which is why this guide runs in that order.

• Google App Campaigns run across Search, Google Play, YouTube, Display and Discover from one asset set, per Google Ads Help.
• Target ROAS bidding in App Campaigns requires the Google Analytics for Firebase SDK and a dynamic revenue value on the conversion event, per Google’s bidding documentation.
• Google’s setup guidance is a daily budget of at least 50 times target cost per install for install campaigns and 10 times target CPA for in-app action campaigns (source).
• On iOS, SKAdNetwork 4 sends up to three postbacks in conversion windows of days 0 to 2, 3 to 7 and 8 to 35, per Apple’s developer documentation.
• App Campaigns for engagement require at least 50,000 installs, conversion tracking through Firebase or an App Attribution Partner, an audience list and deep links (Google Ads Help).

What should you measure before spending on app user acquisition?

App user acquisition is the paid and organic work of getting new people to install and start using an app. Paid acquisition only pays back when the app reports what happens after the install, so measurement comes before the first campaign. Given only an install event, the bidder will buy installs from people who never open the app twice.

GA4 for apps means the Google Analytics for Firebase SDK inside the iOS and Android builds. Firebase describes Google Analytics as an app measurement solution, available at no charge, with unlimited reporting on up to 500 distinct events the developer defines. The first_open event is created automatically and is the install signal Google Ads uses once the Analytics property is linked to the Ads account. Google’s Firebase and Google Ads codelab shows the step that makes an in-app event biddable: mark it as a conversion in Firebase and import it into Google Ads.

The event schema a scaling plan needs is short, with identical names on iOS and Android and a value and currency on every revenue event:

• first_open: the install signal, created by the SDK.
• An activation event that predicts later revenue, such as sign_up or tutorial_complete.
• The core action the app exists for: first order, first booking, first level completed.
• purchase or in_app_purchase with value, so target ROAS has something to bid on.
• ad_impression with value, for apps that earn from AdMob or another mediation platform.

Sigi Technologies does not run advertising for clients. Sigi builds the apps and can instrument them: adding the Google Analytics for Firebase SDK, defining the event schema above, passing purchase values and wiring deep links before the first campaign runs. On Bix Delivery and Antrak, Firebase is already in the stack for push notifications, so analytics is an SDK addition to an existing Firebase project. That is the whole of Sigi’s claim here: the app side of measurement, not campaign results.

How does SKAdNetwork change iOS measurement?

SKAdNetwork (SKAN) is Apple’s privacy-preserving attribution framework for iOS: instead of a device identifier, the ad network receives aggregated postbacks carrying a conversion value. Google Ads Help describes SKAN as Apple’s framework for measuring app installs in your campaigns and notes that conversion values can have only 64 possible values.Apple’s documentation sets out SKAdNetwork 4: up to three postbacks per attribution, in windows covering days 0 to 2, 3 to 7 and 8 to 35 after install. Only the first postback carries the fine-grained value; the later two carry a coarse value, and the lowest crowd-anonymity tier receives no second or third postback. So the iOS conversion value schema has to encode activation and a revenue band inside the first two days.

Google adds a second iOS signal, on-device conversion measurement, which Google Ads Help describes as measuring installs and in-app actions from iOS App Campaigns while keeping user data private. It needs the Google Analytics for Firebase SDK and a link between the Analytics property and the Ads account, and Google states it is inactive for users in the European Economic Area, the United Kingdom and Switzerland. Google’s iOS best-practices guidance adds three numbers: show the App Tracking Transparency prompt within the first one to three sessions, keep at least 30 conversions per day for the bidding model, and set post-install conversion windows longer than seven days.

How should you structure Google App Campaigns?

Two rules: one app, one platform, one goal per campaign, because iOS and Android have different listings, app IDs and measurement; and consolidate rather than fragment, because each campaign needs enough conversions of its own to learn.

1. One install campaign per platform, optimized for install volume, to establish a baseline cost per install.
2. One in-app action campaign per platform once an activation event fires often enough, on target CPA.
3. One value campaign per platform once purchase or ad revenue is flowing, on target ROAS.
4. An engagement campaign per platform when the app qualifies, with deep links to the screen that brings lapsed users back.

Google’s setup best-practices guide supplies the arithmetic: a daily budget of at least 50 times the target CPI for install volume, at least 10 times the target CPA for in-app actions, and an in-app action completed by at least 10 different users per day, which is the threshold for the second campaign above. When a second campaign is added, the guide says to set its target CPI at least 20% higher than the first. For engagement campaigns, Google Ads Help requires a minimum of 50,000 installs, conversion tracking through Firebase or an App Attribution Partner, an audience list, and a Universal Link on iOS, an App Link on Android or a custom scheme.

Which bidding strategy should you use: target CPI, target CPA or target ROAS?

Google Ads Help defines the App Campaign bid strategies by goal. Target cost per install (tCPI) is, in Google’s words, telling Google Ads the average amount you would like to spend each time someone installs your app. Target cost per action (tCPA) bids on a chosen in-app event. Target return on ad spend (tROAS) sets the value wanted back per unit of spend and requires the Google Analytics for Firebase SDK with an event that passes a dynamic revenue value.

The progression that avoids stalling a campaign is one strategy at a time, only when the event behind the next one is stable:

1. Launch on target CPI or maximize conversions for installs. The goal is volume and a baseline, not efficiency.
2. Move to target CPA on the activation event once at least 10 different users a day complete it.
3. Move to target ROAS once revenue events are stable. Google’s initial tROAS guidance says to reach roughly 30 or more conversions in 30 days before leaving maximize conversions, to hold three to four weeks of conversion value data before migrating from target CPA, and to start from the comparable campaign’s achieved conversion value per cost.
4. Judge every change over a 14 to 30 day window because, as the same page puts it, costs are immediate while conversions take time to report.

Apps that earn from ads have a separate option. Target ROAS for ad revenue optimizes toward users likely to deliver revenue by interacting with ads. Google limits it to ad-funded apps, and the mechanism is the ad_impression event: AdMob or third-party ad revenue is sent to Google Analytics, marked as a conversion and imported to Google Ads. This is where AdMob monetization meets acquisition, because revenue per impression becomes the value the bidder optimizes for.

What creative assets do App Campaigns need?

With no targeting to tune, assets are the main lever. Google’s setup guide gives the slots: up to 10 text assets, 20 images, 20 videos and 20 HTML5 playables per ad group, and recommends using all of them. Text assets should be standalone phrases of varied length with clear calls to action. Images should fill the ad frame. Videos should run 10 to 30 seconds in portrait, landscape and square, because the same campaign serves YouTube, Display and Play and each favors a different shape.

How do you scale Google App Campaigns without breaking ROAS?

Lifetime value (LTV) is the revenue a user is expected to generate over their time in the app, after platform fees. Return on ad spend (ROAS) is revenue divided by the ad spend that produced it, over a fixed window. Payback period is the number of days until a cohort’s cumulative revenue equals its acquisition cost. Scaling means raising spend while the marginal cohort still pays back inside the period the business can finance.

LTV prediction is a modelling problem, and the research literature is useful for how much confidence to place in the number. A 2024 paper, Customer Lifetime Value Prediction with Uncertainty Estimation Using Monte Carlo Dropout, benchmarked on data from one of the most downloaded mobile games in the world, returns a confidence interval with each prediction. The rule that follows: set target ROAS from the lower bound of predicted LTV, not the mean, and widen the margin for cohorts the model has seen least.

• Raise budget in steps and wait a full conversion window before the next step. A campaign judged on three days of data is judged on cost and almost no revenue.
• Keep a second channel. The AppsFlyer Performance Index 2025 edition, which analyzed 16.2 billion installs from 39,000 apps across 88 media sources, reports that Google Ads and Apple Ads remain on top while AppLovin, Mintegral, Meta Ads and TikTok for Business are closing the gap.

For ad-funded apps, monetization design is part of LTV. AdMob’s format documentation lists banner, interstitial, rewarded, rewarded interstitial, native and app open formats and describes rewarded ads as good for monetizing free-to-play users. Format choice sets ad revenue per user, which feeds tROAS for ad revenue through ad_impression.

How do you improve app store conversion so paid clicks are not wasted?

App store conversion is the share of store page visitors who install, and every App Campaign click ends on a store page. On iOS, Apple’s custom product pages allow up to 70 additional versions of the product page, each with its own screenshots, promotional text and previews, reached by a unique URL. Apple reports a 2.5 percentage point average conversion increase against a 1.6% average on default pages, with conversion rate, retention and proceeds reported per page in App Store Connect. On Android, Google Play custom store listings allow up to 50 pages per app, targeted by country, keyword, lapsed and churned users, purchase behavior or a URL parameter. An Ads Traffic listing, once approved, can be selected as a landing page in Google Ads; Google notes it shows on AdMob inventory and not on Play search ads.

What does it typically cost to run Google App Campaigns?

Google does not publish average costs per install. What can be stated is the arithmetic that follows from Google’s setup guidance: at a $2 target CPI, 50 times that is $100 a day per campaign, or about $3,000 a month. The tiers below are planning estimates built from that arithmetic, not quotes.

The app itself is a separate cost. Sigi’s guide to how much it costs to build a mobile app publishes typical-scope planning bands of $40k to $80k for a focused MVP, $80k to $180k for production iOS and Android with payments, and $150k to $350k or more for a multi-surface product. Analytics instrumentation and deep links belong inside those bands.

How do you launch and scale step by step?

1. Define the event schema: install, activation, core action, revenue with value and currency, with identical names on iOS and Android.
2. Add the Google Analytics for Firebase SDK to both builds, log the events, and on iOS implement the SKAdNetwork conversion value schema and the App Tracking Transparency prompt.
3. Build deep links, ship the store release, then link the Analytics property to Google Ads and import the conversion events.
4. Prepare assets to Google’s slot counts, launch one install campaign per platform on target CPI with at least 50 times the target as daily budget, and leave it alone for a full conversion window.
5. Add a target CPA campaign on the activation event at 10 or more users a day, with its target CPI above the install campaign.
6. Move to target ROAS after 30 or more conversions in 30 days and three to four weeks of value data.
7. Fit an LTV model on the first cohorts, set targets from its lower bound, step budget up one window at a time, then add engagement campaigns and a second channel.

Related reading

If the app is not built yet, the framework choice affects how the analytics SDK and deep links are wired; see Flutter versus React Native and the guide to how much it costs to build a mobile app. For a multi-app product that needs separate acquisition for each side, read how to build a delivery app and the Bix Delivery case study. Sigi’s mobile app development service covers building and instrumenting the app. To run the campaigns, hire performance marketers through Sigi, or get in touch about a build that is ready to advertise on day one.