Google App Campaigns Rebuilt Around the Conversion Event

A Google App campaign needs roughly ten conversions a day of the event it bids to before its learning stabilises. That single number decides the account: which event you can afford to optimise for, how many campaigns you are allowed to have, and whether a country gets its own campaign or joins a group. Most accounts we inherit are structured around creative themes and split across ten campaigns, none of which reach the threshold, and every one of which is learning forever. We rebuild them around the event. The first decision: Which event. If your day-30 revenue concentrates in a deep action - an enquiry sent to a landlord, an application submitted, a subscription started - and that action clears the daily threshold, we bid to it directly with target CPA and move to tROAS once the value spread justifies it. If it does not clear the threshold, we bid to the nearest upstream event that does and hold a written argument for why that proxy predicts the deep one, with the correlation measured on your cohorts rather than assumed. Install campaigns exist in our accounts only as a deliberate, dated exception with a condition for switching off. Wiring before spending: Firebase or GA4 events imported as conversions with the right counting and attribution settings, deep links verified end to end on both platforms, and value passed as value rather than as a count. Where you run an MMP, we align its event definitions with Google's before we touch a bid, because two systems disagreeing about what an application submission is will produce a quarter of arguments and no decisions. Assets, treated as a variable and not as output: Text, image, video and HTML5 in the ratios that let Google's asset-level reporting say something. We rotate on evidence: an asset group changes when a performance grouping reads Low against a Good peer with enough impressions, not on a monthly calendar. We do not sell creative volume, and if your current agency's App campaign work is priced per asset, ask them what the last twenty assets changed in cost per action. What we refuse: We do not run App campaigns without conversion tracking we have verified ourselves, whatever the previous agency documented. We do not accept network-level breakdowns as a management tool; Google gives you Search, Display, YouTube and Discover as reporting, not as levers, and a report that recommends action on them is selling you control that does not exist. We do not chase a monthly install number. We will not add campaigns to give an account the appearance of activity, because in this product every extra campaign steals conversions from the learning of another. We do not run App campaigns for apps whose install-to-activation rate is below the point where any bid strategy can rescue the unit economics; we will show that arithmetic before quoting. Who it is not for: Pre-launch apps with no conversion history - App campaigns for pre-registration are a different job and we take that as a separate, bounded engagement. Teams who need daily budget shifts by hand; this product punishes it. Apps below a spend level where a two-week learning period costs more than the insight it buys. How we run it: Changes are batched, not continuous, with a documented waiting period after each so learning can complete and the result can be read. One written note per week naming the change and the expectation, one monthly decision session, and a quarterly holdout - one region paused for three weeks - to test whether the campaign is buying installs you would have received anyway. That holdout has ended campaigns we were paid to run, twice. You keep the Google Ads account, the Firebase project and the billing; we hold named access and every change is in the change history under our own logins.