App Campaigns Tuned to Day-7 Value, Not Install Count

The number that decides whether an App campaign earns its budget is revenue per install at day seven, and on most accounts handed to me that number has never been sent to Google at all. The campaign is optimising toward installs, the studio is reporting on installs, and the bidder is doing exactly what it was asked to do: buying the cheapest people who will tap install and never open the app again. This engagement changes what the campaign is asked for. What gets wired before a campaign is touched: Firebase, or your MMP if you run AppsFlyer, Adjust or Branch, sending in-app events into Google Ads as conversion actions with values attached rather than as unvalued counts. On Android, the Play Install Referrer intact so post-install events attribute properly. Deep links registered so a tap on a device that already has the app opens the right screen instead of the store listing. If your MMP contract lists Google as a network but event forwarding was never switched on, that is week one, and it is worth more than everything else in this engagement put together. The bid target: Target cost per install is the setting to leave behind, and I leave it behind in two moves rather than one. First, target cost per action on a downstream in-app event that actually correlates with paying. Tutorial completion is not that event; first purchase, or fourth session, usually is. Then target return on ad spend, once the trailing week carries enough valued conversions for the bidder to model against. Below a few hundred a week the target is decoration, and I will tell you to stay on the action target rather than bill you for a switch that will not hold. iOS is a separate problem, not a segment of the same one: SKAdNetwork gives you a postback, a coarse conversion value and a delay, and no dashboard turns that into user-level return on ad spend. So I work inside the constraint: the conversion value schema mapped to the revenue bands that matter for your title, on-device conversion measurement enabled where it is eligible, and campaign counts kept inside the per-app limits so your own campaigns are not fighting over the same postback. Android and iOS get different targets, different creative rotation and different expectations. I will not average them into one blended cost per install for a board slide. Assets: An App campaign serves what it is given, so an ad group holding one video has one outcome available to it. I brief and organise assets by theme, one theme per ad group, portrait and landscape video, HTML5 where the studio can produce it. Asset performance ratings get read weekly and Low-rated assets retired, but slowly. Pulling assets mid-learning is how accounts end up in a permanent restart. How change is made: Budgets move in steps of about twenty percent, no more than twice a week. Targets and budgets never move in the same week. After a change I wait for the conversion window to close before reading anything, which for a day-seven target means fourteen days, not seven. You get a dated change log, one line per change, with the date that change becomes readable written next to it. Not included: Store listing optimisation, screenshots, keyword fields, ratings prompts. Video and playable production. Apple Search Ads. Incentivised and offerwall traffic, which I will neither buy nor advise on. Server-side event validation engineering, where I specify what is needed and work with your engineers but do not write it. Not for you if: You launched inside the last six weeks and have no post-install event history to model against. Installs and cost per install are the reporting line and nobody upstream will accept a different one. You need the iOS number to look like the Android number. Or your monthly app budget sits under roughly fifteen thousand euros, where the campaign will not gather enough signal for any of this to separate from randomness.